rp2/rp2_psram: Switch to upstream hardware_psram.#19416
Conversation
Required by the include-based linker script support that follows. Signed-off-by: Phil Howard <github@gadgetoid.com>
d683081 to
1e32081
Compare
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## master #19416 +/- ##
=======================================
Coverage 98.51% 98.51%
=======================================
Files 177 177
Lines 22927 22927
=======================================
Hits 22586 22586
Misses 341 341 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
Pico SDK 2.3.0 adds a hardware_psram library that covers what the port's rp2_psram.c did by hand: detecting the chip, computing QMI timing for the current clock, and enabling QPI. Replace the downstream implementation with a thin psram_init() wrapper over psram_detect_size(), psram_configure_params() and psram_reinitialize(), keeping the existing call sites unchanged. The SDK detection also handles ISSI parts (8/16 MiB), which the previous code did not. Link hardware_psram on RP2350 only, and disable its runtime_init auto-setup (PICO_RUNTIME_NO_INIT_PSRAM) since the port initialises PSRAM itself. Signed-off-by: Phil Howard <github@gadgetoid.com>
1e32081 to
3e3aca9
Compare
|
Note: Without the change to disable the SDK's own bringup, and without using the SDK's include-based linker scripts (which define these symbols) a straight bringup will fail to link with: Just linking Edit: I'm going to prep a counterpart to this PR which rebases on top of the linker migrations and removes Irrespective of upstream board config settings, I think we still want a
If and when upstream (board headers) is fully consistent with downstream then perhaps |
|
Code size report: |
Edit: Sorry this has become something of a stream of consciousness as I feel out how this change should take shape.
This PR remains for comment/comparison.
Summary
I petitioned for upstream support for PSRAM in Pico SDK 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.
Originally asked for raspberrypi/pico-sdk#2372
Fixes #19209
Testing
Tested on a Pico LiPo 2 with 8MB PSRAM. This will probably need verification from other vendors with PSRAM-enabled boards, since we (Pimoroni) use the same boring part on everything we ship so my tests are extremely narrow.
So, uh, gentle nudge to:
Things To Do
Set your PSRAM config upstream:
A few boards already have an assumed 8MB, I'm not sure of its provenance but downstream (MicroPython) should endeavour to respect this - 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
Things To Test
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 boardTrade-offs and Alternatives
As with linker includes we'd be silly not to defer to upstream for this, but as with any deferral it does remove some downstream flexibility. Either way we probably don't want to own grotty code like this if we don't have to.
Right now this change is an attempt at a minimal impact switch over to Pico SDK's
hardware_psram, but linking this library includes auto-bringup which we could leverage to more or less remove rp2_psram.c altogether.We'd need to set
PICO_PSRAM_CS_PIN, and eitherPICO_PSRAM_SIZE_BYTESorPICO_AUTO_DETECT_PSRAM_SIZE. We can also potentially usePICO_AUTO_DETECT_PSRAMbut since we already have a CS configured I suggest the best approach would bePICO_PSRAM_CS_PIN+PICO_AUTO_DETECT_PSRAM_SIZEto replicate the current behaviour. Then we could use the SDK'spsram_get_size()instead of ourpsram_init()For clock changes we'd need:
And if
psram_reinitialize()fails we'll need to panic, since rugging the PSRAM portion of gc_heap from under the running system is never going to be recoverable.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.
(P.S. if anyone wants to throw their boards my way - or gently remind me I can pilfer one from stock - for verifying stuff like this, it would be helpful!)