Provision and build declared device-tree overlays - #183
Draft
jetm wants to merge 3 commits into
Draft
Conversation
Shipping a custom device-tree overlay previously meant forking the BSP: the CLI had no notion of one, so a .dtbo could not be compiled from the project or routed onto the boot medium. Add a declarative path. An extension declares its overlays under `device_tree_overlays`, and the runtime build compiles each one, stages it, hands off to the board's delivery hook, and fails the build if anything went undelivered. Placement is at the extension level, alongside the sibling `overlay` key, because a runtime's `packages` list is frequently a bare list of names with nowhere to hang per-overlay objects. The name is a validated basename because it is reused verbatim as the .dtbo filename and the boot-loader argument. Compilation is generated into the in-container build script rather than run in Rust: the dtc/cpp toolchain, the kernel dt-bindings, and the delivery hook all live in the SDK container. The script calls the nativesdk-avocado-dtc-overlay wrapper per overlay, writes an overlays.manifest.json, runs the single fixed-path per-BSP hook ($OECORE_TARGET_SYSROOT/usr/libexec/avocado/device-tree-overlay-deliver), and passes the hook-emitted stone fragment through `stone bundle --overlay`. Two failure modes are hard errors, not silent successes: overlays declared with no hook installed, and overlays staged but left unclaimed by the hook. Fold the declarations and each .dtso's content hash into the runtime-build input hash. Overlays are compiled at runtime-build time, so without this an added or edited overlay would leave the stamp valid and ship the previous bundle unchanged. Signed-off-by: Javier Tia <javier@peridio.com>
When an extension declared device_tree_overlays, the CLI compiled and delivered the overlays at runtime-build time but never installed the tools that step needs: the nativesdk-avocado-dtc-overlay SDK wrapper and the per-BSP avocado-dtc-overlay-deliver hook had to be staged into the SDK by hand, so a clean install could not build a declared overlay. The target-sysroot install that would carry the hook was also gated on an active compile section, which a no-#include overlay does not require, so a pure path/phandle overlay got no target-sysroot at all. Scan the active extension set (not a single runtime's enabled list, since the SDK install spans every runtime) for device_tree_overlays and, when any declares them, add nativesdk-avocado-dtc-overlay to the SDK packages and avocado-dtc-overlay-deliver to the target-sysroot, widening the target-sysroot trigger to fire on a declaration as well as a compile section. nativesdk-dtc is pulled by the wrapper's RDEPENDS and stone is a baseline SDK package, so neither is listed. A BSP that ships no hook package now fails at install time rather than at the build-time backstop. Signed-off-by: Javier Tia <javier@peridio.com>
jetm
force-pushed
the
eng-2134-device-tree-overlays
branch
from
August 12, 2026 21:35
5d58ff7 to
208191e
Compare
A BSP's stone-<arch>.json references boot artifacts this build does not produce - u-boot.bin and bootfiles/ on Raspberry Pi - while the only input directory passed to stone is the runtime dir, which holds just what the build made: rootfs, kernel, initramfs, var. Anything else the manifest names fails resolution with "File 'u-boot.bin' not found in any input directory for FAT image", and the runtime build dies at finalize. Add the SDK's own stone dir as a second input. That is where a BSP recipe would stage artifacts it wants a manifest to be able to name, and it is already where the manifest itself is read from, so the two stay together. This is the consumer half of a two-part change and does nothing on its own: meta-avocado's avocado-sdk-target currently installs only the stone JSON there, so no new file resolves from the added directory yet. It is still the right half to land separately - stone resolves first-match-wins across -i directories, so an extra input carrying nothing cannot change what any current build resolves - but the finalize failure it targets stays until the BSP recipe stages u-boot.bin and bootfiles/ into that directory. The comment says so rather than leaving the next reader to conclude the gap is closed. Signed-off-by: Javier Tia <floss@jetm.me>
Contributor
Author
|
Producer half is up: avocado-linux/meta-avocado#274 stages Either half alone is inert and neither regresses a current build (stone resolves first-match-wins across |
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
1 participant
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.
Problem
The CLI had no support for the device-tree-overlay feature: it neither provisioned the SDK overlay tooling nor compiled and delivered overlays during a runtime build.
Solution
When an extension declares
device_tree_overlays, provision the SDK wrapper and per-BSP delivery hook duringsdk install, then compile and deliver each declared overlay duringavocado build.Key changes
sdk/install: provision device-tree-overlay tooling (nativesdk-avocado-dtc-overlayplus the delivery-hook package) from extension declarationsruntime/build: compile and deliver declared device-tree overlays into the OS bundleReviewer notes
Top of the device-tree-overlay stack (ENG-2134). Depends on the meta-avocado PR, which provides the
nativesdk-avocado-dtc-overlayand delivery-hook packages, and transitively on the stone PR. Merge last. Validated on raspberrypi5.