Ubuntu Concept ♥️ Snapdragon X Elite

For the wifi, the current kernel is missing a way to disable rf-kill.

The patch I currently have applied is the following:

diff --git a/drivers/net/wireless/ath/ath12k/core.c b/drivers/net/wireless/ath/ath12k/core.c
index 4ed608ba3c30..2db54dfb1560 100644
--- a/drivers/net/wireless/ath/ath12k/core.c
+++ b/drivers/net/wireless/ath/ath12k/core.c
@@ -80,6 +80,9 @@ static int ath12k_core_rfkill_config(struct ath12k_base *ab)
        if (ath12k_acpi_get_disable_rfkill(ab))
                return 0;
 
+       if (of_property_read_bool(ab->dev->of_node, "disable-rfkill"))
+               return 0;
+
        for (i = 0; i < ab->num_radios; i++) {
                ar = ab->pdevs[i].ar;
 

The SP11 dts already contain the correct disable-rfkill statement, it is just missing in the driver. I think it didn’t made it into the 7.0.0 kernel change proposal from Dwhinham and Jerome de Bretagne.

For the bluetooth, it is working, only missing a MAC address at boot, the following change are required:

Change the MAC address to the MAC address of the WIFI using the value from windows, same for the bluetooth adapter

New file to be created (/etc/udev/rules.d/99-fix_mac_addresses.rules):

ACTION=="add", SUBSYSTEM=="net", KERNELS=="0004:01:00.0", \
  RUN+="/usr/bin/ip link set dev wlP4p1s0 address C4:CB:76:B2:XX:XX"
ACTION=="add", SUBSYSTEM=="bluetooth", ENV{DEVTYPE}=="host" \
  ENV{DEVPATH}=="*/serial[0-9]*/serial[0-9]*/bluetooth/hci[0-9]*", \
  TAG+="systemd", ENV{SYSTEMD_WANTS}="hci-btaddress@%k.service"

For the wifi MAC address, you can check with lspci that the KERNELS parameter is correct.

Then add the systemd file (/usr/lib/systemd/system/hci-btaddress@.service):

[Unit]
Description=HCI bluetooth address fix

[Service]
Type=simple
ExecStart=/bin/bash -c 'sleep 5; cat /root/start_blue | btmgmt; cat /root/start_blue2 | btmgmt;'

start_blue

info
power off
public-addr C4:CB:76:B2:XX:XX
info
exit

start_blue2

public-addr C4:CB:76:B2:XX:XX
exit

It should be possible to do it simply on the command line but had to do lots of trial and errors to get mgmt to correctly change the MAC address of the BT device.

I am cleaning up firmware-extract to see if I can make it work correctly

2 Likes

Am I understanding correctly that Ubuntu runs on your Surface Pro 11? I have a Surface Pro 12 OLED with Snapdragon X Plus. A few months ago, I tried it using Ventoy, but my Surface got stuck in GRUB mode and kept rebooting.

A lot has changed in the last months, it might be worth trying again with the resolute ISO from https://people.canonical.com/~platform/images/ubuntu-concept/resolute-desktop-arm64+x1e.iso

How did you apply the patch? I not familiar with kernel patching. Do have to rebuild the whole kernel? Thank you for the bluetooth info. Bluetooth is finally working. Just need to get the wifi up.

I just tried it again using Ventoy and the ISO. I can at least get to the menu where I can select “Try or install Ubuntu.” I can also navigate up and down with an external keyboard, which is a significant improvement compared to a few months ago. Unfortunately, after that it just takes me back to the Ventoy boot menu. If I choose “boot into grub2” and then select “Try or install Ubuntu” there, I get an error saying I need to load the kernel first. Secure boot is disabled. Any ideas?

In grub, while hovering over the “Try or install” option try pressing ‘e’ to get an editor. You can then remove “quiet splash”, replace it with “debug” and then boot with CTRL+X

This should print some more info. I would be interested if it says anything about choosing a device tree.

I haven’t heard much talk on the SP12 here. Does that model require a different dtb file to start? That is what my SP11 would do with the older ISO’s because my dtb wasn’t there yet.

Do we have any Acer Swift AI users or Acer Swift GO users here? I’d like to confirm that our current ISO at https://people.canonical.com/~platform/images/ubuntu-concept/resolute-desktop-arm64+x1e.iso works on those.

2 Likes

[ASUS Vivobook S15 x1p42100]

@haider5c It turns out there are two drivers for USB - USB Mass Storage (UMS - old style, you see an eject icon in Disks GUI as well as power-off icon) and USB Attached SCSI (UAS - SSD preferred, only see power-off icon).
lsusb -t

    /:  Bus 002.Port 001: Dev 001, Class=root_hub, Driver=xhci_hcd/4p, 5000M
        |__ Port 001: Dev 003, If 0, Class=Mass Storage, Driver=uas, 5000M
        |__ Port 002: Dev 002, If 0, Class=Mass Storage, Driver=usb-storage, 5000M

The former is UAS (obvs) the latter is UMS (not so obvs).

On my model, my USB3-A ports only support UMS as boot devices (pressing ESC during power on won’t give a UAS device as a boot option). The USB4-C ports support UAS as a boot option but Ubuntu can’t boot off USB C ports (yet). Once booted, both types of ports see both types of USB drivers (hence why you can install on UAS device OK but not boot it up).

I assume this is an ASUS firmware limitation, could it be the case for your Surface Pro 11?

1 Like

I tried it. The only information that was shown to me was:

Booting a command list

stub.c:2230 run: Stubble configuration:

stub.c:2240 run: debug: enabled

stub.c:2250 run: dtp_override: enable

After that, the Surface reboots back into Ventoy.

i want to repot a bug when i closed the led and go to sleep and after wake up and want to unlock the screen keyboard and touchpad not detecting the keyboard light is on but no key detection so i forced reboot and everything worked i think

i dont I try everything even i put the boot efi in ventoy to see if its booting the i shrink 120 gb form my 1 tb internal drive and install it for the first time i got bootloop then its boot directly to ubnutu without grub menu third time its boot and show me grub menu and windows boot selection visable

lsusb -t
/: Bus 001.Port 001: Dev 001, Class=root_hub, Driver=xhci-hcd/1p, 480M
/: Bus 002.Port 001: Dev 001, Class=root_hub, Driver=xhci-hcd/1p, 10000M
/: Bus 003.Port 001: Dev 001, Class=root_hub, Driver=xhci-hcd/1p, 480M
|__ Port 001: Dev 002, If 0, Class=Vendor Specific Class, Driver=rtl8xxxu, 480M
/: Bus 004.Port 001: Dev 001, Class=root_hub, Driver=xhci-hcd/1p, 10000M

Sorry I just looked it up again, seems I was wrong. The SP 12 is still very much WIP. I think @glathe has done some work on it but it isn’t yet included in any of our official ISOs.

Can someone provide me with the steps or a link on how to properly compile this kernel. I have successfully clone the repo, but i am getting conflicting information on how to build it. I’m new to kernel work. Thanks in advance.

1 Like

How to build your own Ubuntu Concept X Elite kernel is a good starting point. I do have my own build script, but its basically a three-liner invoking dpkg-buildpackage with my signing key.

4 Likes

Reinstalled and now it works :slight_smile:
I see that apparmor permissions have also been fixed and snaps and flatpacks now work properly. There was a network problem.
The sound from the speakers is ok. The sound on the headphones seems to work, but it is distorted. Interestingly, the sound works without removing the firmware from Windows.
Since I mainly use headphones, I bought an adapter with an amplifier for headphones to USB, this solution works well.
I’ve only just reinstalled it, so I haven’t checked everything.

1 Like

I found adding this to ~/.config/pipewire/pipewire.conf.d/50-quantum.conf

context.properties = {
    default.clock.quantum       = 2048
    default.clock.min-quantum   = 2048
    default.clock.force-quantum = 2048
}

helps with speaker distortion. not quite if those are the best values, as obviously it increases latency which would matter for some people.

1 Like

I don’t have these files with me

@glathe I noticed a groovy new 6.19.6-jg-4 kernel from you.

The linux-qcom-x1e_6.19.6-jg-4_arm64.changes file notes: “arm64: dts: qcom: x1-el2: add 40-bit dma-ranges/ranges for EL2”

But this isn’t a nostubble kernel so it can’t run EL2 or am I mixed up here.

1 Like

You could if stubble doesn’t interfere with your boot process. Currently building -nostubble (I need it, too)

Short explanation of this patch: I had the 40-bits DMA patch in for all x1 devices regardless of EL2 or not, but it worsens the situation on 64GB hardware and EL1. That’s why I moved it to the x1-el2 overlay (where it is actually useful). This won’t be necessary if the Gunyah bug was fixed and rolled out to all devices, but it is what it is.

For my Windows Dev Kit 2023 and the T14s to start with EL2 I also need the -nostubble variant.

1 Like