<marcan>
ElvishJerricco[m]: the kernel will support all prior supported versions of the OS-tied firmware, forever
<marcan>
the kernel will also support all prior device trees (modulo missing newer hardware of course) *once upstreamed* but we make no guarantees about kernel/devicetree compat until that happens
<marcan>
which is why the Asahi reference distro is set up with a script that updates m1n1 stage 2 with the kernel's device trees when the kernel gets updated
<ElvishJerricco[m]>
marcan: That's good news. Does the firmware that we copy into /lib/firmware need to be from the same version as the currently installed macOS stub?
<marcan>
the installer puts the currently installed stub's firmware in the ESP, so it is expected that it will always match and a distro should always copy it. whether mismatches will cause a problem in the future, only Apple can say. right now given the kinds of firmware involved in that tree, they *probably* won't.
<ElvishJerricco[m]>
Ok, but I'll make sure to plan around trying to match the macOS stub
<marcan>
that's also why the reference distro has a boot-time script to update the copy in /lib/firmware, and there's a manifest file you can check to see if anything changed since last boot
<ElvishJerricco[m]>
Cool
<ElvishJerricco[m]>
Thanks!
<marcan>
currently we only know of four things that go in /lib/firmware: wifi (only one done so far), bluetooth, video decoder, USB xHCI chip for some machines
<marcan>
other than video decoder those are all non-apple and it's hard to imagine how they could interact with other per-OS firmware (and system firmware should always be backwards compatible)
<marcan>
video decoder is fairly small and may be entirely self contained
<marcan>
so I'm guessing mixing and matching won't cause a problem, but I'd rather plan for not doing that
<ElvishJerricco[m]>
Interesting. I'm curious, what causes a piece of firmware to require being loaded out of /lib/firmware by the linux OS instead of the previous boot stages?
<marcan>
when Apple doesn't do it for us
<ElvishJerricco[m]>
Oh, so in theory m1n1 could do it, but we just have linux do it since linux already can
<ElvishJerricco[m]>
I'm guessing?
<marcan>
it could, but it'd still have to be read off of the ESP since those firmware blobs originate in either the XNU kernel or filesystem, and therefore we have to put them somewhere in the installer either way
<marcan>
and then there's potential issues with having to reload firmware after sleep/resume
<ElvishJerricco[m]>
Ok that makes sense.
<marcan>
there's also SEPOS which will be a funny special case. that one will get passed to the kernel via a memory region from m1n1.
<marcan>
Apple puts that one in memory for us but the kernel still has to load it into the coprocessor
<ElvishJerricco[m]>
So alright, plan will be to have the firmware match the macOS stub. The "NixOS way" will probably be to have the user specify which version they need, and automatically download that, rather than copying existing files from the ESP (NixOS tries to be stateless outside of your config file), but that's not strictly necessary. I'll see what ends up making most sense.
chengsun has quit [Ping timeout: 480 seconds]
<marcan>
that one is system firmware too, and *must* be synchronized or everything explodes, so that's the only sane way to do that
<ElvishJerricco[m]>
Oh, that seems a bit odd, but easy enough to work with
<marcan>
consider that the stub partition is stateful anyway
<marcan>
and the ESP is too
<marcan>
you should consider that state part of world state and always synchronize it on boot
<marcan>
if you need to avoid literally writing to the root filesystem, you should have a userspace firmware loader that can read the files off of the ESP directly, or use a ramdisk, or whatever
<ElvishJerricco[m]>
Well the stub partition is; NixOS usually controls the ESP with automation (and little hacks if you want other OSes in your boot loader menu).
<marcan>
sure, but the files the installer puts there are just a mirror of what's in the stub partition anyway, and intended to represent such
<marcan>
there is other useful state there too
<marcan>
like seed credential IDs needed to transfer ownership to a new SEP user down the road
<marcan>
so if you plan of owning and wiping everything in the ESP partition you don't control, well, you're going to have a bad time the way our installer is currently architected
<marcan>
I expect people to manage their stuff in there but not to literally take over the entire partition
<marcan>
u-boot may want to keep state there down the road too
<ElvishJerricco[m]>
Yea we don't fully wipe the ESP; we just configure our boot loader automatically
<marcan>
sure
<marcan>
but then you can still consider the firmware there to be part of system state
<ElvishJerricco[m]>
That's plausible; we're definitely trying to move toward EFI based booting on ARM in general, and just relying on the user to properly configure an EFI environment like u-boot outside of NixOS. We currently have... a lot of hacks because we don't do it that way
<ElvishJerricco[m]>
So I was just hoping to keep the basic assumptions about what the user will have configured the same; i.e. the EFI environment, not necessary firmware.
<ElvishJerricco[m]>
It should be workable either way, and I know just who to talk to in the NixOS rooms about what they think we should do :)
<marcan>
the firmware mechanism we have is intended as a generic thing any platform could use; there's just no good standard like that yet (other than what Android does which is their own thing)
<marcan>
it's just unfortunate we can't just redistribute those blobs and put them in linux-firmware (and have guarantees compat won't be a problem)
<marcan>
but either way there is clearly a use case for "Linux needs firmware synchronized with platform state" even if that's not usually what happens now on desktop systems
<marcan>
so I don't think what we're doing is particularly strange :)
<ElvishJerricco[m]>
Yea. We have some automation for nonredistributable firmware in NixOS, but it basically relies on the assumption that we can have the firmware in a content-addressed path on the root fs.
<ElvishJerricco[m]>
One big reason for this is that we can do rollbacks to old OS configurations from the boot loader. But I guess in principle that would be flawed for firmware like this, which you probably don't want to rollback
<marcan>
exactly
<marcan>
on Apple Silicon a "true" rollback would involve rolling back the stub too, but, well
<ElvishJerricco[m]>
Yea ok. I'll think on it and talk to some NixOS people about it, but that's a fairly convincing point
<marcan>
let's just say that's not a can of worms you want to open right now, and the platform is kind of designed to forbid that, by design (security)
<marcan>
so you'd need two volumes in one stub partition showing up as two OSes
<marcan>
and both getting kmutiled ping-pong etc
<marcan>
fun thought experiment for the future but... let's not go there right now ;)
<ElvishJerricco[m]>
Yea I have absolutely no intention of trying to automate the macOS stub from NixOS; we're just going to assume the user configured that
<marcan>
I don't know about NixOS internals but I imagine it shouldn't be too weird to automate it; there's plenty of approaches for not touching the root filesystem directly (tmpfs+overlayfs, just a tmpfs and a firmware loader looking in an alt path, etc)
<marcan>
I mean the regular firmware handling
<marcan>
if the specific way we do it right now (tarball+manifest) is suboptimal it's early enough to consider doing it a different way
<marcan>
main reason for the tarball is so we can have symlinks
<marcan>
though actually we made them hardlinks now IIRC
<ElvishJerricco[m]>
No handling that should be fine. We can just add some scripting to the boot process that copies the firmware to a usable place (that's how tpw_rules did it in his nixos-m1 repo). The rootfs isn't readonly or anything like that, we just address *almost everything* by paths hashes in the names instead of normal FHS paths; we can still have things at more mutable paths.
<marcan>
cool :)[
<marcan>
-[
xfim has joined #asahi
xfim_ has joined #asahi
millenialhacker has joined #asahi
xfim has quit [Ping timeout: 480 seconds]
millenialhacker has quit []
millenialhacker has joined #asahi
derzahl has quit [Ping timeout: 480 seconds]
derzahl has joined #asahi
bienjensu[m] has joined #asahi
hromwootig has quit [Ping timeout: 480 seconds]
Ry_Darcy has joined #asahi
hromwootig has joined #asahi
Ry_Darcy has quit [Remote host closed the connection]
Ry_Darcy has joined #asahi
Bai-Chiang has quit [Ping timeout: 480 seconds]
millenialhacker_ has joined #asahi
millenialhacker_ has quit [Remote host closed the connection]
jluthra has quit [Remote host closed the connection]
the_lanetly_052 has joined #asahi
jluthra has joined #asahi
Ry_Darcy has quit [Remote host closed the connection]
Ry_Darcy has joined #asahi
Ry_Darcy has quit [Remote host closed the connection]
millenialhacker_ has joined #asahi
millenialhacker_ has quit [Remote host closed the connection]
bps has joined #asahi
hromwootig has quit [Ping timeout: 480 seconds]
hromwootig has joined #asahi
Ry_Darcy has joined #asahi
Ry_Darcy has quit [Remote host closed the connection]
Ry_Darcy has joined #asahi
hromwootig has quit [Ping timeout: 480 seconds]
hromwootig has joined #asahi
hromwootig has quit [Remote host closed the connection]
bps has quit [Ping timeout: 480 seconds]
derzahl has quit [Ping timeout: 480 seconds]
pilonsi_ has joined #asahi
pilonsi has quit [Ping timeout: 480 seconds]
darkapex1 has quit [Ping timeout: 480 seconds]
Ry_Darcy has quit [Remote host closed the connection]
al3xtjames3 has joined #asahi
al3xtjames has quit [Read error: Connection reset by peer]
al3xtjames3 is now known as al3xtjames
Ry_Darcy has joined #asahi
darkapex1 has joined #asahi
Bai-Chiang has joined #asahi
darkapex2 has joined #asahi
darkapex1 has quit [Ping timeout: 480 seconds]
Bai-Chiang has quit [Quit: Konversation terminated!]
Bai-Chiang has joined #asahi
Bai-Chiang has quit [Ping timeout: 480 seconds]
Bai-Chiang has joined #asahi
bps has joined #asahi
MajorBiscuit has joined #asahi
xfim_ has quit [Ping timeout: 480 seconds]
xfim has joined #asahi
Ry_Darcy has quit [Remote host closed the connection]
Gaspare has joined #asahi
<xfim>
exit
xfim has quit [Quit: leaving]
xfim has joined #asahi
Gaspare has quit []
Gaspare has joined #asahi
Gaspare has quit []
MajorBiscuit has quit [Quit: WeeChat 3.4]
MajorBiscuit has joined #asahi
Gaspare has joined #asahi
Gaspare has quit [Quit: Gaspare]
MajorBiscuit has quit [Ping timeout: 480 seconds]
bps has quit [Ping timeout: 480 seconds]
bps has joined #asahi
nicolas17 has joined #asahi
MajorBiscuit has joined #asahi
bps has quit [Ping timeout: 480 seconds]
the_lanetly_052 has quit [Ping timeout: 480 seconds]
MajorBiscuit has quit [Ping timeout: 480 seconds]
MajorBiscuit has joined #asahi
on88ip[m] has joined #asahi
MajorBiscuit has quit [Quit: WeeChat 3.4]
<ElvishJerricco[m]>
I guess the first thing is going to be packaging the installer with Nix-on-macOS. Don't get me wrong, I'm no stranger to `curl | sh` :P But it seems like it'd be nice to have it packaged with an actual package manager on macOS
xfim has quit [Ping timeout: 480 seconds]
kov has joined #asahi
lounge-user has joined #asahi
lounge-user is now known as AoV
MajorBiscuit has joined #asahi
lgarylmtdlt^ has joined #asahi
MajorBiscuit has quit [Ping timeout: 480 seconds]
MajorBiscuit has joined #asahi
vmeson has quit [Ping timeout: 480 seconds]
touttti has joined #asahi
MajorBiscuit has quit [Ping timeout: 480 seconds]
millenialhacker has quit [Quit: Konversation terminated!]
xfim has joined #asahi
psykose has quit [Remote host closed the connection]
psykose has joined #asahi
<kaprests>
How is the notch on the 14 and 16 inch macbook pro's handled? Is it just up to the window manager or DE how to deal with it?
<j`ey>
for now the framebuffer is just made a bit smaller
touttti has quit [Remote host closed the connection]
<marcan>
there's an issue in progress for figuring out how to deal with notches and the like in Wayland, but for now there is no support
<marcan>
once there is some agreed mechanism we'll expose it (optionally), until then we'll hide it
<marcan>
without the notch the screen is an even 16:10
<kaprests>
I see makes sense. Is there any work for supporting it in X? And what are the difficulties? I seems simple to just place a status bar up there, with room in the middle, but I suppose there would have to be some way to deal with full screen mode
<j`ey>
the status bar would still have to know to not place anything in the middle
<kaprests>
Yea, I guess 16:10 is still good, so not a major concern
<kaprests>
j'ey: Yea, but with a 'static' layout that should be no problem right? Say a simple polybar with no middle-modules and fixed with modules on the sides?
<kaprests>
fixed width*
<j`ey>
kaprests: yeah, you can do some work arounds, but the plan is to make wayland or whatever aware of it :)
<kaprests>
Yea, I guess it's better and more "safe" to do it that way, but would be cool if the whole screen could be exposed in some way for those who want to play around with the workarounds
<j`ey>
you can rebuild m1n1 and remove the notchless function, if you wanted
<kaprests>
Oh aha, if it's not too difficult maybe I'll give it a try. Will be getting the 14 inch from work in a couple of weeks :)
<j`ey>
get_notchless_fb in src/kboot.c, I think it should just be as easy as not calling that function
<kaprests>
Noted. Thanks!
vmeson has joined #asahi
<mps>
mbp 2020 doesn't have notch?
<j`ey>
nop
<mps>
aha, that is why I don't see it, :) thanks
<j`ey>
it doesnt have a notch, but has touchbar, the 14/16" have a notch, but no touchbar
<j`ey>
you cant win :P
<mps>
touchbar is ugly thing
<mps>
I'm happy not having it
<j`ey>
mps: which m1 do you have now?
<mps>
I mean, I have it but is 'dead'
<mps>
j`ey: mbp 2020
<j`ey>
oh
<kaprests>
Oh so you meant not having it as in "not having it in Linux" :p
<mps>
though with only 8GB ram, damaged one have 16GB
<mps>
kprasadvnsi[m]: right
<mps>
when I used macos for some time (luckily not long) lights on toucbar irritated me too much
<ChaosPrincess>
at least they found the light and turned esc from a touchbar area into a physical button