Is there a roadmap of future advancements in Qualcomm support for Linux? Thanks in advance!
1 Like
I bought Thinkpad Yoga week ago with idea to check that. Right now, the answer is no, using Hexagon SDK is not possible with what is publicly available to my knowledge, or if there are plans to make it possible.
In addition Hexagon SDK doesn’t support x1e-80-100 and binaries for aarch64 are unavailable. Would be cool to get hexagon-clang build form armv7. But, oh well Hexagon+HVX llvm backend is upstream and you can compile your code with upstream clang just fine using SDK headers in most cases.
Hexagon development on Dell XPS 13/ThinkPad T14s which in itself is pretty compelling in comparison arm+hexagon cross and adb push ways of doing things.
In theory someday yes and FastRPC (Remote Procedure Calls to Hexagon ADSP/CDSP) could work same ways as in android, but some firmware bits are missing.
The kernel support and userspace code to get those part of puzzle seems to be mostly in the open or pretty close to make it possible. Probably not mini-dm for logging, this probably would need some work too.
I don’t know if Windows 11 firmware provided by qcom-firmware-extract is in any way similar to android one and even if it allows use of FastRPC. Or even which hardware units really are in this SoC. But marketing material seems to hint Hexagon DSP + HVX + HMX and maybe LPAI, since all this AI PC/NPU talk.
I’ve established so far it is likely Hexagon ISA v73 (might still be wrong), which wasn’t obvious and easy to find in itself.
I will be able to confirm that and what are capabilities once/if I’ll get to run code on ADSP/CDSP.
There is really no good public source of hard specs beside of calling it AI PC/NPU.
Based on this assumption, I think code signing would be required. With Hexagon v75 and up would be bit better in this regard.
Even if one does build FastRPC FastRPC github repo you’ll need signed/unsigned PD along with some support binaries likefastrpc_shell_<Domain> and few other bits.
Here is part of my attempt to use getserial from Hexagon SDK for code signing.
As expected:
Jan 30 18:47:28 prak-Yoga-Slim-7-14Q8X9 getserial[32416]: ../../src/fastrpc_apps_user.c:3554: Error 0x2: open_shell failed for domain 3 search paths used are /usr/lib/dsp/, /vendor/dsp/, /v>
So no Halide, TVM or your own Hexagon SDK apps for us on ubuntu-concept, unless we get some support from those who can (Qualcomm/linaro) in this area.
Also there are some device-tree fixes for cdsp for 6.14, so you’ll probably would need to pick up those yourself.
If we got that and hardware has required units, it would allow to access Vector Co-processor (ie HVX) and scalar DSP.
The HMX (tensor co-processor part) seems to be closed/not document/inaccessible outside of Qualcomm and usable only on pretty high level by AI SDK’s.
Maybe I’ll be able to get it working/hack my way using some android binaries for Hexagon v73 if I am lucky one day, but I don’t have my hopes up. Or it will turn out to be a gift for youtube watching on couch 
I installed the latest iso image on my Thinkpad T14s. I can only get it to boot if there is a USB drive attached to the unit or if I reboot into Windows and then restart and select Ubuntu in the grub menu. If I boot Ubuntu from shutdown it will not get past the grub menu.
Any time frame when the display brightness for the low power IPS panel will get fixed. I see mention it was working previously, but not working on the latest iteration of the kernel?
Specs of Thinkpad:
CPU: X Elite 78-100
Memory: 32GB
SSD: 1TB
Display: 1920x1200 Low Power IPS
Keyboard: US
Hmm. I could only provide a separate dtb for PWM backlight control to be enabled. You would need to install it manually, and do a change in flash-kernel for it to work. Would that help?
Note sure who you were referring to, but I cannot copy anything from a USB-drive (on my T14s). I get a nice blue screen of death and a hard reset is the only thing that get the system up again. I can see the file system on the USB-drive, but that is all. Any further interaction and it is blue screen. Not sure if this may be file system type dependent, I haven’t tested that many different USB-drives.
Oddly enough, the install ISO was of course on a USB-drive.
As I am writing this, I am watching you @tobhe speaking at a Ubuntu conference (on YouTube). Thanks for all the work.
That’s the 64GB memory problem we were talking about (:
Ohh! That sucks. Well, I guess I haven’t stress tested my T14s that hard yet with other things (than USB-drive copying). Anything else that would be easy to test? That is, to see if the memory bug gets triggered.
Also, could you provide more details on how to perform the temporary fix you did?
Running 6.14.0-rc1 I seem to be missing firmware:
qcom-apm gprsvc:service:2:1: tplg firmware loading qcom/x1e80100/X1E80100-LENOVO-Thinkpad-T14s-tplg.bin failed -2
So no sound (for me at least) yet.
Did you install 6.14.0-rc1 through mainline?
Yes, compiled from https://git.kernel.org/torvalds/t/linux-6.14-rc1.tar.gz
Simply with defconfig? Interesting
With (I’m on NixOS):
kernelPackages =
let
kernel_pkg =
{ buildLinux, ... }@args:
buildLinux (
args
// {
ignoreConfigErrors = true;
src = builtins.fetchTarball {
url = "https://git.kernel.org/torvalds/t/linux-6.14-rc1.tar.gz";
sha256 = "0schcgij7kdzj0zb6g3sjf32mq7s388hysrfzjzi5g1y3py21igk";
};
version = "6.14.0-rc1";
}
// (args.argsOverride or { })
);
kernel = pkgs.callPackage kernel_pkg { };
in
pkgs.recurseIntoAttrs (pkgs.linuxPackagesFor kernel);
kernelParams = [
"clk_ignore_unused"
"pd_ignore_unused"
"mem=31G"
];
kernelPatches = [
{
extraConfig = ''
TYPEC y
PHY_QCOM_QMP y
QCOM_CLK_RPM y
MFD_QCOM_RPM y
REGULATOR_QCOM_RPM y
PHY_QCOM_QMP_PCIE y
CLK_X1E80100_CAMCC y
'';
name = "snapdragon-config";
patch = null;
}
];
1 Like
I guess things like compiling large amounts of code or opening lots of large files?
I created the executable file /etc/grub.d/01_cutmem with the following content:
echo "cutmem 0x8800000000 0x8fffffffff"
This disables half of your memory during boot.
1 Like
Is there separate bug-tracking for display related things somewhere? Currently I have the following issues:
- internal screen: no backlight control
- one 4k screen: cannot boot with it plugged in (hang after grub); but plugging it in afterwards works. Sometimes the screen shows only 640x480, but unplugging and replugging fixes it.
- another 4k screen: no problems booting with it or with resolutions.
- third screen (3440x1440): if the screen turns off (e.g. after time in idle), it never turns back on. However,
swaymsg -t get_outputsreports it as connected and even as focused when I move the mouse there. Unplugging and replugging the screen does not fix this. The only way to get the screen back on is killing the session (gdm does manage to bring it back online). - HDMI does not work
[T14s, IPS screen, 64GB]
Apparently a tplg file is an ALSA Topology file, used by kernel drivers as a map between driver and different configurations of hardware. Or something like that.
I’ve downloaded and extracted Lenovo Thinkpad T14s firmware from https://download.lenovo.com/pccbbs/mobiles/n42qq11w.exe as per Bug #2084178 “[X1E] Request: Add support for Lenovo Thinkpad T14...” : Bugs : ubuntu-concept but it does not contain any tplg file.
I’ve cloned git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git but no sign of a tplg file for x1e80100 yet. There is one for SC8280XP-LENOVO-X13S-tplg.bin called ./qcom/sc8280xp/LENOVO/21BX/audioreach-tplg.bin committed in https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/commit/?id=f9a35b3f0779844aa686b76506344db70a72820d
Would we somehow be able to compile a tplg file with Ubuntu Manpage: alsatplg - ALSA Topology Compiler ?
1 Like
Happy to help test. I’ve got a Asus Vivobook S 15 X1P42100
2 Likes
Will do the build, getting it uploaded tomorrow I guess.
1 Like
There is now a conflict between linux-firmware and qcom-x1e-firmware-extracted, because both provide /lib/firmware/qcom/x1e80100/LENOVO/21N1/adspr.jsn.
1 Like
Oh of course, actually makes sense. Let me see how we can solve that nicely.
EDIT: for now it should be safe for T14s users to delete qcom-x1e-firmware-extracted before upgrading linux-firmware. I’ll see if we can have it replaced automatically without affecting other hardware.
2 Likes
I was able to install oracular-desktop-arm64+x1e-20250124.iso on ASUS Vivobook S15 with X1E-78-100. Some observations:
- Installation was not possible when booting from the USB-A ports. After GRUB, I got a blinking dash and then all became black.
- It was not possible to use an external (wired) mouse with the USB-A ports.
How I worked around the problems? I have a USB-C dongle with different ports, including USB-A. Both, installation and external mouse did work when using the USB-A ports on the USB-C dongle.
1 Like