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
gladiac is now known as Guest98
gladiac has joined #asahi
Guest98 has quit [Ping timeout: 480 seconds]
<marcan>
kettenis: SMC sends HID events for the key, we wouldn't be using the GPIO directly
<marcan>
we do not support interrupts; lid is a special case
<marcan>
there's an SMC HID driver planned
<marcan>
we *can* support interrupts for the GPIOs, but GPIO1 behaves differently anyway
<marcan>
so in fact we can't for that one, it sends special case events instead :-)
<marcan>
*for the lid
yuyichao has quit [Ping timeout: 480 seconds]
<marcan>
kettenis: don't think backlight is supposed to go through GPIO directly
<marcan>
that one is DCP's job
<conradev>
this is a random question, but does anyone know if the A15 SoCs have the virtualization extensions that the M1 has?
yuyichao has joined #asahi
pg12 has quit [Ping timeout: 480 seconds]
atka has joined #asahi
pg12 has joined #asahi
<kit_ty_kate>
Glanzmann: your m1-debian repository doesn’t show which file you upload as grubaa64.efi
<kit_ty_kate>
is that just testing/usr/lib/grub/arm64-efi/monolithic/grubaa64.efi ?
kov has quit [Quit: Coyote finally caught me]
kov has joined #asahi
phiologe has joined #asahi
PhilippvK has quit [Ping timeout: 480 seconds]
<marcan>
for everyone messing with partitions: it would help a lot if you can narrow down what happens in confusing cases, like when partitions are out of order
<marcan>
we can read the EFI GPT partition map directly from the installer, but we can't write to it
<marcan>
so if we determine diskutil gets confused with out-of-order partitions and there is no workaround, I can add a cross-check to detect that case
<marcan>
but we need to know exactly what happens
<tpw_rules>
marcan: if you have partitions B and A on disk but A and B in the numbering, disk utility will show (free space equal to size of A), B, A, (free space equal to size of B)
<tpw_rules>
diskutil*
<tpw_rules>
IME it seems to process the partitions okay but if you look for free space in such a map it's fake
<marcan>
what I want to know is what diskutil info -plist <partition> says, in particular PartitionMapPartitionOffset and TotalSize
<tpw_rules>
you parse the plist?
<marcan>
yes
<marcan>
we certainly don't parse the user-friendly output ;)
<tpw_rules>
well it sounds like it has the same invalid info as that
<marcan>
the plist doesn't have a concept of free space
<marcan>
it only lists partition offsets and sizes
<marcan>
so I can sort by offset and compute free space properly, if the data is good
<marcan>
but I also want to know whether the disk0sN numbering is consistent with partition order (I don't think it is after making changes, but maybe it always is on boot?)
<kit_ty_kate>
marcan: (unrelated) is there an "easy" way of copying extra files to 1TR? or do i have to patch src/stub.py by adding some more shutil.copy("<extra-file>", os.path.join(self.osi.system)) ?
<marcan>
kit_ty_kate: what is your use case?
<marcan>
I mean nothing stops you from just opening up another terminal tab and copying some files manually
<marcan>
but is this something you want the installer to do?
<tpw_rules>
marcan: yeah, it looks like you will want to sort by offset
<marcan>
ok, that changes the logic a bit
<tpw_rules>
by more than a sort call?
<marcan>
just need to get all partition info first, *then* sort, *then* walk the list and insert free space
<marcan>
already implemented it, about to test
<kit_ty_kate>
marcan: I’m making a "one-click" reproducible distribution installer for fun (I’m almost done but the missing step is to copy uboot, kernel, partition image and so on to 1TR for the modified step2.sh to use there)
<tpw_rules>
although i am not sure what "the partition after" will mean to diskutil when such misorderings are present
<tpw_rules>
if there is both fake and real free space
<tpw_rules>
so it might be best to just bail completely in that case. although i'm not sure how the user will fix the problem
<marcan>
pushed & updated installer
<marcan>
tpw_rules: that is something I'd like people to test
<marcan>
though I'd hope it means we have to specify the partition that is *physically* before the free space we want to use
<marcan>
which is what I do now
<tpw_rules>
i wonder if e.g. shrinking the user's main partition by 1 sector will force diskutil to sort the table
<tpw_rules>
the manpage says it tries to place the new partition at (pos + size) of the specified partition, so yes it should do it physically
<marcan>
kit_ty_kate: why would you copy uboot/kernel/partition image in step2?
<marcan>
you can do that in the main installer, that's literally what I'm about to implement, er, right now
<marcan>
(streaming shortly)
<marcan>
the only thing step2 *has* to do is bputil/kmutil m1n1 in, because that is gated on paired recovery
<marcan>
everything else can be done ahead of time
<marcan>
I even intend to stream the partition image directly to disk so we can avoid requiring temp storage anywhere
<kit_ty_kate>
each dockerfiles produces a component (uboot, kernel, ext4 image to dd) and everything builds from macOS which is quite handy
<chadmed>
how do we reliably expand the dd-ed image into whatever free space the user actually specified? ik some rpi images do it but it looks like these assume any space below the root partition is free to bulldoze?
<kit_ty_kate>
chadmed: resize2fs does that pretty well. I didn’t have any issues with it so far
<chadmed>
oh good stuff then
<marcan>
kit_ty_kate: btw, my idea for the future is that if you run the asahi installer from Linux, it'll prompt you to make a USB install instead
<marcan>
which is required anyway, since a true standalone installer is not redistributable
<marcan>
that would fetch the IPSW subset it needs, and re-pack it into a zip file containing only those bits for use by the installer
<marcan>
kit_ty_kate: I'm interested in the resize2fs build for macos though
<marcan>
chadmed: as a "general purpose" plan, my idea is that the installer will create the *partition* with as much space as the user requests
<marcan>
and then the distro, on first boot, will resize the *filesystem* (and whatever volume management layers it uses under it) to fit the partition size
<marcan>
but for simple resize2fs cases it would be helpful if the installer just does it ahead of time
chadmed has quit [Read error: Connection reset by peer]
chadmed has joined #asahi
off^ has joined #asahi
babilen has quit [Remote host closed the connection]
babilen has joined #asahi
<zv>
I am intending to set up this mac mini in a data center with a raspberry pi for tethering. is there anything I should know that's not documented that might be of concern?
<zv>
hm. without physical access to the power switch, how does one handle the case where /dev/ttyACM0 is no longer present for some reason?
<marcan>
zv: I would not recommend that set up. you'd need a USB-PD interface to be able to reset the device if it wedges. a rPi won't give you that.
<marcan>
the Mac Mini 10G supposedly has LOM, but none of that has been reverse engineered yet
<marcan>
also, I haven't found a way to make the machines always power up on AC application, which means that if you ever do a clean shutdown, you're toast
<marcan>
(there is AC restore but not always power)
<zv>
remotely-managed power switches or PDUs are easily obtained, maybe Wake-on-LAN is possible?
<marcan>
I doubt WOL would work on cold power-up on the regular 1G Mini
<marcan>
maybe on the 10G one, but that NIC is very unexplored so far
<marcan>
feel free to dig around into it but I can't promise anything right now
<zv>
no worries; seriously great work going on here.
Xe has quit [Remote host closed the connection]
Xe has joined #asahi
the_lanetly_052 has joined #asahi
the_lanetly_052 has quit [Remote host closed the connection]
the_lanetly_052 has joined #asahi
eroux has joined #asahi
<Glanzmann>
kit_ty_kate: testing/usr/lib/grub/arm64-efi/monolithic/grubaa64.efi fixed in the repository.
<Glanzmann>
mps: Thank you for testing.
<Glanzmann>
tpw_rules: Whenever I did something with diskutil, it reoordered the partitions.
<Glanzmann>
zv: You could use a gpio of the rapsbery pie with a optocoupler to remotely press the mini power button.
<Glanzmann>
I used a smiliar setup to remotely install system half away around the world for years when I could not afford remote management boards.
<Glanzmann>
Systems were set to pxe boot and I could press the power button using a gpio pin. I said the system using pxe to boot from disk or reinstall itself with Linux/Windows/VMware or boot a rescue system.
<Glanzmann>
marcan: Do you have any more information of the LOM 10G mini support?
<Glanzmann>
zv: Povik did some development on the air using a mini remotely. as m a r c a n said it hang itself a few times. So that I had to manually power it off and on again.
<zv>
Glanzmann: let me dig into some things and get back to you tomorrow or later this week. trying to think of reliable options that others can easily set up too.
<Glanzmann>
zv: By default the mini will recover the last power state it was on. So you could also hook it up to a pdu.
<Glanzmann>
zv: What I would be most interested is a driver for Linux on m1 to be able to sissue to reset.
ciggi_ has joined #asahi
<_jannau_>
Amazon uses a servo in their mac aws instances to press the power button
ciggi has quit [Ping timeout: 480 seconds]
the_lanetly_052 has quit [Ping timeout: 480 seconds]
MajorBiscuit has joined #asahi
the_lanetly_052 has joined #asahi
<mps>
Glanzmann: regarding syslog parsing, metalog have option to set regex triggers (as shell or perl script) when something is happens
steven1lung[m] has joined #asahi
chadmed has quit [Read error: No route to host]
<povik>
_jannau_: you can't be serious
<povik>
oh, *mac* aws instances
<povik>
i thought it's something they do in general
<_jannau_>
I suppose they do it to use unmodified mac minis
eroux has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
tomtastic has joined #asahi
<marcan>
streaming installer stuff in a bit
<bestouff[m]>
Hi everybody; I know that asking for ETA is deeply frowned upon, but does anyone know for when the next blog post is due ?
<j`ey>
markan is working on the installer / bootloader stuff currently, with a view to making something 'release worthy'
<sven>
Hi, I know that I shouldn't do X, but let me do X anyway!
<j`ey>
I guess that's what the next blog will be about, so in N weeks where N is probably 3
<j`ey>
or 2, or maybe 4
<bestouff[m]>
sven: ... more let me do Y instead, where X is a derivative of Y
<sven>
and how does that make it any better?
<psykose>
the next blog post gets moved back every time someone asks
<psykose>
the current expected date is 2037
<sven>
:>
<psykose>
thank you for your patience
<j`ey>
jeez, we'll be on m50 by then
<psykose>
gonna overtake the bmw model numbers
<Glanzmann>
I have tldr of the blog post: u-boot max/pro, nvme and spi support, wifi, wifi firmware extractor, smc (battery, wip: reboot/poweroff), asahi installer (retry downloads, warn user about recovery OS, m1n1 nvme support), dcp, debian installer, OpenBSD, Asahi Installer for Arch, backlight for 2020 laptops
<povik>
Glanzmann: don't forget mention of audio!
<sven>
and if it takes another weeks possibly also usb 3 ;)
<Glanzmann>
Thank you, also forgot rtc.
<Glanzmann>
Okay I add that.
<Glanzmann>
sven: Can I include tb a well?
<sven>
i was half-joking, but no
<sven>
usb 3 seems to be relatively painless
<j`ey>
sven: so we need to keep asking markan so that you have time >:D
<sven>
tb is seems to be very painful though
<sven>
-is
<mps>
sven: this is good news
<Glanzmann>
Okay here is that tldr: u-boot max/pro, nvme and spi support, wifi, wifi firmware extractor, smc (battery, reboot, poweroff, rtc), asahi installer (retry downloads, warn user about recovery OS, m1n1 nvme support, robustness), dcp, debian installer, OpenBSD, Asahi Installer for Arch, backlight for 2020 laptops, wip: Audio speakers on 2020 models, stable audio jack output 2020 modes, stable audio input
<sven>
i haven't written code yet, but from what i can tell usb 3 is a few dozen register pokes + applying some tunables
<Glanzmann>
jack 2020 models, wip: usb-3
<Glanzmann>
Cool.
<mps>
Glanzmann: audio capture
<Glanzmann>
'stable audio input'
<mps>
ah you added
<Glanzmann>
Okay, I'll rename it.
<povik>
uh, don't wave the 'stable' too much, just to be sure
<mps>
no, no problem, I just didn't read it carefully
<j`ey>
povik: stable and perfectly working, no bugs, fully guaranteed or your money back
<povik>
:D
<mps>
nothing is 'stable' but working
<j`ey>
povik: that's what the github sponsorhip stuff is for ;)
<mps>
though it is quite stable for me
<Glanzmann>
povik: It did not fail for me once since the last patch.
<povik>
uh oh, i didn't read the terms then
<Glanzmann>
povik: Before that I had no audio every other reboot. Now I have audio on every reboot.
<povik>
that's probably coincidental caused by some other change in new kernel. there's a failure mode with the cs42l codec we still don't understand
<povik>
so i don't think it's fixed yet
<povik>
could be related to what remains of the m1n1 tipd issue
<Glanzmann>
I see.
<mps>
I don't noticed this problem on MBP
<mps>
s/don't/didn't/
the_lanetly_052 has quit [Ping timeout: 480 seconds]
<kit_ty_kate>
Glanzmann: cool then i had the correct one. Thanks!
<kit_ty_kate>
@marcan | which is required anyway, since a true standalone installer is not redistributable // You mean because of the firmware? Glanzmann’s solution (and by extention mine, since my work is based on his) to that is to simply create it in 1TR and move it to the EFI partition. That way on first boot it can be simply unpacked and everything is ready
<marcan>
kit_ty_kate: no, because of the stub OS
<marcan>
also that's not Glanzmann's solution, that's my solution :p
Gaspare has quit [Quit: Gaspare]
ciggi has joined #asahi
ciggi_ has quit [Ping timeout: 480 seconds]
<kit_ty_kate>
ah fair enough. Ah is that a license thing? Thinking about it, the only dd-able image I came accross was FreeBSD’s for Raspberry PI
<Glanzmann>
kit_ty_kate: The problem is the wifi firmware.
<Glanzmann>
We're not allowed to redistribute it.
<kit_ty_kate>
yeah but as long as we build it locally in the install script and copy it to EFI, the rest can be distributed right?
<Glanzmann>
Yep.
<mps>
I created tar archive on macos, copied to other linux machine and run there firmware extract script, copied tarball on alpine install usb disk, boot usb disk and untar firmware tarball during installation
<mps>
iirc someone told earlier that it could/would be possible to download something (tar file?) from apple and extract firmware, but I forgot details
<Glanzmann>
mps: That is what the ipfw is about.
<Glanzmann>
The ipfw are the macos images that the official macos installer downloads from the internet. It also contains the firmware.
<mps>
Glanzmann: aha, that way complete installation media could be prepared offline on another machine (though I guess that that image is huge)
Gaspare has joined #asahi
<Glanzmann>
mps: It is huge, but probably we could seek to the location the firmware is located, maybe m a r c a n already does that?
<Glanzmann>
And only get that chunk.
the_lanetly_052 has joined #asahi
<sven>
the installer already only streams the parts of the IPSW it actually needs afaik
yuyichao has quit [Ping timeout: 480 seconds]
eroux has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
nico_32_ is now known as nico_32
yuyichao has joined #asahi
eroux has joined #asahi
the_lanetly_052__ has joined #asahi
kgarrington has joined #asahi
kgarrington has quit [Remote host closed the connection]
the_lanetly_052 has quit [Ping timeout: 480 seconds]
kgarrington has joined #asahi
kgarrington has quit [Remote host closed the connection]
<marcan>
Glanzmann: it is not just about the firmware
<marcan>
it is about the whole stub OS
<marcan>
including the entire macOS recovery environment
<marcan>
also it's "ipsw"
<marcan>
kit_ty_kate: it is 1GB+ of nonredistributable stuff you have to download from apple
<marcan>
my thought is I'll make the installer have a "prepare offline install" mode where it downloads the needed bits to make a reduced ipsw
<marcan>
as of today the installer already supports loading the ipsw from a local path instead of the internet
<tpw_rules>
1TR doesn't need to correspond with apple to set the security mode and alternate kernel and stuff?
<marcan>
you mean phone home?
<tpw_rules>
yes
<marcan>
no
<tpw_rules>
oh, cool
<marcan>
the installer already switches to reduced security to avoid any phone home calls
<marcan>
haven't actually tested it 100% offline but it *should* work
<tpw_rules>
it always took a weirdly long time so i thought that's what it was doing
<marcan>
I'll do that once I plumb in the sparse ipsw stuff
<marcan>
it's talking to SEP
<marcan>
and resigning all boot policies
<marcan>
and the more junk boot policies you have left over, the slower it gets
<tpw_rules>
can you clear them out?
<marcan>
installing n OSes is O(n²) time the way this is designed
<marcan>
yes, I wrote a cleanup script during today's stream
<sven>
for some reason it needs to chat quite a bit with SEP and it takes SEP a while to reply. if you enable verbose mode it'll show all the messages it send
<sven>
+s
<kit_ty_kate>
marcan: sure, I’m not talking about having a dd-able image for everything, just for the ext4 partition, the rest of the installer stays the same
<kit_ty_kate>
but maybe I’m missing your point (sorry I am)
<marcan>
kit_ty_kate: then yes, the plan was always to put the firmware in the EFI partition and have the distro copy/upgrade it on every boot (so we can handle stub/firmware upgrades)
<marcan>
that's why I wrote the whole manifest thing
<marcan>
so you can compare that to find out if it changed
<marcan>
I wrote the code to do all the EFI partition stuff in the installer during the stream I just finished
<kit_ty_kate>
yeah i was watching (good job btw ^^)
<mps>
marcan: that sounds good as solution
<mps>
though I will always install all manually
the_lanetly_052__ has quit [Ping timeout: 480 seconds]
<marcan>
that's why there's a "just give me the bootloader" option
<kit_ty_kate>
oh btw I noticed the root.img input file during the stream. Is that the same idea as the ext4 partition image or is it meant for a USB stick? (if it is, hopefully it could be used for both with an option)
the_lanetly_052 has joined #asahi
off^ has quit [Remote host closed the connection]
<marcan>
kit_ty_kate: it's an ext4 partition image (well, it will be)
<Glanzmann>
marcan: PIng me when you push it, I'm eager to try it out and also to create a pull request for Debian. :-)
<Glanzmann>
marcan: Of course, I forgot about the rest of the ipsw to setup the stub partition.
<Glanzmann>
marcan: The ext4 image will be hosted on one of your systems I assume and will not be created on the fly using a tar archive (I remeber some discussion if there is a tool which can create a ext4 image from a tar archive)?
<Glanzmann>
j`ey: Can you give me a quick recap how far marcan got with the installer?
<j`ey>
Glanzmann: it creates the partitions from a json file now, and dumps the contents of the image into the partitions
<j`ey>
including running the wifi fw script etc
<Glanzmann>
Cool.
<j`ey>
(oh and creating some detailed logs for debugging)
<Glanzmann>
j`ey: Thank you for the recap. Does it also write the grub and grub configuration already?
<j`ey>
no
<Glanzmann>
I see, but that is a 10 liner for marcan.
<marcan>
grub configuration is in ext4 and not writable for the installer, but it doesn't need to be
<Glanzmann>
It's pretty easy because 'diskutil list' gives a first number the parition number.
<marcan>
there is nothing to be changed there
<Glanzmann>
marcan: So what I did in my installer, I wrote a fake grub config on the efi which loads the kernel.
<Glanzmann>
Once properly booted, grub can be properly installed.
<marcan>
the system as installed will use static UUIDs and everything will work out of the box
<marcan>
on first boot I will make it randomize its own UUIDs
<marcan>
that will involve a grub re-config
<marcan>
there is no fakery or weirdness involved
<Glanzmann>
marcan: I see, good idea.
<marcan>
the image as built will have a real grub config with static UUIDs
<Glanzmann>
And than you have some /etc/rc.local or equivalant which extracts the wifi firmware and call resize2fs?
<marcan>
well, a systemd early unit but yes
<marcan>
one will be one-time and do the disk stuff, the firmware stuff will run on every boot
<Glanzmann>
I see. cool.
<tpw_rules>
why does the firmware one need to run every boot? doesn't that only change if the stub partition is upgraded?
<Glanzmann>
I assume it checks.
<Glanzmann>
And extracts if file has changed.
<kettenis>
marcan: EBBR contains a proposal to name firmware directories on an ESP
<tpw_rules>
sure, but that's going to happen like, yearly, right?
<marcan>
that's why there's a manifest file, so the script can figure out if anything changed without unpacking everything again
<kettenis>
the EBBR use case is a little bit different because it is targeted at "AP" firmware
<kettenis>
but it still might make sense to align with it
<marcan>
kettenis: that looks to be about boot-time firmware?
<marcan>
not really what we're doing here, that's more like the stub partition story
<marcan>
what I'm doing is providing a bundle that follows the standard /lib/firmware hierarchy for the OS to consume
<kettenis>
it is indeed primarily about boot-time firmware, but I remember shipping wifi firmware was discussed as well
<kettenis>
seems that isn't explicitly mentioned in the text though
<marcan>
not going to work; we need symlinks
<marcan>
that's one reason why I'm using a tarball
<marcan>
(also case sensitivity - that could be a mess on FAT without)
<kettenis>
sure, but you could stick the tarball into /FIRMWARE/APPLE or /FIRMWARE/ASAHI
<kettenis>
in the end it probably doesn't matter
<marcan>
yeah but then that makes the mechanism apple-specific
<marcan>
the idea with this vendor-firmware thing is that other platforms may want to use it to do the same thing
<marcan>
i.e. provide vendor-supplied firmware for linux driver consumption
<marcan>
(or bsd for that matter)
<marcan>
how does bsd do firmware anyway, is it /lib/firmware or is there some other mechanism?
<kettenis>
it is called /etc/firmware (to make sure it lands on the root partition)
<marcan>
same hierarchy though?
<kettenis>
doesn't strictly match what Linux does
<kettenis>
we have a tool to update the firmware
<marcan>
not even the wifi stuff?
<kettenis>
so I'm going to look into extending that tool to pick up the firmware from the ESP
<kettenis>
for bwfm(4) the filenames are the same as what Linux uses
<marcan>
cool
<marcan>
I think everything else will be asahi-specific
<marcan>
so we can just agree on that too and then you won't need to do any weird logic
<marcan>
anyway, I should get some sleep
<kettenis>
sorry, I lost you, what asahi-specific bits are you thinking of?
<marcan>
AVD and that USB XHCI firmware for the iMacs
<kettenis>
ah, right
<tpw_rules>
(AVD?)
<marcan>
apple video decoder
MajorBiscuit has quit [Ping timeout: 480 seconds]
<kettenis>
Theo wants to look into copying the wifi firmware into the installer from the ESP such that we can have working wifi in the OpenBSD installer
<kettenis>
so as soon as you push your current work I'll have a closer look
<tpw_rules>
are you planning on shipping a pre-canned rootfs for the installer?
<kettenis>
that doesn't make sense
<tpw_rules>
sorry, by "the installer" i mean "the asahi linux 1TR/macOS resident install script"
<kettenis>
how would a filesystem image of some sort help you?
<tpw_rules>
afaik that's how that installer will install things
the_lanetly_052 has quit [Ping timeout: 480 seconds]
<tpw_rules>
so that would allow installation of openbsd from the script without having to prepare a flash drive or whatever
<kettenis>
oh, you mean an OpenBSD rootfs?
<kettenis>
Not keen on that
<tpw_rules>
yes.
<marcan>
he wants to go the UEFI-only route for bsd, works for me
<marcan>
the canned images are an option, not a requirement
<tpw_rules>
yeah, i was thinking the same for nixos. but it's a bit of a barrier
<kettenis>
what may make sense is to copy bsd.rd and BOOTAA64.EFI into the ESP
<tpw_rules>
i was also wondering about that for nixos, but then that would require modifications to the asahi script
<marcan>
if that's all you need to boot the installer, we could have a "bsd installer" OS option
<marcan>
what I wrote today is flexible enough to copy arbitrary trees to the ESP, and otherwise leave the space unpartitioned
<tpw_rules>
can your json setup thing be changed to allow both the ext4 and ESP as targets?
<kettenis>
FreeBSD an NetBSD do things in a different way I think
<marcan>
it's completely flexible
<marcan>
you list the partitions and it can copy a raw image, or a tree into the ESP
<marcan>
it can have a partition that stretches to fit the user-specified space or not
<kettenis>
the real question is how we'd handle the maintenance burden of updating the installer for each new release
<marcan>
the OS images are streamed from a ZIP file, so you could host yours if you wanted to, it wouldn't have to be on asahi infra
<marcan>
we could move the bulk of the OS definition into there too, to make it self-contained
<kettenis>
I still think I prefer the "install u-boot using the Asahi installer and pretend this is a normal machine afterwards" approach
<mps>
I'm not sure I will work on this for alpine linux but will propose this if someone of alpine devs wants to do all these things
<mps>
and will help, ofc
<mps>
actually i think I have POC ready for this
<mps>
but I'm not in hurry, waiting for most important things to be in u-boot and kernel mainline
<mps>
and I know that two experienced alpine developers 'lurking' on both asahi channels ;)
<tpw_rules>
i just think it would be nice to have an option in the installer more or less for marketing purposes
<Glanzmann>
marcan: What I don't understand. You hardcode the efi parition in u-boot. But how does Linux know which is the corresponding EFI parition?
<Glanzmann>
marcan: And how do you handle when someone wants to install the same distribution twice? Because than the UUID of the root filesystem will be same, won't it?
sarah[m] has joined #asahi
riker77 has quit [Quit: Quitting IRC - gone for good...]
<Glanzmann>
mps: I mean doing the UEFI approach is the goal, but having what marcan is doing at the moment is from my point a big gain. Because you can install a complete distribution in less than 20 minutes including everything. The majority of the time is actually spent on entering 1tr and setting up the stub. The Linux installation is done in 10 seconds.
<Glanzmann>
Also with what marcan is currently doing you don't need any usb sticks, usb-c to usb-a convertes and god knows what, so especially for unpexerienced Linux users, it will be very easy.
<zv>
Glanzmann: is there a specific page/script you're referring to here?
<tpw_rules>
i mean you can write the intsaller to the internal storage, but the problem is there's no way to return back to it
<j`ey>
zv: but doesnt yet have the stuff that was worked on, on todays stream
<zv>
j`ey: thanks; haven't had a chance to catch up on the state of the project yet so please pardon the outsider questions for now
<mps>
Glanzmann: that is ok. but I expect that alpine users are experienced ones
<mps>
Glanzmann: and alpine 'smells' more like OpenBSD than popular linux distros
<Glanzmann>
mps: But to be honest, even as experienced user, I prefer the dd approach. because it takes me 10 seconds to install Linux (of course setting up the stub and rebooting in 1tr also takes a little bit of time especially if you don't get it right the first time, like I always do).
riker77 has joined #asahi
<mps>
Glanzmann: all alpine install media uses 'install' method and not ready made tarballs or disk images
<Glanzmann>
But probably the best way is to having multiple ways of setting up linux (tethered, untethered, dd, live system, distro installer).
<Glanzmann>
mps: I mean at least on Debian, the disk image is also created using debootstrap what is the exact method the installer uses itself.
<mps>
Glanzmann: yes, I know. I was on debian more than 15 years
<Glanzmann>
Also on Debian you can verify the checksum of every installed file, and apply upgrades very easily. Also on of the unattended debian installation methods, fai (fully automated installation) also uses a tarball that it extracts to bootstrap systems. I used it for many year to install 100+ systems.
<Glanzmann>
mps: I see. Anyway having different choices is nice. Pick whatever fits best.
<mps>
Glanzmann: I agree
<mps>
Glanzmann: and I really appreciate your work and help
<tpw_rules>
tl;dr all AArch64 boards and distros should be UEFI instead of having to rely on weird setups for platform firmware (i.e. u-boot and the like)
<mps>
tpw_rules: and armv7?
<mps>
tpw_rules: don't take this as serious question, please
<tpw_rules>
i want to say yes? but 32 bit arm is not as supported on nixos
<mps>
tbh I don't know inner points of UEFI and don't like current grub, so have some aversion to this combo
<mps>
but I'm not against this, even first alpine installer script for alpine I created with grub
bisko has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
bisko has joined #asahi
nijifu[m] has joined #asahi
bisko has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<zv>
in a tethered configuration, if some exception occurs then /dev/ttyACM0 might disappear on the host. disconnecting and reconnecting the USB cable seems insufficient to resurrect it, and only rebooting the mac appears to work. is this the only solution?
<Glanzmann>
This is the way.
<Glanzmann>
zv: Or you have another mac and can use macvdmtool to reboot the mac.
eroux has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<zv>
eep. not currently an option.
<sven>
or run Linux inside the hypervisor. It’s much harder to trigger an exception that breaks usb in that setup
<zv>
I'm playing with QEMU on here now but the issue is memory. This machine is intended to be a public-access Linux-on-M1 system for the GCC cfarm.
<sven>
ah. that makes it much harder unfortunately
<j`ey>
what do you mean the issue is memory?
<sven>
hm, wait, or maybe I just got confused
<sven>
do you develop qemu and need Linux to run in EL2 for that?
<zv>
oh, perhaps I misunderstood. I read "run Linux inside a hypervisor".
<sven>
no, that sounds about right. We have a very thin hypervisor inside m1n1
<sven>
it passes through ~everything
<sven>
but it’ll emulate the serial console as another usb serial device and you’ll be able to quickly reboot the machine with a Python command
bisko has joined #asahi
<zv>
I see; that will be ttyACM1 ?
<sven>
yup
Gaspare has quit [Ping timeout: 480 seconds]
<tpw_rules>
zv: just out of curiosity, do you plan to use 4K or 16K pages?
<zv>
tpw_rules: haven't gotten there yet; someone mailed me a mac mini to set up and I haven't spent any time familiarizing myself with this project or modern macs yet. (the only one I own is from 2006).
<tpw_rules>
ah. if you use 4K i don't think it would be different to any other aarch64 machine
<tpw_rules>
16K is also noticeably faster
<j`ey>
its still faster than other machines at 4k
<zv>
sounds like I should aim for 16k then
<zv>
there is one other issue. when ttyACM0 disappears so does ttyACM1
<j`ey>
what kinda exception causes it to disappear?
<tpw_rules>
zv: they disappear under different circumstances in the hypervisor
<zv>
I don't recall; will let you know next time I do that.
<j`ey>
as sven has said many times, USB is cursed
<j`ey>
if the HV loses USB, there's not really much you can do
<zv>
are there any interesting headers inside? haven't opened it up.
<sven>
don’t think so. UART (and SWD but that’s fused off for us mere mortals) can be muxed on the usb-c port
<j`ey>
sven: the USD PD is very reliable right?
<sven>
it has USB in its name and the wire signals are beyond cursed (seriously, look up how complex it is for what feels like a glorified uart) but other than that the reboot command has been pretty reliable
<j`ey>
for a remote mini, it seems like the best option
<sven>
the only thing it can’t do is power on a mini that’s turns off fwiw
<sven>
and I haven’t figured out how to reliably enable “auto power on” yet
<zv>
there was a note in one of the wiki pages about asking Hector for an early sample, "In the coming weeks we'll be designing an open hardware interface for interfacing to M1 serial ports"
bisko has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<kit_ty_kate>
is there a list of tools that currently doesn’t work with a 16k page size somewhere? If there isn’t I think it might be worth adding a new wiki page to list them
<kit_ty_kate>
I’ve seen chromium listed here a couple of times but apart from this one I don’t know
<j`ey>
jemalloc compiles the page size into it
<j`ey>
(so works with if compiled with 16k, but isnt portable)
<tpw_rules>
libunwind and webkitgtk
<zv>
are there kernel patches to enable a 2020 mac mini to use a usb-a keyboard?
<j`ey>
zv: does it not work?
<jannau>
zv: with an upstream kernel? the usb-a ports should work
<zv>
I'm using commit 501bccfe4c2d4d9524d8cafcdd4e84b7c58e976a plus a handful of patches mentioned in the docs
<zv>
and I tried a u-boot image and separately the debian installer initrd, seemingly no keyboard support
<j`ey>
4k or 16k kernel?
<zv>
great question
<tpw_rules>
yeah the usb-a ports don't work in u-boot but they should work once the kernel comes up?
<kit_ty_kate>
feel free to remove it if someone think it shouldn’t be placed there or add stuff if it’s helpful and something is missing
<kit_ty_kate>
mps: feel free to add it ^
<mps>
kit_ty_kate: I don't have github account
joske has joined #asahi
<joske>
kit_ty_kate: add vscode, electron
<joske>
balena etcher
<mps>
kit_ty_kate: so please add f2fs
<joske>
all those use chromium underneath, so all are broken on 16k pages
<kit_ty_kate>
mps: added
<mps>
kit_ty_kate: thanks
<kit_ty_kate>
joske: included as a note under chromium (I’m not sure if they should all be listed one by one given it’s a dependency issue, but if you think it’s better feel free to edit)
<joske>
kit_ty_kate: well not everyone may know that vscode (which is an electron app) uses chromium
<joske>
as do all electron apps, they run in a chromium window
<joske>
so I want to use vscode in linux, so I need 4k pages ;-)