01:13 <Jawse> Getting an SError Interrupt on CPU3(new 8 core M1 pro), any get the kernel to boot on this model? I'm using the T6000 codebase.

05:44 <marcan> I was thinking about asking if anyone had the 8 core models, since we probably need to do something there

05:44 <marcan> but it looks like Jawse left :/

05:46 <marcan> if anyone else has an 8-core, I'd appreciate an ADT dump (in m1n1/proxyclient: `python -m m1n1.adt -r adt.bin > adt.txt` and note that it might contain your wifi password; remove the huge `nvram-proxy-data` line if you want to get rid of that)

10:20 <marcan> ha, while messing with the HV I caught m1n1 booting the primary core from RVBAR (i.e. through what normally is the secondary entry) and then blowing up on the spinlocks not working

10:20 <marcan> that was when macos went to sleep

10:21 <marcan> so indeed the CPUs come back through RVBAR, but the more interesting question is how did this happen....

10:36 <marcan> ah, it sets [0] Disable WFI Return. fair.

11:02 <marcan> maz: since we're *eventually* going to have to support this suspend dance, what's your thinking? right now for arm64 there is only PSCI and ACPI.

11:03 <marcan> either we do an Apple-specific driver, or we add a non-hvc/smc PSCI interface and make m1n1 into a PSCI provider

11:06 <marcan> doing it the PSCI way should also allow m1n1 to handle the deep cpuidle stuff instead of having to write a driver for that too

11:09 <marcan> but calling from the kernel into m1n1 has some, er, interesting consequences (e.g. does the kernel 1:1 map m1n1 in the low address space for this, or do the called functions have to be position-independent and callable at any random vaddr the kernel feels like using, or do we turn the MMU off?)

11:10 <marcan> (how does EFI do this, I wonder...)

11:18 <marcan> apparently there is a SetVirtualAddressMap thing, heh

11:36 <maz> marcan: yeah, EFI provides its own address map (which is a 1:1 mapping IIRC), which we use when calling into it.

11:37 <maz> marcan: ardb had some idea on how to fake this up, though this will require some buy-in from the usual suspects.

11:38 <maz> marcan: I'm obviously partial to the PSCI solution, as it avoids reinventing another wheel, even if that's not a very nice wheel.

11:39 <marcan> fair enough

11:41 <marcan> in other news, all the pmgr-pwrstate instances for t6001 are ~2000 lines of DT

11:41 <marcan> I'm thinking that should at least go in an include :-)

11:42 <marcan> on the plus side, the extra stuff in t6001 vs t6000 is neatly in a separate PMGR instance, so I can keep my "t6000.dtsi includes t6001.dtsi and removes stuff" thing and all it takes is one node deletion

11:55 <kettenis> marcan: the UEFI memory map basically indicates memory ranges that need to be preserved for runtime services

11:55 <kettenis> these are 1:1 mappings, but they can be relocated by calling SetVirtualAddressMap

12:56 <Jawse> Here is the ADT dump from the 8-core

12:56 <Jawse> https://gist.github.com/jawse/e8d82123f84225101f61649799dec69b

13:06 <_jannau_> Jawse: thanks. did you retry with an updated m1n1? marcan pushed a related fix to m1n1 a couple of hours ago

13:06 <Jawse> jannau: working on that this morning, will let you know how it works

13:07 <marcan> ok, so CPU nodes just disappear

13:08 <marcan> I think the fix I pushed should just work then

13:08 <_jannau_> which kernel repo/branch do you use? M1 Pro/Max is currently only supported by https://github.com/AsahiLinux/linux/tree/t6000/bringup-work

13:10 <Jawse> jannau: Yes that's the one I used.

13:33 <kettenis> marcan: I believe you need to remove the cpu nodes from the device tree in m1n1 instead of disabling them

13:33 <marcan> ah, linux doesn't listen to the disabled prop on CPUs?

13:34 <kettenis> yeah, there are (broken) DTs out there that have all but the primary CPU node disabled

13:34 <marcan> sigh

13:35 <kettenis> so I remember removing the check of the "status" property on OpenBSD for that

13:35 <kettenis> and as far as I can follow the code path Linux doesn't check on arm64

13:35 <marcan> lovely

13:35 <kettenis> I may be misreading the code though

13:48 <marcan> pushed a change to delete the nodes

13:53 <kettenis> great; that'll help OpenBSD when I get around to supporting the new SoCs

16:09 <marcan> so I added all the pmgr pwrstates to the DT, and set the ones that obviously break things to always on...

16:09 <marcan> and now it boots, except it randomly reboots

16:10 <marcan> methinks I'm shutting down something that breaks the SMC or similar, and that causes a panic later

16:10 <marcan> ISTR sven might've seen this before?

16:10 <sven> that happened when i half-enabled the thunderbolt coprocessors

16:11 <sven> but that was more than just PMGR

16:33 <marcan> okay yeah, pretty sure it was the SPMI interfaces and indeed it was crashing SMC