thinkpad-x13s: remoteproc firmware fails to load if on a fast boot device

[jglathe]

Hi there,

 

not sure where to post this, intended for @rpardini

 

I have an x13s running here with dual boot to win11 and ubuntu 23.04 lunar, the armbian work was a great help to get it to work. Not quite finished setting it up tbqh. However, if you're on a fast boot device like the local NVMe drive, the remoteproc firmwares qcadsp8280.mbn and qccdsp8280.mbn fail to load and won't get retried later, the GPU firmwares a660_sqe.fw and a660_gmu.bin may fail but get loaded later. That is a little unfortunate, since PMIC GLINK (among other things) is running on one of these. My Windows Dev Kit 2023 (same SoC) doesn't balk this way, both boot the same Ubuntu image (more or less). Analysis has shown that I have a firmware hook for initramfs on the wdk2023 which provides the firmware images in the initrd.img file. This is the version I hacked up for the x13s, which appears to load the desired firmwares as intended:

 

#!/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

# Define a list of firmware files to be included
FIRMWARE_FILES="\
qcom/sc8280xp/LENOVO/21BX/qcadsp8280.mbn \
qcom/sc8280xp/LENOVO/21BX/qccdsp8280.mbn \
qcom/sc8280xp/LENOVO/21BX/qcdxkmsuc8280.mbn \
qcom/sc8280xp/LENOVO/21BX/qcvss8280.mbn \
qcom/sc8280xp/LENOVO/21BX/qcslpi8280.mbn \
qcom/a660_sqe.fw \
qcom/a660_gmu.bin"

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

It needs to be copied into /etc/initramfs-tools/hooks/ and be set as executable. initramfs -u -k all includes the files into the initrd images.

 

with best regards

 

Jens

x13s-firmware

[Igor]

In the name of users (sadly, I am not one of them) of this device, I am thanking you for those bits.

 

10 hours ago, jglathe said:

It needs to be copied

 

The only reason why we have invested (100% our private cash, 0% users, 0% Lenovo) into this device is promotion of our build framework. Try it, here we will try best to help you, and make a PR: https://github.com/armbian/build/pulls 

[jglathe]

I've used the armbian/build system to generate the image, and it's impressive. Not familiar enough with it (and all that linux-y stuff) to dish out PRs left and right. I actually built with my repo, rebased that to @steev's repo when I confirmed the early hang on clk on the x13s (but not on the wdk), now this can build a kernel for both platforms, same laptop_defconfig, same branch. The armbian build framework does create an image with lunar, the final stages of setup balk on wrong rights and essentially lead to an incomplete install. However, it is coming up with battmgr working (yay!), and Touchscreen working (yay again!) and it is 6.5.4. Will investigate further. Would the wdk2023 be a candidate target for armbian, too? Do I just create a microsoft-dev-kit-2023.wip and on it goes?

Edited September 28, 2023 by jglathe
grammar

[rpardini]

On 9/28/2023 at 9:01 AM, jglathe said:

The armbian build framework does create an image with lunar, the final stages of setup balk on wrong rights and essentially lead to an incomplete install

 

Please build with `SHARE_LOG=yes` and send us the URL so we can check.

 

On 9/28/2023 at 9:01 AM, jglathe said:

it is coming up with battmgr working

 

That's due to the pd-mapper and qrtr in userspace working. (Only for lunar, coming from ubuntu x13s ppa)

 

On 9/28/2023 at 9:01 AM, jglathe said:

Touchscreen working (yay again!)

 

Yep it has a hid bind loop that is work-arounded via some udev rules... it's strange.

 

On 9/28/2023 at 9:01 AM, jglathe said:

Would the wdk2023 be a candidate target for armbian, too? Do I just create a microsoft-dev-kit-2023.wip and on it goes?

 

Mostly, yes. I'd say send your patches to steev, or add them to Armbian. Copy the x13s board file and change the DTB.

If this works we can refactor/unify more later...

 

On 9/27/2023 at 9:34 PM, jglathe said:

This is the version I hacked up for the x13s, which appears to load the desired firmwares as intended:

 

 

Yeah take a look at the x13s board file, you'll find something really similar. I have not kept up to the rapid amount of changes after 6.3.y. I might try to update to 6.6, since that's gonna be LTS.

 

 

[jglathe]

Will do the next time I build an image. Yes there are lots of changes regarding qcom, nice progress (or something). Building dts files is still quite the quesswork. Anybody got some schematics or valid documentation, perchance?  

My top list for the near future:

- fix the PMIC GLINK errors

- working sound on display port

- see if USB-C actually works with a display 

- get qemu to to work for VMs (gunyah might be the way)

- nxp support 🤨

Since this works on both wdk and x13s, nice synergies if something of this works out. Pretty happy user of both platforms as it is now. 

[rpardini]

Some progress has been made, 6.6-rc5, new alsa-ucm-conf and firmware.

Try the "Armbian Trixie - Gnome Desktop" image available at https://www.armbian.com/lenovo-x13s/ under "Other supported variants", that might work: filename is Armbian_23.8.6_Thinkpad-x13s_trixie_sc8280xp_6.6.0-rc5_gnome_desktop

 

[jglathe]

That‘s great news. Actually, I found out this morning (by concidence) that my x13s is now making \<bonk\> sounds after getting qrtr-ns and pd-mapper online on mantic. My kernel is 6.6-rc6. 😎 👯‍♀️ I guess we’re approaching fast.

[jglathe]

Oh, and USB-C Display works. On an iiyama XUB2792QSN with 2560x1440.