search

linux-surface / surface-pro-x

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

MS Surface 9 Pro 5G #46

Open tilator opened 3 months ago

tilator commented 3 months ago

Let's discuss here about MS Surface.

I booted the new image now. Then I removed all new files from /usr/lib/firmware/qcom/sc8280xp/MICROSOFT/DEVKIT23 folder.

Now it boots and reboots letting network and SSH come up.

Is it possible to run the script again to get those files back?

tilator commented 3 months ago

Deleting qcadsp8280.mbn makes it boot again. Other files are allowed.

Attached is dmesg after this modification. dmesg_2.txt

tilator commented 3 months ago

Here is some addition to the dmesg:

[  407.185520] r8152-cfgselector 5-1: USB disconnect, device number 2
[  407.216411] firmware_class:__free_fw_priv: firmware_class: __free_fw_priv: fw-rtl_nic/rtl8153a-3.fw fw_priv=000000006b97e10a data=00000000803d95d2 size=1440
[  407.240122] firmware_class:fw_name_devm_release: firmware_class: fw_name_devm_release: fw_name-rtl_nic/rtl8153a-3.fw devm-000000005ee3e6a4 released
[  442.194004] usb 5-1: new full-speed USB device number 3 using xhci-hcd
[  442.362830] usb 5-1: not running at top speed; connect to a high speed hub
[  442.389990] usb 5-1: New USB device found, idVendor=25a4, idProduct=9311, bcdDevice= 2.01
[  442.390029] usb 5-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[  442.390041] usb 5-1: Product: USB C Video Adaptor
[  442.390052] usb 5-1: Manufacturer: USB C
[  442.390061] usb 5-1: SerialNumber: 000000000001
[  457.509207] usb 5-1: USB disconnect, device number 3
[  467.314754] usb 5-1: new full-speed USB device number 4 using xhci-hcd
[  467.482770] usb 5-1: not running at top speed; connect to a high speed hub
[  467.511212] usb 5-1: New USB device found, idVendor=25a4, idProduct=9311, bcdDevice= 2.01
[  467.511254] usb 5-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[  467.511267] usb 5-1: Product: USB C Video Adaptor
[  467.511277] usb 5-1: Manufacturer: USB C
[  467.511286] usb 5-1: SerialNumber: 000000000001
[  481.143084] usb 5-1: USB disconnect, device number 4
[  496.696187] usb 5-1: new high-speed USB device number 5 using xhci-hcd
[  496.851861] usb 5-1: New USB device found, idVendor=0bda, idProduct=8153, bcdDevice=30.00
[  496.851901] usb 5-1: New USB device strings: Mfr=1, Product=2, SerialNumber=6
[  496.851914] usb 5-1: Product: USB 10/100/1000 LAN
[  496.851924] usb 5-1: Manufacturer: Realtek
[  496.851932] usb 5-1: SerialNumber: 000001000000
[  497.061800] r8152-cfgselector 5-1: reset high-speed USB device number 5 using xhci-hcd
[  497.224598] firmware_class:__allocate_fw_priv: firmware_class: __allocate_fw_priv: fw-rtl_nic/rtl8153a-3.fw fw_priv=0000000005c09bb9
[  497.224736] firmware_class:fw_get_filesystem_firmware: r8152 5-1:1.0: loading /lib/firmware/updates/6.7.1-gd7da5073ce3d/rtl_nic/rtl8153a-3.fw failed for no such file or directory.
[  497.224809] firmware_class:fw_get_filesystem_firmware: r8152 5-1:1.0: loading /lib/firmware/updates/rtl_nic/rtl8153a-3.fw failed for no such file or directory.
[  497.224835] firmware_class:fw_get_filesystem_firmware: r8152 5-1:1.0: loading /lib/firmware/6.7.1-gd7da5073ce3d/rtl_nic/rtl8153a-3.fw failed for no such file or directory.
[  497.227767] firmware_class:fw_get_filesystem_firmware: r8152 5-1:1.0: loading /lib/firmware/rtl_nic/rtl8153a-3.fw failed for no such file or directory.
[  497.227794] firmware_class:fw_get_filesystem_firmware: r8152 5-1:1.0: loading /lib/firmware/updates/6.7.1-gd7da5073ce3d/rtl_nic/rtl8153a-3.fw.zst failed for no such file or directory.
[  497.227810] firmware_class:fw_get_filesystem_firmware: r8152 5-1:1.0: loading /lib/firmware/updates/rtl_nic/rtl8153a-3.fw.zst failed for no such file or directory.
[  497.227823] firmware_class:fw_get_filesystem_firmware: r8152 5-1:1.0: loading /lib/firmware/6.7.1-gd7da5073ce3d/rtl_nic/rtl8153a-3.fw.zst failed for no such file or directory.
[  497.239634] firmware_class:fw_get_filesystem_firmware: r8152 5-1:1.0: Loading firmware from /lib/firmware/rtl_nic/rtl8153a-3.fw.zst
[  497.239648] firmware_class:fw_get_filesystem_firmware: r8152 5-1:1.0: f/w decompressing rtl_nic/rtl8153a-3.fw
[  497.239788] firmware_class:fw_set_page_data: firmware_class: fw_set_page_data: fw-rtl_nic/rtl8153a-3.fw fw_priv=0000000005c09bb9 data=000000007f121b56 size=1440
[  497.239868] firmware_class:fw_log_firmware_info: r8152 5-1:1.0: Loaded FW: rtl_nic/rtl8153a-3.fw, sha256: c7099a1b0fc80e02ff7276aacbb08b5771e2f5c763fb76a7a8df3a89d58d8208
[  497.261019] r8152 5-1:1.0: load rtl8153a-3 v2 02/07/20 successfully
[  497.290504] r8152 5-1:1.0 eth0: v1.12.13
[  497.313277] usbcore: registered new interface driver r8153_ecm
[  497.319984] r8152 5-1:1.0 enxa0cec80839bf: renamed from eth0
[  499.917878] r8152 5-1:1.0 enxa0cec80839bf: carrier on

This was taken by first removing USB-RJ45 adapter. Then connecting USB-HDMI adapter. Removing and connecting it second time. Then removing USB-HDMI and connecting USB-RJ45 again.

jglathe commented 3 months ago

You can execute sudo fetch_sc8280xp_fw.sh, fetches the firmwares to /usr/lib/firmware/updates. Every time you think they should be refreshed. @JeromeDeBretagne how about setting up a separate dts file like sc8280xp-microsoft-arcata.dts ? There will be some differences I'm sure, DP use for example and WWAN. Maybe a good idea to declare a separate firmware path, too.

jglathe commented 3 months ago

Do you get a screen with the USB-C video adapter? Not impossible.

jglathe commented 3 months ago

For debugging dp operation, please add drm.debug=0x100 to your boot command line.

tilator commented 3 months ago

how about setting up a separate dts file like sc8280xp-microsoft-arcata.dts ? There will be some differences I'm sure, DP use for example and WWAN. Maybe a good idea to declare a separate firmware path, too.

How are these made? Does it need dtb compiled again using the arcata dts? I have not been compiling linux kernel for some years. I don't even know which cross-compiler it takes.

tilator commented 3 months ago

Do you get a screen with the USB-C video adapter? Not impossible.

Nothing come up. I tried cold booting and connecting adapter while it was already up.

tilator commented 3 months ago

For debugging dp operation, please add drm.debug=0x100 to your boot command line.

This is grub parameter, I suppose.

tilator commented 3 months ago

How about this qcadsp8280.mbn preventing it booting up. Might it be just some kind of loading order issue?

jglathe commented 3 months ago

Need to look into the dmesg. The fun part is, after copying the firmwares they are also integrated into the initrd :grin: So they will be loaded, but they also should load. Yes it is a grub parameter.

tilator commented 3 months ago

Here is dmesg with grub debug option as you wished. dmesg_3.txt

jglathe commented 3 months ago

How are these made? Does it need dtb compiled again using the arcata dts? I have not been compiling linux kernel for some years. I don't even know which cross-compiler it takes.

You can compile on the sp9, no prob. Tthe separate dts file is given as boot parameter, usually by providing a link before update-grub. Thanks for the dmesg. I have created the new dts and a new branch.

tilator commented 3 months ago

Need to look into the dmesg. The fun part is, after copying the firmwares theay are also integrated into the initrd :grin So they will be loaded, but they also should load.

Thats weird. How could removing one of the firmware files from userspace FS effect booting then.

jglathe commented 3 months ago

Thats weird. How could removing one of the firmware files from userspace FS effect booting then.

No idea yet. But many of these are actually loaded.

JeromeDeBretagne commented 3 months ago

You can execute sudo fetch_sc8280xp_fw.sh, fetches the firmwares to /usr/lib/firmware/updates. Every time you think they should be refreshed. @JeromeDeBretagne how about setting up a separate dts file like sc8280xp-microsoft-arcata.dts ? There will be some differences I'm sure, DP use for example and WWAN. Maybe a good idea to declare a separate firmware path, too.

Yes, I just did in fact :-) You can find my update here, I can copy & past it here if you want.

JeromeDeBretagne commented 3 months ago

How are these made? Does it need dtb compiled again using the arcata dts? I have not been compiling linux kernel for some years. I don't even know which cross-compiler it takes.

You shouldn't need to, I have provided both the .dts source but also the compiled .dtb files in my repository in the following branch: https://github.com/JeromeDeBretagne/linux_surface_pro_9_5G/commits/wip/sc8280xp-v6.7/

The latest .dtb should get external display working with the bottom USB-C port, if you provide the .dtb file at boot with a devicetree line and with the right firmware files extracted from the Windows partition / drive. I have used the following path for the firmware files "qcom/sc8280xp/MICROSOFT/SurfacePro9/" in the devicetree, so it needs to be in this specific location.

jglathe commented 3 months ago

Can you list the firmware files fetched by fetch_sc8280xp_fw.sh? The output of it running in bash should be enough. As it seems the files are not there. The co-processors boot up, though.

tilator commented 3 months ago

The latest .dtb should get external display working with the bottom USB-C port, if you provide the .dtb file at boot with a devicetree line and with the right firmware files extracted from the Windows partition / drive. I have used the following path for the firmware files "qcom/sc8280xp/MICROSOFT/SurfacePro9/" in the devicetree, so it needs to be in this specific location.

I found the dtb file. I suppose dts is not needed if the device tee blob is loaded by bootloader, right?

I did not find the "qcom/sc8280xp/MICROSOFT/SurfacePro9/" folder anywhere. Are the files same as grabbed from Windows?

jglathe commented 3 months ago

I did not find the "qcom/sc8280xp/MICROSOFT/SurfacePro9/" folder anywhere. Are the files same as grabbed from Windows?

Yes they are. You can just mv the directory tree: sudo mv /usr/lib/firmware/updates/qcom/sc8280xp/MICROSOFT/DEVKIT23 /usr/lib/firmware/updates/qcom/sc8280xp/MICROSOFT/SurfacePro9

would still be interesting what's in here

tilator commented 3 months ago

would still be interesting what's in here

There is all except the one I removed:

root@ubuntu: ls /usr/lib/firmware/qcom/sc8280xp/MICROSOFT/DEVKIT23/ -la total 5520 drwxr-xr-x 2 root root 4096 Mar 4 11:41 . drwxr-xr-x 3 root root 4096 Oct 22 20:10 .. -rwxr-xr-x 1 root root 534 Mar 4 11:27 adspr.jsn -rwxr-xr-x 1 root root 731 Mar 4 11:27 adspua.jsn -rwxr-xr-x 1 root root 537 Mar 4 11:27 battmgr.jsn -rwxr-xr-x 1 root root 534 Mar 4 11:27 cdspr.jsn -rwxr-xr-x 1 root root 3571712 Mar 4 11:37 qccdsp8280.mbn -rwxr-xr-x 1 root root 14392 Mar 4 11:39 qcdxkmsuc8280.mbn -rwxr-xr-x 1 root root 2035812 Mar 4 11:41 qcvss8280.mbn root@ubuntu

qcadsp8280.mbn is just moved to an other location. I can put it back when I try the other device tree.

Did I understand it right, the dtb-file has path to the FW directory, which is "qcom/sc8280xp/MICROSOFT/SurfacePro9/" in Jerome's dtb?

jglathe commented 3 months ago

Looks okay to me:

jglathe@sdbox2:~/Downloads$ ls /usr/lib/firmware/qcom/sc8280xp/MICROSOFT/DEVKIT23/ -la
total 19728
drwxr-xr-x 2 root root     4096 Mar 13  1970 .
drwxr-xr-x 3 root root     4096 Oct 22 22:10 ..
-rwxr-xr-x 1 root root      534 Feb 19 08:23 adspr.jsn
-rwxr-xr-x 1 root root      731 Feb 19 08:23 adspua.jsn
-rwxr-xr-x 1 root root      537 Feb 19 08:23 battmgr.jsn
-rwxr-xr-x 1 root root      534 Feb 19 08:23 cdspr.jsn
-rwxr-xr-x 1 root root 14545260 Feb 19 08:23 qcadsp8280.mbn
-rwxr-xr-x 1 root root  3571712 Feb 19 08:23 qccdsp8280.mbn
-rwxr-xr-x 1 root root    14392 Feb 19 08:23 qcdxkmsuc8280.mbn
-rwxr-xr-x 1 root root  2035748 Feb 19 08:23 qcvss8280.mbn
tilator commented 3 months ago

Looks okay to me:

If you compare it to my listing above, mine is missing the one file I told.

jglathe commented 3 months ago

Yep. You need to add some other stuff I'm afraid.

/etc/initramfs-tools/modules needs to be this:

pwm_bl
phy_qcom_qmp_pcie
pcie_qcom
phy_qcom_qmp_combo
qrtr
phy_qcom_edp
gpio_sbu_mux
i2c_hid_of
i2c_qcom_geni
pmic_glink_altmode
leds_qcom_lpg
gpucc_sc8280xp
dispcc_sc8280xp
panel_edp
msm
nvme
usb_storage
uas

The one for the wdk doesn't contain all of them (no panel).

Also, /etc/initramfs-tools/hooks/wdk23-firmware needs a changed path to the new firmwares.

#!/bin/sh

set -e

PREREQ=""

prereqs()
{
        echo "$PREREQ"
}

case \\$1 in
# get pre-requisites
prereqs)
        prereqs
        exit 0
        ;;
esac

. /usr/share/initramfs-tools/hook-functions

#set target dir for firmware files
FW_BASEDIR="lib/firmware"
FW_USERDIR="usr/lib/firmware/updates"

# Define a list of firmware files to be included
FIRMWARE_FILES="\
$FW_USERDIR/qcom/sc8280xp/MICROSOFT/SurfacePro9/qcadsp8280.mbn \
$FW_USERDIR/qcom/sc8280xp/MICROSOFT/SurfacePro9/qccdsp8280.mbn \
$FW_USERDIR/qcom/sc8280xp/MICROSOFT/SurfacePro9/qcdxkmsuc8280.mbn \
$FW_USERDIR/qcom/sc8280xp/MICROSOFT/SurfacePro9/qcvss8280.mbn \
$FW_BASEDIR/qcom/a660_sqe.fw.zst \
$FW_BASEDIR/qcom/a660_gmu.bin.zst \
$FW_BASEDIR/rtl_nic/rtl8153b-2.fw.zst"

# Copy each firmware file to initramfs
for file in $FIRMWARE_FILES; do
    dir=$(dirname "$file")
    mkdir -p "${DESTDIR}/${dir}"
    cp "/${file}" "${DESTDIR}/${dir}/"
done

afterwards, update initramfs:

sudo update-initramfs -u -k all

and reboot.

jglathe commented 3 months ago

Did I understand it right, the dtb-file has path to the FW directory, which is "qcom/sc8280xp/MICROSOFT/SurfacePro9/" in Jerome's dtb?

yes. It is compiled-in.

tilator commented 3 months ago

This is what happened:

root@ubuntu:/etc# update-initramfs -u -k all
update-initramfs: Generating /boot/initrd.img-6.7.1-gd7da5073ce3d
/etc/initramfs-tools/hooks/wdk23-firmware: 1: !/bin/sh: not found
/etc/initramfs-tools/hooks/wdk23-firmware: 1: !/bin/sh: not found
update-initramfs: Generating /boot/initrd.img-6.6.0+
/etc/initramfs-tools/hooks/wdk23-firmware: 1: !/bin/sh: not found
/etc/initramfs-tools/hooks/wdk23-firmware: 1: !/bin/sh: not found
jglathe commented 3 months ago

The # as the first char is missing, sorry my mistake. Edited the wdk23-firmware script. You can also save it as a more apropriate name, like sp9-firmware. The file must have root as owner and execute rights.

tilator commented 3 months ago

Now it's invining "invalid devicetree".

Should it be same version? Dbt is 6.7 InitRamFs is 6.7.1.

jglathe commented 3 months ago

nah no real change. let me pull and compile it to be sure.

JeromeDeBretagne commented 3 months ago

Weird, I've compiled the .dts file within a Linux 6.7 source tree... as you can see in my repository

tilator commented 3 months ago

Weird, I've compiled the .dts file within a Linux 6.7 source tree... as you can see in my repository

I made definitely some misstake. I have not been doing this for several years. I don't know the present systems well enough. Kernel version was 3.x something back then.

It's definitely better, Jens makes a full image.

I saw some boot message giving the devices own native screen resolution. So I think it's not very far away right now.

jglathe commented 3 months ago

sc8280xp-microsoft-surface-pro-9-5G.dtb.txt

Full image is a bit more complicated, but this is compiled on my tree.

install:

reboot.

tilator commented 3 months ago

I'll try it. It takes awhile because I have to start it from the beginning.

tilator commented 3 months ago

Here is the best there is available. Still the same qcadsp8280.mbn FW had to be taken off to make it boot. dmesg_4.txt

tilator commented 3 months ago

This sounds much to me that this qcadsp8280.mbn and loading it has something odd to do with USB. All USB traffic cuts out in the middle of booting process if this FW is available. Because I boot from a USB drive, cut in USB access messes it all up.

jglathe commented 3 months ago

@JeromeDeBretagne does your box load qcadsp8280.mbn and bring up 3000000.remoteproc successfully? This sounds pretty odd. @tilator can you update your windows installation to the newest drivers? Maybe the .mbns will be updated, too. Alternatively, it might be worth to look at https://github.com/WOA-Project/Qualcomm-Reference-Drivers/tree/master/8280_QRD/200.0.55.0 and extract from there.

jglathe commented 3 months ago

Because I boot from a USB drive, cut in USB access messes it all up.

Hmm could you use the other USB connector for the drive? Or do you have a Surface port extender connected? I'd advise to try with as little as possible peripherals first, maybe some odd USB-C hub with Power Delivery instead. I suspect that adsp is fscking with the extender over some protocol and OS is not prepared for it.

JeromeDeBretagne commented 3 months ago

Don't you want to try my .dtb file with a Debian netinst USB key, as a comparison?

tilator commented 3 months ago

@JeromeDeBretagne does your box load qcadsp8280.mbn and bring up 3000000.remoteproc successfully?

I don't know, because whenever qcadsp8280.mbn is loaded from userspace there is no screen, no network no nothing to see what happened.

I'll try to update Windows.

More here - after updating Windows all eight extracted files are exactly same size as before.

tilator commented 3 months ago

Don't you want to try my .dtb file with a Debian netinst USB key, as a comparison?

That might be one partial solution if the USB is part of this trouble. But even better would be if the primary problem can be solved.

tilator commented 3 months ago

Something new here:

I took a USB hub and I installed installing package on an SSD drive connected by USB-Sata adapter to the hub.

This setup boots as good as connecting a USB drive directly with Surface without the hub if qcadsp8280.mbn is not present in userspace.

If I put qcadsp8280.mbn back booting stops again.

There are some leds on both the hub and USB-Sata adapter and there is only power from USB. Whatever happends with booting process, leds on the hub are solidly lit. I suppose there is enough continuous power from USB because these leds are on all the time.

USB-Sata adapter has one led on it. This led is solidly lit when drive is properly connected to the OS. It flashes rapidly while there is some data transfer between drive and OS.

If I boot up without qcadsp8280.mbn everything seems to act "normally". Leds on hub solidly on and led on SSD drive controller flashes rapidly as there is data transfer.

Whlile I put qcadsp8280.mbn back, booting starts similarly as without it. But when the process has gone a while, led on SATA controller is lit off for about a second. Then led is lit again and it keeps solidly lit. Booting process seems to stop there. Nothing else happends but network adapter leds flash every now and then. Screen is totally black for a while before this happends and there is no network. Router has not given IP address for it.

My opinion is, it really cuts USB data transfer off while loading qcadsp8280.mbn. Can you confirm if this happens on the devkit too?

jglathe commented 3 months ago

No, this doesn't happen. But I guess it gives us an idea what is wrong. Initial work around would be to set regulators providing power for USB to always on. Which brings us to the topic of tweaking the dts file :grin: I can remember in the early days that regulators were a big issue. I might have time this evening to do something.

jglathe commented 3 months ago

You could install on nvme, though... That's how I got the first boots at all. USB came way later.

jglathe commented 3 months ago

I would recommend reading up on this in the devkit repo, though. Lots of pitfalls.

JeromeDeBretagne commented 3 months ago

@JeromeDeBretagne does your box load qcadsp8280.mbn and bring up 3000000.remoteproc successfully?

Yes, I can see such lines during my Surface Pro 9 5G boot, via dmesg :

[    2.315722] remoteproc remoteproc0: 3000000.remoteproc is available
[    2.326258] remoteproc remoteproc0: firmware: direct-loading firmware qcom/sc8280xp/MICROSOFT/SurfacePro9/qcadsp8280.mbn
[    2.361200] remoteproc remoteproc1: 1b300000.remoteproc is available
[    2.363360] remoteproc remoteproc1: firmware: direct-loading firmware qcom/sc8280xp/MICROSOFT/SurfacePro9/qccdsp8280.mbn
[    2.365719] remoteproc remoteproc1: powering up 1b300000.remoteproc
[    2.368082] remoteproc remoteproc1: Booting fw image qcom/sc8280xp/MICROSOFT/SurfacePro9/qccdsp8280.mbn, size 3571712
[    2.381319] remoteproc remoteproc0: powering up 3000000.remoteproc
[    2.390984] remoteproc remoteproc0: Booting fw image qcom/sc8280xp/MICROSOFT/SurfacePro9/qcadsp8280.mbn, size 14606924
[    2.450270] remoteproc remoteproc1: remote processor 1b300000.remoteproc is now up
[    2.493001] qcom,fastrpc 1b300000.remoteproc:glink-edge.fastrpcglink-apps-dsp.-1.-1: no reserved DMA memory for FASTRPC
[    2.493280] qcom,fastrpc-cb 1b300000.remoteproc:glink-edge:fastrpc:compute-cb@1: Adding to iommu group 9
[    2.493605] qcom,fastrpc-cb 1b300000.remoteproc:glink-edge:fastrpc:compute-cb@2: Adding to iommu group 10
[    2.493906] qcom,fastrpc-cb 1b300000.remoteproc:glink-edge:fastrpc:compute-cb@3: Adding to iommu group 11
[    2.494206] qcom,fastrpc-cb 1b300000.remoteproc:glink-edge:fastrpc:compute-cb@4: Adding to iommu group 12
[    2.494501] qcom,fastrpc-cb 1b300000.remoteproc:glink-edge:fastrpc:compute-cb@5: Adding to iommu group 13
[    2.494798] qcom,fastrpc-cb 1b300000.remoteproc:glink-edge:fastrpc:compute-cb@6: Adding to iommu group 14
[    2.495074] qcom,fastrpc-cb 1b300000.remoteproc:glink-edge:fastrpc:compute-cb@7: Adding to iommu group 15
[    2.495368] qcom,fastrpc-cb 1b300000.remoteproc:glink-edge:fastrpc:compute-cb@8: Adding to iommu group 16
[    2.495669] qcom,fastrpc-cb 1b300000.remoteproc:glink-edge:fastrpc:compute-cb@9: Adding to iommu group 17
[    2.495956] qcom,fastrpc-cb 1b300000.remoteproc:glink-edge:fastrpc:compute-cb@10: Adding to iommu group 17
[    2.496186] qcom,fastrpc-cb 1b300000.remoteproc:glink-edge:fastrpc:compute-cb@11: Adding to iommu group 18
[    2.496507] qcom,fastrpc-cb 1b300000.remoteproc:glink-edge:fastrpc:compute-cb@12: Adding to iommu group 19
[    2.496820] qcom,fastrpc-cb 1b300000.remoteproc:glink-edge:fastrpc:compute-cb@13: Adding to iommu group 20
[    2.497109] qcom,fastrpc-cb 1b300000.remoteproc:glink-edge:fastrpc:compute-cb@14: Adding to iommu group 21
[    2.515305] remoteproc remoteproc0: remote processor 3000000.remoteproc is now up

but I'm booting Debian so there can be differences here and there. I have followed the instructions from the Debian wiki page for the Thinkpad X13s from here, it tells in particular to add some modules into the initramfs.

jglathe commented 3 months ago

@tilator remoteproc 0 seems to be the culprit, which is a bit odd. @JeromeDeBretagne Could be that you circumvent the issue because you're booting from nvme. Be wary of older documentation, this thing is moving pretty fast.

JeromeDeBretagne commented 3 months ago

Indeed, I've installed directly on the NVMe drive and I boot from it then, this may avoid this issue. The regulators may not be all properly defined.

About this Debian doc, it has been rock solid for me so I can still recommend it, as long as one provides the right .dtb file for the Surface Pro 9 5G.

JeromeDeBretagne commented 3 months ago

About USB booting, could it be similar to this old situation maybe : https://github.com/jglathe/linux_ms_dev_kit/discussions/1#discussioncomment-6687419 or this one: https://github.com/jglathe/linux_ms_dev_kit/discussions/1#discussioncomment-6873936

jglathe commented 3 months ago

They are probably related, but... in your case 

2.515305] remoteproc remoteproc0: remote processor 3000000.remoteproc is now up

loading of the adsp firmware and bringing it up appears to work. Which makes me curious. It also works here (booting from any USB or nvme internal):

Mar 05 19:36:14 volterra kernel: remoteproc remoteproc0: 3000000.remoteproc is available
Mar 05 19:36:14 volterra kernel: remoteproc remoteproc0: powering up 3000000.remoteproc
Mar 05 19:36:14 volterra kernel: remoteproc remoteproc0: remote processor 3000000.remoteproc is now up
Mar 05 19:36:15 volterra kernel: qcom,apr 3000000.remoteproc:glink-edge.adsp_apps.-1.-1: Adding APR/GPR dev: gprsvc:service:2:1
Mar 05 19:36:15 volterra kernel: qcom,apr 3000000.remoteproc:glink-edge.adsp_apps.-1.-1: Adding APR/GPR dev: gprsvc:service:2:2
Mar 05 19:36:21 volterra kernel: q6apm-dai 3000000.remoteproc:glink-edge:gpr:service@1:dais: Adding to iommu group 23

What I've seen is one USB disconnect in @tilator dmesgs, which points to some init / power oddity. Therefore it is probably not mhi... not sure. It is configured as modules, and the mhi and USB-C drivers are in initramfs-tools/hooks/modules.

I'm curious: on which USB-C port does the external display work? Is it the "lower" one? Do you have a picture? External display on Volterra only works on the "upper" one, more to the edge of the case, but the M/B is mounted flipped in there.

denysvitali commented 3 months ago

FWIW, I'm trying to enable external displays on the SPX by modifying the DT with the changes that can be found in the Lenovo Flex upstream DT.

I face the same issue as you: the screen goes completely black and the external screens do not work.

This happens when the DRM module is loaded (or the glink one). I can almost confidently say this because while I attempted to denug the problem I've embedded a few modules in the kernel (TYPEC / GLINK / DRM) and the behavior started to happen after a few seconds into the kernel booting (as opposed to after the cryptroot decryption as it was happening before).

Without the patch, everything works normally (display & stuff), but I can't use external displays.

JeromeDeBretagne commented 3 months ago

I'm curious: on which USB-C port does the external display work? Is it the "lower" one? Do you have a picture? External display on Volterra only works on the "upper" one, more to the edge of the case, but the M/B is mounted flipped in there.

Sure, here you go with a picture :

https://cdn.shopify.com/s/files/1/0045/4092/4007/products/A61UJm1NbEiAyHl1.jpg?v=1705445545&width=1200

it is the "lower" port that I have working indeed, it is on the edge of the board on this picture but closer to the middle of the tablet in practice (as the board is positioned at the top, above the battery)