ports/zephyr-cp: add ranges; to the rpi_pico flash partitions - #11234
Merged
Conversation
The overlay redefines &flash0's partitions with flash-relative addresses but without ranges;, so they never translate to the XIP window. Two consequences: CONFIG_RP2_REQUIRES_SECOND_STAGE_BOOT is not selected (its Kconfig tests for a code partition at 0x10000100), so the image ships without a second-stage bootloader; and the generated UF2 targets 0x00000100 instead of 0x10000000. The RP2040 boot ROM will not run the result. Presumably unnoticed because CI and developers flash over SWD, where the ELF loads fine. boards/adafruit/metro_rp2350 upstream in Zephyr uses this exact pattern. Built raspberrypi_rpi_pico_zephyr before and after: the UF2 first block address moves from 0x00000100 to 0x10000000 and RP2_REQUIRES_SECOND_STAGE_BOOT=y gets selected. An RP2040 image built this way boots from UF2 on a PicoPad.
tannewt
requested changes
Aug 24, 2026
tannewt
left a comment
tannewt
left a comment
Member
There was a problem hiding this comment.
Thanks for the fix! One comment... comment.
This was referenced Aug 29, 2026
tannewt
pushed a commit
that referenced
this pull request
Aug 31, 2026
Each of these overlays deletes the partitions node its board DTS declares and rebuilds it without re-declaring ranges;. Devicetree then leaves the child addresses untranslated and every partition resolves to a bare offset. On the two RP2040 boards the code partition lands at 0x100 instead of 0x10000100, so RP2_REQUIRES_SECOND_STAGE_BOOT no longer matches, the second stage bootloader is not linked in and the UF2 is built for the wrong address. Same as #11234, which covered rpi_pico_zephyr. On stm32wba65i_dk1 the partitions resolve to 0x0, 0x10000, 0x108000 and 0x1e0000 rather than 0x08000000 upwards. flash_map computes a mapped partition's offset as DT_REG_ADDR(partition) - DT_REG_ADDR(memory), so every flash_area offset on that board underflows. Each board's own DTS declares ranges; on that node, so this only puts back what the overlay dropped. Partition offsets and sizes are unchanged.
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
2 participants
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.
Without
ranges;the partition addresses stay flash-relative and never translate to the XIP window:Verified: the UF2 first block moves 0x00000100 -> 0x10000000, RP2_REQUIRES_SECOND_STAGE_BOOT=y, and the image boots from UF2 on an RP2040 board.