13:46 <chadmed> plasma 6.4 seems to break dpms

14:14 <jannau> works for me on studio and I think on j493 (both fedora)

14:15 <jannau> breaks how? display does never power off? what happens when you press esc on the lock screen?

14:21 <fl0_id> does anybody have an idea why this seemingly stops at bootup? https://www.pastery.net/exwxde/

14:21 <fl0_id> second serial device didn't show anythin

14:21 <chadmed> yeah display on my studio never powers off. seems to be okay on both my laptops

14:24 <chaos_princess> fl0_id: usb power gating is probably not working properly

14:40 <fl0_id> mmh yeah that would make sense. if that is necessary for bootup :) anyway, if you have any idea on boot options to try, let me know. though I assume it needs support in m1n1

14:45 <fl0_id> just would have expected some kind of error or sth

14:49 <sven> probably need to figure out where xnu is stuck now and see what's missing/broken

14:54 <fl0_id> sven yeah. is there a way to turn more debugging/verbosity on? I just used the flags/command from the docs, only adapted for t6031 kernel

14:55 <sven> flags aren't going to help here probably

14:55 <sven> at this point it comes down to figuring out what xnu is doing and why it gets stuck

14:55 <fl0_id> mmh k. as long as it's not necessary to solder a uart or sth

14:56 <fl0_id> based on the output, is this still just m1n1 output or already xnu? It doesn't look like xnu output that I am used to from just turning on -v mode

14:56 <jannau> development kernel with symbols might be helpful as long it's not panicking

14:57 <fl0_id> this is a dev kernel

14:58 <jannau> have interrupted the HV and `bt`s each CPU?

14:58 <sven> should be xnu already after "Jumping to entrypoint at 0x1001b800660"

14:59 <fl0_id> sven k

14:59 <fl0_id> jannau you would have to explain a bit more. ctrl-c the hv and then?

15:00 <fl0_id> there is also TTY> i2c: Error getting /arm-io/i2c0 node TTY> usb: i2c init failed.

15:00 <fl0_id> but not sure if that matters

15:00 <sven> that's expected, usb-pd no longer uses i2c

15:01 <jannau> chicken bits in xnu are sone on the boot CPU

15:01 <jannau> fl0_id: bt should provide a backtrace

15:02 <jannau> on the current cpu and the hypervisor can switch CPUs

15:17 <fl0_id> sven ah k

15:18 <fl0_id> jannau ok cool. might get to try this evening

15:18 <fl0_id> thanks for the feedback

15:28 <fl0_id> oh and as it has so much output about the cpu4 at the end, I assume that's the one it's starting on?

16:19 <nickchan> I think so

16:19 <nickchan> > and during booting you might want to add cpus=1

16:19 <nickchan> oops, meant > > CPU init (MIDR: 0x611f0492 smp_id:0x4)...

16:19 <nickchan> so yeah it's starting on cpu4

16:21 <nickchan> s3_0_c15_c2_3 and s3_0_c15_c2_4 should be HID30 and HID31 respectively

16:25 <nickchan> and the output after jumping to entrypoint is from the m1n1 hypervisor not from m1n1

16:25 <nickchan> *not from xnu

16:26 <nickchan> xnu is running but those output are not from it

16:28 <amarioguy2> btw one note on the backtrace thing in m1n1 - more of an aside i wanted to note than anything else - i've had certain situations during my debugging where the hv debugger backtrace is just infinitely spamming the same two addresses when it tries to print the backtrace

16:30 <amarioguy2> i don't think it's a foundational m1n1 debugger problem? but at the same time wanted to point the weird behavior out in case anyone else had that behavior (it usually tends to happen when the Windows first-stage bootloader hits an exception and enters the branch loop)

16:31 <amarioguy2> also had a quirk a couple times where sometimes a few instructions before an exception is hit it will "speculate" to the exception directly - which was *so* annoying when trying to debug why exceptions happened

16:46 <fl0_id> nickchan yeah that's what I assumed, but just wanted to make sure

16:47 <fl0_id> amarioguy2 so you're loading windows on arm with m1n1 hv?

16:47 <fl0_id> or do I misunderstand windows bootloader

16:53 <sven> nickchan: what device doesn't have smc-reboot btw.? was that really only introduced later?

16:53 <amarioguy2> fl0_id: yes that's sorta been the reason i sometimes ask questions here

16:54 <fl0_id> interesting :)

16:55 <sven> nickchan: also, does the key MBSE exist there?

17:31 <nickchan> sven: on t8015: #401: MBSE = (hex_, 0xd4) 2f 00 00 00

17:31 <sven> so the key exists but reboot doesn't?

17:31 <nickchan> no mbse on t8012

17:32 <sven> so does t8015 support smc-reboot then?

17:40 <nickchan> sven: says reboot: Restarting system

17:41 <nickchan> then it does not restart

17:41 <sven> weird

17:41 <nickchan> well that's after disabled wdt in device tree

17:42 <nickchan> the gpio driver also probes without a node btw

17:42 <sven> ofc it does, the reboot driver isn't special in that case

17:42 <sven> it's either a bug in mfd or it's expected behavior

17:59 <nickchan> it's also very annoying to put t8012 into dfu mode without macvdmtool

17:59 <nickchan> and i can't do that from linux