Skip to content

DE25: mirror the DE10 firmware set via a shared image-common fragment (ADR 0029 D11/D12) - #141

Merged
mcfbytes merged 2 commits into
masterfrom
feat/de25-firmware-parity
Sep 6, 2026
Merged

DE25: mirror the DE10 firmware set via a shared image-common fragment (ADR 0029 D11/D12)#141
mcfbytes merged 2 commits into
masterfrom
feat/de25-firmware-parity

Conversation

@mcfbytes

@mcfbytes mcfbytes commented Sep 3, 2026

Copy link
Copy Markdown
Owner

Summary

Owner decision (ADR 0029 D12): the DE25-Nano ships the DE10's linux-firmware selection for parity, so a dongle that works on a DE10 works on a DE25. The shared kernel fragment already built every Wi-Fi/Bluetooth driver; without the blobs they bound and failed at request_firmware().

Implemented the structural way: a new configs/fragments/image-common.fragment, included by both boards' image stacks and never by the kernel-only stack, holding the 31 firmware symbols moved byte-for-byte out of de10nano-image.fragment. This is the first shared package content between the boards and the home for more as the DE25 grows.

Also records D11 (the DE10-style two-stage card layout is the target; the plain-ext4 card stays until hardware) and the seccomp-off decision, and retires both from the open list.

Proof the DE10 is unchanged

  • check-config-fragments.sh: all four stacks OK; the de10nano, de10nano-kernel and rt golden lines are unchanged (moving symbols within a stack cannot change its resolved config); only de25nano moves, and its normalised delta is exactly the 31 symbols plus the two CYPRESS_CYW43XX* they select.
  • Toolchain fingerprint byte-identical (it denies BR2_PACKAGE_ lines). Only the DE10 dl-cache key moves once, with restore-keys fallback.
  • hashFiles() list in the build action updated; check (e) enforces it.

DE25 build

Only the firmware packages built; rootfs and card regenerated. target/lib/firmware: 202 files + 66 symlinks, 52 MB, vs the DE10's 204 + 67 — the three missing are the xow/xone dongle blobs, left with the DE10 on purpose because their depends on BR2_PACKAGE_XONE (an out-of-tree module the DE25 doesn't build) would be silently dropped by olddefconfig. ext4 usage 85.6 MiB of 256 MiB, so no size bump. Card checker passes.

Placement calls (docs/buildroot-config.md §12)

Moved: LINUX_FIRMWARE + 27 sub-options, WIRELESS_REGDB (cfg80211 loads it from /lib/firmware; without it the DE25 sits on world-roaming), LINUX_FIRMWARE_EXTRA, BCM20702_FIRMWARE. Stayed: XOW_FIRMWARE, XONE, RTL8852CU_MORROWNR (OOT drivers), KMOD_TOOLS (no decision taken).

🤖 Generated with Claude Code

https://claude.ai/code/session_01FYjrnzEEu4HzJSPWNAaRvm

mcfbytes and others added 2 commits September 2, 2026 22:32
Owner decision (2026-09-03): the DE25-Nano image mirrors the DE10's
linux-firmware selection for parity. The shared kernel fragment
(board/mister/common/linux-mister.fragment) already builds the whole DE10
Wi-Fi/Bluetooth driver set on both boards, so the DE25 had exactly those
drivers binding and then failing at request_firmware() -- the standing
obligation docs/de25-kernel-config.md 7.1 recorded, now closed.

Implemented the way the config layout anticipates, not by copying 31 lines
into de25nano.fragment: a new configs/fragments/image-common.fragment holds
the selection, and it is in the IMAGE stack of BOTH boards and in the
kernel-only stack of NEITHER.

  DE10NANO_FRAGMENTS        := common de10nano image-common de10nano-image
  DE10NANO_KERNEL_FRAGMENTS := common de10nano kernel-only
  DE25NANO_FRAGMENTS        := common de25nano image-common

Not `common`: that fragment IS in the kernel-only stack, whose rootfs.tar
carries modules and is then thrown away -- it must not spend a ~557 MiB fetch
and 52 MiB of install per kernel leg on blobs no variant ships. Not per-board:
parity is the point, and a mirrored copy is what the fragment split exists to
end.

Moved (31 symbols, byte-for-byte): BR2_PACKAGE_LINUX_FIRMWARE + its 27
sub-options; WIRELESS_REGDB (cfg80211 loads regulatory.db the same way, and
the DE25 builds cfg80211); LINUX_FIRMWARE_EXTRA (depends on its parent,
installs out of its extracted tree); BCM20702_FIRMWARE (one .hcd for btbcm
under btusb, both built by the shared kernel fragment). Left behind:
XOW_FIRMWARE (depends on BR2_PACKAGE_XONE, an out-of-tree module the DE25 does
not build -- moving it would be silently dropped by olddefconfig, which check
(b) turns into a failure), the out-of-tree driver packages, and KMOD_TOOLS (no
owner decision has taken it for the DE25).

Proof:
* scripts/check-config-fragments.sh: the de10nano, de10nano-kernel and rt
  golden lines are UNCHANGED -- moving symbols between fragments of one stack
  cannot change the resolved config, and did not. Only de25nano moved,
  2adb6b40 -> 714728e0; the delta is exactly the 31 symbols plus the two
  CYPRESS_CYW43XX* sub-options BRCM_BCM43XX* select.
* CI's toolchain fingerprint: byte-identical (26 lines) before and after (it
  denies BR2_PACKAGE_ and sorts, so a relocation cannot move it). action.yml's
  DE10 hashFiles() list gains the new fragment, as check (e) requires; that
  dl-cache key moves once and falls back through restore-keys.
* scripts/check-kernel-defconfig-sync.sh: OK.
* Built output-de25 with the new stack: target/lib/firmware = 202 files + 66
  symlinks, 52 MiB, identical to the DE10's tree minus exactly the three
  xow/xone entries. ext4 rootfs 85.6 MiB used of 256 MiB (33%), so
  BR2_TARGET_ROOTFS_EXT2_SIZE stays at 256M (measurement recorded at the
  line). scripts/check-sdcard-de25.sh passes.
* renovate.json unchanged: no manager's file pattern covers these lines (the
  firmware pins live in package/*/*.mk and package/*/*.hash).

Docs: buildroot-config.md gains section 12 for the new fragment (the firmware
rationale and its sub-option table moved there from 5.28, which is kept as a
redirect so section 5's numbering, cited elsewhere, stays put); section 1's
layout and stack tables, section 6.1/6.6/6.8, section 10's rules (new rule 6),
placement table and symbol counts, and section 11 are updated.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01FYjrnzEEu4HzJSPWNAaRvm
…rmware parity, seccomp off)

Owner decisions 2026-09-03: the DE25 card targets the DE10-style
two-stage layout (p1 FAT boot files, p2 exFAT data with linux.img loop
root) once hardware exists; the plain-ext4 card stays until then. The
DE25 mirrors the DE10's linux-firmware selection via the image-common
fragment; CONFIG_SECCOMP stays off as on the DE10, with the openssh
sandbox obligation accepted. Task list: both items retired, next steps
reordered for a board that arrives after the owner's vacation.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01FYjrnzEEu4HzJSPWNAaRvm
Copilot AI lite review requested due to automatic review settings September 3, 2026 03:33

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.

🟢 Approval recommended

The fragment refactor is consistently applied across stacks/CI/docs, and the supporting checks/scripts are aligned to the new shared image-common layer without introducing conflicting definitions.

Pull request overview

This PR implements the ADR 0029 D12 decision to give the DE25-Nano image parity with the DE10-Nano’s linux-firmware selection by factoring the firmware-related Buildroot symbols into a shared image-layer fragment used by both boards’ image stacks (but excluded from kernel-only stacks).

Changes:

  • Introduces configs/fragments/image-common.fragment and includes it in both DE10NANO_FRAGMENTS and DE25NANO_FRAGMENTS to share the /lib/firmware package selections.
  • Moves the DE10’s firmware selection block out of de10nano-image.fragment into image-common.fragment, preserving DE10 resolved-config identity while extending DE25.
  • Updates CI cache keying and documentation/ADRs to reflect the new fragment structure and the resolved decisions (D11/D12).
File summaries
File Description
TASKS.md Updates task history/cross-references to point firmware selection to image-common.fragment.
docs/firmware-parity.md Updates citations and notes to reflect the firmware symbols’ new home in image-common.fragment.
docs/decisions/0029-de25-implementation-path.md Records decisions D11 and D12 and closes corresponding “open” items.
docs/de25-nano-tasks.md Marks previously-open firmware/layout items as decided (D11/D12) and updates next-steps text.
docs/de25-kernel-config.md Rewrites §7.1 to mark firmware parity as resolved and documents the structural implementation.
docs/buildroot-config.md Adds a new §12 documenting image-common.fragment, updates stack descriptions, and adds redirects from the old §5.28 content.
configs/fragments/stacks.mk Adds image-common into DE10 and DE25 image stacks, preserving kernel-only stacks.
configs/fragments/image-common.fragment New shared fragment containing the firmware/regdb/extra/BCM20702 selections for both images.
configs/fragments/golden.sha256 Updates the de25nano golden hash to reflect the new shared fragment being included.
configs/fragments/de25nano.fragment Updates commentary to reflect the shared firmware set coming via image-common.
configs/fragments/de10nano-image.fragment Removes the firmware block and leaves a redirect comment to image-common.fragment.
.github/actions/buildroot-build/action.yml Updates the DE10 main dl-cache key to include image-common.fragment and documents the invariant enforced by the fragment-check script.
Review details
  • Files reviewed: 12/12 changed files
  • Comments generated: 0
  • Review effort level: Lite

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

@mcfbytes
mcfbytes merged commit aeaf72a into master Sep 6, 2026
7 checks passed
@mcfbytes
mcfbytes deleted the feat/de25-firmware-parity branch September 6, 2026 04:06
mcfbytes added a commit that referenced this pull request Sep 6, 2026
golden: refresh the de25nano hash after #141's image-common (fixes red master)
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.

2 participants