Add Lenovo Yoga Slim 7x board support - #8673
Open
birkskyum wants to merge 24 commits into
Open
Conversation
Author
|
Validation correction: microphone input works, but internal-speaker playback is currently silent. This draft therefore proves the DSP startup and input path, not complete audio support. |
Contributor
There was a problem hiding this comment.
Pull request overview
Adds generic Snapdragon X enablement and Lenovo Yoga Slim 7x board-specific hardware support.
Changes:
- Configures aarch64 packages, firmware, DTBs, Vulkan, and kernel parameters.
- Enables Yoga keyboard, CPU-frequency, ADSP, and CDSP support.
- Adds focused Snapdragon and Yoga shell tests.
Tip
If you aren't ready for review, convert to a draft PR.
Click "Convert to draft" or run gh pr ready --undo.
Click "Ready for review" or run gh pr ready to reengage.
Reviewed changes
Copilot reviewed 15 out of 16 changed files in this pull request and generated 2 comments.
Show a summary per file
| File | Description |
|---|---|
bin/omarchy-hw-qualcomm-soc |
Detects Qualcomm device-tree platforms. |
default/pacman/mirrorlist-aarch64 |
Adds the Arch Linux ARM mirror. |
default/pacman/pacman-aarch64.conf |
Configures aarch64 repositories. |
etc/mkinitcpio.conf.d/thunderbolt_module.conf |
Gates Thunderbolt to x86_64. |
install/hardware/all.sh |
Runs Qualcomm and Yoga setup leaves. |
install/hardware/lenovo/start-yoga-slim7x-remoteprocs.sh |
Starts Yoga DSP remote processors. |
install/hardware/lenovo/yoga-slim7x.sh |
Applies Yoga board-specific configuration. |
install/hardware/qualcomm/dtb-uki.sh |
Embeds Qualcomm DTBs in UKIs. |
install/hardware/qualcomm/firmware.sh |
Installs firmware and protects USB roots. |
install/hardware/qualcomm/kernel-params.sh |
Adds Snapdragon kernel parameters. |
install/hardware/vulkan.sh |
Installs Freedreno on Qualcomm systems. |
install/omarchy-other.packages |
Includes the firmware extractor. |
install/post-install/pacman.sh |
Restores appropriate architecture repositories. |
install/user/mise-work.sh |
Selects the architecture-specific Node archive. |
test/shell.d/snapdragon-hardware-test.sh |
Tests firmware safeguards and DTB configuration. |
test/shell.d/yoga-slim7x-hardware-test.sh |
Tests Yoga configuration and DSP selection. |
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
Author
|
Follow-up validation on the physical Yoga: after rebooting into the rebuilt ALARM kernel with |
Author
|
Physical early-display validation is now complete on the Yoga Slim 7x. Before the fix, PMIC GLINK reported
The normal UKI was rebuilt with the same configuration, then checked for all required modules, firmware, 32 DTBs, encrypted-root command line and an exact Limine BLAKE2b hash match. The working experimental entry remains available as a fallback. The same update also removes |
Author
|
Final reboot confirmation: the regenerated normal The follow-up boot audit shows Two cosmetic messages remain immediately above the password prompt: They come from the upstream mkinitcpio |
Each of these is an unconditional assumption that only holds on x86_64. None
is x86-specific in spirit, and each one blocks or breaks an ARM64 install.
1. etc/mkinitcpio.conf.d/thunderbolt_module.conf
MODULES+=(thunderbolt) is unconditional, but Thunderbolt is x86-oriented
hardware and the module is not built for every architecture -- Arch Linux
ARM's aarch64 kernel has no `thunderbolt`. mkinitcpio treats an unresolvable
MODULES entry as a hard error, so *every* initramfs build fails:
==> ERROR: module not found: `thunderbolt'
That means no UKI, no boot entry, and an install that completes and then
cannot boot.
2. install/post-install/pacman.sh
This overwrites /etc/pacman.conf unconditionally. That config points
[core]/[extra]/[multilib] at Omarchy's mirror of Arch, which is x86_64-only,
and [omarchy] at pkgs.omarchy.org/stable/$arch, which 404s for aarch64.
([multilib] is 32-bit x86 libraries and exists on no ARM mirror at all.)
Applying it on ARM leaves the installed system unable to update anything.
3. install/user/mise-work.sh
Node publishes its builds as linux-x64 / linux-arm64, which does not match
uname -m. The bundled-tarball lookup hardcodes linux-x64, so on ARM it finds
nothing and the install aborts with "no bundled Node tarball". The sed that
parses the version back out of the filename needs the same treatment.
All three were found by installing Omarchy on aarch64 (Arch Linux ARM) and are
fixed here the same way: derive from uname -m rather than assuming.
The previous guard skipped the pacman.conf restore on aarch64 on the grounds that Omarchy's config points at x86-only repositories. But at that point the target still carries the live ISO's pacman.conf, which knows only the offline mirror, and that directory does not exist on the installed system. Skipping therefore left every aarch64 install unable to run pacman at all, which is the outcome the guard claimed to prevent. Derive the config from Omarchy's template instead: drop [multilib], keep [omarchy] (its $arch placeholder resolves correctly), add Arch Linux ARM's [alarm] and [aur] repositories, and leave the mirrorlist the distribution installed rather than replacing it with Omarchy's x86_64 mirror of Arch. The x86_64 path is unchanged.
Snapdragon laptops boot with the device tree for their exact model and the firmware provides none. The live ISO already boots them with a systemd-stub UKI that carries every candidate tree as .dtbauto sections and picks one by SMBIOS hardware id; the installed system built its UKIs with no tree at all, so the first reboot after the install had nothing to boot. Add the omarchy-hw-qualcomm-soc probe (root device-tree compatible starts with qcom,) and a hardware leaf that lists the trees in /etc/kernel/uki.conf, which mkinitcpio hands to ukify for every UKI limine-mkinitcpio-hook builds. The list is a snapshot of /boot/dtbs/qcom taken when the leaf runs; the file header says so, and the enumeration retires when ukify accepts globs.
The same set Fedora's Snapdragon images and the live ISO carry, as a limine-entry-tool drop-in so limine-update folds it into every entry, with each parameter's reason and retirement condition in the file.
Adreno GPUs are platform devices, so the lspci vendor scan in vulkan.sh never sees them; ask the SoC probe instead.
…s exist Arch Linux ARM keeps the redistributable Qualcomm blobs in linux-firmware-qcom; the installed system had none of them. The vendor-signed DSP firmware comes later from the owner's Windows partition; until it is there the DSP driver's failing probe resets the USB-C mux, which drops a USB-C root disk and hangs the boot (seen on the HP EliteBook Ultra G1q).
install/hardware/qualcomm/firmware.sh installs qcom-firmware-extract next to linux-firmware-qcom and runs it in the target: the files the device tree names (GPU zap shader, audio and compute DSP images) are taken from the stage the ISO saved before the disk was written, or from a Windows partition still on disk, into /usr/lib/firmware/updates. The audio-DSP blacklist now follows what is actually missing (qcom-firmware-extract --list-missing) instead of a path glob, so it clears itself once the firmware is present. install/omarchy-other.packages lists qcom-firmware-extract (arch=any) so the offline mirror carries it.
With real DSP firmware the Type-C port controller takes over the ports once the ADSP is up and resets them, which drops a root disk behind a USB-C port (G1q, external NVMe: cdsp up at 10.8 s, I/O errors and a read-only root at 22 s). Installs whose root disk reports TRAN=usb keep qcom_q6v5_pas blacklisted (no audio or battery reporting) until the kernel stops resetting connected ports; internal-disk installs are unchanged.
The final pacman restore is skipped entirely on ARM, which leaves the installed system pointed at the live ISO's offline config -- a file:// repo under a bind mount that only exists during the install. The first thing a new aarch64 desktop does is fail: $ sudo pacman -Sy evtest failed retrieving file 'offline.db' from disk: Could not open file /var/cache/omarchy/mirror/offline/offline.db No pacman -S, no omarchy-update. The skip was right that Omarchy's channel configs cannot be applied on ARM -- [core]/[extra] come from Omarchy's mirror of Arch, which builds x86_64 only, [multilib] is 32-bit x86, and the Omarchy package repository serves no aarch64 tree -- but the configuration it keeps instead is the offline one, so it trades a broken config for no config. Restore Arch Linux ARM's repositories there instead: [core] [extra] [alarm] [aur], its stock set, through a mirrorlist of its own because ALARM serves $arch/$repo where Arch serves $repo/os/$arch. [options] is kept byte-identical to the x86_64 channel configs. [omarchy] is left out until that tree exists; including it would 404 on every sync, and Omarchy's own packages simply hold at the versions the ISO installed. Three further things the restore has to do that the x86_64 path does not: - Take archlinuxarm-keyring while the offline mirror is still the active source. Arch's `base` pulls in archlinux-keyring and nothing pulls in this one, and the repositories being written are unreachable during an offline install. - Write the mirrorlist unconditionally. The target's mirrorlist carries Omarchy's and Arch's x86_64 mirrors ahead of ALARM's, so a sync logs 404s from mirror.omarchy.org, mirror.rackspace.com and geo.mirror.pkgbuild.com before it finds anything. - Populate the keyring. The install leaves ALARM's build key untrusted on the target, so the first signed install fails with "Arch Linux ARM Build System <builder@archlinuxarm.org> is unknown trust". x86_64 keeps running the same two lines it ran before, and every other architecture keeps the behaviour it had before the skip was introduced.
birkskyum
force-pushed
the
upstream/yoga-slim7x
branch
from
September 5, 2026 23:24
27c5cd5 to
4ed59ee
Compare
birkskyum
force-pushed
the
upstream/yoga-slim7x
branch
from
September 6, 2026 01:23
5d95ea5 to
91a5a70
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
console=tty0) for graphical Plymouth disk unlock and working keymap/consolefont hooks.scmi-cpufreqand starts ADSP/CDSP by firmware identity, respecting the generic DSP-disable guard.Dependencies
f681ff0. The generic runtime should land first; afterward, this PR's diff should contain only the board-specific changes.The systemd shutdown fix and camera stack described below are separate follow-ups, not merge prerequisites.
Validation
Physical Yoga Slim 7x 14Q8X9 (83ED) validation confirms Limine boot without the UKI hash warning, graphical Omarchy disk-encryption unlock with the built-in keyboard, polished shutdown/reboot without terminal messages, the graphical desktop, native display, GPU acceleration, Wi-Fi, Bluetooth mouse, internal speakers and microphone. The shutdown/reboot result also used a separate systemd v261.2 backport of the change proposed in systemd/systemd#43671. That fix remains under review and is not included in this PR. The speaker-reset kernel fix, archlinuxarm/PKGBUILDs#2217, has merged.
The OV02C10 camera also has a visually confirmed fast, upright preview with natural-looking colors and strong noise reduction on the separate experimental kernel
7.2.0-1.1-aarch64-ARCH-camera1. Camera enablement is a follow-up, not part of this PR; the hardware report covers the subsequent Chromium live-video test and remaining integration work. The separate libcamera cleanup-hang fix prevents a hang after capture-start failure and carries Kieran Bingham'sReviewed-by. It remains unmerged and does not fix the underlying sensor timeout or image quality.Barnabás Pőcze's PipeWire libcamera compatibility fixes (!2981) merged on 7 September 2026. Release and Arch Linux ARM package availability are still pending; this merge alone does not provide stock camera support.
The 7 September isolated source-built comparison passed direct capture and showed upright video with acceptable colors, but startup/preview latency and PipeWire validation remain unresolved before replacing the private camera stack.
The updated Bash 5 tests pass for matching/nonmatching boards, DMI-only detection, already-running DSPs, missing ADSP, failed starts, independent zstd/xz selection, firmware precedence and console selection without replacing existing boot parameters. A cross-repository fixture verifies that shared extraction and Yoga setup include each GPU firmware file once. ShellCheck and whitespace checks pass.
The console change was boot-tested on the Yoga with kernel
7.2.0-1.1-aarch64-ARCH, changing only the command line of the working boot image. Active consoles changed fromtty0 ttyMSM0totty0. The owner confirmed graphical Omarchy disk unlock and successful desktop startup, withoutkbd_mode: KDSKBMODE: Inappropriate ioctl for device,Couldn't open /dev/console, or scrolling service status.The current firmware-consolidation and failure-path changes were tested in an ARM64 container; they have not been deployed to the Yoga for another boot test. HP/ASUS validation of the console and early-display changes is still pending.