marcan changed the topic of #asahi to: Asahi Linux: porting Linux to Apple Silicon macs | Not ready for end users / self contained install yet. Soon. | General project discussion | GitHub: https://alx.sh/g | Wiki: https://alx.sh/w | Topics: #asahi-dev #asahi-re #asahi-gpu #asahi-stream #asahi-offtopic | Keep things on topic | Logs: https://alx.sh/l/asahi
<zv>
what more is needed than to have (a) built the kernel as mentioned earlier, (2) dd'd a rootfs image to e.g. /dev/disk0p6, (3) linux.py with root=PARTUUID=... ?
<tpw_rules>
yes, the chromium folks semi-deliberately broke it on aarch64 with >4K pages
chadmed has joined #asahi
yuyichao has quit [Ping timeout: 480 seconds]
rolodondo9378[m] is now known as rolodondo[m]
yuyichao has joined #asahi
vmeson has quit [Remote host closed the connection]
<Glanzmann>
than follow quickstart.txt inside /root to install grub properlly
<Glanzmann>
zv: Marcan currently works on the installer. As soon as he pushes, I'll prepare a Debian Image for the installer. Than all of that is completly automated.
<Glanzmann>
zv: I'm also working with Debian Guy on getting the official Debian installer in shape, but at the moment you can also use the official Debian installer. You just need to execute on script, when it fails to install grub from another console to install grub and the kernel.
<Glanzmann>
See Asahi wiki Debian installer page.
<Glanzmann>
Another option that does a friend of mine for 1,5 years: Just install Debian in a VM under macos. It runs with near native performance. Perfect for a build machine and easy to handle.
<Glanzmann>
zv: If you just want it as a build host and do not touch the kernel, in my experience Debian is very stable to run multiple weeks.
<Glanzmann>
zv: But if you want the latest and gratest features, you need to touch u-boot constantly which requires you to but into 1tr. than maybe you want pikvm with a opto coupler to the power button.
<Glanzmann>
At some point we will have m1n1 chainload support, than you can update the device tree without fiddling in 1tr.
<zv>
Glanzmann: thanks. a VM is probably out of the question due to the extremely limited memory and wanting to minimize overhead. I'll look into the script above tomorrow.
<Glanzmann>
zv: If you have any problems, let me know. I made it a hobie to install Debian on these machines.
<Glanzmann>
zv: Oh and you can run Debian stable. The only thing you need 'testing' for at the moment is a newer libinput.
<Glanzmann>
Which is necessary to make the touchpad run.
<Glanzmann>
zv: All the builds that are referenced in the Debian wiki, are 'testing' due to that.
eroux has joined #asahi
<Glanzmann>
My kernel builds are currently all 4k due to the webkit issue but of course in the long run I would like to run 16k pages. And I'm contact with a Debian developer which might help us to get to a 16k kernel on Debian with alle the dependencies.
<Glanzmann>
marcan: Yesterday evening I was working on Linux and used 'halt -p' to shutdown Linux. This morning my macbook air did not turn on. Normally it turns on when I open the lid. But for sure when I press the power button. So the first thing I thought is that, I forgot to specify -p and it drained my battery. But that was _not_ the case.
<Glanzmann>
So I plugged in the charger and tried to turn it on, no luck, than I waited 10 minutes, and tried the power button again, no luck, than I press and hold the power button. The charger was connected in the rear most usb-c port.
<Glanzmann>
Than I unplugged the charger and put it in the front most port. And it made the chime and I was able to power on the system.
<Glanzmann>
Now I checked the battery capacity and it is 76% not it was not power drained.
<Glanzmann>
Did that ever happen to you or someone else. For me. I think it was the second time that happened.
<Glanzmann>
mps: Did you had problems to turn the mbp '14 on with a charged battery?
chadmed has joined #asahi
the_lanetly_052 has joined #asahi
MajorBiscuit has joined #asahi
<marcan>
Glanzmann: I've never seen that
<mps>
Glanzmann: about week ago I had a 'glitch' similar like you but not same. I powered down machine with battery above 95% full. one hour later I opened lid but machine didn't started as always does. I pressed power button but again it didn't started. then I press and hold power button for about 5-10 seconds and it started
<mps>
that was only such 'problem' I had and only once
<Glanzmann>
I think, I had this once with the mini and again with the air. But this glitch this morning I never had before. But again replugging the power supply to the front most port, gave me the charging chime and than I could power on.
<Glanzmann>
marcan: Once you finish the installer, we need to build a fedora installation to unboard Linus.
<as400[m]>
Glanzmann: I bet if you look at Apple forums you will find similar reports.
<Glanzmann>
onboard*
<Glanzmann>
as400[m]: I don't think so, because when you run macos, you never turn off your device.
<Glanzmann>
At least, I never did, you just close the lid.
<as400[m]>
Glanzmann: ok, might be. I don't run macos :D
<as400[m]>
marcan: I noticed that upower does not properly read battery capacity on my mbp 14. Two questions: do you have the same on yours ? Would you like us to file issues like that on github ?
<marcan>
as400[m]: we do not have capacity values in Wh, we have them in Ah.
<marcan>
it seems upower converts that using the design min voltage, which we do provide, in the absence of a design max voltage, which I haven't found yet
<marcan>
there is no correct way to calculate that anyway
<as400[m]>
marcan: ok. Strange it doesn't just read capacity
<as400[m]>
anyway thx
gladiac has quit [Read error: No route to host]
gladiac has joined #asahi
gladiac has quit [Read error: No route to host]
gladiac has joined #asahi
<marcan>
as400[m]: note that macOS does not report capacity in Wh either
<marcan>
either way it's just a number, doesn't really matter if it doesn't match whatever apple uses in their marketing
<as400[m]>
marcan: yeah - just to make things "different" :D
<as400[m]>
although on their site they state that the battery is 69Wh
<as400[m]>
what a mess
the_lanetly_052 has quit [Remote host closed the connection]
the_lanetly_052 has joined #asahi
<marcan>
battery capacites are a lie anyway
<as400[m]>
marcan: why ?
<marcan>
because it's just an estimate
<marcan>
it all depends on discharge rate and a ton of different things
<as400[m]>
ah yes - in that regard - sure
<as400[m]>
But anyway you need to have this estimate to estimate roughly how much time you have left on battery
<mps>
as400[m]: battery calc are mostly (always) heuristic
bisko has joined #asahi
<marcan>
as400[m]: no you do not
<marcan>
the time left estimate is provided by the battery
<marcan>
the Wh number is not needed nor used for anything useful to the user
<j`ey>
as400[m]: SMC gives a value 'TIME_TO_EMPTY' :)
<as400[m]>
I didn't know that. So this is where upower takes the value from to show you how much time is left ?
<marcan>
yes
<as400[m]>
ok - I learned something new today :)
the_lanetly_052 has quit [Remote host closed the connection]
the_lanetly_052 has joined #asahi
<mps>
as400[m]: https://tpaste.us/yped this is lua widget on my computers, and you can see how it calculates battery values
<as400[m]>
mps: thx - will take a look
<marcan>
mps: that code is wrong, it should be using time_to_empty
<marcan>
you do not calculate that yourself, you let the battery do it for you if it will
<mps>
marcan: yes, after seeing you message above I thought to change this script
<mps>
s/you/your/
eroux has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<as400[m]>
It's probably the same with plasma battery widget. AFAIR it let's upower do this and its calculating this value instead of reading it from time_to_empty.
<as400[m]>
lets
<mps>
I think upower and similar things are made to be 'generic' solutions and not taking specifics of different battery models
<as400[m]>
very plausible
<as400[m]>
seems like tech went ahead again and they didn't change it
<mps>
I'm following on #linux-rockchip loooong time discussion about this things
<Glanzmann>
mps: When you correct it, send it to me, I want to try it.
<mps>
Glanzmann: does fvwm supports lua
animus98[m] has joined #asahi
akemin_dayo has quit [Ping timeout: 480 seconds]
eroux has joined #asahi
<Glanzmann>
mps: yes, it does.
chadmed has quit [Remote host closed the connection]
<mps>
Glanzmann: through 'exec' or lua interpreter is integrated in fvwm
<Glanzmann>
I was mistaken. I thought i saw lua support for fvwm but must have it confused, because I just checked out the fvwm2 source code and there is no lua, but there is perl, not that I'm using it.
<mps>
Glanzmann: aha
m42uko_ has joined #asahi
m42uko has quit [Ping timeout: 480 seconds]
skepti has joined #asahi
skepti has quit []
<Glanzmann>
Debian has a package that automatically resizes the root filesystem. I need to test this: cloud-initramfs-growroot
<Glanzmann>
marcan: About having multiple Linux installations. So I assume the uuid of the rootfs will always be same, and the uuid of the esp will be different, correct?
<mps>
mkfs.ext4 have '-U' option to set UUID
<Glanzmann>
mps: My question is actually, can I install three arch linux versions in parallel?
<Glanzmann>
And IIUC what marcan is currently doing, than the answer is no. Because grub identifies the root partition using the uuid which is hardcoded in dd of the ext4.
<tpw_rules>
he said he also wanted to add something that randomizes the UUID on first start after resizing the partition
<Glanzmann>
ah thank you, that makes sense
<Glanzmann>
because having the same uuid on every system is asking for trouble.
<as400[m]>
Glanzmann: you can always use partname or dev
<Glanzmann>
as400[m]: But you probably don't want to.
<mps>
Glanzmann: I prefer PARTUUID but marcan is free to use whatever it thinks is best
<mps>
Glanzmann: bootaa64.efi uses gpt partition number to search for grub and then in grub.cfg 'everything is possible' to set
<as400[m]>
Glanzmann: what I'm saying is - lets not push marcan into users heads and anticipating "what would user want". The installer should be as simple as possible for the time being. That's my two cents.
<Glanzmann>
mps: I use whatever Debian uses which is uuid of the filesystem.
<Glanzmann>
So if marcan change fs uuid on first boot, than I need to isntall grub again.
<Glanzmann>
But that fits my mo anyway because it makes it much easier to build Debian automated. I can currently build the complete Debian artefacts in less than 5 minutes.
<Glanzmann>
kernel, u-boot, m1n1, root filesystem, usb stick and d-i.
yuyichao has quit [Ping timeout: 480 seconds]
<mps>
Glanzmann: I think debian use 'trick' to add something for grub on ESP to find grub files and conf and don't embed gpt part number in bootaa64.efi
<Glanzmann>
mps: On the m1 I prefer fsuuid over partuuid, because macos diskutil sometimes reassign partition numbers which change the partuuid IIUC.
bisko has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<mps>
Glanzmann: makes sense, I don't know how diskutil works on macos
<marcan>
you may have noticed that this project is all about doing things the right way, not about hacking together the first thing that works ;)
<Glanzmann>
marcan: I agree, but I think Debian does it the right way, but whatever meets your standards.
<Glanzmann>
marcan: And probably you want to use the method of the distribution, so that grub updates don't break the boot chain.
<marcan>
yes, I agree that that's a good approach, and I guarantee we can come up with a better solution than "use the debian grub package"
<marcan>
exactly
<tpw_rules>
does debian's grub look for the grub files in another partition?
<Glanzmann>
tpw_rules: See above.
<marcan>
tpw_rules: it configures `prefix` relative to the EFI boot volume, then loads a config file from there to find the real config file by UUID
<marcan>
which is a good idea
<Glanzmann>
tpw_rules: So Debian grub searches for grub.cfg in the same directory. In that grub.cfg it chainloads the real grub.cfg and uses that.
<Glanzmann>
tpw_rules: What marcan said.
<marcan>
Glanzmann: fwiw, you can already achieve this with grub-mkimage, which is what grub-install calls anyway
<marcan>
I'm trying to figure out if there's a way to get grub-install to call it like that
<mps>
on my machine `strings bootaa64.efi | grep ,gpt` gives `(,gpt5)/boot/grub` which is correct
<_jannau_>
mps: correct until the partition numbering changes
<mps>
and that is done by `grub-install --target=x86_64-efi --efi-directory=/boot/efi`
<mps>
_jannau_: yes, but I don't change partition so often ;)
<_jannau_>
also not correct if the grub binary is just copied to ESP during the install from macos
<mps>
sure
<mps>
I just told how it works with separate install media
<mps>
and is it possible to run `grub-install` from macos
<mps>
I think no, but who knows
___nick___ has joined #asahi
___nick___ has quit []
<Glanzmann>
marcan: My plan for Debian after reading how you do things is: Don't use grub-install during image building, boot using a grub.cfg simliar to the one I posted above to boot the first time.
<Glanzmann>
During first boot in the initrd, grow the filesystem and exchange the uuid of the ext4
<Glanzmann>
Than with rc.local or systemd equivalent install grub the debian way.
<Glanzmann>
That reduces complexity a lot.
___nick___ has joined #asahi
<Glanzmann>
You could do the same by patching the grub binary the same way the distro does it using python.
<Glanzmann>
If noone else looks at it, I'll also look at Fedora. So that we can unboard Linus.
<j`ey>
he wont run anything non mainline :p
<marcan>
good thing we're mainlining everything
<Glanzmann>
That's why we need Linus.
<axboe>
linus was balking at the pricing of the laptops, but sounds like he wants to go get a mini
<axboe>
so he'll be receptive to get everything upstream
<axboe>
I too look forward to the day where I don't need a special branch :)
* sven
too
<marcan>
hey, you can boot mainline on t8103, if you don't mind a bunch of missing features
<marcan>
and if you want it on t6000, go shout at the IOMMU maintainer, that's not happening until that gets looked at ;)
<marcan>
(and then I need to submit AIC2 too)
<maz>
yup. I only use mainline on my mini, no extra patch whatsoever.
<marcan>
there's actually not much missing there for a desktop, isn't there? other than wifi and cpufreq
<marcan>
and nvme of course
* marcan
pokes sven about rtkit ;)
<sven>
uh, do I need to do anything there?
<marcan>
just figure out when and how we're submitting it :D
akemin_dayo has joined #asahi
<sven>
phew. I was afraid I was supposed to do something there and forgot :D
<marcan>
but we're getting there, right? what with having 3 consumers already
<marcan>
seems like it's slowly qualifying as decently tested
<sven>
yeah
<sven>
also doesn’t do anything stupid that only works for one iop
<marcan>
yeah
<Glanzmann>
axboe: I mean the macbook air has a reasonable price, IMHO.
<sven>
and I guess nvme and possibly smc are in a shape we could submit
<marcan>
yeah
<maz>
marcan: I'll probably close the door on the irqchip stuff one -rc7 is out, so if you aiming for 5.18, the time is now...
<maz>
once*
<marcan>
maz: nod, let me take care of that tomorrow
<j`ey>
sven: well bindings is the big thing missing I think?
<sven>
I’m still annoyed about that mystery lock that fixed the missed irqs but I’m out of ideas at this point :/
<marcan>
though IOMMU is still kind of a blocker...
<marcan>
sven: wanna poke that?
<sven>
(except for a scary “this doesn’t make sense but we don’t know wtf is going in either”)
<sven>
Marcan: already sent robin an email off list
<marcan>
ack
<axboe>
marcan: where's the last posting of the IOMMU patches? I'm quite happy to help drive some of these forward...
<marcan>
sven should be able to point you at that (the dart-t6000 stuff)
<axboe>
ok
<sven>
it’s been a while, let me check
<marcan>
with AIC2 and that, the kernel will boot on t6000, and I think there isn't even anything strictly missing, it'd be on par with t8103
<marcan>
IIRC the silly bug I found and fixed was already merged
<marcan>
so it's just that series
<axboe>
is he replying in general?
<marcan>
plus AIC2, which I'll send tomorrow
<axboe>
I kind of take the approach of ensuring Joerg provides a reviwed-by and then just send it in yourself for the merge window with Robin on CC
<sven>
Joerg mentioned that he wants to wait for robin to take a look at it
<axboe>
sven: right, but if robin isn't replying...
<axboe>
sven: then you just punt the decision higher up
<axboe>
meeting...
* marcan
sleeps
<maz>
sven: Robin is on Libera Chat if you need to get hold of him (I saw him in #linux-rockchip).
<sven>
I’ll send another reminder to the list tomorrow
<sven>
looks like the only other comment was jannau’s tested-by anyway
<sven>
oh, and Rob’s ack for the dt bindings
the_lanetly_052__ has quit [Ping timeout: 480 seconds]
jx0 has quit [Quit: poof!]
the_lanetly_052__ has joined #asahi
MajorBiscuit has joined #asahi
the_lanetly_052__ has quit [Ping timeout: 480 seconds]
<mps>
hm, I didn't enabled CONFIG_NVMEM_RMEM in my kernel build. should it be enabled for asahi kernel
<mps>
`This driver maps reserved memory into an nvmem device. It might be useful to expose information left by firmware in memory`
<Glanzmann>
mps: I have it as a module, but it is not loaded.
<mps>
Glanzmann: ok, I will also enable it as module
<mps>
thanks
<sven>
don't think we use that anywhere
kloenk has joined #asahi
darkapex1 has joined #asahi
darkapex has quit [Ping timeout: 480 seconds]
MajorBiscuit has quit [Ping timeout: 480 seconds]
eroux has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<jannau>
so far no reserved memory in the devicetree, dcp will probably use reserved memory but things will blow up if another driver grabs it
eroux has joined #asahi
<mps>
heh, very nice, just plugged in something which have headphone jack and saw this with lsusb `Bus 001 Device 002: ID 4c4a:4155 Jieli Technology UACDemoV1.0`
<mps>
and alsamixer see it
<mps>
and found how use mpv with it
<mps>
this device is usb-c type
mrkajetanp has quit [Read error: Connection reset by peer]
<Glanzmann>
That is what happened since the last blog post.
<Glanzmann>
Feature-Support is also up2date.
<sarah[m]>
Glanzmann: Oh, that you
<sarah[m]>
thank*
<Glanzmann>
You're welcome, I'm sure m a r c a n will also write something up once he has upstreamed the kernel stuff and finished the asahi installer.
<sarah[m]>
Can we expect an alpha version or something once there is an installer?
<sarah[m]>
Or is the asahi project not interested in labels like "alpha"
<j`ey>
yeah, its gearing up for that
<sarah[m]>
From the feature support page, it seems linux is daily drivable.
<sarah[m]>
People would mostly be missing out on fast usb connections and audio I think