Repository navigation
packaging: our kernel, amdxdna and the AXB35 EC as deb, rpm and Arch packages, with the NPU config (Fixes #1280) - #1297
Conversation
…packages, with the NPU config (#1280) The engine package is userspace only; the NPU and the board's EC need the kernel side too, and until now that side existed only as 1bit OS's own build. This adds the package set, one script, one staged payload per package, three families: kernel linux-image/linux-headers (deb, the OS build's own), 1bit-kernel + 1bit-kernel-devel (rpm), linux-1bit + linux-1bit-headers (Arch) drivers amdxdna-1bit-dkms: amd/xdna-driver at 526c6081 plus third_party/patches/amdxdna 0001,0002,0004,0005,0003 — the series the c26 image and this box run; 0006/0007 stay carried and unapplied, because loading them is the owner's call ec-su-axb35-dkms: the AXB35-02 EC driver (GPL-2.0, upstream f62c2c22) plus a DMI gate, so it attaches only on an AXB35 board and is inert everywhere else config 1bit-npu-config: unlimited memlock, the NPU keep-awake udev rule, modules-load.d for the EC, and the PUBLIC kernel MOK certificate Both drivers build through dkms against the user's own kernel headers and sign with the user's own MOK, which is what makes them work on a distribution kernel and not only on ours; they land in updates/ (Debian, Arch) or extra/ (Fedora), in front of the in-tree amdxdna, and uninstalling puts the in-tree driver back. The kernel is not rebuilt three times: rpm and Arch carry the deb payload in that family's layout, so all three families ship the same bits. Measured: the payload's vmlinuz is sha256 6f3c6764..., byte-identical to /boot/vmlinuz-7.4.0-rc1-1bit here, and sbverify says Signature verification OK against the certificate in 1bit-npu-config. scripts/pkg-proof.sh proves each family in a clean container of that family: install, build both modules against the container's own headers, amdxdna resolving ahead of the in-tree one, the DMI gate in the built EC module, the kernel package's payload and build tree, then uninstall. 22/22 rows PASS on ubuntu:26.04, fedora (fc45) and archlinux. No private key is packaged, printed or committed; the script refuses a --mok-cert that carries one. Nothing was installed, removed or reloaded on this box, and no release or upload is part of this change: docs/install-any-distro.md carries the per-family install, the Secure Boot step and the measured rows. Fixes #1280
|
#1297 ready for review at Measured, same three clean containers, Two things a reviewer should push back on if they disagree: (1) rpm and Arch carry the deb's kernel payload rearranged rather than rebuilding the kernel twice — one kernel, three formats, no drift; (2) |
… submodule check (#1324) The #1297 squash captured a mid-state of the branch: scripts/mk-kernel-packages.sh landed in its pre-shellcheck form and scripts/pkg-proof.sh without the EC-gate fix, so main's gate row is the string-only form that failed true-false on Arch, and docs/install-any-distro.md still says 22/22 rows with the take-1 hardware wording. This ports the two follow-up commits that the squash dropped and adds one new fix: * mk-kernel-packages.sh: the lint set (split assignments, the arch tar array, the rpm echo), and the submodule check. `git -C third_party/xdna-driver rev-parse HEAD` on an UNINITIALIZED submodule walks up to the enclosing repository, so a plain clone of main reported the driver as 'at 0f45221' (the engine's commit) instead of 'not initialized'. The toplevel must now be the driver directory itself, and the failure names `git submodule update --init third_party/xdna-driver`. * pkg-proof.sh: the EC gate row decompresses to a file and accepts the undefined `dmi_get_system_info` reference or the message (grep -q on a pipe ends it early and pipefail then fails the row with the match in hand — measured on arch); the Arch `vmlinuz-1bit` row; `krel` as a constant; the leftover-module count as a loop. * docs: 'all 24 / all 22 / all 22 rows PASS' and the take-2 known-answer row (/v1/completions, twice, identical). pi-pkg's edits in the same file are untouched. Verified: a clean clone of main with the submodule initialized builds all five debs (kernel payload hashes unchanged); without it, the new message. Re-proved deb and arch from the repaired script in their containers. Refs #1280 Co-authored-by: bong-water-water-bong <bong-water-water-bong@1bit.gg>
Fixes #1280.
The engine package is userspace only; the NPU and the board's EC need the kernel side too, and until now
that side existed only as 1bit OS's own build. This adds the package set: one script, one staged payload
per package, three families.
linux-image-7.4.0-rc1-1bit+linux-headers-…1bit-kernel+1bit-kernel-devellinux-1bit+linux-1bit-headersamdxdna-1bit-dkmsec-su-axb35-dkms1bit-npu-configThe drivers are DKMS source, not binaries.
amdxdna-1bit-dkmsisamd/xdna-driverat526c6081plusthird_party/patches/amdxdna0001,0002,0004,0005,0003— the series the c26 image and this box run.0006and
0007stay carried and unapplied here: loading them is the owner's call (engine#812), so a packagedoes not decide it. They build against your kernel headers through dkms and sign with your MOK, land in
/lib/modules/<ver>/updates/(Debian, Arch) or/extra/(Fedora) — in front of the in-treeamdxdna— anduninstalling puts the in-tree driver back.
ec-su-axb35-dkmsis GPL-2.0 upstreamcmetz/ec-su_axb35-linuxatf62c2c22(source shipped in thepackage) plus the one patch the issue asks for: it attaches only on an AXB35 board
(
dmi_get_system_info(DMI_BOARD_NAME),third_party/patches/ec_su_axb35/0001), so having it installed onany machine is inert.
The kernel is not rebuilt three times: rpm and Arch carry the deb payload in that family's layout, so all
three families ship the same bits.
Measured
vmlinuzissha256 6f3c6764…, byte-identical to/boot/vmlinuz-7.4.0-rc1-1bit, andsbverify --cert MOK-Kernel.der→Signature verification OK7.0.0-43-genericcomesout at
srcversion EE1F36A2B9BA294CE11AD80, the srcversion of the installed/lib/modules/7.4.0-rc1-1bit/updates/amdxdna.koscripts/pkg-proof.sh, 22 rows per family, clean container of that family: install → dkms builds andinstalls both modules against the container's own headers →
modprobe --show-depends amdxdnaresolves tothe dkms build, not the in-tree one → the AXB35 gate string is in the built EC module → the kernel package
installs with its payload and
buildtree → uninstall leaves nothing and a cleandkms statusubuntu:26.047.0.0-43-genericfedora:latest(fc45)7.2.15-300.fc45.x86_64archlinux:latest7.2.14-arch1-1(
PROOF-RC=0in all three; deb has two extra rows — the kernel image is present andsbverifys againstthe shipped certificate.)
npu-hold, read-only, two tickets of 2 s and 5 s of token time.1bit serve --device npuon Qwen3-0.6B,/v1/completionsgreedy, twice:The capital of France is→Paris. The capital of Italy is Rome. The capital of Spain is Madrid.identically on both runs(56.9 / 50.7 tok/s, load 2.2 s), 0
amdxdnalines in both windows, and the loaded module issrcversion EE1F36A2B9BA294CE11AD80— the build this package's source produces in a container. Noinstall, no
modprobe, no udev reload, nothing outside/tmp. For the record: a ring-buffer count ofamdxdnaerrors reads 9, all at 17:12:45–46 — between the two probes,Populate ranges failed, ret -14(the engine#812 signature), another lane's work, not mine.Not in this PR, deliberately
No release and no upload. No weekly-release wiring (
scripts/weekly.shcalling the new script is #1279'scadence and pi-pkg's call), no AUR entry, and no bootloader integration: the doc gives
depmod/dracut/mkinitcpio -Pand leavesgrub/systemd-bootto the distribution's own tooling. rpm andArch kernel packages are unsigned until the release pipeline signs them, which the doc says plainly
(
dnf install --nogpgcheck,zypper --allow-unsigned-rpm, pacman's warning).The MOK private key is not in this PR and cannot be: the packages ship only the public certificate, and
scripts/mk-kernel-packages.shrefuses a--mok-certwhose text carriesPRIVATE KEY.Docs are in the same PR:
docs/install-any-distro.mdgets the per-family install, the Secure Boot step, thesource offer and six measured rows;
docs/kernel.md's out-of-tree-modules bullet names the two dkms packages.