marcan changed the topic of #asahi to: Asahi Linux: porting Linux to Apple Silicon macs | 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
<chadmed>
noob-tier question, is there a particular technical reason why one might want to expose the UEFI interface on these machines other than to make the Linux experience more PC-like? the only obvious thing I can think of is it might make the life of distro kernel maintainers a little easier, but UEFI is... problematic... and i can see some users specifically complaining about it if made a requirement
<chadmed>
but then again those users would probably have far bigger philosophical issues with this platform than needing to use UEFI
<marcan>
chadmed: what do you think is problematic about UEFI?
<marcan>
UEFI allows distributions to use the same installation process as on ARM SystemReady platforms (and x86), with GRUB and such, which users are used to and things integrate with
<phire>
I think it's more so that any random OS can work unmodified, like the various BSDs
<marcan>
the OS still needs to be modified; *bootloaders* don't, and thus neither does a lot of the installation machinery
<marcan>
that means once we upstream things into the kernel/userspace, distros don't have to do *anything*
<marcan>
you just install m1n1+u-boot, plug in a USB install image, and it just works like on any other machine
<marcan>
(especially if we solve the page size issue)
<marcan>
(which looks likely with sven's magic)
<marcan>
we are going to be using the UEFI implementation that is part of U-Boot; we are not throwing EDK2 on here
<phire>
by *works*, I mean with a basic framebuffer and keyboard via the UEFI interfaces
<marcan>
that's not a thing once you exit bootservices AIUI
<marcan>
only the FB, not the keyboard
<marcan>
and without interrupts and timers you can't really have an OS
<phire>
that will apply to grub too?
<marcan>
no, I don't think grub needs IRQs, nor do most bootloaders
<marcan>
ExitBootServices gets called prior to booting the OS
<phire>
I mean lack of keyboard
<marcan>
GRUB is a UEFI app that runs in the UEFI environment
<marcan>
OSes aren't
<marcan>
UEFI apps can use console/keyboard/etc services
<marcan>
OSes can only use an extremely restricted set of services, basically the framebuffer that is already set up and EFI variable storage
<phire>
I though OSes could continue to use UEFI interfaces after boot as a fallback for not having a driver. Guess I was wrong
<marcan>
nope
<marcan>
you're thinking of ye olde PS/2 SMM emulation nonsense on x86
<marcan>
that's not a thing on ARM
<marcan>
and it runs on that secret hypervisor mode on x86 that has existed since pentium
<chadmed>
yeah no i dont have a personal problem with using it. it is disliked mostly in infosec circles because it is a large and complex interface (generally something youd want to avoid for security reasons) and non-libre. like i said though, these sorts of people likely have far bigger things to complain about with this platform than the UEFI
<phire>
yeah, I don't think I've played with OS dev since UEFI became a thing
<marcan>
chadmed: it's completely libre
<marcan>
all the code is open source, both EDK2 and what we'll be using in U-Boot
<marcan>
and as I said, the U-Boot version is way, way simpler
<marcan>
this is not UEFI *firmware*
<marcan>
this is *U-Boot* that just happens to provide a UEFI *interface*
<marcan>
it's a very different thing
<chadmed>
yeah true
<chadmed>
i did not realise EDK2 and uboots interface were actually libre
<chadmed>
that was _my_ main gripe with it
<marcan>
UEFI's core stuff is completely open source, e.g. the versions that run on KVM/QEMU
<marcan>
you can build them yourself, I have
<chadmed>
i guess other complaints are also PC-centric
<marcan>
of course once manufacturers go and put that on devices they throw in a million proprietary modules
<marcan>
part of which is required by AMD/Intel etc
<marcan>
but this isn't even that, this is a completely separate implementation in U-Boot, which has nothing to do with EDK2 as far as I know
<marcan>
(except maybe like, headers)
<marcan>
(not sure, just guessing)
<chadmed>
yeah ive worked with uboot precisely once but didnt really pay attention to what parts of uefi it actually incorporates
<marcan>
there are of course technical reasons not to like UEFI's design (e.g. the fact that it uses the Windows PE executable format of all things), but those are minor gripes; the reality is that for better or for worse it's a standard well worth supporting
<marcan>
and actually completely openly documented and open source as I said
<marcan>
(in its core)
<marcan>
of course if you want to build U-Boot without UEFI support and install that with m1n1, you are completely free to do that too :)
<marcan>
then you get to roll your own install tooling though, most mainstream distros won't be managing U-Boot configs for you
<chadmed>
well yeah if youre building your own kernel youll be able to load it and the dt straight from m1n1 like is possible now, right?
<marcan>
yeah though I wouldn't recommend skipping U-Boot, because it means you have to go into macos recovery for every kernel update
<marcan>
(or load it via USB, tethered)
<chadmed>
ah yeah true that would get very painful
<marcan>
the point of the m1n1 -> U-Boot -> GRUB chain is that each step of the way gets closer to distro/user-friendly management
<marcan>
sure you can skil everything after m1n1, it's just not... practical
<marcan>
*skip
<chadmed>
yeah and once youre out of boot services theres no difference to the user experience while the machine is running, apart from not having to mess around with macos every time theres a kernel update
<marcan>
yup
<marcan>
not even sure if U-Boot provides runtime services
<marcan>
I should look into that
<marcan>
(EFI variables basically)
<marcan>
I'm guessing not, given it has no way to share storage access
<marcan>
so probably efibootmgr and co won't actually work, need to look into that
yuyichao has quit [Quit: Konversation terminated!]
<marcan>
but at least booting from the default path should
<marcan>
"As of U-Boot v2018.03 UEFI variables are not persisted and cannot be set at
<marcan>
runtime."
<marcan>
yeah thought so
<marcan>
so we might still need to have users manually move grub if installed to a nondefault path, or patch u-boot to recognize "typical" boot paths for distros, to make it properly seamless
<chadmed>
yeah it seems to have once been able to but no longer
yuyichao has joined #asahi
<marcan>
there's no real way for us to support that
<marcan>
since unless we use the M1's actual nvram (which seems reeeeal hairy), we'd have to store variables on disk
<marcan>
and we have no way to share NVMe access with the running OS
<marcan>
OTOH, it would be possible to just patch efibootmgr to access efivars differently, or even if u-boot uses an EFI variable storage as flat files, just bind mount that into /sys/firmware/efi/efivars
<marcan>
that'd be a neat hack
<chadmed>
its probably worth finding ways to avoid exposing the machine's nvram at all costs. someone will inevitably brick their machine if they have the means to do so
<chadmed>
it should probably be a formalised axiom at this point :P
<marcan>
yes, I don't plan to expose the NOR flash at *all* unless I have to
<marcan>
you'll probably need a DT overlay or somesuch to turn it on if I have my way
<marcan>
OTOH I've heard that, in fact, these machines *are* fully unbrickable via DFU even if you manage to nuke the entire NOR
<marcan>
though I'm not sure if I want to try that
<marcan>
I guess that works by grabbing certs/calibration from the mothership? which is neat if it works
tomtastic_ has joined #asahi
tomtastic has quit [Ping timeout: 480 seconds]
malvo has quit [Ping timeout: 480 seconds]
malvo has joined #asahi
PhilippvK has joined #asahi
phiologe has quit [Ping timeout: 480 seconds]
<phire>
that would imply there is some other way of identifying the serial number, other than NOR
marvin24_ has joined #asahi
marvin24 has quit [Ping timeout: 480 seconds]
<chadmed>
getting flashbacks of the pentium iii...
<marcan>
phire: fuses
<marcan>
the chip ID etc
<marcan>
there is definitely calibration data in fuses too
<marcan>
chadmed: *every* modern SoC has a unique serial number
<marcan>
that ship has long sailed
<marcan>
the piii controversy wasn't about that
<marcan>
the piii controversy was about *letting any random unprivileged app read it*
<marcan>
*that* was the problem, not the existence of a serial number
zigmars has quit [Remote host closed the connection]
zigmars has joined #asahi
zigmars has quit [Ping timeout: 480 seconds]
zigmars has joined #asahi
zigmars has quit [Ping timeout: 480 seconds]
zigmars has joined #asahi
<sorear>
can the fuses be used to brick the soc during usage or do they have a "lock out fuse writes" fuse
<amw>
marcan: I'm testing your installer again so I can update the wiki but it's failing with "Unable to determine primary OS" - https://paste.debian.net/1211454/
<nico_32_>
sorear: an "out of factory" fuse?
<sorear>
something like that
<amw>
I think my problem might be because I upgraded MacOS 11.5.2 (was 11.4 when it worked last time)
<sven>
alyssa: :<
aleasto has joined #asahi
<marcan>
amw: it should work; it doesn't like something about the macOS partition
<marcan>
sorear: they usually have locks like that, yes
<marcan>
amw: can you show the APFS volumes on that first partition?
<marcan>
if you have multiple installs in one APFS container it won't work, I need to rearchitect things a bit to fix that
<amw>
disk0s2 returns at 'elif len(vols) > 1:' bit
<marcan>
amw: you have a Linux-V thing going on in your first container
<marcan>
besides the macOS install
<marcan>
that's what's causing it to bail
<marcan>
(I need to fix this to make multiple OSes per container work)
Tom__ has joined #asahi
StupidYui has quit [Ping timeout: 480 seconds]
zigmars has quit [Remote host closed the connection]
zigmars has joined #asahi
<jmcneill>
marcan: U-Boot can provide quite a few UEFI runtime services apart from variable services
<jmcneill>
(whether or not it does depends on build options and target I suppose)
<jmcneill>
NetBSD will use UEFI RT services for RTC access and if PSCI isn't available, for shutdown/reset
<jmcneill>
(although only when booting in ACPI mode today)
<jmcneill>
for shutdown/reset anyway
zigmars has quit [Remote host closed the connection]
zigmars has joined #asahi
zigmars has quit [Ping timeout: 480 seconds]
zigmars has joined #asahi
zigmars_ has joined #asahi
zigmars has quit [Read error: Connection reset by peer]
zigmars_ has quit [Ping timeout: 480 seconds]
zigmars has joined #asahi
zigmars has quit [Ping timeout: 480 seconds]
<sven>
shutdown may a bit tricky. it requires talking to the SMC co-processor which can't easily be multiplexed between the os and u-boot. and the os will probably need to talk to SMC for e.g. enabling wifi
<jmcneill>
yeah common problem with UEFI RT, i think why a lot of vendors prefer other approaches
<jmcneill>
often problematic for i2c based RTCs too
<jmcneill>
for shutdown/reset your OS stack is probably quiescent or crashed by the time you make those calls, so it's not as much of a problem
<sven>
true. i guess uboot could just reinitialize communication with SMC at that point and send the shutdown command
<kettenis>
most runtime services are optional
method_ has joined #asahi
<kettenis>
this includes the ResetSystem() call so we don't have to bend over backwards to implement that in u-boot
<kettenis>
same holds for GetTime()/SetTime()
Method has quit [Ping timeout: 480 seconds]
Andalu30 has joined #asahi
<kettenis>
Not being able to set the BootOrder variable and others isn't really an issue if you don't install multiple OSes that boot via UEFI as the removable media boot flow will just work
<kettenis>
I believe most of the arm64 linux distros that use the UEFI bootflow can handle that already and so can OpenBSD
<marcan>
kettenis: I don't know if this is different on arm64, but at least on x86 it's common to put grub on a nonstandard path and rely on BootOrder to point to it
<j_ey>
what's the benefit over uboot loading grub?
<j_ey>
s/over/of/
<marcan>
distros being able to use the usual kernel management stuff
<j_ey>
oh, distros might be using grub..
<j_ey>
yeah ok
Andalu30 has quit [Ping timeout: 480 seconds]
jvoisin has joined #asahi
lanodan has quit [Quit: WeeChat 3.1]
zigmars has joined #asahi
lanodan has joined #asahi
aleasto has quit [Remote host closed the connection]
psykose has quit [Remote host closed the connection]
zigmars has quit [Remote host closed the connection]
zigmars has joined #asahi
zigmars has quit [Remote host closed the connection]