ChanServ changed the topic of #asahi-alt to: Asahi Linux: porting Linux to Apple Silicon macs | User-contributed/unofficial distribution ports | Logs: https://alx.sh/l/asahi-alt
glem8100548899408697 has joined #asahi-alt
glem810054889940869 has quit [Ping timeout: 480 seconds]
glem8100548899408697 is now known as glem810054889940869
bgb has quit [Remote host closed the connection]
tobhe has joined #asahi-alt
tobhe_ has quit [Ping timeout: 480 seconds]
opticron has quit [Read error: Connection reset by peer]
opticron has joined #asahi-alt
HitokiriKincho has joined #asahi-alt
n3ph has quit [Ping timeout: 480 seconds]
WoC has joined #asahi-alt
<craftyguy>
well I can see now why that kernel doesn't work... asahi gpu driver crashes early in boot with: https://bpa.st/34CQ
<craftyguy>
does that look familiar to anyone?
HitokiriKincho has quit [Remote host closed the connection]
HitokiriKincho has joined #asahi-alt
HitokiriKincho has quit [Remote host closed the connection]
HitokiriKincho has joined #asahi-alt
<chaos_princess>
Ensure latest u-boot, m1n1 and device trees
<craftyguy>
I'm using u-boot v2025.07-1, m1n1 1.5.0, and kernel/dtbs 6.16.5-1, but I just realized there's a 6.16.5-2 for the kernel...
<craftyguy>
Is the "ttb at ... is not mapped" message a problem?
<chaos_princess>
it failed to hand off a memory area that gpu wants from an earlier boot stage. i do not remember the exact issue that causes it, but a mismatch between the various pieces involved in the boot process can be it.
<mps>
craftyguy: is this happened on machine which worked, i mean after kernel upgrade
<craftyguy>
mps: no this is my first attempt to boot anything on it besides macos.
<craftyguy>
chaos_princess: hmmm ok. AFAIK I'm using the latest versions of everything in the stage2 🤔
<chaos_princess>
y'all have the update-m1n1 or whatever syncs dtbs there, right?
<craftyguy>
to generate a m1n1.bin with the latest dtbs? Ya
<craftyguy>
it's using the dtbs from the kernel and not u-boot... (The Asahi docs show generating it from the u-boot dtbs), I'm not sure if that matters. Anyways I just tried generating a m1n1.bin with u-boot dtbs and it didn't help
<chaos_princess>
ok, framing this as "user guide" is quite wrong, this is more of a "hacker guide" if you want to work on kernel
<mps>
craftyguy: if you copied it from alpine you should have '/usr/sbin/update-u-boot-asahi' script to do that
<craftyguy>
mps: ya I am using the stuff you packaged in Alpine
<craftyguy>
u-boot and m1n1. Your kernel and the custom one I built earlier both crash when loading the asahi GPU driver
<chaos_princess>
i am confused now, are you using whatever is the "official" asahi alpine, or building your own on top of upstream?
<craftyguy>
building my own. AFIAK there is no official Alpine asahi?
<craftyguy>
I'd expect any official thing to be on alpinelinux.org 😅
<chaos_princess>
not _that_ official, but there is support
<mps>
craftyguy: you mean official install image iso? then no
<craftyguy>
sure, I'm using the stuff packaged in Alpine to build my own images. postmarketOS is a downstream distro from Alpine, we use the Alpine binary repos for most stuff
<chaos_princess>
try following the steps mps linked above
<chaos_princess>
and then go from there to port it to pmOS
<craftyguy>
mps: can you link to how you build the image installed by that installer?
<mps>
craftyguy: I changed build script a lot in last month/two and not yet made it ready to publish
<craftyguy>
can I see what you have, even if it's messy?
<mps>
but i can post it in crude form if you want play with it but then you to be careful, i had to use DFU two times and reinstall macos
<mps>
craftyguy: i will post it after morning coffee, not right now on machine where it is
<chaos_princess>
wat
<craftyguy>
that's fine. I'm not going to run it, I just want to see if I'm missing a step somewhere. For booting, I used the asahi-installer to install only an ESP and have been booting images from USB (and extracting vendorfw in early boot and stuff like I'm supposed to)
<chaos_princess>
please do not post stuff that has the chance of killing macos unless you did it by screwing up manual repartitioning
<mps>
chaos_princess: I'm not screwed by running this, but by some other actions
<chaos_princess>
ah, ok
<mps>
resulting image is tested by few people and no one had problem
<mps>
i just wrote 'usual hackers disclaimer' above
<mps>
will be afk for some time
<jannau>
craftyguy: please boot with `modprobe.blacklist=asahi` in the kernel command line. that should boot without gpu and make it easier to diagnose
<jannau>
if you built the kernel with CONFIG_MTD_PHRAM we have access to the m1n1 log
<jannau>
but even without it `dtc -I fs -O dts -o - /proc/device-tree` displays the boot DT. I would expect that
<craftyguy>
ok I'll blacklist it. Anything in particular that would be useful for me to look at?
<jannau>
the uat-ttbs node in reserved-memory
<jannau>
/chosen/asahi,m1n1-stage2-version is interesting as well
<craftyguy>
ohhh ok so the m1n1 stage2 version is old... the ESP created by the latest asahi-installer installed m1n1 v1.4.1 (with probably some old dtbs) to the ESP. I was then booting that stage2 to load my OS (which has a newer kernel than the asahi fedora stuff...) from USB
<craftyguy>
I tried replacing the m1n1/boot.bin in that ESP (created by the asahi installer) with a newer one with the latest m1n1+u-boot+dtbs for the kernel I'm booting, but after a reboot it seems like 1.4.1 was restored in the ESP (by recovery or ???)
<craftyguy>
anyways, here's what the booted devicetree shows for that uat-ttbs thing: https://bpa.st/V6XQ
<jannau>
there is no mechanism which restores boot.bin. Did you replace the one on the partiotion with the part uuid in /chosen/asahi,efi-system-partition ?
<mps>
this crude script which needs some work to make it better
<mps>
craftyguy: if you have any improvement please send or report. it would be nice if we can work together to improve all these for alpine and pmOS. till now I was alone to work on having asahi on alpine
<jannau>
any idea where m1n1 1.4.1 comes from? I fear it might be the version we ship in the uefi-only install option
* jannau
realized that it is ancient (October 2023)
<chadmed>
ive been meaning to look into getting the artefacts to build automatically via gh actions but i have had ~zero downtime :p
<jannau>
I was planning to build it in the fedora installer image creation. At least there we have easy access to the dtbs
<jannau>
that was one reason for the theme-able m1n1 logos
<mps>
craftyguy: just pushed testing/linux-asahi-6.16.5_p2 to builder
<craftyguy>
jannau: 1.4.1 must be the version shipped in the UEFI only option, because that's what created the ESP I used. I got this laptop on Monday and ran the official asahi-installer on Wednesday to create it. I'll try to update the binary again on it later, maybe I forgot to sync before unmounting or ???
n3ph has joined #asahi-alt
seb_ has joined #asahi-alt
<jannau>
craftyguy: yeah, I figured. we're in the process of sorting this out to not ship an ancient version
qyliss has quit [Quit: bye]
qyliss has joined #asahi-alt
<craftyguy>
np :) I suspect probably most folks go for installing a distro and not the uefi-only option (and then try to boot a new kernel) 😅
<mps>
those who want to install from external media probably use this
<tpw_rules>
yes, uefi-only is the recommended way with nixos
<mps>
it was also for alpine till february this year
MichaelLong has joined #asahi-alt
n3ph has quit [Ping timeout: 480 seconds]
n3ph has joined #asahi-alt
n3ph has quit [Ping timeout: 480 seconds]
<chadmed>
it is for gentoo too, we just made a bunch of "abi incompatible" changes recently
<chadmed>
we'll get it sorted and try to prevent it happening again
nela has joined #asahi-alt
n3ph has joined #asahi-alt
<tpw_rules>
i still dream that m1n1 wouldn't have to mangle the device trees... is ACPI tables a rust target yet
<chaos_princess>
do you have a spare $3k-ish for acpi org membership to get AIC support into the standard?
chadmed has quit [Quit: Konversation terminated!]
chadmed has joined #asahi-alt
<chadmed>
id rather write 100 billion lines of dts than hammer out a single line of acpi language
n3ph has quit [Ping timeout: 480 seconds]
<chadmed>
have you ever actually looked at manually wrangling acpi tables? fuuuhuhuuuuckkkk that
<chaos_princess>
eh, it is not _that_ bad, just pull a generic-x86-vendor and have every single aml method be a smm call
cylm has joined #asahi-alt
<chadmed>
i have bad memories from patching acpi tables when i was doing hackintosh stuff
seb_ has quit [Quit: Konversation terminated!]
<sven>
the only issue with the device tree imho is that we keep them downstream for too long and then get breaking changes while upstreaming
<jannau>
I think some people equate ACPI with x86 PC style install support which wouldn't be true for several reason
<jannau>
see snapdragon X devices which are in a much better position than we as qualcomm has at least designed with it in mind
<sven>
true
<craftyguy>
Is ARM acpi a thing in the Linux kernel?
<sven>
pretty sure it is, never looked into it though
HitokiriKincho has quit [Ping timeout: 480 seconds]
HitokiriKincho has joined #asahi-alt
<chadmed>
yeah its required for a bunch of arm servers
<chadmed>
uefi+acpi is actually the official arm systemready spec for servers etc
<sven>
ideally it won't matter for our users if there's a device tree or acpi table behind the scenes
<craftyguy>
Ok when I updated the m1n1 stage2 thingy on the nvme's ESP (which was created by the asahi installer), my GPU woes went away, I can now load the GPU driver without crashing the kernel on boot.
<sven>
realistically it'll take another year or so to get there
<chadmed>
barring gpu stuff i think we can get there sooner
<chadmed>
most of the annoying stuff is merged, queued, or in various stages of discussion
<chadmed>
im mad about not being able to sort out the smc stuff while im on break but since theres not much to do and ill be "w"fh for a couple of weeks when i get home i _might_ get that in for 6.18
HitokiriKincho has quit [Ping timeout: 480 seconds]
<sven>
hm, true
<chaos_princess>
power stuff will be annoying :P
<jannau>
dcp will be annoying
<sven>
:D
<sven>
thunderbolt will just have a weird iommu issue
HitokiriKincho has joined #asahi-alt
<jannau>
DP tunneling might drag thunderbolt into dcp
<craftyguy>
There's no external display support, right? (with the current stuff)
<jannau>
not via usb-c
<chaos_princess>
there is over hdmi
<chaos_princess>
and i guess displaylink (not display_port_) if you tolerate the issues that come with using it
<chadmed>
i am ignoring all the annoying hard stuff for the purposes of this thought experiment :p
<craftyguy>
ah ok, I only have usb-c on the macbook. I guess HDMI is on the Mac mini or ?
<chaos_princess>
14/16 mbps
<chaos_princess>
and mini/studio
<craftyguy>
Thanks. Oh right I just rediscovered the feature table... it shows WIP for DP alt mode (on M2), sorry for asking here 😅
WoC has quit [Remote host closed the connection]
WoC has joined #asahi-alt
HitokiriKincho has quit [Remote host closed the connection]
n3ph has joined #asahi-alt
HitokiriKincho has joined #asahi-alt
HitokiriKincho has quit [Remote host closed the connection]