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
yuyichao has joined #asahi
chamomile has joined #asahi
leah has quit [Quit: WeeChat 3.3]
leah has joined #asahi
DragoonAethis has quit [Quit: hej-hej!]
DragoonAethis has joined #asahi
darkapex4 has joined #asahi
darkapex3 has quit [Ping timeout: 480 seconds]
phiologe has joined #asahi
PhilippvK has quit [Ping timeout: 480 seconds]
kov has quit [Quit: Coyote finally caught me]
bgb_ has quit [Ping timeout: 480 seconds]
marvin24_ has joined #asahi
marvin24 has quit [Ping timeout: 480 seconds]
bgb_ has joined #asahi
chamomile has quit [Ping timeout: 480 seconds]
bgb_ has quit [Ping timeout: 480 seconds]
Graypup_ has quit [Quit: meow]
Graypup_ has joined #asahi
Graypup_ has quit []
Graypup_ has joined #asahi
bgb_ has joined #asahi
user982492 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
user982492 has joined #asahi
chamomile has joined #asahi
user982492 has quit []
bgb_ has quit [Ping timeout: 480 seconds]
palmer_ has joined #asahi
palmer_ has quit [Remote host closed the connection]
leah has quit [Quit: WeeChat 3.3]
leah has joined #asahi
bgb_ has joined #asahi
user982492 has joined #asahi
user982492 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
bgb_ has quit [Ping timeout: 480 seconds]
chamomile has quit [Ping timeout: 480 seconds]
kov has joined #asahi
user982492 has joined #asahi
sailorek1234 has joined #asahi
d0p1__ has joined #asahi
Dcow has joined #asahi
Dcow_ has quit [Ping timeout: 480 seconds]
d0p1__ has quit [Ping timeout: 480 seconds]
bgb_ has joined #asahi
VinDuv has quit [Quit: ZNC 1.8.2+deb2+b1 - https://znc.in]
VinDuv has joined #asahi
cth451_desktop has quit [Quit: Quitting]
cth451_desktop has joined #asahi
bgb has joined #asahi
bgb_ has quit [Ping timeout: 480 seconds]
nepeat has quit [Remote host closed the connection]
nepeat has joined #asahi
bingoChecker has joined #asahi
Dcow_ has joined #asahi
Dcow has quit [Ping timeout: 480 seconds]
hendry2 has joined #asahi
loki_val has joined #asahi
crabbedhaloablut has quit [Ping timeout: 480 seconds]
hendry1 has quit [Ping timeout: 480 seconds]
aleasto 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
the_lanetly_052 has quit [Quit: Leaving]
the_lanetly_052 has joined #asahi
user982492 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
dsrt^ has quit [Remote host closed the connection]
sailorek1234 has quit []
<mps>
testing u-boot apple-m1-m1n1-nvme branch, usb keyboard works, detects usb storage and tries to boot but then it hangs and after some minutes reset machine and repeat
<mps>
doesn't show it detected nvme device
<mps>
testing boot with efi formated and set usb device
sailorek1234 has joined #asahi
<kettenis>
are you using firmware from macos 12.0?
<mps>
kettenis: firmware? which and where it is needed for u-boot? first time hear about this
<mps>
I upgraded machine to macos 12.0.x (x is 1 iirc)
Darksecond4 has joined #asahi
<kettenis>
that may explain why nvme isn't working for you
<mps>
does that means I should downgrade to 11.0
sailorek1234 has quit []
Darksecond has quit [Ping timeout: 480 seconds]
Darksecond4 is now known as Darksecond
<mps>
11.2
Gaspare has quit [Quit: Gaspare]
<kettenis>
no, it means I should fix the code
<mps>
ah ok
aleasto has quit [Ping timeout: 480 seconds]
aleasto has joined #asahi
hspak has quit [Ping timeout: 480 seconds]
NightRaven[m] has joined #asahi
<NightRaven[m]>
I have a question does anyone know when arch will be done for m1 ?
<opticron>
common question and depends on your personal definition of "done"
<opticron>
alyssa has been running an unaccelerated desktop env for a while now (GPU support is not yet done)
garyodernichts[m] has joined #asahi
wouter has joined #asahi
chamomile has joined #asahi
<wouter>
should the m1n1 thing allow dual-booting my M1 mini, or is that something I shouldn't be playing with just yet?
chamomile has quit [Ping timeout: 480 seconds]
<j_ey>
wouter: dual booting macOS and linux? you'll just do that through 1TR
<j_ey>
power on, and then hold the power button
<wouter>
j_ey: yeah, that
<wouter>
oh, right, I can do that I guess
<wouter>
(I just repartitioned the internal storage that way)
<sven>
that’ll very likely be the only way dual booting will be possible
<wouter>
fair enough
<wouter>
(this m1 mini isn't mine, it's work's, but I thought I'd give "start porting debian-installer to m1 mac" a go...)
<wouter>
and yes, I know it's way too early for release :)
<sven>
as long youre
<sven>
*as long as you’re comfortable building downstream kernels with patches you can already somewhat use Linux :)
<kettenis>
there really shouldn't be a need to "port" debian-installer
<sven>
I think jannau has a nice collection for arch
<maz>
the debian installer works out of the box.
<maz>
all it needs is a kernel that knows about the M1.
<wouter>
well, it'd need a module for the boot loader
<wouter>
and perhaps some other things that are different on the m1 (if any)
<wouter>
I guess "porting" isn't the right word
<wouter>
but I have done d-i work in the past, for m68k and nbd-related things, so I have a fairly good idea how it works ;-)
<maz>
wouter: Debian knows about EFI, and u-boot provides just enough EFI for debian to be happy.
<wouter>
maz: oh, asahi uses u-boot? yeah that does make things easier then
<wouter>
I thought it used m1n1 as a custom boot loader or something
<j_ey>
wouter: m1n1 boots u-boot
<wouter>
oh, okay, right
<j_ey>
(as an option)
<wouter>
well, really, then all that needs is another flavour for m1 I guess
the_lanetly_052 has quit [Ping timeout: 480 seconds]
nickiminjaj has joined #asahi
d0p1__ has joined #asahi
fgfhmnrtry4r4t[m] has joined #asahi
jakou[m] has joined #asahi
chamomile has joined #asahi
nickiminjaj has quit [Quit: leaving]
<marcan>
wouter: I don't really expect distro installers to need any porting beyond adding some bits once we have them (e.g. some kind of bundled touchbard for the M1 13" MBP, or else you get no function keys...)
<marcan>
mostly just the firmware thing
<marcan>
the bootloader should be GRUB or whatever, u-boot provides EFI services
<marcan>
so just like any other GRUB machine from a distro's point of view
<marcan>
(or whatever EFI bootloader the distro wants to use)
<marcan>
we provide m1n1+u-boot which will be required to boot the distro installers in the first place (which users will install using a script from macOS/1TR); I don't expect distros to attempt to roll their own from scratch replacement for that (trust me, you don't want to)
<marcan>
once that's installed it'll just be an EFI boot which should work with USB disks for distro installers and such
<marcan>
or you could preinstall a netinstall image or what have you
<marcan>
I also want to offer distro images pre-configured in our installer so people can just dump those in in one shot; I need to get around to writing a spec for those...
<marcan>
for the firmware, I also need to write a spec for that, but my current thinking is something like <EFI PART>/asahi/firmware.tar.gz; distros would be expected to untar that into /lib/firmware, and keep track of the mtime so they can do it again if it changes (e.g. the user ran a bootloader/firmware upgrade)
<marcan>
there are some subtleties to work out around multi-boot; my current thinking is we should recommend that users do multi-distro-boot by using completely separate OS containers from the machine's point of view, which lets you use the native boot picker, and means each distro gets its own EFI partition (which is important because we don't have a good way to do efivars, so no configurable EFI boot menu, ...
<marcan>
... just the default boot)
<marcan>
barring changes to distros, maybe we can have u-boot mark only the currently booted EFI part with the real GUID, so distros don't get confused by multiple EFI parts
<marcan>
and then it might be nice if we could get some feedback on the currently installed kernel version, e.g. dumping a file in <EFI PART>/asahi/kernel.ver or something. that could be used by our bootloader installer/updater to filter the firmware versions we offer, so users don't accidentally install firmware that's too new for their kernel
<kettenis>
marcan: for u-boot we need to annotate a few nodes in the device tree with a "u-boot,dm-pre-reloc" proprty
<marcan>
dm-pre-reloc?
<j_ey>
marcan: kernel.ver being macos version or linux version?
<marcan>
linux version
<kettenis>
this is needed to make sure the power domains needed for the serial console can be found in the early "pre-relocation" phase of u-boot
<marcan>
(openbsd can pick whatever version it claims to support the same stuff as :p)
<j_ey>
marcan: was about to mention openbsd :p
<marcan>
I assume openbsd will at least try to follow the same "blessed" firmware versions we pick for linux, otherwise things will get really confusing :-)
<kettenis>
heh
<kettenis>
will be fine
<kettenis>
if we store the firmware on the ESP our firmware update tool should be able to grab it from there
<marcan>
perfect
<marcan>
the tag *could* be macos version, but it's possible they release updates that don't change the ABI (they already have, dcp.py works across a few releases at least) so I feel it makes more sense to have the flexibility to decide what works and what doesn't at the installer
<marcan>
and just track linux kernel release support
<marcan>
and it's not just firmware; it's also potentially a devicetree thing (though we will try not to screw up compat there)
<marcan>
kettenis: re power domains, sure
<marcan>
I was actually thinking about how to maintain our out of tree devicetrees
<marcan>
ideally I want to automate syncing with linux somehow, while still being able to have patches on top
<kettenis>
u-boot solves this by having *-u-boot.dtsi files that get included automatically
<marcan>
ah, sure, but I mean not just that, also just extracting the DTs out
<marcan>
though there was already a tree for that IIRC
<kettenis>
alternatively, for these u-boot,dm-pre-reloc properties we could write code that add them
<kettenis>
but that is probably a bigger mainenance burden
<marcan>
fwiw the serial console should be powered on boot, m1n1 certainly uses it and won't be shutting it down
<marcan>
(that would break earlycon too)
<marcan>
so given that DT tree tracks all official kernel releases, I'm thinking I can have some minor scripting to transfer changes from one or more of our asahi branches on top of that, and then we can have some includes/overlays if we need something extra
<kettenis>
yup, the problem is that u-boot sees the power-domain property, tries to find a driver, fails and then ends up without a serial console
<marcan>
ah, I see
<marcan>
and yeah, I think we can just have some makefile voodoo to overlay those properties on top
<marcan>
could even do it in code in m1n1 though, it wouldn't be too hard to pick out the serial0 alias and walk the power domain reference adding that
<marcan>
that should work for all machines, right?
nabaiste^ has joined #asahi
<marcan>
we already do a bunch of walking for things like disabling devices/DARTs on certain platforms, so...
<kettenis>
also need the syscon node that sits on top of the power domains
<marcan>
yeah, but that'd just walking up the tree
<kettenis>
but yes, that's what I was thinking of
<marcan>
remind me if I don't get to it, shouldn't be a big deal to add
<marcan>
going to get some sleep now :)
<marcan>
and hopefully catch up on reviews and send arnd_ some pulls tomorrow
<marcan>
I've had... a few days full of external IRQs
aleasto has quit [Remote host closed the connection]
bgb_ has joined #asahi
bgb has quit [Ping timeout: 480 seconds]
<kettenis>
the changes I just pushed to my apple-m1-m1n1-nvme u-boot branch may fix nvme with the macos 12 firmware
<mps>
kettenis: thanks, I will test it tomorrow, too late is here and I'm tired now and going to bed