Skip to content

Add Lenovo Yoga Slim 7x board support - #8673

Open
birkskyum wants to merge 15 commits into
omacom:quattrofrom
birkskyum:upstream/yoga-slim7x
Open

Add Lenovo Yoga Slim 7x board support#8673
birkskyum wants to merge 15 commits into
omacom:quattrofrom
birkskyum:upstream/yoga-slim7x

Conversation

@birkskyum

@birkskyum birkskyum commented Aug 27, 2026

Copy link
Copy Markdown

Summary

  • detects the Lenovo Yoga Slim 7x by its Qualcomm device-tree compatible or Lenovo DMI identifiers
  • initializes the built-in keyboard and native display stack in the initramfs so encrypted installs show and accept the disk passphrase
  • loads scmi-cpufreq for platform CPU frequency control
  • starts the audio and compute DSP remote processors by firmware identity without waiting for every udev device
  • tests matching and nonmatching Qualcomm boards, early boot configuration, the DSP service guard and both expected remote processors

Dependency

This is intentionally stacked on the generic Snapdragon work in #8672. Until that PR merges, GitHub displays its commits here too. After #8672 merges this branch should be rebased onto quattro.

The encrypted-install ISO is tracked in omacom/omarchy-iso#129. The matching-safe Lenovo firmware extraction is omacom/omarchy-pkgs#221.

Physical validation

Validated on a Lenovo Yoga Slim 7 14Q8X9 (83ED) with Snapdragon X Elite:

  • full-disk installation creates a 951.9 GB LUKS2 root volume
  • the initramfs contains the HID-over-I2C input driver and the QRTR, PMIC GLINK, PS883x, eDP and MSM display chain
  • the required SQE, GMU and Lenovo display firmware are embedded in the UKI
  • Qualcomm DRM initializes about 9 ms after /init, creates msmdrmfb and shows the LUKS prompt before root is unlocked
  • the built-in keyboard accepts the visible LUKS passphrase and the system reaches the Omarchy desktop
  • the internal 2944x1840 display, keyboard, touchpad, touchscreen, Wi-Fi, Freedreno GPU acceleration, microphone input and speaker output work
  • both ADSP and CDSP start with matching Windows firmware
  • the generated UKI contains 32 DTBs and its BLAKE2b hash matches the Limine entry
  • the focused board-support test passes under Bash 5 on the physical machine

Speaker output was validated with an ALARM kernel rebuilt with CONFIG_RESET_GPIO=m: all four WSA8845 amplifiers changed from UNATTACHED to Attached, and speaker-test produced audible output. The kernel config fix is submitted as archlinuxarm/PKGBUILDs#2217.

The board-specific work, visible encrypted-root prompt and encrypted-install gate have passed. This PR is ready for review.

oceanapplications and others added 10 commits August 27, 2026 22:51
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

Copy link
Copy Markdown
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.

@birkskyum
birkskyum marked this pull request as ready for review August 28, 2026 10:44
Copilot AI balanced review requested due to automatic review settings August 28, 2026 10:44

Copilot AI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Comment thread install/hardware/lenovo/yoga-slim7x.sh Outdated
Comment thread test/shell.d/yoga-slim7x-hardware-test.sh
@birkskyum

Copy link
Copy Markdown
Author

Follow-up validation on the physical Yoga: after rebooting into the rebuilt ALARM kernel with CONFIG_RESET_GPIO=m, reset_gpio is loaded for two consumers and speaker-test -D pipewire -c 2 -t sine -f 440 -l 1 produces audible output from the internal speakers. The kernel change remains isolated in archlinuxarm/PKGBUILDs#2217.

@birkskyum

Copy link
Copy Markdown
Author

Physical early-display validation is now complete on the Yoga Slim 7x.

Before the fix, PMIC GLINK reported failed to initialize pdr, the MSM display probe deferred, and the LUKS prompt was black. Adding QRTR before PMIC GLINK in the initramfs lets the native Qualcomm display chain bind before disk unlock. On the successful boot:

  • /init began at 165.402955 seconds
  • MSM DRM initialized at 165.411677 seconds
  • msmdrmfb appeared at 165.411990 seconds
  • the LUKS prompt was visible and accepted the built-in keyboard input
  • there was no PDR initialization failure or deferred display probe

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 systemd-udev-settle.service from the Yoga DSP unit. The remoteproc helper already retries for device discovery, and the dependency added 6.884 seconds to userspace startup while emitting systemd's deprecation warning.

@birkskyum

birkskyum commented Aug 28, 2026

Copy link
Copy Markdown
Author

Final reboot confirmation: the regenerated normal linux-aarch64 entry shows the LUKS prompt, accepts the passphrase and reaches the desktop. The experimental entry was not needed.

The follow-up boot audit shows msmdrmfb, connected eDP, successful ADSP/CDSP startup and no systemd-udev-settle.service activation. Userspace reached graphical.target in 8.139 seconds.

Two cosmetic messages remain immediately above the password prompt:

kbd_mode: KDSKBMODE: Inappropriate ioctl for device
Couldn't open /dev/console

They come from the upstream mkinitcpio keymap and consolefont hooks attempting console ioctls before fbcon is fully attached. They do not affect input or unlock, so they are intentionally outside this board-support PR.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants