Skip to content

ports/zephyr-cp: add ranges; to the rpi_pico flash partitions - #11234

Open
lynt-smitka wants to merge 1 commit into
adafruit:mainfrom
MakerClassCZ:zephyr-cp-rpi-pico-ranges
Open

ports/zephyr-cp: add ranges; to the rpi_pico flash partitions#11234
lynt-smitka wants to merge 1 commit into
adafruit:mainfrom
MakerClassCZ:zephyr-cp-rpi-pico-ranges

Conversation

@lynt-smitka

Copy link
Copy Markdown

Without ranges; the partition addresses stay flash-relative and never translate to the XIP window:

  • CONFIG_RP2_REQUIRES_SECOND_STAGE_BOOT is not selected (its Kconfig check expects the code partition at 0x10000100), so the image has no second-stage bootloader.
  • The generated UF2 targets 0x00000100 instead of 0x10000000.

Verified: the UF2 first block moves 0x00000100 -> 0x10000000, RP2_REQUIRES_SECOND_STAGE_BOOT=y, and the image boots from UF2 on an RP2040 board.

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.
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.

1 participant