rpi4: restore the firmware device trees the *.dtb rule swallowed - #305
Merged
Conversation
bsp/rpi4 ships the Raspberry Pi firmware blobs the BSP copies onto the boot partition, and it used to ship Broadcom's prebuilt bcm27xx device trees with them. Those disappeared in 5eddc8b ("Migrate SO3 build system to Infrabase"), which moved bsp/rpi4 under build/meta-bsp/recipes-bsp/: bootcode.bin, start4.elf and the overlays made the move, but the .dtb did not — .gitignore's "*.dtb" rule matched them on the way in and git never took them. The rule is right for every other .dtb in the tree: those are build products, compiled from a .dts. These are vendored *inputs* to the deploy, so un-ignore just that directory — same shape as the /atf and /qemu anchoring fixes already in the file. Nothing has installed a device tree on the boot partition since. Cards that were flashed before the migration still carry the old ones and boot fine, which is why this went unnoticed; a freshly initialised card gets none, the firmware finds no DT to load, and U-Boot — which takes its own DT from the firmware (CONFIG_OF_BOARD=y) — has nothing to work with. Restored verbatim from 5eddc8b^ and byte-identical to what the deploy used to install.
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
build/meta-bsp/recipes-bsp/bsp/rpi4/ships the Raspberry Pi firmware blobs the BSP copies onto the boot partition — and it used to ship Broadcom's prebuiltbcm27xxdevice trees with them.They vanished in 5eddc8b (Migrate SO3 build system to Infrabase), which moved
bsp/rpi4underbuild/meta-bsp/recipes-bsp/.bootcode.bin,start4.elfandoverlays/made the move; the 11.dtbdid not —.gitignore's*.dtbrule matched them on the way in and git silently never took them:Why it matters
Nothing has installed a device tree on the boot partition since. Cards flashed before the migration still carry the old ones and boot fine — which is exactly why this went unnoticed for a month. A freshly initialised card gets none: the firmware finds no DT to load, and U-Boot takes its own DT from the firmware (
CONFIG_OF_BOARD=y), so it has nothing to work with.Fix
Restore the 11 files verbatim from
5eddc8bd^(byte-identical to what the deploy used to install) and un-ignore that one directory.The
*.dtbrule is right for every other .dtb in the tree — those are build products compiled from a.dts. These are vendored inputs to the deploy. Same shape as the/atfand/qemuanchoring fixes already in the file, and the comment follows their style.Verification
The negation is surgical — generated device trees stay ignored:
…and nothing else becomes visible:
git statusshows exactly the 11 firmware.dtband.gitignore.Note
Found while chasing an unrelated rpi4 boot problem: the card under test only booted because it still had device trees written by a pre-migration deploy, which is exactly why nothing had flagged this yet.