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 https://github.com/linux-surface/grub/commit/55b95a388414a3d850e24fd2ae8fac100ffd9319. 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 https://github.com/linux-surface/surface-pro-x/issues/7#issuecomment-1306998491

[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: https://github.com/aarch64-laptops/debian-cdimage/issues/21. Created following PR to add wdk2023 acpi to smmu platlist here: https://github.com/linux-surface/kernel/pull/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: https://github.com/linux-surface/acpidumps/issues/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.

[shawnguo2]

@nickdepinet I haven't got time to debug, but that RCU stall issue seems caused by cpuidle support. You can try to disable CONFIG_CPU_IDLE and see if it helps.

[jwijenbergh]

Has anyone seen https://github.com/merckhung/linux_ms_dev_kit/commit/195ccc926158b49c33edbccde99685a497032c3b?

Source: https://twitter.com/merckhung/status/1602205575902683136

[qzed]

That looks like what you'd need to get it booted via a DT. Not sure about the remoteproc firmware paths (from what I've heard they're signed individually for each device, so you might have to copy them from Windows) but those aren't required to get the basics up and running.

[xlazom00]

@qzed can you plz cherrypick that to your 6.2 linux kernel THX

[qzed]

@xlazom00 I have thought about it, but decided not to do this, sorry. The reason for that is that I can't maintain this. I don't have a dev-kit, so at best I can keep things compiling. The sc8280xp platform is still moving fairly quickly, so it's likely that things will break and I won't be able to fix these things, or even detect any breakage. Due to this, I've decided to focus on the SPX exclusively, which is time-consuming enough at this point.

[xlazom00]

I was able to boot with Johan's Hovald(@jhovold) git https://github.com/jhovold/linux/tree/wip/sc8280xp-v6.2-rc8 and @shawnguo2 patches on top of that https://github.com/shawnguo2/linux/commits/devkit-dt-6.2-rc5 DTB https://github.com/shawnguo2/linux/commit/f3e0834be69a07b627991101c2f098d19e961324

with this clk_ignore_unused efi=novamap earlycon=efifb console=efifb and I pluged in usbc ethernet so I have internet on that

I still have some problems

1. cpu is reporting 3GHz but in real it is runing on something really low as benchmarks are reporting same results on every frequency
2. I see kernel and some OS stuff booting on display connected with displayport but then it go dark. I am able to ssh as usb-c ethernet is working

[CriXYZ]

Greeting! I'm very novice in linux, help me , please instaley and a version as complete as possible for 7c s book go. I found the link with the sd image but I can not download to the end greenblue81@protonmail.com Regards!!!

[qzed]

@CriXYZ This is not the right place for this question, I don't think anyone here can help you with that device. Maybe people at https://github.com/aarch64-laptops can help you, but installing Linux on those devices is generally not something that I can recommend for a beginner.

[rgn]

I was able to boot with Johan's Hovald(@jhovold) git https://github.com/jhovold/linux/tree/wip/sc8280xp-v6.2-rc8 and @shawnguo2 patches on top of that https://github.com/shawnguo2/linux/commits/devkit-dt-6.2-rc5 DTB shawnguo2/linux@f3e0834

with this clk_ignore_unused efi=novamap earlycon=efifb console=efifb and I pluged in usbc ethernet so I have internet on that

I still have some problems

1. cpu is reporting 3GHz but in real it is runing on something really low as benchmarks are reporting same results on every frequency
2. I see kernel and some OS stuff booting on display connected with displayport but then it go dark. I am able to ssh as usb-c ethernet is working

@xlazom00 Awsome! Would you mind sharing the image/iso? Would love to test it as well.

[thelumberjhack]

I was able to boot with Johan's Hovald(@jhovold) git https://github.com/jhovold/linux/tree/wip/sc8280xp-v6.2-rc8 and @shawnguo2 patches on top of that https://github.com/shawnguo2/linux/commits/devkit-dt-6.2-rc5 DTB shawnguo2/linux@f3e0834 with this clk_ignore_unused efi=novamap earlycon=efifb console=efifb and I pluged in usbc ethernet so I have internet on that I still have some problems

1. cpu is reporting 3GHz but in real it is runing on something really low as benchmarks are reporting same results on every frequency
2. I see kernel and some OS stuff booting on display connected with displayport but then it go dark. I am able to ssh as usb-c ethernet is working

@xlazom00 Awsome! Would you mind sharing the image/iso? Would love to test it as well.

I second that, but a quick write up on how you did it if you can would be preferred. Thanks

[mjrc]

Is there any progress on this - by any luck?

[xlazom00]

Sorry :)

I made this branch of armbian https://github.com/xlazom00/build/tree/qcom-sc8280xp

1. You will need to build image like this ./compile.sh EXPERT="yes" KERNEL_GIT=shallow BOARD=microsoft-devkit-2023 BRANCH=edge RELEASE=kinetic BUILD_MINIMAL=yes BUILD_DESKTOP=no KERNEL_CONFIGURE=no COMPRESS_OUTPUTIMAGE=sha,img EXTRAWIFI=no WIREGUARD=no PLYMOUTH=no PREFER_DOCKER=no

2. flash image to sd card or usb dongle with this for example https://www.balena.io/etcher

3. disable secure UEFI on device and change order to boot from usb first

Kernel will use ACPI to setup hw USB ports working(ethernet port), PCI also(wifi only need blobs from linux firmware) cpufreq driver don't so device will run on some low freq gpu driver don't

armbian will use https://github.com/jhovold/linux/tree/wip/sc8280xp-v6.3-rc4 and ACPI paches from here https://github.com/shawnguo2/linux/commits/wdk2023-acpi-6.2

Thank you for @jhovold and @shawnguo2 work!

Now it will be nice to have device tree version with all drivers in DT version cpufreq is working missing one usb port(one with usb-ethernet) display port dont ....

[merckhung]

Hi so I have booted DevKit 2023 to Ubuntu 23.04 desktop. But I am still using 6.0 kernel. I will try your kernel and see if I am lucky.

[merckhung]

So, I have switched to Steev’s 6.3-rc4 kernel with your ACPI patches. I feel the system (Ubuntu 23.04) runs smoother and faster than before (higher CPU freq?), but the GPU DRM is not detected, so it’s still software rendered.

I took a look at my X13s dmesg, I believe x13s’ GPU/DRM is detected through DTB (overlay?), instead of ACPI. Thinking about having a hack in the DRM msm_dpu driver.

[xlazom00]

@merckhung this one https://github.com/steev/linux/commits/lenovo-x13s-linux-v6.3-rc5 ?

[merckhung]

@merckhung this one https://github.com/steev/linux/commits/lenovo-x13s-linux-v6.3-rc5 ?

I used rc4 branch, but the GPU is not working yet as it was not detected in the driver probe() function through ACPI. Sound card not working yet as well.

[merckhung]

Just want to give some update on the Device Tree enablement for Microsoft Dev Kit 2023. I spent a few days last weekend to work on this, and finally, I have had a version of DTB that enables Dev Kit 2023 with the following key functions:

1. Adreno 690 GPU works
2. Sound driver loaded correctly, but unable to test it (I expected the sound over DisplayPort cable or Bluetooth)
3. Bluetooth should be working, I didn't test it thoroughly.
4. Wi-Fi working as usual.
5. All firmwares were loaded and copied from Windows/System32/DriverStore of MS dev kit 2023.
6. One of the USB-C-to-DisplayPort works (Connector must be on the right side, can't be flipped) - can see GUI on the monitor
7. DisplayPort signal lost after Display controller loaded, believe to be the lack of DP hot plug GPIO, I am testing each GPIO pins.
8. USB-A enablement. Host controller works but it seems like PHYs or POWERs were not right. (ACPI uses GICv3 pins as the interrupt, but the DT version uses PDC interrupt controller, need to figure which pins are used as INTs)
9. USB-C ports works as usual. Only one of them can display signal to the DisplayPort monitor, and the cable connector can't flip.

I will wrap up the work to see if I can resolve the DisplayPort problem (hot plug pin) and the USB-A problem (PHY and/or power) before I upload the DeviceTree changes.

[xlazom00]

@merckhung Can you share your kernel branch ?

[merckhung]

@merckhung Can you share your kernel branch ?

I have just uploaded it here.

Still need to work on mDP detection and USB-A.

You should copy firmware images (.jsn and .mbn) from Windows' system32/DriverStore folders.

Thanks

[xlazom00]

@merckhung Can you share your kernel branch ?

I have just uploaded it here.

Still need to work on mDP detection and USB-A.

You should copy firmware images (.jsn and .mbn) from Windows' system32/DriverStore folders.

Thanks

Which hardware need firmware from windows?

[qzed]

Probably similar to the Pro X: GPU, WiFi, Bluetooth. You can have a look at the pages at https://github.com/linux-surface/surface-pro-x/wiki, I suspect that many things (in particular those three) will be similar (just with different file names).

[xlazom00]

@qzed I only want to know why they are not in https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/

[qzed]

Licensing... You would need Qualcomm or MS to sign off on that. Technically, I'm probably also not allowed to distribute many of the files at https://github.com/linux-surface/aarch64-firmware/, but I'm hoping that nobody cares and that if they care they're polite about it and let me take it down first before suing...

[xlazom00]

@qzed interesting. I am living in the world where linux firmware blob-s are just dumps/blobs that nobody cares

[merckhung]

Wanted to give a shout-out to @xlazom00 on helping with enabling DWC3 usb_2 function (USB-A ports and USB ethernet of MS Dev Kit 2023).

I also figured out how to configure the mDP port (mdss0_dp2 instead of mdss0_dp3 on X13s) and mDP detection GPIO (TLMM no.2) properly. The kernel config and dts are uploaded.

I would say, except sound card output is not worked out yet, every piece of MS Dev Kit 2023 machine has had a Linux driver loaded and working in some way as of now.

[merckhung]

Hi,

According to this git update: https://git.linaro.org/people/srinivas.kandagatla/audioreach-topology.git/

It looks to me the "Audio over DisplayPort of SC8280XP" is being enabled, thanks to the author. But it seems the commit is incomplete, therefore I'm not able to build my own audioreach topology for X13s, because of the missing symbol.

In the meantime, I am making a bootable Ubuntu 23.04 LiveCD, so that more audiences can test on their own devices. I will share more progress on that front.

[mirogl]

Hi @merckhung, since the Windows Dev Kit 2023 is based on the Surface Pro 9 5G (using the same mainboard as a base). Are there any plans / chances to get also the 5G running ? I plan to buy a Surface Pro 9 5G and would love to run Linux on it.

Thanks Miro

[qzed]

@mirogl The SP9 is probably quite a bit closer to the Lenovo X13s than the Dev Kit. Still, likely quite a bit of work required to get things working.

[chenguokai]

USB-C ports works as usual. Only one of them can display signal to the DisplayPort monitor, and the cable connector can't flip.

Hi @merckhung I have been trying to boot your kernel. It boots but fails to recognize my usb disks. I wonder if the USB-C works when it boots in your environment or is there any thing I need to pass besides the kernel Image itself.

[jglathe]

I also got it booting, however my system won't come up completely when you try to boot from USB disk. I had to use the nvme port, and even then I had to revert to using root=/dev/nvme0n1p2, because root={guid} would also fail. After booting USB disks are recognized and mounted fine. Still investigating the cause... I assume that init is a little too fast and the devices are not yet ready (or something)

Got it working with disabling the GUID boot parameter in grub.cfg.

/etc/default/grub:

GRUB_CMDLINE_LINUX_DEFAULT="iommu.strict=0 pd_ignore_unused clk_ignore_unused mitigations=off"
# Uncomment if you don't want GRUB to pass "root=UUID=xxx" parameter to Linux
GRUB_DISABLE_LINUX_UUID=true

This leads to the entry in /boot/grub/grub.cfg:

linux   /boot/vmlinuz-6.3.0+wdk2023+ root=/dev/nvme0n1p2 ro  iommu.strict=0 pd_ignore_unused clk_ignore_unused mitigations=off

update-grub finds the right partition itself.

[jglathe]

update on the "cannot mount root fs" issue: it is not a timing issue. Something else is amiss in my (probably odd) setup. rootdelay doesn't change a thing, so the USB stack doesn't appear to be up when it's trying to mount the root fs.

[chenguokai]

so the USB stack doesn't appear to be up when it's trying to mount the root fs.

How did you setup the rootfs without using a usb disk? Maybe I should try your method.

BTW I have got some interesting log:

By default usb storage support is compiled as a module, not as built-in. I changed the setting and add rootwait and rootdelay parameters to the kernel to find a log below:

The kernel seems to be delaying usb probing.

[jglathe]

How did you setup the rootfs without using a usb disk? Maybe I should try your method.

Not sure this is a good idea. I took an ubuntu 23.04 desktop preinstalled image for RPi 4B, put this on a 30mm nvme SSD in an USB casing, booted it with the RPi. Added an EFI partition, set it to bootable, installed grub-efi-aarch64. Somehow installed the newly compiled kernel, modules and dtb. Added some firmware. Had some battles with flash-kernel and update-initramfs. The intent was to have a disk that could always be booted by the RPi if something didn't work. This was a great help to approach this thing without screwing too much with the wdk hardware. Until I happened to run across the "couldn't mount root" issue. Next logical step was to use the internal nvme slot, since it insisted on showing the internal nvme partitions as the only block devices available (sometimes with UUIDs, sometimes with PARTUUIDs only). Explicitly giving the root=/dev/nvme0s1p2 command got it booting up to a login.

I have attached my dmesg output for reference: dmesg.txt

There are two crashes happening at boot time:

1. pcie_3a_gdsc status stuck at 'off' WARNING: CPU: 1 PID: 1 at drivers/clk/qcom/gdsc.c:180 gdsc_toggle_logic+0x174/0x188 Something doesn't work on PCIe...

2. WARNING: CPU: 3 PID: 191 at drivers/gpu/drm/panel/panel-edp.c:758 panel_edp_probe+0x4bc/0x530 This is a crash related to the miniDP connector. Works afterwards, though

I would assume that the first crash somehow partially kills bus discovery. Even when fully booted up, lspci won't show the xhci controllers (but they can be used).

jglathe@snapdragix:~$ lspci -tvnn
-+-[0000:00]-
 +-[0002:00]---00.0-[01-ff]----00.0  Sandisk Corp PC SN520 NVMe SSD [15b7:5004]
 \-[0006:00]---00.0-[01-ff]----00.0  Qualcomm Technologies, Inc QCNFA765 Wireless Network Adapter [17cb:1103]

Also, it is evident that at the moment when rootfs is to be mounted no USB hardware was discovered yet. This happens a second later:

[    2.155536] kernel: EDAC DEVICE0: Giving out device to module qcom_llcc_edac controller llcc: DEV qcom_llcc_edac (INTERRUPT)
[    2.160834] kernel: qcom_pmic_glink pmic-glink: Failed to create device link (0x180) with usb0-sbu-mux
[    2.172753] kernel: qcom_pmic_glink pmic-glink: Failed to create device link (0x180) with usb1-sbu-mux
[    2.172887] kernel: cfg80211: Loading compiled-in X.509 certificates for regulatory database
[    2.179443] kernel: dwc3 a600000.usb: Adding to iommu group 3
[    2.179957] kernel: Loaded X.509 cert 'sforshee: 00b28ddf47aef9cea7'
[    2.189077] kernel: adreno 3d00000.gpu: Adding to iommu group 4
[    2.191514] kernel: rtc-pm8xxx c440000.spmi:pmic@0:rtc@6100: registered as rtc0
[    2.191548] kernel: rtc-pm8xxx c440000.spmi:pmic@0:rtc@6100: setting system clock to 2023-06-16T04:04:43 UTC (1686888283)
[    2.192401] kernel: msm-mdss ae00000.display-subsystem: Adding to iommu group 5
[    2.194524] systemd-journald[234]: Oldest entry in /var/log/journal/da63cdfff2f4486283ca604d73523533/system.journal is older than the configured file retention duration (1month), suggesting rotation.
[    2.194529] systemd-journald[234]: /var/log/journal/da63cdfff2f4486283ca604d73523533/system.journal: Journal header limits reached or header out-of-date, rotating.
[    2.194946] kernel: remoteproc remoteproc0: 3000000.remoteproc is available
[    2.211252] kernel: remoteproc remoteproc0: powering up 3000000.remoteproc
[    2.211259] kernel: remoteproc remoteproc0: Booting fw image qcom/sc8280xp/MICROSOFT/DEVKIT23/qcadsp8280.mbn, size 14367860
[    2.213270] kernel: qcom_q6v5_pas 3000000.remoteproc: error -22 initializing firmware qcom/sc8280xp/MICROSOFT/DEVKIT23/qcadsp8280.mbn
[    2.213286] kernel: xhci-hcd xhci-hcd.1.auto: xHCI Host Controller
[    2.214387] kernel: remoteproc remoteproc0: can't start rproc 3000000.remoteproc: -22
[    2.215617] kernel: xhci-hcd xhci-hcd.1.auto: new USB bus registered, assigned bus number 1
[    2.218057] kernel: xhci-hcd xhci-hcd.1.auto: hcc params 0x0110ffc5 hci version 0x110 quirks 0x0000000000010010
[    2.218072] kernel: xhci-hcd xhci-hcd.1.auto: irq 210, io mem 0x0a600000
[    2.218138] kernel: xhci-hcd xhci-hcd.1.auto: xHCI Host Controller
[    2.218141] kernel: xhci-hcd xhci-hcd.1.auto: new USB bus registered, assigned bus number 2
[    2.218144] kernel: xhci-hcd xhci-hcd.1.auto: Host supports USB 3.1 Enhanced SuperSpeed
[    2.218183] kernel: usb usb1: New USB device found, idVendor=1d6b, idProduct=0002, bcdDevice= 6.03
[    2.218185] kernel: usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[    2.218187] kernel: usb usb1: Product: xHCI Host Controller
[    2.218188] kernel: usb usb1: Manufacturer: Linux 6.3.0+wdk2023+ xhci-hcd
[    2.218189] kernel: usb usb1: SerialNumber: xhci-hcd.1.auto
[    2.218194] kernel: remoteproc remoteproc1: 1b300000.remoteproc is available
[    2.218798] kernel: ath11k_pci 0006:01:00.0: assign IRQ: got 0
[    2.218872] kernel: ath11k_pci 0006:01:00.0: BAR 0: assigned [mem 0x30400000-0x305fffff 64bit]
[    2.218932] kernel: ath11k_pci 0006:01:00.0: enabling device (0000 -> 0002)
[    2.218960] kernel: ath11k_pci 0006:01:00.0: enabling bus mastering
[    2.222104] kernel: remoteproc remoteproc1: powering up 1b300000.remoteproc
[    2.222110] kernel: remoteproc remoteproc1: Booting fw image qcom/sc8280xp/MICROSOFT/DEVKIT23/qccdsp8280.mbn, size 3575808
[    2.222441] kernel: platform ae90000.displayport-controller: Fixed dependency cycle(s) with /soc@0/display-subsystem@ae00000/display-controller@ae01000/ports/port@0/endpoint
[    2.223976] kernel: qcom_q6v5_pas 1b300000.remoteproc: error -22 initializing firmware qcom/sc8280xp/MICROSOFT/DEVKIT23/qccdsp8280.mbn
[    2.225306] kernel: remoteproc remoteproc1: can't start rproc 1b300000.remoteproc: -22
[    2.228682] kernel: platform ae98000.displayport-controller: Fixed dependency cycle(s) with /soc@0/display-subsystem@ae00000/display-controller@ae01000/ports/port@4/endpoint
[    2.231860] kernel: hub 1-0:1.0: USB hub found
[    2.231875] kernel: hub 1-0:1.0: 1 port detected
[    2.232497] kernel: platform ae9a000.displayport-controller: Fixed dependency cycle(s) with /soc@0/display-subsystem@ae00000/displayport-controller@ae9a000/aux-bus/panel/ports/port/endpoint
[    2.232510] kernel: platform ae9a000.displayport-controller: Fixed dependency cycle(s) with /soc@0/display-subsystem@ae00000/display-controller@ae01000/ports/port@6/endpoint

with lots of odd warnings. But it might explain why booting form USB doesn't work (yet). So, still some work to do, but it's booting now and actually quite usable. I also built the kernel on it and added MGLRU :-)

[shvetsnikita]

@jglathe

Had some battles with flash-kernel and update-initramfs.

May I ask what you did here exactly? I assume you didn't use DtbLoader.efi, so you probably feed kernel with right dtb file via grub2, but is it automated by some script, or you just added devicetree line into grub.cfg?

I asking because AFAIK flash-kernel only copy dtb into /boot, but doesn't modify grub.cfg.

[chenguokai]

Update on boot from internal nvme disk:

I am able to boot into a partition with content from ubuntu 23.04 rpi image before the display port monitor lost its signal. I suppose DP should have been fixed in the latest kernel, any ideas?

EDIT: I am able to boot, as long as a currect initrd and kernel modules are installed to the RPI rootfs. ignore anything below.

The boot command line was clk_ignore_unused efi=novamap earlycon=efifb root=/dev/nvme0n1p4 ro iommu.strict=0 pd_ignore_unused mitigations=off

[jglathe]

flash-kernel is required for the u-boot the RPi is using. I actually added a wdk2023 entry and managed to install the dtb with symlink. This is all moot for grub2, best is to remove flash-kernel, grub-efi has its own boot loader.

• install grub-efi-aarch64, efivars
• copy the kernel, dtb and modules into the right places
• do some update-initramfs -c -k magic - could be tricky, I had to borrow a .config from another kernel (the raspi one should be ok?)
• run update-grub
• have a look into grub.cfg to make sure.

I have no complete writeup on this yet.