search

linux-surface / surface-pro-x

Tracking and meta repository for Surface Pro X support.
76 stars 6 forks source link

Windows Dev Kit 2023 Boot Work #43

Open nickdepinet opened 1 year ago

nickdepinet commented 1 year ago

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

shvetsnikita commented 1 year ago

I actually added a wdk2023 entry

Manually or it was created automatically by update-grub in your case?

jglathe commented 1 year ago

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?

hey, congrats! Can you ssh into it? DP will start working if you have the adreno firmware loaded. @merckhung (thank you again) gave this hint: "Adreno should be working out of the box as long as you have the a690 firmware and a660 firmware placed under /lib/firmware/qcom folder. You may download the a690 firmware from the Internet or debian package."

Not sure if its enough, or if I did something wrong, I got video working when I did update-initramfs on the wdk2023, and it listed the missing firmware files. Apparrently not all of them are working completely, but it gets you further. This is my notes from this:

Get firmware from the Debian firmware-nonfree package. Since we're on Ubuntu, we only get sources (should be sufficient)

in /etc/apt/sources.list:

#debian sources, only for qcom and ath firmware
deb-src https://deb.debian.org/debian/ sid non-free-firmware

get the package sources for firmware-qcom-soc

sudo apt-get source firmware-qcom-soc

in the source tree, copy files from firmware-nonfree-20230210/qcom/sc8280xp/LENOVO/21BX to /lib/firmware/qcom/sc8280xp/MICROSOFT/DEVKIT>

sudo mkdir -p /lib/firmware/qcom/sc8280xp/MICROSOFT/DEVKIT23/
sudo cp firmware-nonfree-20230210/qcom/sc8280xp/LENOVO/21BX/* /lib/firmware/qcom/sc8280xp/MICROSOFT/DEVKIT23/

/qcom/sdm845$ sudo cp a630_zap.mbn /lib/firmware/qcom/

Additional files missing:

https://github.com/TheMuppets/proprietary_vendor_google_barbet.git

sudo cp ~/src/wdk2023/proprietary_vendor_google_barbet/proprietary/vendor/firmware/a619_gmu.bin /lib/firmware/qcom/

https://github.com/Netronome/linux-firmware.git

~/src/wdk2023/linux-firmware$ sudo cp qcom/a530_zap.b* /lib/firmware/qcom/
jglathe commented 1 year ago

I actually added a wdk2023 entry

Manually or it was created automatically by update-grub in your case?

Manually in the flash-kernel /etc/flash-kernel/db, and also in /etc/flash-kernel/machine. As I said this is moot for grub. Grub will find a kernel and assign a dtb. If its the wrong one, edit to the right path.

        menuentry 'Ubuntu, with Linux 6.3.0+wdk2023+' --class ubuntu --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-6.3.0>
                recordfail
                load_video
                gfxmode $linux_gfx_mode
                insmod gzio
                if [ x$grub_platform = xxen ]; then insmod xzio; insmod lzopio; fi
                insmod part_msdos
                insmod ext2
                search --no-floppy --fs-uuid --set=root 65d266e9-d7b3-4b5a-806c-956a9f30c00e
                echo    'Loading Linux 6.3.0+wdk2023+ ...'
                linux   /boot/vmlinuz-6.3.0+wdk2023+ root=/dev/nvme0n1p2 ro  iommu.strict=0 pd_ignore_unused clk_ignore_unused mitigations=off
                echo    'Loading initial ramdisk ...'
                initrd  /boot/initrd.img-6.3.0+wdk2023+
                echo    'Loading device tree blob...'
                devicetree      /boot/dtb-6.3.0+wdk2023+
        }

I didn't have to, it was the right one...?

jglathe commented 1 year ago

before the display port monitor lost its signal

mm tried Alt-F2 if you get a login? There should be multiple consoles, you will get a text login if X can't start. Was the case here, at least.

shvetsnikita commented 1 year ago

Grub will find a kernel and assign a dtb.

Is there any prerequirements for this behavior? As this is does not happen for me for some reason - update-grub ignore dtb files in /boot, although flash-kernel created all necessary symlinks with right names, etc.

jglathe commented 1 year ago

Grub will find a kernel and assign a dtb.

Is there any prerequirements for this behavior? As this is does not happen for me for some reason - update-grub ignore dtb files in /boot, although flash-kernel created all necessary symlinks with right names, etc.

You're beyond my knowledge range with this question :) I wondered the same thing. update-initramfs won't work with flash-kernel present in my case, but it helped putting up the symlinks.

shvetsnikita commented 1 year ago

Found prerequirement - it's this patch: https://lists.gnu.org/archive/html/grub-devel/2019-05/msg00121.html https://lists.gnu.org/archive/html/grub-devel/2019-05/msg00133.html Which is probably present in your distribution, but not in mine: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=929427

Updated version of the patch from Canonical repository:

From: Dimitri John Ledkov <xnox@ubuntu.com>
Date: Wed, 22 May 2019 19:57:29 +0100
Subject: Add devicetree command, if a dtb is present.

Specically support dtb paths as installed by flash-kernel.

Signed-off-by: Dimitri John Ledkov <xnox@ubuntu.com>
Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=929427
Bug-Upstream: https://lists.gnu.org/archive/html/grub-devel/2019-05/msg00121.html
Patch-Name: ubuntu-add-devicetree-command-support.patch
---
 util/grub.d/10_linux.in | 19 +++++++++++++++++++
 1 file changed, 19 insertions(+)

diff --git a/util/grub.d/10_linux.in b/util/grub.d/10_linux.in
index ac6226f..2dc026b 100644
--- a/util/grub.d/10_linux.in
+++ b/util/grub.d/10_linux.in
@@ -254,6 +254,17 @@ EOF
 EOF
         fi
     fi
+    if test -n "${dtb}" ; then
+      if [ x"$quiet_boot" = x0 ] || [ x"$type" != xsimple ]; then
+        message="$(gettext_printf "Loading device tree blob...")"
+        sed "s/^/$submenu_indentation/" << EOF
+   echo    '$(echo "$message" | grub_quote)'
+EOF
+      fi
+      sed "s/^/$submenu_indentation/" << EOF
+   devicetree  ${rel_dirname}/${dtb}
+EOF
+    fi
   fi
   sed "s/^/$submenu_indentation/" << EOF
 }
@@ -389,6 +400,14 @@ while [ "x$list" != "x" ] ; do
     gettext_printf "Found initrd image: %s\n" "$(echo $initrd_display)" >&2
   fi

+  dtb=
+  for i in "dtb-${version}" "dtb-${alt_version}" "dtb"; do
+    if test -e "${dirname}/${i}" ; then
+      dtb="$i"
+      break
+    fi
+  done
+
   config=
   for i in "${dirname}/config-${version}" "${dirname}/config-${alt_version}" "/etc/kernels/kernel-config-${version}" ; do
     if test -e "${i}" ; then
chenguokai commented 1 year ago

I finally figured out. The reason for dp's signal loss is for lack of essential kernel modules in the rootfs. Also the rpi image contains garbage configurations that are likely to break. I made a clean rootfs with debootstrap and it works as expected.

jglathe commented 1 year ago

@chenguokai could you document a little how to? Great news, though

chenguokai commented 1 year ago

could you document a little how to?

Sure but maybe later. I am likely to work on it tomorrow

gauravsuman007 commented 1 year ago

Hi guys, I'm excited to follow the discussion but I'm a little lost on how to use the work from @merckhung and his device tree repository and the work done by @chenguokai .

In the past I've only built Ubuntu kernels by downloading their official sources and doing my modifications. Is there a how-to that I can go through to use the work done here?

Thanks a lot

jglathe commented 1 year ago

Actually, there is no complete writeup (yet). I tried to compile the kernel with debian toolchain, building deb packages. Didn't boot. What worked for me was:

-2. have a target fs. Needs to be on nvme ssd that can be put into the wdk. I used the RPi desktop image for Ubuntu 23.04. Not the best choice, but it did the job. -1. add all the firmwares you need. For a boot to console this might not be necessary, as my first successful boot was actually without added firmware.

  1. have a build machine, either native or cross
  2. clone the repo
  3. check out ms-dev-kit-2023-v6.3.0
  4. clean up: make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- mrproper
  5. configure: make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- devkit_defconfig
  6. make changes to the config: make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- menuconfig
  7. do the actual make: make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- Image.gz dtbs modules -j<threads you have available>
  8. get this to your target fs: rsync worked for me
  9. on the target fs: sudo make modules_install
  10. copy over Image.gz and dtb to the right place
  11. "borrow" a .config for update-initramfs
  12. update-initramfs -c -k <your kernel version>
  13. sudo update-grub
  14. install the nvme disk in the wdk, secure boot off, fire.

which is still quite error prone. Anyway, it's making progress. I googled a lot to put my sys together. Next up will be further comparison of wdk2023 device tree with the Thinkpad X13s one to fix odd behaviour. Obtaining the right firmware. MiniDP bugs. Getting the thing to boot from USB. Setting up a clean root fs with debootstrap. Enabling EL2 kvm (I know, but this is a goal to have). This thread is a good starting point.

chenguokai commented 1 year ago

I have summarized my key steps here. Hope it helps :-)

jglathe commented 1 year ago

@chenguokai That’s an elegant way to boot :-) thank you for documenting it.

gauravsuman007 commented 1 year ago

Thanks @jglathe ang @chenguokai , you guys made it really simple

likeadragonmaid commented 1 year ago

Is it possible to upstream this work to Ubuntu or similar distros for official support?

jglathe commented 1 year ago

@gibcheesepuffs oh boy we're far, far away from that.

jglathe commented 1 year ago

Got 6.4-rc6 running now. Better (different) pcie handling, but still no boot from USB. But, booting Win11 and Ubuntu 23.04 via grub works. Interesting detail: There were not many (<20?) commits left that are not in 6.4-rc6 itself. So, maybe just far away now. Another interesting detail: when booting from internal nvme and there's a Windows Boot Manager somewhere, disable it in the BIOS boot order or grub won't come up and you ask yourself what went wrong %-) Will document in the next days, the branch can be found here.

qzed commented 1 year ago

As far as I can tell, booting via USB should work (at least if the USB port works at all / when fully booted), but you might need the proper modules in the initramfs.

jglathe commented 1 year ago

The issue appears to be more subtle than that. dmesg has a crash recorded and a few of „failed“ messages regarding USB host controllers, something with clock and glink setup. The required drivers are there, also in the initrd file. I assume there‘s something not right in the device tree. This is my dmesg. dmesg.txt

jglathe commented 1 year ago

Added a discusion here.

jglathe commented 11 months ago

Since there is quite a similarity between a Surface pro 9 5G and the WDK2023, could somebody with access to the former please run 2 programs to get some info:

  1. run hwinfo64 and save the report as xml
  2. run start /w msinfo32.exe /report msiout.txt

I'm trying to get some insight on those drivers loaded by windows to decide what to do with the Linux Device Tree. Booting up with ACPI forced will get you into a boot loop, but my DTS is based on a Lenovo Thinkpad X13s and work from @merckhung (which works), however it is getting a lot of strange messages:

sudo dmesg|grep 'dummy regulator'
[    0.584571] qcom-qmp-usb-phy 88ef000.phy: supply vdda-phy not found, using dummy regulator
[    0.584680] qcom-qmp-usb-phy 88ef000.phy: supply vdda-pll not found, using dummy regulator
[    0.585228] qcom-qmp-usb-phy 88f1000.phy: supply vdda-phy not found, using dummy regulator
[    0.585303] qcom-qmp-usb-phy 88f1000.phy: supply vdda-pll not found, using dummy regulator
[    0.585606] qcom-snps-hs-femto-v2-phy 88e7000.phy: supply vdda-pll not found, using dummy regulator
[    0.585670] qcom-snps-hs-femto-v2-phy 88e7000.phy: supply vdda33 not found, using dummy regulator
[    0.585721] qcom-snps-hs-femto-v2-phy 88e7000.phy: supply vdda18 not found, using dummy regulator
[    0.585912] qcom-snps-hs-femto-v2-phy 88e8000.phy: supply vdda-pll not found, using dummy regulator
[    0.586051] qcom-snps-hs-femto-v2-phy 88e8000.phy: supply vdda33 not found, using dummy regulator
[    0.586111] qcom-snps-hs-femto-v2-phy 88e8000.phy: supply vdda18 not found, using dummy regulator
[    0.586251] qcom-snps-hs-femto-v2-phy 88e9000.phy: supply vdda-pll not found, using dummy regulator
[    0.587433] qcom-snps-hs-femto-v2-phy 88e9000.phy: supply vdda33 not found, using dummy regulator
[    0.588617] qcom-snps-hs-femto-v2-phy 88e9000.phy: supply vdda18 not found, using dummy regulator
[    0.589818] qcom-snps-hs-femto-v2-phy 88ea000.phy: supply vdda-pll not found, using dummy regulator
[    0.590957] qcom-snps-hs-femto-v2-phy 88ea000.phy: supply vdda33 not found, using dummy regulator
[    0.592080] qcom-snps-hs-femto-v2-phy 88ea000.phy: supply vdda18 not found, using dummy regulator
[    0.789998] qcom-pcie 1c00000.pcie: supply vdda not found, using dummy regulator
[    0.792076] qcom-pcie 1c20000.pcie: supply vdda not found, using dummy regulator
[    2.628722] adreno 3d00000.gpu: supply vdd not found, using dummy regulator
[    2.631947] adreno 3d00000.gpu: supply vddcx not found, using dummy regulator

sudo dmesg|grep 'deferred'
[    0.102545] node 0 deferred pages initialised in 91ms
[   14.310722] platform 3210000.soundwire-controller: deferred probe pending
[   14.310749] platform 3250000.soundwire-controller: deferred probe pending
[   14.310759] platform 3330000.soundwire-controller: deferred probe pending
[   14.310766] platform sound: deferred probe pending
[   14.310774] platform 3240000.codec: deferred probe pending
[   14.310781] platform 3370000.codec: deferred probe pending
[   14.310788] platform 3200000.rxmacro: deferred probe pending
[   14.310795] platform 3220000.txmacro: deferred probe pending
[   14.310802] platform 33c0000.pinctrl: deferred probe pending

I'd like to improve on that state. The box is quite usable, though.

qzed commented 11 months ago

@jglathe Regarding deferred probes you can also try cat /sys/kernel/debug/devices_deferred.

jglathe commented 11 months ago

@qzed 

sudo cat /sys/kernel/debug/devices_deferred
sound   snd-sc8280xp: WCD Playback: error getting cpu dai name
3210000.soundwire-controller    platform: supplier 3200000.rxmacro not ready
3250000.soundwire-controller    platform: supplier 3240000.codec not ready
3330000.soundwire-controller    platform: supplier 3220000.txmacro not ready
3240000.codec   platform: wait for supplier /soc@0/pinctrl@33c0000/wsa-swr-default-state
3370000.codec   platform: wait for supplier /soc@0/pinctrl@33c0000/dmic02-default-state
3200000.rxmacro platform: wait for supplier /soc@0/pinctrl@33c0000/rx-swr-default-state
3220000.txmacro platform: wait for supplier /soc@0/pinctrl@33c0000/tx-swr-default-state
33c0000.pinctrl qcom-sc8280xp-lpass-lpi-pinctrl: Failed to get clk 'core'

That's something. Thanks!

mirogl commented 11 months ago

Since there is quite a similarity between a Surface pro 9 5G and the WDK2023, could somebody with access to the former please run 2 programs to get some info:

  1. run hwinfo64 and save the report as xml
  2. run start /w msinfo32.exe /report msiout.txt

Hi I have both - a Surface Pro 9 5G and the WDK2023. But since both run a german Windows 11, the output of msinfo32.exe is in German - and I would need to switch the system language to english.

So - do you need the hwinfo64 only from the Surface Pro 9 5G ? Do you need msinfo32.exe - or is the input enough from hwinfo64 ?

Thanks Miro

jglathe commented 11 months ago

@mirogl Great! German would be fine :) I would need both msinfo32 (it shows other things, too) and hwinfo64. Thank you!

mirogl commented 11 months ago

@mirogl Great! German would be fine :) I would need both msinfo32 (it shows other things, too) and hwinfo64. Thank you!

Hi, ok - I attached the files - just removed the serial number,

SurfaceHWInfo.zip

xlazom00 commented 11 months ago

https://www.cnx-software.com/2023/07/28/armbian-ubuntu-23-04-can-now-run-on-lenovo-x13s-arm-laptop/

jglathe commented 10 months ago

The WDK boots now from USB. MHI drivers need to be built as modules, that's it. Found this out comparing my lsmod with the one of the Thinkpad X13s with @armbian with the WDK one. Also, rebased the code to 6.5-rc5, and guess what, most of the required changes are already in upstream. It's 5 measly commits (or so) that are not. Looks like we can close this issue soon.

jglathe commented 10 months ago

https://github.com/jglathe/linux_ms_dev_kit/discussions/1#discussioncomment-6795620

An image bootable from USB is now available here. The image is Ubuntu 23.04 live for Desktop (raspi), marginally altered for grub-efi boot. The wdk-specific firmware is not in the image, it will be fetched with a script from the Windows installation. Should be good to test Linux on the box without too much fuss.

mirogl commented 10 months ago

Hi, many thanks - I tried the USB Image from 01.09. and it booted into Desktop and crashed while running the installer. Then it started the Desktop again - but i can't start the Ubuntu installer. I wanted to install Ubuntu directly on the SSD - is this currently possible or is this a normal, that the installation is not possible - so it should run only from the external USB drive ? Thanks Miro

jglathe commented 10 months ago

Actually not tested. Is there an installer on this thing? I doubt it. Currently I'm doing a new image with 6.5.0 from raspi-scratch, might be worth the wait. Installing on the local nvme like we knew and expect from the x86-based systems is a thing to find out I guess. The raspi-image is for an sdcard... therein lies the issue. But if you want to "install" you could fake it. Should work this way:

You might want to install /etc/initramfs-tools/modulesas described here, this gives you better working USB-C ports.

mirogl commented 10 months ago

Hi, Many thanks for the infos. So I will wait for the 6.5.0 image, before I try to install it on my SSD. Great work and many thanks !

jglathe commented 10 months ago

Just did my first test run with the new 6.5.0 USB stick. Almost everything works, yay. Only 2 oddities:

clausecker commented 8 months ago

I'm using the Windows 2023 Dev Kit as an ARM compile box for FreeBSD. It works well, the biggest annoyance is that we can't boot into EL2 for virtualisation. Does anybody know what needs to be done to do that?

qzed commented 8 months ago

I'm using the Windows 2023 Dev Kit as an ARM compile box for FreeBSD. It works well, the biggest annoyance is that we can't boot into EL2 for virtualisation. Does anybody know what needs to be done to do that?

Yeah... new firmware from Qualcomm. Or some kind of exploit.

Unfortunately EL2 just isn't accessible for us (at the moment at least). Virtualization on Windows is implemented via a custom Secure Launch protocol, which validates and loads a signed stub into EL2. That stub then sets up everything else. There might be a way to use it and essentially follow what Windows does, but so far no one made that work. And pretty much everything seems to be checked against known signatures, so it'd be pretty hard to pull that off. In other words: It's specifically designed in a way that you can't run arbitrary code in EL2 (where "arbitrary" sadly includes everything except for certain binaries signed by MS). You can find a lot more details on this here: https://github.com/TravMurav/Qcom-Secure-Launch.

tilator commented 4 months ago

Anyway, looks promising. It is published at the usual place.

Hi,

I have a SP9 SQ3 too and can test it.

So far it seems that 6.6.0 version boots without display. Unfortunately I can not SSH it even though network is up and running having USB-C adapter connected and router lists the device.

Is it possible SSH is off?

jglathe commented 4 months ago

Hmm interesting. SSH is not on AFAIR. But, willing to do another image with it on and a default user. I would assume that the SP9 5G has its own specifically signed firmwares, too. But getting a dmesg would certainly help.

Typing this from a Volterra running on EL2, btw :)

jglathe commented 4 months ago

I'm using the Windows 2023 Dev Kit as an ARM compile box for FreeBSD. It works well, the biggest annoyance is that we can't boot into EL2 for virtualisation. Does anybody know what needs to be done to do that?

This is possible now (since about 2 weeks or so, thanks to slbounce from @travmurav). I have a dedicated branch on my repo named el2-hackery. Need to write up the how-to, still. You won't have PCIE devices and a few other things, but USB is working well, and the ethernet port, too. Running here on EL2 with a VM for tests.

jglathe commented 4 months ago

These are the devices that work:

jglathe@sdbox2:~$ sudo lshw -short
H/W path          Device           Class      Description
=========================================================
                                   system     Microsoft Dev Kit 2023
/0                                 bus        Windows Dev Kit 2023
/0/0                               memory     384KiB L1 cache
/0/1                               memory     384KiB L1 cache
/0/2                               memory     1280KiB L2 cache
/0/3                               memory     2MiB L3 cache
/0/4                               processor  ARM (428)
/0/5                               memory     32GiB System Memory
/0/5/0                             memory     32GiB TSOP LPDDR4 2092 MHz (0.5 ns)
/0/8                               memory     1MiB BIOS
/0/6                               processor  cpu-map
/0/7                               processor  cpu
/0/9                               processor  cpu
/0/a                               processor  cpu
/0/b                               processor  cpu
/0/c                               processor  cpu
/0/d                               processor  cpu
/0/e                               processor  cpu
/0/f                               processor  cpu
/0/10                              processor  domain-idle-states
/0/11                              processor  idle-states
/1                usb1             bus        xHCI Host Controller
/1/1                               bus        USB2.1 Hub
/1/1/2                             bus        USB2.0 Hub
/1/1/2/3                           bus        USB2.0 Hub
/1/1/2/4          input10          input      Cherry USB keyboard
/1/1/3                             input      USB Receiver
/1/1/3/0          input12          input      Logitech M185
/2                usb2             bus        xHCI Host Controller
/2/1                               bus        USB3.2 Hub
/2/1/1                             generic    USB 10/100/1000 LAN
/2/1/2                             bus        USB3.0 Hub
/2/1/2/1          scsi1            storage    Ugreen Storage Device
/2/1/2/1/0.0.0    /dev/sdb         disk       240GB SSD PLUS 240GB
/2/1/2/1/0.0.0/1                   volume     259MiB Windows FAT volume
/2/1/2/1/0.0.0/2  /dev/sdb2        volume     223GiB EXT4 volume
/2/1/2/3                           bus        USB3.0 Hub
/3                usb3             bus        xHCI Host Controller
/4                usb4             bus        xHCI Host Controller
/4/1              scsi0            storage    Ugreen Storage Device
/4/1/0.0.0        /dev/sda         disk       1920GB Pro III
/4/1/0.0.0/1      /dev/sda1        volume     15MiB reserved partition
/4/1/0.0.0/2      /dev/sda2        volume     1738GiB Windows NTFS volume
/5                usb5             bus        xHCI Host Controller
/6                usb6             bus        xHCI Host Controller
/7                /dev/fb0         display    msmdrmfb
/8                input13          input      pmic_pwrkey
/9                input14          input      pmic_resin
/a                enxa04a5edf9958  network    Ethernet interface
tilator commented 4 months ago

Hmm interesting. SSH is not on AFAIR. But, willing to do another image with it on and a default user. I would assume that the SP9 5G has its own specifically signed firmwares, too. But getting a dmesg would certainly help.

That's what I had on my mind too. Editing SSH config file to enable password login did not help.

jglathe commented 4 months ago

That's what I had on my mind too. Editing SSH config file to enable password login did not help.

And regarding display: That would be internal, probably different port (mdss0_dp3?) And edp-panel. Will take a few tries to get this working I'm afraid. Will do a new image at the weekend I guess.

tilator commented 4 months ago

I have been playing around with this ARM-Surface. Booted it from a USB with some wrong bios settings and it ended up to some error. Seems to have some PCI address. Might it be for any use/help?

I try to attach a picture here. 20240215_140336

jglathe commented 4 months ago

This is an error of the ntfs-3g driver of the uefi-ntfs boot function. I have seen this one, had opened a ticket there, it got fixed. Maybe it is because you have secure boot enabled, but this is unrelated to booting the Ubuntu image (I hope). For this, secure boot needs to be off (I assume) and USB boot enabled. You should see a grub menu to boot it up. When disabling secure boot, be aware that this can get you into Bitlocker woes . New boot image to try will come on weekend, it's progressing. Will be Kernel 6.7.1, this one seems to work quite nice even with my very odd 4k Iiyama display.

tilator commented 4 months ago

This:

https://github.com/WOA-Project/Qualcomm-Reference-Drivers/tree/master/Surface

suggests there is some driver/FW differencies between development kit and Surface. Do you know if this makes more trouble?

jglathe commented 4 months ago

I guess we‘ll find out. The opp tables and thermal limits can be set in the device tree file. Lets get it to at least ssh first :grin:Von meinem iPhone gesendetAm 17.02.2024 um 11:53 schrieb tilator @.***>: This: https://github.com/WOA-Project/Qualcomm-Reference-Drivers/tree/master/Surface suggests there is some driver/FW differencies between development kit and Surface. Do you know if this makes more trouble?

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: @.***>

JeromeDeBretagne commented 4 months ago

Hi,

I have a Microsoft Surface Pro 9 5G too, and I have been able to install Debian on its NVMe SSD following the instructions for the Lenovo Thinkpad X13s from the Debian Wiki here using a recent Debian netinst image flashed on a USB stick.

I have created and used a minimal devicetree to do so, based on the Thinkpad X13s one, copied on the USB stick and I can proceed with the Debian installation by editing the Grub entry to add a devicetree /sc8280xp-microsoft-surface-pro-9-5G.dtb line.

I have added both the .dts and .dtb files in the branch here in this commit, this is based on the Linux 6.7 branch from @jhovold.

With this initial setup, I have the following working : NVMe, Wi-Fi, USB. The surface keyboard doesn't work so I am using an external USB keyboard for the moment.

Surprisingly, I have the display working during the Debian installation in console mode but when booting with the Debian system installed on the NVMe SSD, I end up with a black screen after seeing the initial boot messages, I don't know what's the difference between the 2 cases.

Luckily, I can ssh onto the machine over Wi-Fi so I will be able to continue my investigation and improve the devicetree overtime to support more features. The wireless connectivity doesn't seem to work on each boot, sometimes I have to reboot my SP9 5G two or three times to finally see it connect to my local Wi-Fi network, and it's a joy to find as I don't have a fixed mac address nor a fixed IP address either :-) but that's a minor inconvenience at this stage.

My first priority would be to get the built-in display and/or external display over USB-C working, then the keyboard and touchpad if possible. It's a bit annoying as I have to add the devicetree line upon each boot, I still need to better understand how Debian's Grub supports devicetree files, where to put them on the filesystem, etc.

If anyone has some suggestions, I am more than happy to give them a try. I can provide some files / command outputs to help with the investigation of course. Finally I plan to try and get an acpidump soon too, as it may be useful.

Thanks, Jérôme

JeromeDeBretagne commented 4 months ago

Finally I plan to try and get an acpidump soon too, as it may be useful.

Microsoft Surface Pro 9 5G ACPI dump extracted, shared here for info: https://github.com/linux-surface/acpidumps/issues/27

jglathe commented 4 months ago

The Volterra box is using the same mainboard. So maybe using the dts from Volterra might be a better fit. But since it's there... :grin: Does the SP9 5G have a mini-DP out? Actually, as of 6.7, USB-C display works kinda nicely with Volterra, but only one of them. I guess its USB-1. It's 2 lanes only, too, so 4K@60 is a little out of reach. But 2560x1440 works here. I prefer the miniDP of the Volterra, it's recognized and used as 4 lanes. The acpi dump should help identifying i2c hid ports, thank you. regarding the screen, I would assume it needs some firmware files. all 8280.mbn files are device specific (signing), need to be extracted/copied from the Windows partition. The dts should have dedicated file paths, like 

&remoteproc_adsp {
    firmware-name = "qcom/sc8280xp/MICROSOFT/DEVKIT23/qcadsp8280.mbn";

    status = "okay";
};

&remoteproc_nsp0 {
    firmware-name = "qcom/sc8280xp/MICROSOFT/DEVKIT23/qccdsp8280.mbn";

    status = "okay";
};

I actually created a script to extract these files from the (not bitlockered) Windows partition, branch x13s is the newest.

Nice to see this going forward. I was tied up this weekend, unfortunately. Work and EL2 stuff, mostly work.

tilator commented 4 months ago

Does the SP9 5G have a mini-DP out?

It only has 2 USB-C ports. There is a separate connector for Surface keyboard but I don't know what else it might cover.