Hmmm, you mean… end up AT ALL? Even if I reinstall Ubuntu, or even if I switch to Windows?
Hmm, and what extra steps do I need to do?
And also, what about camera?
Hmmm, you mean… end up AT ALL? Even if I reinstall Ubuntu, or even if I switch to Windows?
Hmm, and what extra steps do I need to do?
And also, what about camera?
hmm, you mean, I need to start $(pwd)/firmware ?
Wow, it’s perfect and great)
I thought that first thing that would be working with external monitors is HDMI, I didn’t expect that it would be Type-C)
Well, I’m delighted.
But, yeah. There is an issue, when suspending laptop, it breaks monitor, it has black screen, though you see it in Display Settings, you can see external monitor, but it has black screen.
Hey guys! I don’t know if this could help for maybe adding support for the X1-45 GPU, but I’ll upload my DSDT dump from my x1p42100 laptop, and I also have ARMv8 reverse engineering experience, if reverse engineering the windows kernel driver is necessary to help make it work! https://drive.proton.me/urls/YHXSCF64RW#sYD27Y5oxKt6
A couple of weeks ago, Microsoft released new firmware in Windows 11 for the Asus Vivobook S 15 XP-42-100 (S5507QA). It seems the file structure in Windows/System32/DriverStore/FileRepository has changed. For a start, there is no longer an ASUSTeK/vivobook-s15 subdirectory.
Looking through all subdirectories finds the files searched for in the qcom-extract-firmware script but cdsp_dtbs.elf and cdspr.jsn have duplicates:
$ fw_files="adsp_dtbs.elf adspr.jsn adsps.jsn adspua.jsn battmgr.jsn cdsp_dtbs.elf cdspr.jsn qcadsp8380.mbn qccdsp8380.mbn qcdxkmsuc8380.mbn"
$ for f_path in ${fw_files}; do
echo -e "\t${f_path}"
find . -name "*${f_path}" -exec ls -ltd {} +
done
adsp_dtbs.elf
-rwxrwxrwx 1 root root 73528 Mar 24 04:48 ./qcsubsys_ext_adsp8380.inf_arm64_c0835864643a2a1c/adsp_dtbs.elf
adspr.jsn
-rwxrwxrwx 1 root root 697 Mar 24 04:48 ./qcsubsys_ext_adsp8380.inf_arm64_c0835864643a2a1c/adspr.jsn
adsps.jsn
-rwxrwxrwx 1 root root 536 Mar 24 04:48 ./qcsubsys_ext_adsp8380.inf_arm64_c0835864643a2a1c/adsps.jsn
adspua.jsn
-rwxrwxrwx 1 root root 731 Mar 24 04:48 ./qcsubsys_ext_adsp8380.inf_arm64_c0835864643a2a1c/adspua.jsn
battmgr.jsn
-rwxrwxrwx 1 root root 537 Mar 24 04:48 ./qcsubsys_ext_adsp8380.inf_arm64_c0835864643a2a1c/battmgr.jsn
cdsp_dtbs.elf
-rwxrwxrwx 1 root root 40760 Feb 18 06:33 ./qcnspmcdm_ext_cdsp8380.inf_arm64_1b18f9dc06e2d351/cdsp_dtbs.elf
-rwxrwxrwx 1 root root 40760 Oct 16 2024 ./qcsubsys_ext_cdsp8380.inf_arm64_0e08ce45173446a1/cdsp_dtbs.elf
cdspr.jsn
-rwxrwxrwx 1 root root 534 Feb 18 06:33 ./qcnspmcdm_ext_cdsp8380.inf_arm64_1b18f9dc06e2d351/cdspr.jsn
-rwxrwxrwx 1 root root 534 Oct 16 2024 ./qcsubsys_ext_cdsp8380.inf_arm64_0e08ce45173446a1/cdspr.jsn
qcadsp8380.mbn
-rwxrwxrwx 1 root root 21879224 Mar 24 04:48 ./qcsubsys_ext_adsp8380.inf_arm64_c0835864643a2a1c/qcadsp8380.mbn
qccdsp8380.mbn
-rwxrwxrwx 1 root root 3174824 Feb 18 06:33 ./qcnspmcdm_ext_cdsp8380.inf_arm64_1b18f9dc06e2d351/qccdsp8380.mbn
-rwxrwxrwx 1 root root 3072424 Oct 16 2024 ./qcsubsys_ext_cdsp8380.inf_arm64_0e08ce45173446a1/qccdsp8380.mbn
qcdxkmsuc8380.mbn
-rwxrwxrwx 2 root root 12088 Feb 27 04:32 ./qcdx8380.inf_arm64_95e56db089b80d1a/qcdxkmsuc8380.mbn
-rwxrwxrwx 1 root root 12088 Aug 7 2024 ./qcdx8380.inf_arm64_3cab1dfe836f6c02/qcdxkmsuc8380.mbn
There is also a new .jsn file:
-rwxrwxrwx 1 root root 424 Feb 17 08:06 ./qcwlanmsl_ext_wpss8380.inf_arm64_894090fd7f708b97/wpssr.jsn
and a pile of 'mbn files:
$ find . -name '*.mbn' -exec ls -ltd {} +
-rwxrwxrwx 1 root root 21879224 Mar 24 04:48 ./qcsubsys_ext_adsp8380.inf_arm64_c0835864643a2a1c/qcadsp8380.mbn
-rwxrwxrwx 1 root root 2314856 Feb 27 04:32 ./qcdx8380.inf_arm64_95e56db089b80d1a/qcvss8380.mbn
-rwxrwxrwx 1 root root 2314856 Feb 27 04:32 ./qcdx8380.inf_arm64_95e56db089b80d1a/qcvss8380_pa.mbn
-rwxrwxrwx 1 root root 4607848 Feb 27 04:32 ./qcdx8380.inf_arm64_95e56db089b80d1a/qcav1e8380.mbn
-rwxrwxrwx 2 root root 12088 Feb 27 04:32 ./qcdx8380.inf_arm64_95e56db089b80d1a/qcdxkmsuc8380.mbn
-rwxrwxrwx 2 root root 12088 Feb 27 04:32 ./qcdx8380.inf_arm64_95e56db089b80d1a/qcdxkmsucpurwa.mbn
-rwxrwxrwx 1 root root 4886528 Feb 21 07:16 ./qcwlanhsp8380.inf_arm64_28005e4da5e5e3db/wlanfw20.mbn
-rwxrwxrwx 1 root root 4851488 Feb 21 07:16 ./qcwlanhsp8380.inf_arm64_28005e4da5e5e3db/wlanfw.mbn
-rwxrwxrwx 1 root root 6082624 Feb 20 18:06 ./qcwlanhmt8380.inf_arm64_947fe21a1b8d08f0/wlanfw20.mbn
-rwxrwxrwx 1 root root 65624 Feb 19 10:12 ./qctreeextqcom8380.inf_arm64_57b498d39219a01b/hdcp1.mbn
-rwxrwxrwx 1 root root 168024 Feb 19 10:12 ./qctreeextqcom8380.inf_arm64_57b498d39219a01b/hdcp2p2.mbn
-rwxrwxrwx 1 root root 53336 Feb 19 10:12 ./qctreeextqcom8380.inf_arm64_57b498d39219a01b/hdcpsrm.mbn
-rwxrwxrwx 1 root root 855008 Feb 19 10:12 ./qctreeextqcom8380.inf_arm64_57b498d39219a01b/pr_3_wp.mbn
-rwxrwxrwx 1 root root 1794664 Feb 18 12:45 ./qceva8380.inf_arm64_2c225ab110269463/evass.mbn
-rwxrwxrwx 1 root root 3174824 Feb 18 06:33 ./qcnspmcdm_ext_cdsp8380.inf_arm64_1b18f9dc06e2d351/qccdsp8380.mbn
-rwxrwxrwx 1 root root 7263024 Feb 17 08:06 ./qcwlanmsl8380.inf_arm64_7a63905061a06bda/wpss.mbn
-rwxrwxrwx 1 root root 905880 Jan 27 12:47 ./qccamisp8380.inf_arm64_82e4ecb81ad980d2/CAMERA_ICP.mbn
-rwxrwxrwx 1 root root 6078528 Nov 24 16:31 ./qcwlanhmt8380.inf_arm64_387c0930431e022f/wlanfw20.mbn
-rwxrwxrwx 1 root root 3072424 Oct 16 2024 ./qcsubsys_ext_cdsp8380.inf_arm64_0e08ce45173446a1/qccdsp8380.mbn
-rwxrwxrwx 1 root root 2310760 Aug 7 2024 ./qcdx8380.inf_arm64_3cab1dfe836f6c02/qcvss8380.mbn
-rwxrwxrwx 1 root root 2310760 Aug 7 2024 ./qcdx8380.inf_arm64_3cab1dfe836f6c02/qcvss8380_pa.mbn
-rwxrwxrwx 1 root root 4607848 Aug 7 2024 ./qcdx8380.inf_arm64_3cab1dfe836f6c02/qcav1e8380.mbn
-rwxrwxrwx 1 root root 12088 Aug 7 2024 ./qcdx8380.inf_arm64_3cab1dfe836f6c02/qcdxkmsuc8380.mbn
-rwxrwxrwx 1 root root 12088 Aug 7 2024 ./qcdx8380.inf_arm64_3cab1dfe836f6c02/qcdxkmsucpurwa.mbn
Anyone venture a suggestion as to which of the duplicates should be chosen? Are the rest of them OK to package up a la qcom-extract-firmware does? Do we need to do anything with the new ones?
It may be unrelated, the new grub @tobhe mentioned 4 days ago, let me do-release-upgrade -d to Ubuntu 25.04 (having originally dd’ed from the image of @glathe 9 Feb 2025 Ubuntu_Desktop_24.10_VivobookS15_x1p42.img.xz) but I suspect I have a firmware mismatch as after a reboot or going into Windows, my laptop keyboard goes walkabout (unresponsive) until I try various accessibility “screen keyboard” workarounds, then it comes back. Would be nice to have this settle down.
Thanks again as always to Ubuntu Heros @tobhe and @glathe for letting us get this far.
I want to install Ubuntu25.04 on my Surface Pro 11th Editon. But I even can’t boot to Grub of the installer USB. It keeps rebooting(I set boot from USB is the first and disable Secure Boot).
There are a few grub fixes in the concept image that we couldn’t get into 25.04 because they caused regressions on other machines. You might be able to install the 24.10 concept and upgrade to 25.04 from there.
@icecream95 @mrprmohammad or anyone else with an Asus Vivobook it would be helpful if you could test https://cdimage.ubuntu.com/daily-live/current/questing-desktop-arm64.iso which should fix this issue. If this works we can backport the fix to 25.04.
In particular I’d like to see that the installed system has ubuntu-x1e-settings installed as expected.
EDIT: for more context see: Bug #2107692 “[SRU] Asus Vivobook S15 hwe-qcom-x1e-meta modsign...” : Bugs : ubuntu-x1e-settings package : Ubuntu
It didn’t work. And the latest daily build(25.10) arm64 Ubuntu didn’t work, too. They all kept rebooting.
Is that before or after you get the grub boot selection screen?
before the grub boot selection screen
weird. You could try an older image from Index of /~platform/images/ubuntu-concept to see if any of those work.
Do you want to watch the video of that?
But there is an exception: Arch Linux for SP11 from Github. I have tried Debian arm64, Arch Linux for SP11, Fedora arm64 and Ubuntu arm64. But only Arch Linux for SP11 boot successfully. And Debian arm64 can boot to grub. But can’t start installer live. Others kept restarting.
I see the struction of Arch Linux for SP11 installer USB is different from many other Arm64 Linux distros in some ways. Maybe I can try changing the struction of Ubuntu Arm64 Installer USB
Concerning the crashes/reboots I have been seeing on my T14s-64GB:
I have both of these in my grub.cfg:
badram 0x8800000000,0xf800000000
cutmem 0x8800000000 0x8fffffffff
But free reports:
# free
gesamt benutzt frei gemns. Puffer/Cache verfügbar
Speicher: 63859836 5831568 39886016 1399884 20176904 58028268
Auslager: 8388604 0 8388604
Previously, this was reduced to 32GB.
![]()
This is unexpected indeed. Looks like the same happens on my machine. Is that 25.04?
It looks like they ship additional kernel patches. The grub config patch shouldn’t really make a difference. Afaict this wouldn’t why you don’t even see grub.
I can observe the same behavior on my 14s. Actually I just came back here to report this issue myself
I can reproduce this with a 24.10 concept installation with kernel 6.15.0-rc4 and a fresh 25.04 on 6.14.0-15. Both used to work with GRUB_BADRAM="0x8800000000,0xf800000000". Maybe the recent grub update broke something?
As a workaround I add mem=31G to the kernel cmdline manually in grub.
I was wondering if it might have been a change in grub or in the kernel. This makes it sound like a kernel change is more likely.
I have tried replacing Ubuntu25.04 arm64 grub and boot/ files with grub and boot/ files of Arch Linux for SP11. It stopped keeping rebooting. But it didn’t show grub selection screen. It outputed some grub errors.