02:09 <marcan> and now it's starting to look like something in 6.5.4 stable (or some other prior version) regressed PCIe for us

02:09 <marcan> since my 6.5.0 merge works, but the Fedora 6.5.4 rebase is all kinds of broken with PCIe IRQs

02:12 <Tramtrist> :(

07:49 <maz> axboe: sorry for stating the obvious, but these bugs *do* go undetected, all the time. there is no way the current level of kernel CI covers anything useful (it is usually limited to booting...). now, if you are prepared to dedicate significant resources to stress-test all RCs and to convince Linus to *gate* releases until these tests have completed, then I'm all ears!

07:50 <maz> (and we should probably take this somewhere else, as this is quite OT)

11:00 <eiln> lina: estimated time of the sekrit work stream (if any)? I really don't wanna miss that one ;)

15:13 <lina> eiln: I was planning to do it today, but I had a weirdly busy day again... maybe tomorrow (sunday) 3PM JST?

15:14 <lina> I mean saturday

17:25 <leio> Any hints what to poke at for https://dpaste.com/FXN89AY6Z - this is https://github.com/AsahiLinux/m1n1/pull/329 on a M2 Ultra Mac Studio

17:26 <j`ey> what are you trying to do? run u-boot/linux?

17:27 <leio> chain-load patched m1n1

17:28 <j`ey> that worked didn't it?

17:28 <leio> there's no HDMI output - am I not supposed to see any picture until u-boot?

17:28 <j`ey> what command have you run?

17:29 <j`ey> so youve rebuilt boot.bin? with the patched m1n1?

17:29 <leio> I ran make on m1n1 off the branch and `proxyclient/tools/chainload.py -r build/m1n1.bin`

17:30 <j`ey> yeah, that just runs m1n1, there's no u-boot there

17:30 <leio> and that won't output any picture either way?

17:33 <j`ey> m1n1 *should* write a framebuffer (TTY> fb init: 1920x1080 (30) [s=1920] @0x12fc6b54000)

17:34 <j`ey> (but this is now outside of what I know, I was just trying to figure out exactly what you tried / expected)

17:38 <leio> yeah, it says "TTY> fb: display logo" but I don't see any. I'm sure it's some stuff to do in the patch with actual access to such a device

18:35 <leio> there's also the note of "Still missing but prepared is the SMC gpio support required to power the MCDP29xx DP to HDMI converter on." in the patch - maybe that?

18:35 <leio> and also "M2 Ultra support is untested and broken due to the wrong clock-gate."

18:37 <j`ey> ah, didnt see that in the commit messages (didnt look)

18:37 <j`ey> (I saw the SMC support added, so assumed it was used)

18:39 <leio> the pull request mentions it should work, so maybe outdated commit msg

18:40 <j`ey> I think the commits have been updated, but not the PR

18:54 <janneg> PR/and commit messages were outdated, refreshed

18:55 <janneg> leio: your log looks to me like everything works. does the display sees that 1920x1080@60 is used as mode?

18:56 <janneg> what happens if you chainload m1n1 again

19:15 <leio> janneg: should I be seeing any logo on it?

19:16 <leio> janneg: uh, and now running it again I see stuff

19:16 <leio> pretty sure it was the third run of the patched m1n1.bin

19:22 <leio> ok, shut down and tried again

19:22 <janneg> third chainload or 3rd run after reboots?

19:22 <leio> first nothing, as it's old m1n1

19:22 <leio> then chainloaded patched m1n1.bin - no picture

19:22 <leio> then chainloaded it again - picture now

19:23 <janneg> ok, that sounds as if there's an issue with rendering after the display config

19:23 <janneg> the second chainload shouldn't touch the display

19:24 <janneg> or maybe it does. please paste the log of the second chainload

19:24 <leio> https://dpaste.com/8D7KS6TPR has the first and second chainload

19:25 <leio> (second chainload at line 201)

19:26 <janneg> the second chainload reconfigures the display

19:26 <janneg> maybe there's an issue with not updating the framebuffer address fully/correctly in 1st chainload

19:27 <leio> looks like to get further I need to patch the kernel too - ERROR: Kernel found but no devicetree for apple,j475d available.

19:28 <leio> https://dpaste.com/G33AZYEKC is the fedora minimal installed m1n1 initial boot, fwiw

19:31 <janneg> looks like display_map_fb() misses to update video.base. I'll prepare a patch to test

19:32 <leio> eh, after another reboot try I have it shift to /dev/ttyACM0 - before I had ttyACM0 through 2 and M1N1DEVICE as ttyACM1, now that's ttyACM0

19:32 <janneg> yes, you need https://github.com/AsahiLinux/linux/pull/180 and https://github.com/AsahiLinux/linux/pull/192 for the kernel

19:33 <janneg> leio: see https://github.com/AsahiLinux/m1n1/blob/main/udev/80-m1n1.rules for stable symlinks

19:33 <leio> weird to have an extra one - I'd understand the swapping between them otherwise

19:35 <leio> right, so the first run with patched m1n1 does make the monitor do something too

19:36 <leio> and second run I start seeing picture since "TTY> USB2: initialized at 0x10004f71690" or so, with the rest scrolling by

19:43 <leio> do there happen to be any docs about how the installer images need to be like?

19:45 <janneg> hmm, no I think

19:45 <leio> or the json file or whatnot - basically why the arch ones don't work for me and is there more to it than just editing the json file to say 13.5 mac OS too

19:46 <leio> the previous question was for seeing about that approach for gentoo installing

19:47 <janneg> the black screen after the first chainload is just a side effect of starting with an uninitilized display and iboot not setting an apple logo in the framebuffer

19:48 <leio> and then with patched m1n1 it resets the monitor, while it lights up on second run

19:50 <leio> lights up = shows text and logos

19:52 <janneg> there is https://github.com/AsahiLinux/docs/wiki/Distro:Differences-from-Arch-Linux-ARM#image-format with a dead link to https://github.com/AsahiLinux/docs/wiki/Installer%3AOS-Packages

19:54 <janneg> but I don't think there any tricky bits, in doubt read the installer source code

19:55 <leio> yeah, no worries, just in case there was something in existence

19:57 <janneg> hmm, I think after the display init it should start printing the log from "fb console: max rows ..." on

19:57 <leio> it's what I saw from my camera recording, the monitor might take a bit of time

19:59 <leio> (or I need a slow motion camera instead of a phone :)

20:00 <janneg> I'd recommend to install fedora-asahi-remix, that images already support 13.5

20:01 <leio> kernel needs patching for it to boot and I am putting gentoo on here, at least eventually

20:02 <leio> but that's why I asked, if I will need to do something special for such a gentoo image zip

20:02 <janneg> after that rename m1n1/boot.bin on the ESP and then start with the kernel booting sections on the bottom of https://github.com/AsahiLinux/docs/wiki/Tethered-Boot-Setup-(For-Developers)

20:03 <leio> so boot.bin is the kernel and the lack of it will allow to load one from the m1n1 usb?

20:04 <j`ey> boot.bin is m1n1+u-boot

20:04 <janneg> no boot.bin is the 2nd stage m1n1 holding m1n1, dtbs and u-boot

20:04 <leio> ok, didn't get the purpose of the rename on the ESP then

20:05 <janneg> ah, yes not necessary if it misses the dtb for the mac studio anyway

20:06 <leio> right, ok, so renaming the boot.bin would make me not have stage2 and then I can load a kernel from the stage1 m1n1? (if kernel would otherwise boot)

20:06 <janneg> otherwise it will result in a fallback to proxy mode in the 1st stage m1n1

20:06 <leio> and I can access the ESP to do so from mac OS I guess?

20:06 <j`ey> yeah, since it's some kinda FAT partition

20:07 <janneg> yes, but I think it's atm not necessary for the m2 ultra mac studio

20:07 <leio> that's right, and why I could just chainload the patched m1n1 then

20:07 <janneg> the 2nd stage m1n1 falls back to proxy mode sionce there is no devicetree

20:08 <leio> otherwise I was reading something about needing `nvram boot-args=-v`, crsutil disable and some such that I didn't do yet

20:08 <janneg> renaming boot.bin seems esier than that

22:15 <eiln> dw

22:16 <eiln> ignore that