<kode54>
they posted a reply to your review already
<kode54>
"works for me" seems to be the general point, and that it works for T2 Macs, and that they've never even tested M1
<marcan>
yeah, well... "works for me" doesn't cut it for Linux kernel submissions, unfortunately
X-Scale` has joined #asahi-dev
X-Scale has quit [Ping timeout: 480 seconds]
kov has quit [Quit: Coyote finally caught me]
PhilippvK has joined #asahi-dev
phiologe has quit [Ping timeout: 480 seconds]
<kode54>
no shit
<kode54>
I was just stating what general bonehead said
<kode54>
I know that public contributions to pretty much any respectable project require that they work properly, not just for the submitter
<kode54>
when I saw that the patch included a function for getting mapping registers, I didn't realize it was a large switch block inside of a function that was also included in the patch
<kode54>
at least now if that person wishes to volunteer their hardware, you know you have someone who can test if T2 works
<kode54>
unfortunately, it doesn't look like any of that patch automates getting the board info from the ACPI tables, either
<kode54>
or does it?
<kode54>
guess that's another thing someone will have to implement, if a T2 owner is willing to donate a dump of their ACPI tables
<kode54>
as if it would be useful to write drivers without having hands-on with the test hardware
<PthariensFlame[m]>
I have a T2 model and would be willing to contribute, although I might have to be walked through some things.
method_ has quit [Ping timeout: 480 seconds]
Method has joined #asahi-dev
<chadmed>
bruh did the submitter really just answer marcan's criticism with "no its fine lol"
<kode54>
seems like it
<chadmed>
oh gosh he even defends ACPI-specific platform discovery
<chadmed>
s/he/they
bps2 has quit [Ping timeout: 480 seconds]
useableporthole has quit [Remote host closed the connection]
<sven>
they are just new and not very experienced
<chadmed>
yeah, though idk how much slack is acceptable here given that its not really unique to linux that "works for me mate" isnt an acceptable QA test
<j_ey>
if no-one else is at least sending the patches...
<maz>
you can always explain what is expected from a submission. they are of course free to ignore your suggestions, but you are also free to ignore them altogether in athat case.
<marcan>
kode54: I actually have a friend with a T2 mac so I could test there fairly easily too
<marcan>
chadmed: the thing is the corellium patch was meant for M1 but doesn't do any of the DT things it should be doing, so it's actually doing neither of the M1/DT nor the ACPI stuff it should be
<marcan>
a proper patch ideally needs to implement both DT and ACPI support so it works on both platforms
<sven>
at least that submission might be a good starting point for the firmware name discussion
<marcan>
yeah, I hope some other folks chip in on the firmware story
<marcan>
it was good to bring that up
<marcan>
if nobody does I'll just make something up and submit it :-)
<marcan>
btw, does anyone know of a functional userspace ext4 implementation? It would be really convenient if the installer could poke around the linux rootfs, e.g. to deal with the firmware story
<marcan>
the alternative is to have a firstboot thing or some firmware copy script that copies it from e.g. the ESP, but that's a bit more annoying since it needs distro integration to a greater extent
<marcan>
wonder if any of the incompatible features are common these days in default filesystems
<maz>
marcan: fuse-ext2 ?
<marcan>
would have to dike out the fuse part, but maybe?
<marcan>
looking at my normal rootfs (which should've been mkfs'ed last year) all the features are compatible with lwext4 as far as I can tell
<marcan>
so that might be a good option
<marcan>
I just need to wrap it in a python module or something...
<marcan>
oh wait, but can I even hit raw block devices in 1TR?
* marcan
tries...
<marcan>
yeah, works fine from python (at least for unmounted volumes)
<marcan>
and diskutil can create partitions without formatting and arbitrary GPT type GUIDs, so no issue there
jacoxon has joined #asahi-dev
<kettenis>
read-only filesystem support is usually pretty easy, but writing is always tricky
<kettenis>
Using the ESP has the benefit that other OSes can easily pick up things from there
<kettenis>
wouldn't pre-creating the Linux rootfs confuse a distro installer?
<kettenis>
i.e. it would see no free space, offer the user to use the existing Linux partition and wipe it?
<chadmed>
i assume it would just see an empty partition marked as a "Linux rootfs" with the correct GUID
<chadmed>
Anaconda can detect these and offer to automatically configure the rest of the filesystem automatically for you
<kettenis>
well marcan is thinking about putting a filesystem there an pre-populate it with the wifi firmware
<chadmed>
well that being said im not actually aware of any distros that offer arm64 installers like they do on the PC, usually you just extract a tarball of a rootfs and its up to the user (or in this case the asahi installer) to configure the rest of the system to boot and point a kernel to it
<chadmed>
so if we had the wifi firmware already dumped into the partition, youd just be adding whatever is in the tarball to /lib/firmware
<kettenis>
in my opinion that model (extract rootfs) is fundamentally broken
<kettenis>
especially the armbian model where you have different rootfs images for each board that is supported
<chadmed>
i agree, but its what we have to work with for arm right now sadly
<chadmed>
until someone has the bright idea of releasing a new standard that standardises all the standards :P
<kettenis>
major Linux distros offer proper installers for arm64 for "servers"
<chadmed>
yeah thats because those servers are usually equipped with ACPI and UEFI, so the existing amd64/PC installers work with very little modification
<chadmed>
you cant guarantee every arm platform has both or even one of those though
<kettenis>
well, the M1 will have UEFI ;)
<kettenis>
that's the whole point
<kettenis>
RHEL will probably not run because they alledgedly only want to support ACPI
<chadmed>
true, but for the linux install experience to be "good" theyd have to boot from a live medium through the UEFI provided by u-boot and install... provided the distros release bootable arm live images that work without ACPI
<kettenis>
But the others (Debian, Ubuntu, SuSE) should just work
<kettenis>
there seems to be a little bit of an Arch bias here though, which I think uses the "untar rootfs" approach even on x86 isn't it?
<chadmed>
i think the benefit of supporting m1n1+uboot+edk2 is that once the rootfs is decompressed and configured (which we can make automatic via the asahi installer anyway), future updates and booting looks exactly like a PC to the end user
<kettenis>
but that is probably because folks here tend to be tinkerers
<jix>
kettenis: not sure if it supports untar rootfs on x86 but it's not the default way to install it
<jix>
kettenis: usually you boot from USB and then use pacstrap, then chroot into that and setup more stuff
<sven>
i've only used arch because it had a convenient rootfs available fwiw
<chadmed>
nah the arch install is somewhat similar to gentoo with less manual intervention. theres one command to build the rootfs once youve configured your disk
<kettenis>
anyway, I'm biased
<kettenis>
On OpenBSD we use the same installer on all our architectures with jost some small quirks for each hardware platform
<chadmed>
thats the best way to do it imo, but im not sure you could convince the distros to rejig their arm tooling to support that on linux... yet...
<chadmed>
now that we have real arm workstations within reach of consumers that dont suck and arent $10,000 (looking at you ampere) they might be more willing to invest time in the process
<chadmed>
hell, we could really just set an example tbh
<kettenis>
as I said, Debian, Ubuntu and SuSE all offer ISO images for arm64
<chadmed>
true but the trick is booting them on the machine and getting them to work minus ACPI
<chadmed>
can edk2 boot external media after its been chainloaded from u-boot? would we have to have an EFI executable that presents this as an option to the user?
<chadmed>
(im genuinely curious)
<kettenis>
that just works as long as they don't deliberately cripple their kernel config like RHEL does
<kettenis>
and yes, both edk2 and u-boot automatically boot the removable media path thingy from external media
<kettenis>
with my u-boot you can already boot a debian installer ISO from usb
<dottedmag>
Creating a small ext4 fs and stuffing all firmware into it would probably work, distro will only need to mount and symlink it.
<kettenis>
FAT would be better from my perspective ;)
<dottedmag>
But then how is it different from ESP
<dottedmag>
Right
<kettenis>
anayway, there is no reason the Asahi installer couldn't do both
<kettenis>
have a generic UEFI install option for Debian/Ubuntu/SuSE/OpenBSD and another option for the ALARM-based distro that marcan has proposed
<chadmed>
yeah i broadly agree. my one concern would be how we make this look sufficiently PC-like that even the most basic users will understand the paradigm
<chadmed>
do we make a fake efi shim that tells them to mash F12 to boot from USB as a skeuomorph? do we let u-boot sort it out?
<marcan>
kettenis: I'm talking about dumping a prepopulated rootfs
<marcan>
"proper installers" are great when distros have had a chance to do all the proper hardware enablement
<marcan>
until that happens images with the right things already installed are a better idea
<marcan>
proper installers won't work until everything is upstream and back downstream; I don't expect most people want to go that path for linux for at least a couple years
<kettenis>
yeah, I don't have to worry about that for OpenBSD
<kettenis>
I just commit stuff and within 24 hours Theo has built a new snapshot with it enabled ;)
<marcan>
:p
<marcan>
and yeah, I think I'll dump the firmware into the ESP unconditionally so people can always rely on that being there
<phire>
I personally dislike "proper installers", I always try to install from a previous linux distro
<phire>
usb flash drives suck
<kettenis>
well, you have to start somewhere ;)
* maz
installed his M1 by running the debian installer as a guest...
<phire>
I actually managed to install Linux on my newest laptop without a usb flash drive
<chadmed>
i havent used a gui installer in like 10 years, but the kinds of people we need to entice over are people who use gui installers...
<kettenis>
edk2 provides http boot, where you can point it directly at an ISO image and boot it
<chadmed>
despite not wanting to use it at all, i do think its a worthwhile thing to support. that said, its mostly out of our hands as marcan said. itll be a thing the distros have to sort out themselves.
<phire>
That was an adventure, I had to install grub from windows, then get the arch iso booting as a loopback
<kettenis>
no reason u-boot couldn't do the same
yuyichao_ has joined #asahi-dev
<chadmed>
would u-boot need to do it if edk2 can? we're chainloading that anyway, right?
<kettenis>
no, there is no edk2 involved on the m1 macs
<maz>
I don't think anyone plans to port edk2...
<kettenis>
u-boot provides its own UEFI implementation
<chadmed>
oh right yep
<chadmed>
im pretty sure i did know that, im just dumb
<kettenis>
marcan: so we need to transplant the "module-instance" property from the ADT into the device tree
<kettenis>
we already add a "local-mac-address" property to the wifi pcie device node, so this isn't too difficult
<kettenis>
the hard bit is to come up with a sensible property name and where to define the binding for it ;)
<milek7>
>btw, does anyone know of a functional userspace ext4 implementation?
<milek7>
maybe libguestfs?
<jn>
(hmm, i guess i should not suggest User Mode Linux or Linux in QEMU-TCG)