Windows Dev Kit 2023 Boot Work

[nickdepinet]

Discussion started in Issue #7, splitting to it's own issue for tracking:

I've recently gotten ahold of a windows dev kit 2023, which appears to be a surface pro 9 (5g) / sq3 in a box, and I'm attempting to boot linux on it with these patches.

Progress so far -

Booting base Ubuntu 22.04.1 LTS arm image - Hangs at:
Booting a command list

Synchronous Exception at 0x0000000C1B17927C
Building a "default" profile image with the image tool - Hangs at:
Loading initramfs...
Booting into Surface kernel...
EFI stub: Booting Linux Kernel...
EFI stub: Using DTB from configuration table
EFI stub: Exiting boot services...
Barring better suggestions, I'm going to try to extract the firmware with the script from aarch64-firmware and stuff it into the arch image above and see where that gets booting

---

1. could possibly be fixed by linux-surface/grub@55b95a3. So you could try to use e.g. the pre-built grub from https://github.com/linux-surface/grub-image-aarch64/releases/tag/fedora-37-2 with your Ubuntu kernel. Alternatively, just use the image from 2) which contains the patched grub, but remove the devicetree option from the boot entry. That should get you booting in ACPI mode.

2. is way before any firmware gets loaded, so I doubt that that will make any difference. Can you make sure that efi=novamap is set (press e in the grub menu to edit)? Also, this is booting with the SPX DT, and I'm not sure if that's a good idea. So as I've said above, you can remove the devicetree option in the grub config and it should hopefully get you a bit further.

You can also experiment with earlycon=efifb.

In the long run, you'll probably want to have a look at the DT of the sc8280xp (that is 8cx Gen 3; it's also used in the Thinkpad X13s) and use that as a base. Also, you might want to join the oftc/#aarch64-laptops IRC. There are a lot more experienced people who also might have some ideas.

Originally posted by @qzed in #7 (comment)

[nickdepinet]

Booting the image from number 2 above with the devicetree line removed gets into a boot loop. Adding earlycon=efifb console=efifb boot_delay=200 to the boot parameters gets us to see that we're reaching the following lines before instantly rebooting:

there are a bunch of BAR and firmware errors further up the log as well that may be worth investigating

[nickdepinet]

swapping in sc8280xp-lenovo-thinkpad-x13s.dtb as the devicetree on boot gets to same line & rebootloop behavior as above

[qzed]

So at this point you'll probably really want to head over to oftc/#aarch64-laptops :) They'll know much more about what might be going wrong here.

Also if you're starting off with the thinkpad DTS you might need to remove/disable a couple of parts. AFAIK sudden restarts are generally happening when you access something you shouldn't (yet) access, like powered-off MMIO, invalid memory, ...

Particular stuff that you might want to remove:

• HID-over-I2C input nodes (https://github.com/torvalds/linux/blob/f141df371335645ce29a87d9683a3f79fba7fd67/arch/arm64/boot/dts/qcom/sc8280xp-lenovo-thinkpad-x13s.dts#L206-L257)
• Backlight (https://github.com/torvalds/linux/blob/f141df371335645ce29a87d9683a3f79fba7fd67/arch/arm64/boot/dts/qcom/sc8280xp-lenovo-thinkpad-x13s.dts#L19-L43)

maybe more...

[nickdepinet]

Stripped a bunch of stuff out of the dts into a new copy and attempted booting with it - same result. oftc/#aarch64-laptops says that the big thing is that I need to add an override for the smmu. Some googling around found this patch that seems relevant to what needs to be done: https://patchwork.kernel.org/project/linux-arm-kernel/patch/20210509022607.17534-1-shawn.guo@linaro.org/#24198673

[nickdepinet]

This does indeed appear to be the right path - whitequark logs direct us to similar issue for samsung galaxy book go here: aarch64-laptops/debian-cdimage#21. Created following PR to add wdk2023 acpi to smmu platlist here: linux-surface/kernel#130. Working on getting my local build environment setup for cross-compiling linux kernel for test

[qzed]

Ahh, I completely forgot about this being a thing... That explains at least why it boot-looped with ACPI. However, I think the DTS should have the SMMU described properly, so not sure why that fails similarly.

[nickdepinet]

No longer boot looping in ACPI mode with a kernel built with the above patch. Now we're getting rcu_preempt stalls:
.

Booting with a dtb empty except for including the sc8280xp.dtsi still causes bootloop behavior.

I've also attached the acpidump.txt here: linux-surface/acpidumps#24

[qzed]

I'd guess some MMIO region or something is being accessed that hasn't been powered up yet... but hard to tell what exactly...

[hexdump0815]

@nickdepinet - just out of curiosity: did you make any further progress in getting this device to boot mainline linux?

[xlazom00]

Any progress?
Btw @qzed are you mainlining your fixes ?

[qzed]

@xlazom00 Hopefully at some point. But that depends on someone upstreaming a device tree for the sc8180x platform. People have been working on that but I don't know the current status.

[xlazom00]

@qzed btw motherboard in dev kit is same as surface pro 9
so do you know if there is some dts for surface pro 9 somewhere ?

[nickdepinet]

@nickdepinet - just out of curiosity: did you make any further progress in getting this device to boot mainline linux?

I haven't had time to visit this in a while, so no further progress on my end. There's been some interesting qcom improvements in the arm64 upstream tree that may let us get further, but I haven't had a chance to build a new kernel and give it a go

[qzed]

@qzed btw motherboard in dev kit is same as surface pro 9
so do you know if there is some dts for surface pro 9 somewhere ?

I'm not aware of any, sorry.