Skip to content

rp2/rp2_psram: *Fully* switch to upstream hardware_psram.#19418

Open
Gadgetoid wants to merge 3 commits into
micropython:masterfrom
pimoroni:patch-rp2-psram-sdk-native
Open

rp2/rp2_psram: *Fully* switch to upstream hardware_psram.#19418
Gadgetoid wants to merge 3 commits into
micropython:masterfrom
pimoroni:patch-rp2-psram-sdk-native

Conversation

@Gadgetoid

@Gadgetoid Gadgetoid commented Jul 3, 2026 •
edited
Loading

Copy link
Copy Markdown
Contributor

Summary

⚠️ by virtue of its dependence on the modular Pico SDK linker scripts introduced in SDK 2.3.0, this change is much louder and harder to parse than it should be. Assuming #19415 gets merged, it should be much easier to parse.

This change is the more complete alternative to #19416

It builds on the idea that we should fully defer to the SDK for PSRAM bringup and configuration, and tries to handle MicroPython's downstream config where it has not yet been migrated to pico-sdk board header files.

Vendors should set the relevant PSRAM config in their boards header, regardless of whether this change (or the other one) lands in MicroPython. Several upstream headers for PSRAM boards already have 8MB enabled, see: https://github.com/search?q=repo%3Araspberrypi%2Fpico-sdk+PICO_PSRAM_SIZE_BYTES+path%3A%2F%5Esrc%5C%2Fboards%5C%2Finclude%5C%2Fboards%5C%2F%2F&type=code

I petitioned for upstream support for PSRAM in Pico SDK (raspberrypi/pico-sdk#2372) back when we first started the RP2350 bringup, it didn't arrive quickly enough for us to skip a downstream alternative but now it's here and we should switch to it.

Testing

As with #19416 I am only equipped to test this on Pimoroni boards.

Vendors, excuse me for the tag, these boards should also be tested:

  • @gatesphere: ADAFRUIT_FEATHER_RP2350
  • @sfe-SparkFro: SPARKFUN_IOTNODE_LORAWAN_RP2350, SPARKFUN_PROMICRO_RP2350, SPARKFUN_THINGPLUS_RP2350, SPARKFUN_XRP_CONTROLLER
  • @SFE-Brudnerd: SPARKFUN_IOTREDBOARD_RP2350
  • @bikeNomad: WAVESHARE_RP2350B_CORE

You should test:

  • Board starts up and runs, a good start 😆
  • gc.mem_free() reports the correct gc_heap region (may include SRAM, will exclude a large chunk for GC tracking)
  • machine.freq() changes (within reason) do not push PSRAM timings out of whack or baulk the board
  • flash writes (merely saving a file, or otherwise, since these disable IRQs and more) restore the PSRAM settings upon completion

For the lazy I'm running verification with this mess: https://gist.github.com/Gadgetoid/4c86406f57995096c0aecab578a039f1

And probing clocks with: https://gist.github.com/Gadgetoid/e0673a3e1eaf7bef5f8557233122f4d3

Trade-offs and Alternatives

This change is the more complete alternative to #19416, touches more files and changes more things. It's probably the right approach, and lays the foundations for vendors to configure their boards upstream.

It still relies on MICROPY_HW_ENABLE_PSRAM to opt-in to PSRAM support, but will defer to upstream's PICO_PSRAM_SIZE_BYTES and PICO_PSRAM_CS_PIN where available.

When a CS pin is supplied and no PICO_PSRAM_SIZE_BYTES is available, it will set PICO_AUTO_DETECT_PSRAM_SIZE and sets PICO_PSRAM_CS_PIN=MICROPY_HW_PSRAM_CS_PIN which effectively recreates the previous behaviour.

The biggest thrust of this change is the move from mpconfigboard.h to mpconfigboard.cmake for PSRAM config, this is necessary to support all the backwards-compatibility and mirrors config breaking changes like the move of MICROPY_HW_FLASH_STORAGE_BYTES that spicy downstream vendors (like meeee, aah) will just have to deal with.

Generative AI

I used generative AI tools when creating this PR, but a human has checked the
code and is responsible for the code and the description above.

Gadgetoid and others added 3 commits July 3, 2026 16:52
@Gadgetoid
rp2: Update pico-sdk to 2.3.0.
36be022 
Required by the include-based linker script support that follows.

Signed-off-by: Phil Howard <github@gadgetoid.com>
@will-v-pi @Gadgetoid
rp2: Migrate to pico-sdk 2.3.0 include-based linker scripts.
ec6397c 
Pico SDK 2.3.0 makes its default linker script overridable via includes,
so the port no longer needs to carry a full copy. Replace the monolithic
memmap_mp_rp2040.ld and memmap_mp_rp2350.ld with memmap_mp_rp2.ld, which
includes the SDK default, plus small override fragments under memmap_rp2/,
memmap_rp2040/ and memmap_rp2350/ that supply only the MicroPython parts:
the FLASH/FLASH_FS split, moving gc/vm/parse into RAM, and the GC heap and
stack layout.

Memory region boundaries are unchanged.

Co-authored-by: Phil Howard <github@gadgetoid.com>
Signed-off-by: Phil Howard <github@gadgetoid.com>
@Gadgetoid
rp2: Bring up PSRAM using the SDK's hardware_psram library.
f52a077 
Pico SDK 2.3.0 provides a hardware_psram library that detects and
initialises PSRAM during runtime_init. Use it instead of the port's
hand-written rp2_psram.c.

Boards that fit PSRAM set MICROPY_HW_ENABLE_PSRAM (and, where the pico-sdk
board header does not already provide it, MICROPY_HW_PSRAM_CS_PIN) in their
mpconfigboard.cmake. These gate the hardware_psram link and feed the SDK:
where the board header configures a size, its chip-select and size are used
as-is; otherwise the size is auto-detected on the configured chip-select.
main.c asserts the configured chip-select matches the board header.

The GC heap is sized from psram_get_size() and placed using the SDK's
__psram_start__/__psram_end__ linker symbols. PSRAM QMI timing is re-tuned
after clock changes; flash programming restores it via the SDK's CS1 setup
callback.

CMakeLists: Reconsile board header config with mpconfigboard.*.
rp2/rp2_psram: Redundant, removed.
rp2/boards: Config updated.
rp2/modmachine: Reconfigure PSRAM on clock change.
rp2/rp2_flash: Document that SDK implicitly restores PSRAM.

Signed-off-by: Phil Howard <github@gadgetoid.com>
@Gadgetoid Gadgetoid force-pushed the patch-rp2-psram-sdk-native branch from 12fdb6a to f52a077 Compare July 3, 2026 18:43
@github-actions

github-actions Bot commented Jul 3, 2026

Copy link
Copy Markdown

Code size report:

Reference:  nrf: Restore interrupt-based I2C with nrfx v3. [964803a]
Comparison: rp2: Bring up PSRAM using the SDK's hardware_psram library. [merge of f52a077]
  mpy-cross:    +0 +0.000% 
   bare-arm:    +0 +0.000% 
minimal x86:    +0 +0.000% 
   unix x64:    +0 +0.000% standard
      stm32:    +0 +0.000% PYBV10
      esp32:    +0 +0.000% ESP32_GENERIC
     mimxrt:    +0 +0.000% TEENSY40
        rp2: +9740 +1.025% RPI_PICO_W[incl -200(bss)]
       samd:    +0 +0.000% ADAFRUIT_ITSYBITSY_M4_EXPRESS
  qemu rv32:    +0 +0.000% VIRT_RV32

@Gadgetoid

Gadgetoid commented Jul 3, 2026 •
edited
Loading

Copy link
Copy Markdown
Contributor Author

FWIW tested on a Pimoroni Pico LiPo 2:

[PASS] psram.data.aa / 55 / 00 / ff - 0/125 chunks bad
[PASS] psram.address - 0/2000 pages bad      ← full 7.8MB addressed correctly
[PASS] freq sweep 48→250MHz - psram + flash all clean
[PASS] psram_vs_flash - 2MB held across flash IO, 0 bad pages
RESULT: 44/44 checks passed

Note that the rp2: +9740 +1.025% RPI_PICO_W[incl -200(bss)] in the Code Size Report is from the linker changes, which implicitly fix some bugs and move some things to SRAM. See: #19415

@Gadgetoid Gadgetoid mentioned this pull request Jul 3, 2026
Open
@codecov

codecov Bot commented Jul 3, 2026

Copy link
Copy Markdown

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 98.51%. Comparing base (964803a) to head (f52a077).

Additional details and impacted files 
@@           Coverage Diff           @@
##           master   #19418   +/-   ##
=======================================
  Coverage   98.51%   98.51%           
=======================================
  Files         177      177           
  Lines       22927    22927           
=======================================
  Hits        22586    22586           
  Misses        341      341

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
  • 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

2 participants

@Gadgetoid @will-v-pi