<Glanzmann>
povik: I would not get my hope up, the last 'asahi' branch also had three small hickups which killed the keyboard that never got in after the initial 'merge' for 4 weeks. :-)
<povik>
worth trying...
<povik>
yeah, the warnings fix is obvious
<j`ey>
I wonder if it's easier for markan to just cherry-pick on top of asahi, and then incorporate all the fixes into the proper branches on the next rebase
<jannau>
povik: `git commit --fixup $commit_hash` is helpful for suche commits. `git rebase --autosquash` handles sorts and marks such commits as fixup automatically
<jannau>
I think it is. that's how I work on stuff living in a bits branch. That case is even worse as I can't test the bits branch standalone
<povik>
jannau: i know that workflow, but then there's the cherry-picking j`ey suggests
<jannau>
I'm not suggesting to rebase immediately, the fixup commit can be cherry picked as well
<marcan>
kettenis: I think we should move it under asahilinux, yeah. I can give you commit rights :)
<marcan>
I finally got the kernel ~where I want it, so I finally need to get on the u-boot side of things
<jannau>
not much to do on u-boot side except integrating it into the installer
<mps>
marcan: would it be (in future) possible to integrate m1n1 and u-boot, and does this idea make sense at all
<marcan>
mps: not really, they chain off of each other
<marcan>
jannau: I mostly want to work out how to specify an EFI partition from m1n1
<jannau>
only important missing feature is pcie support for the usb-a ports of the mac mini
<mps>
distros would like to install m1n1+u-boot once (when machine is converted to linux/openbsd) and upgrade kernels with dtbs whenever are mainline kernels are released
<marcan>
we already talked about this
<marcan>
m1n1 will eventually have chainloading from NVMe ability so that can bring in updated dtbs
<marcan>
u-boot will be embedded in the second stage
<mps>
aha, that sounds fine (sorry, didn't read backlog here)
<marcan>
it doesn't make any sense to upgrade dtbs outside of m1n1 because m1n1 has to modify the dtb, and because very often m1n1 will require some more initialization code to make whatever you changed in the dtb work anyway
<marcan>
but we've already very thoroughly proven that chainloading m1n1 is a solid way to add features, so we're just going to make that the normal way
<marcan>
but it's not as easy as "distros upgrading dtbs" either; we're going to need some kind of max-version mechanism, because we don't want a distro to downgrade a m1n1 that was installed by the installer which is newer
<marcan>
so that will require some thought, probably just having m1n1 be packaged in /usr/share or whatever and then have an install script that checks versions and only installs it if it's newer
<mps>
marcan: thanks for good explanation. now I understand better
<sven>
alright, i'm out of ideas why we miss interrupts or don't start commands sometimes without the lock around the writel :/
<sven>
from looking at the ANS firmware there's a hardware FIFO behind that submission doorbell and ANS would panic if we somehow managed to overflow it. I've also written some hack in m1n1 to issues commands from all 8 cores simultaneously and everything worked as expected.
<sven>
there also doesn't seem to be any relationship between the CQ and the NVMMU inval. I can submit commands with the same tag even without advancing the CQ as long as I invalidate the tag inbetween
<sven>
and if you submit the same tag twice without that nvmmu invalidation ANS will panic
bps has quit [Ping timeout: 480 seconds]
bps has joined #asahi-dev
<Dcow[m]>
`
<kettenis>
marcan: I suppose the easiest way is for you to fork https://github.com/u-boot/u-boot and give me access to that such that I can push my asahi branch to that?
<jannau>
one simple way to set the boot_esp variable in u-boot would be to tunnel it through the chosen devicetree node
<jannau>
m1ni could set it from a config payload. modifying all dtbs from the installer seems to be annoying
bps has joined #asahi-dev
<tpw_rules>
jannau: what is the point of this?
<tpw_rules>
confused about why marcan wants m1n1 to be involved with EFI
<jannau>
the installer will create for each installtion a seperate efi system partition which is fully owned by the installed OS
<tpw_rules>
how will you boot off a flash drive or so
<jannau>
u-boot can't provide efi variables so using efi as boot manger will not work
<tpw_rules>
it's currently possible by running commands at u-boot's prompt
<jannau>
that will continue to work
<jannau>
this patch will fall back to the u-boot cmdline if the ESP is not found
<jannau>
also the installer could offer to create the ESP on the flash drive
<mps>
jannau: cmdline or read extlinux.conf?
<tpw_rules>
jannau: i think your patch will break a simple "run usb_boot"
<mps>
tpw_rules: I think 'breaking' u-boot will be still possible with pressing key before timeout expire
<tpw_rules>
yes that is, but if you do "run usb_boot", it will go right back into that code path
<tpw_rules>
so the usb device would have to have an ESP with the correct UUID to be booted from. it would be possible to manually construct a bootefi command but that would be a pain.
<mps>
hmm, yes
<jannau>
it intentionally will only boot from a partition with the correct UUID, otherwise it's just a proof of concept and we can think how we can make manually booting from mismatched ESP easier
<mps>
jannau: currently I boot from usb without ESP
<jannau>
currently the easiest option to override the booth from the cmdline would be to modify boot_esp
<tpw_rules>
how is that easy?
<jannau>
it is easier than the other options
<sven>
it’s a proof of concept not a final patch
<tpw_rules>
wouldn't you have to know and punch in the correct UUID?
<mps>
I prefer u-boot default behavior, find first ESP or partition with extlinux.conf
<mps>
or I don't understand this patch
<jannau>
this is for the u-boot bundled by the installer and required to support more than one linux/*bsd installation without requiring cooperation
<jannau>
you're free to install a m1n1 + u-boot payload configured as you like in the same way you do it now
<mps>
sure
<mps>
but this will confuse end users I think
<sven>
Do you have an alternative then?
<jannau>
define end users
<jannau>
I guess most will not have more than one alternative OS installation and they would expect it to boot like it was installed and not from a random usb-stick
<kettenis>
I'm skeptical about this approach; OS installers will be confused by the presence of multiple ESPs
<mps>
jannau: distro end user
<mps>
jannau: and some (most?) users would like to have rescue system on usb
<kettenis>
I'd rather figure out a way to support EFI variables
<kettenis>
that said, most users will not install multiple Linux distros on their machines
<kettenis>
so if things continue to work as normal if you just create a single "install" in the Asahi installer I don't see a problem
<tpw_rules>
imo the asahi installer should have a base option of making free space on the disk and installing m1n1 + u-boot. then have a separate section where it will optionally create an ESP and rootfs and download a few pre-canned images to it. otherwise, you put an iso on a flash drive or so and boot off that
<jannau>
mps: this is an proof of concept, there can be a convenient way to boot from a mismatched partition
<jannau>
but a usb rescue system is good argument for using a blessed boot partition. I the main installation is also on usb it would only depend on scan order which one is booted
<jannau>
kettenis: if we can get efi vars to work it would be preferable
<tpw_rules>
at the risk of making the boot process even more ludicrous, rEFInd will let you select multiple boot options from one ESP without having to persist anything
<kettenis>
tpw_rules: you are free to do that (is rEFInd a thing on arm64)
<tpw_rules>
yeah
<tpw_rules>
if the goal behind having multiple ESPs is to have multiple linuces on the same machine, then i think one ESP + rEFInd in the fallback boot path is better
<kettenis>
so one thought I had was to have a way for the OS to leave a file behind on the ESP that would then be used to update the EFI variables on the next boot
<kettenis>
if we get something agreed upon and convince the maintainers of the efibootmgr tool to implement it, that would provide a solution for all systems that don't have proper EFI variables support
<mps>
jannau: yes, understand that this is POC and I just thinking aloud what is in my head right now, which doesn't mean I'm right
<kettenis>
jannau: I'm wondering if it is possible to pre-seed the EFI variables in u-boot in a way that makes "bootefi bootmgr" do the right thing
<kettenis>
note that the current u-boot config does not define CMD_EFIDEBUG and doesn't provide a way to save the U-Boot environment
<tpw_rules>
it seems to save something as there is a mysterious "ubootefi.var" file on my ESP
<marcan>
kettenis: invite sent
<marcan>
jannau: yes, we won't touch dtbs from the installer since they have to be generic; /chosen was my plan
<tpw_rules>
refind seems to work well
<kettenis>
marcan: thanks
<marcan>
kettenis: OS installers will need changes to support multiple ESPs, yes; one workaround would be to have u-boot or m1n1 mark the current ESP as the only real ESP, but that's hacky
<marcan>
we still want multiple ESPs for other reasons, like platform firmware comes from the stub which goes in its associated ESP
<marcan>
from the POV of the platform the stub partitions are the OSes; it doesn't *really* make sense to have them all merge back into one ESP
<marcan>
and I don't see how we can support EFI variables sanely including runtime services, which we need for installers to work...
<marcan>
so it seems easier to get distros to read a DT node and look for the ESP there, to be honest
<jannau>
kettenis: can't we use u-boot's standard environment handling for that with a file on the ESP? and then convince the efibootmgr to support this format
<marcan>
yeah, an efibootmgr patch could do it
<marcan>
but I'm still not convinced of the idea of merging everything into one ESP
<marcan>
then what, how does each top-level stub know which sub-OS to boot?r
<marcan>
remember there are good reasons to have separate stubs everywhere
<marcan>
for one distros will want to update their DTBs/u-boot with the chained m1n1 thing
<marcan>
plus using the native bootpicker means a11y support
<marcan>
plus there's the whole how badly are we going to confuse SEP if multiple OSes try to use it under the same boot context
<marcan>
I see too many things becoming a mess letting OSes share an ESP, at least for the "official" install approach
<marcan>
of course people will do whatever they want
<kettenis>
I'm just trying to prevent U-Boot on the M1 to become too much of a special snowflake
<marcan>
well, u-boot doesn't really have to change more does it?
<jannau>
mutliple stubs are also needed for allowing an old dcp driver to continue to work
<marcan>
other than ESP selection
<marcan>
that too
<marcan>
distros will update their kernels separately
<marcan>
you'd be locked into the oldest supported firmware
<marcan>
there's just too much pain down this road, as a default
<kettenis>
if you can achieve what you want with pre-seeded EFI variables, I think that would be preferable to hacking the distroboot script
<kettenis>
sjg1 is trying to get rid of those scripts, so that hack wouldn't be future-proof
<marcan>
certainly, I don't particularly care about the approach
<marcan>
as long as we can use multiple EFI partitions
<kettenis>
note that multibooting OpenBSD is pretty much a non-starter at this point
<marcan>
hm?
<kettenis>
all those APFS volumes and EFI partitions would eat too many entries in the BSD disklabel
<marcan>
lol
<marcan>
that seems like an OpenBSD problem ;)
<kettenis>
sure
<marcan>
anyway, next week is going to be playing around with all this and the installer, that's why I wanted a u-boot repo
<marcan>
I'm happy to try any number of approaches as far as how u-boot actually handles this
<kettenis>
I pushed my asahi branch there; you might want to make that the default branch
<kettenis>
(I don't seem to have the permissions to do that)
<marcan>
done
<jannau>
we should not hack the distroboot scripts, that's just the PoC, we would use our own bootcmd to search and boot the blessed ESP first (reusing as much as possible from the distro boot)
<kettenis>
as with the asahi branch for the linux.git repository, expect this branch to be rebased every now and then
<marcan>
yeah, I kind of assumed we'd be writing our own scripts/bootcmd to some extent anyway
<marcan>
though I'm not a u-boot expert
<marcan>
anyhoo, feel free to shave this yak while I sleep :-)
<Glanzmann>
jannau: Just one thing you should keep in mind: parted and the Debian installer creates partition numbers which are not ordered. If you run diskutil under macos, it will reorder the partitions. That means you can not use the parition as identifier for the esp, but you need another mechanism.
<kettenis>
that's why it uses UUIDs
<kettenis>
marcan: sleep well
<Glanzmann>
kettenis: I just looked at the patch, you're right of course. ;-)
<tpw_rules>
i did some testing with efidebug and it looks like writing ubootefi.var will work
<tpw_rules>
but actually, wouldn't pre-seeding EFI variables require a specific ESP?
<tpw_rules>
like it will read the efi variables off the first ESP it finds, which brings us back to the original problem, right?
<tpw_rules>
jannau: how would you plan to tell u-boot about the blessed ESP?
<jannau>
add a "esp_uuid" property to the "/chosen" node in the dt and set an u-boot env variable based on it
<tpw_rules>
ok. so u-boot could also just use that to pick an ESP that it tries to read its variables from
<tpw_rules>
which is not controlled by the distro bootcmds
<jannau>
yes, it will be a little annoying to recreate all the device scanning distro_bootcmd does
<tpw_rules>
hm? you don't need to
<tpw_rules>
just write the EFI device path to the vars file
<jannau>
for finding the correct ESP to read the vars file
<kettenis>
unfortunately this is an area of active development in u-boot and not necessarily one where there is consensus among developers how things should work
<ar>
speaking of menu-driven selection, there is a heavily-opinionated toward user-friendlyness fork of uboot, https://tow-boot.org/
<tpw_rules>
yeah, i've been eying that too (and talking with the person behind it a lot)
axboe has joined #asahi-dev
<jannau>
kettenis: but not yet implemented/committed in u-boot. it seems to use "/config"
<kettenis>
jannau: that should indeed work with the current status quo
<kettenis>
although as soon as you set the Boot#### and BootOrder EFI variables, those will override the effect of boot_esp as soon as "bootefi bootmgr" runs
<jannau>
I think that's fine since we first need to find the ESP to read the EFI variables
<kettenis>
well, yes, that is the other issue
<kettenis>
I think the EFI variables will be read from the first ESP, even with your change
<tpw_rules>
yes, the segment of code i posted is what identifies the ESP that houses the variables
<tpw_rules>
the distro_bootcmds script doesn't really have anything to do with that