EL2: No video output about linux_ms_dev_kit HOT 20 CLOSED

No video output, dmesg here

[    1.988199] qcom_q6v5_pas 1b300000.remoteproc: error -22 initializing firmware qcom/sc8280xp/MICROSOFT/DEVKIT23/qccdsp8280.mbn
[    1.988256] qcom_q6v5_pas 3000000.remoteproc: error -22 initializing firmware qcom/sc8280xp/MICROSOFT/DEVKIT23/qcadsp8280.mbn
[    3.151808] msm-dp-display: probe of ae9a000.displayport-controller failed with error -22
[    3.157707] platform regulatory.0: Direct firmware load for regulatory.db failed with error -2
[    3.214461] qcom-venus aa00000.video-codec: error -22 initializing firmware qcom/sc8280xp/MICROSOFT/DEVKIT23/qcvss8280.mbn
[    3.239875] qcom-venus: probe of aa00000.video-codec failed with error -22
[   14.307043] platform sound: deferred probe pending: snd-sc8280xp: WCD Playback: error getting cpu dai name

from linux_ms_dev_kit.

The name change was in preparation for upstreaming this work, therefore blackrock (the code name for the WDK 2023). Better to change all downstream applications. I will change the title of this issue to EL2: no video output.

from linux_ms_dev_kit.

The branch jg/el2-iommu-v6.8 is the ongoing effort to get the box up as good as possible on EL2 when booting with the help of @travmurav 's slbounce. The key changes by now are:

• no ZAP shader node in the dts
• arm-smmuv3 enabled as pcie_smmu with mappings
• hack in drivers/iommu/iommu.c to allow the use of iommu despite multiple iommu drivers being loaded.

With that the WDK boots up with PCIe operational, and you get video output on display port. The sc8280xp specific firmware files are not loaded, so it is not full support with ZAP shader and Venus, but quite usable nonetheless.
The use of multiple IOMMU drivers is quite new, it starts to come to mainline with 6.8 as it seems. Therefore not everything works (yet) or is intentionally disabled.
The use should be straight forward compile and install with devkit_defconfig as described in master/README.md. With armbian the way may be different, might be adapted a little.
I have not yet tried to boot to EL2 from internal nvme SSD.

from linux_ms_dev_kit.

dtbhack is not needed to boot this, btw. I just use EFI shell -> load slbounce.efi -> exit -> grub to the right menu.

from linux_ms_dev_kit.

顺便说一句，不需要 dtbhack 来启动它。我只是使用 EFI shell -> 加载 slbounce.efi -> exit -> grub 到右侧菜单。

Right, i use devicetree with grub.

from linux_ms_dev_kit.

Did you get the display to work, though? Attached my dmesg for reference.
el2_dmesg.txt

from linux_ms_dev_kit.

This is my cmdline for the kernel: pd_ignore_unused clk_ignore_unused regulator_ignore_unused arm64.nopauth efi=noruntime drm.debug=0x100 "dyndbg=file drivers/regulator/core.c +p;file drivers/base/firmware_loader/main.c +fmp"

from linux_ms_dev_kit.

Not working
dmesg

from linux_ms_dev_kit.

from linux_ms_dev_kit.

Yes, I'm using DP, DP to HDMI.
Use Armbian with EL1, its working fine.

from linux_ms_dev_kit.

Are u using TypeC Video output?

from linux_ms_dev_kit.

I'm using DP normally, no adapter. I have a miniDP to DVI adapter, too, working great (needs to be an active version). TypeC won't work on EL2 (it does - well enough - on EL1) because the coprocessors are needed for the USB multiplexing.
What I've seen is that you still get the WARNs. I tweaked the dts a little since then, I don't get WARNs anymore. It should work even without the hack in iommu.c now. Maybe rebuild with the updated branch? OTOH I would recommend to load the newest Volterra-specific firmwares from Windows with this script. Armbian-firmware is not the newest IMO.

from linux_ms_dev_kit.

Yes, I'm using latest dtb with latest firmware. video output works find. but also has error.

if I only using latest firmware with previous kernel, its not working. but I update dtb and kernel, its works fine.
but after update to latest kernel, NVMe has error. see dmesg below

Thanks for ur working

dmesg.txt

from linux_ms_dev_kit.

Thanks for the hint. I've seen these messages too, they are correctable errors due to PCIe L0s ASPM state. It is already solved for the X13s, need to update the WDK dts accordingly. Great that video is working. I will open a new issue for the AER messages.

from linux_ms_dev_kit.

Thanks for the hint. I've seen these messages too, they are correctable errors due to PCIe L0s ASPM state. It is already solved for the X13s, need to update the WDK dts accordingly. Great that video is working. I will open a new issue for the AER messages.

dmesg still has gpu error, Is this caused by PCIe L0s ASPM?
Or only nvme error caused by PCIe L0s ASPM?

from linux_ms_dev_kit.

No, gpu is integrated and not on the PCIe bus. This sounds a little odd, can you post the dmesg?

from linux_ms_dev_kit.

The last time I submitted dmesg, it included this part.
I'll upload it again.

dmesg

from linux_ms_dev_kit.

Here is error part of dmesg

[    2.058598] firmware_class:fw_log_firmware_info: remoteproc remoteproc0: Loaded FW: qcom/sc8280xp/MICROSOFT/DEVKIT23/qcadsp8280.mbn, sha256: 012297b4c3fea46afb147dc3a85a8fd105da8f5bd9d3591afbe9dc7693d94f28
[    2.058600] remoteproc remoteproc0: Booting fw image qcom/sc8280xp/MICROSOFT/DEVKIT23/qcadsp8280.mbn, size 14545260
[    2.059034] qcom_q6v5_pas 1b300000.remoteproc: error -22 initializing firmware qcom/sc8280xp/MICROSOFT/DEVKIT23/qccdsp8280.mbn
[    2.059093] remoteproc remoteproc1: can't start rproc 1b300000.remoteproc: -22
[    2.059110] firmware_class:__free_fw_priv: firmware_class: __free_fw_priv: fw-qcom/sc8280xp/MICROSOFT/DEVKIT23/qccdsp8280.mbn fw_priv=0000000062318922 data=0000000052f9c7e7 size=3571712
[    2.059208] qcom_q6v5_pas 3000000.remoteproc: error -22 initializing firmware qcom/sc8280xp/MICROSOFT/DEVKIT23/qcadsp8280.mbn
[    2.059305] remoteproc remoteproc0: can't start rproc 3000000.remoteproc: -22
[    2.059315] firmware_class:__free_fw_priv: firmware_class: __free_fw_priv: fw-qcom/sc8280xp/MICROSOFT/DEVKIT23/qcadsp8280.mbn fw_priv=000000007a4a9336 data=00000000da383c54 size=14545260

from linux_ms_dev_kit.

Oh, that... 😏 These are the coprocessors that rely on the HYP firmware to boot... actually this firmware is no longer there after slbounce. Linux is booting on EL2 where HYP was. Of what I heard there are other ways to boot these processors, but this needs to be changed in the kernel (if we can find out how). For all the parts relying on HYP firmware solutions need to be found:

• ZAP Shader
• Venus firmware
• ADSP
• CDSP

This will take some time and effort. Oh, and I'd like to make the NXPs operational, too. 😀 Luckily, for Volterra you can do without all these and still have a useful VM platform with working thermal management. So, not everything is bad.

from linux_ms_dev_kit.

Oh, that... 😏 These are the coprocessors that rely on the HYP firmware to boot... actually this firmware is no longer there after slbounce. Linux is booting on EL2 where HYP was. Of what I heard there are other ways to boot these processors, but this needs to be changed in the kernel (if we can find out how). For all the parts relying on HYP firmware solutions need to be found:

• ZAP Shader
• Venus firmware
• ADSP
• CDSP

This will take some time and effort. Oh, and I'd like to make the NXPs operational, too. 😀 Luckily, for Volterra you can do without all these and still have a useful VM platform with working thermal management. So, not everything is bad.

Ok, thanks for ur answer

from linux_ms_dev_kit.