zephyr-cp: size nvm and storage to a whole erase block on RP2040/RP2350 - #11272
Open
lynt-smitka wants to merge 2 commits into
Open
zephyr-cp: size nvm and storage to a whole erase block on RP2040/RP2350#11272lynt-smitka wants to merge 2 commits into
lynt-smitka wants to merge 2 commits into
Conversation
tannewt
reviewed
Aug 31, 2026
tannewt
left a comment
tannewt
left a comment
Member
There was a problem hiding this comment.
Did you check these ranges against the addresses used in ports/raspberrypi? Let's make sure nvm and circuitpy have the same region. storage_partition may need to use some firmware space.
Author
|
Good point. No, I hadn't checked those against ports/raspberrypi... Will do, and try to rework the overlays so nvm and circuitpy match the classic layout. |
tannewt
reviewed
Sep 2, 2026
tannewt
left a comment
tannewt
left a comment
Member
There was a problem hiding this comment.
Did you test switching between the two?
Both partitions are 0x800 on the five RP2040 and RP2350 boards, but the erase block on those chips is 4096. common_hal_nvm_bytearray_set_bytes takes its page size from the flash device, so it asks flash_area_read for 4096 bytes out of a 2048-byte area; flash_area_read bounds-checks that and returns -EINVAL, and the write fails. Were it to get past that, the following flash_area_erase of a full page would take storage_partition with it. Measured on a picopad running zephyr-cp: len(microcontroller.nvm) is 2048 and nvm[0:4] = b"ABCD" raises RuntimeError: Unable to write to nvm. The same code on the raspberrypi port, where nvm is a full 4096, writes and reads back fine. Both partitions grow to one erase block, which shifts circuitpy_partition 4 KB up. The filesystem moves with it, so a board updating to this comes up with an empty CIRCUITPY drive and whatever was on it is gone.
After the previous commit the partitions sat at 0x180000 (nvm), 0x181000 (storage) and 0x182000 (circuitpy) on all five boards, which matches neither port. ports/raspberrypi derives both from CIRCUITPY_FIRMWARE_SIZE: nvm sits at that address, the drive 4 KB above it. Three of the boards take the 1020K default, so nvm at 0xff000 and CIRCUITPY at 0x100000; pico_w and pico2_w set 1536K, so 0x180000 and 0x181000. Use those addresses, and take storage out of the code partition rather than pushing circuitpy up, so a board keeps both its filesystem and its nvm contents across a switch between the two ports. That leaves the W boards' nvm and circuitpy where they already were; the three non-W boards move circuitpy down from 0x181000, which grows their drive by 516 KB (rpi_pico: 508 KB -> 1 MB) and costs one empty CIRCUITPY on update. The code partitions are just under 1016 KB and 1532 KB, against images of 490 KB (rpi_pico) and 1042 KB (rpi_pico_w). Verified on an RP2040 with 2 MB flash, both layouts and both directions, against the 10.3.0 raspberry_pi_pico and raspberry_pi_pico_w release images: CIRCUITPY keeps its files and nvm keeps its contents across every switch.
lynt-smitka
force-pushed
the
zephyr-cp-nvm-erase-block
branch
from
September 2, 2026 18:12
42c0119 to
fdb56f9
Compare
Author
|
Yes, they didn't match at first (thanks!), but line up now:
Tested the switch on an RP2040, both directions, against the 10.3.0 |
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.
nvm_partition and storage_partition are 0x800 on all five RP2040/RP2350 boards, but the erase block on those chips is 4096.
common_hal_nvm_bytearray_set_bytes reads a whole erase page before modifying it, and takes that page size from the flash device rather than the partition, so it asks flash_area_read for 4096 bytes out of a 2048-byte area. flash_area_read bounds-checks and returns -EINVAL.
Measured on a picopad running zephyr-cp:
The same test on the raspberrypi port, where nvm is a full 4096, writes and reads back fine.
Both partitions grow to one erase block, which shifts circuitpy_partition 4 KB up. The filesystem moves with it, so a board updating to this comes up with an empty CIRCUITPY drive...