New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Windows Dev Kit 2023 Boot Work #43
Comments
|
Booting the image from number 2 above with the devicetree line removed gets into a boot loop. Adding there are a bunch of BAR and firmware errors further up the log as well that may be worth investigating |
|
swapping in |
|
So at this point you'll probably really want to head over to 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:
maybe more... |
|
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 |
|
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 |
|
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. |
|
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 |
|
I'd guess some MMIO region or something is being accessed that hasn't been powered up yet... but hard to tell what exactly... |
|
@nickdepinet - just out of curiosity: did you make any further progress in getting this device to boot mainline linux? |
|
Any progress? |
|
@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. |
|
@qzed btw motherboard in dev kit is same as surface pro 9 |
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 |
I'm not aware of any, sorry. |
|
@nickdepinet I haven't got time to debug, but that RCU stall issue seems caused by cpuidle support. You can try to disable |
|
Has anyone seen merckhung/linux_ms_dev_kit@195ccc9? Source: https://twitter.com/merckhung/status/1602205575902683136 |
|
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. |
|
@qzed can you plz cherrypick that to your 6.2 linux kernel |
|
@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. |
|
I was able to boot with Johan's Hovald(@jhovold) git with this I still have some problems
|
|
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!!! |
|
@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. |
@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. |
|
Is there any progress on this - by any luck? |
|
Sorry :) I made this branch of armbian
Kernel will use ACPI to setup hw armbian will use https://github.com/jhovold/linux/tree/wip/sc8280xp-v6.3-rc4 Thank you for @jhovold and @shawnguo2 work! Now it will be nice to have device tree version with all drivers |
|
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. |
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. |
|
Just want to give some update on the Device Tree enablement for Microsoft Dev Kit 2023.
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. |
|
@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? |
|
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). |
|
@qzed I only want to know why they are not in https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/ |
|
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... |
|
@qzed interesting. I am living in the world where linux firmware blob-s are just dumps/blobs that nobody cares |
|
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. |
|
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. In the meantime, I am making a bootable Ubuntu 23.04 LiveCD, so that more audiences can test on their own devices. |





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
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
devicetreeoption from the boot entry. That should get you booting in ACPI mode.is way before any firmware gets loaded, so I doubt that that will make any difference. Can you make sure that
efi=novamapis set (pressein 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 thedevicetreeoption 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-laptopsIRC. There are a lot more experienced people who also might have some ideas.Originally posted by @qzed in #7 (comment)
The text was updated successfully, but these errors were encountered: