[FEATURE] RAM Chip Added

[ineskhou]

Short summary

Add external RAM chip APS1604M-3SQR

Motivation and user story

We need more RAM because we are quickly running out and it is on the board!

Proposed implementation

1. Configure the device tree
2. Implement the PSRAM driver
3. Talks to your RPI2350 QSPI peripheral (Implements APS1604M read/write commands, Optionally supports quad I/O and burst transfers, jiust simple read and write)
4. Init the driver
5. Test read/write functionality
6. Wrap in a simple PSRAM heap
7. wrap heap in sys_multi_heap

Priority

High

[ineskhou]

Notes:

What we may need to do

• Add PSRAM controller setup early in boot (before the kernel starts using heaps/partitions that live there).
• Configure the QSPI/PSRAM chip select, timing, and caching like CircuitPython does.
• Add a psram node (or equivalent) in the RP2350 board’s w/ Base address and size of PSRAM in the address space and Which bus/peripheral controls it. (follow up queiont can this be geenral prupose region or custom) (heap only seems easier mayeb a good first step)
• Check what KConfing things we need

to find specific region of memory

Can define a point to the specific region of memoryj
#define MY_HW_REGISTER_ADDR 0xC0001000
volatile unsigned int *hw_reg_ptr = (volatile unsigned int *)MY_HW_REGISTER_ADDR;
*hw_reg_ptr = some_value;

Can also specify types of memory using flags flags (GFP_KERNEL, GFP_DMA)

sys_multi_heap functionaliry
https://docs.zephyrproject.org/latest/kernel/memory_management/heap.html

with this

1. Add both your RAM heap this new PRAM heap to a multi-heap.

2. Define allocation rules via the callback (choice function) (can choose size wise to go to PRAM for certain)

3. just Access them via a unified API: sys_multi_heap_alloc(), sys_multi_heap_free(), etc., without worrying about which physical memory region the object lives in.

bc we have driver this makes this tricky

Your sys_multi_heap would have to either:

Allocate buffers in internal SRAM and copy to/from PSRAM via the driver, or

Use the driver’s API to directly allocate in PSRAM (if the driver exposes that).

note:

Boot ordering: if something expects RAM before PSRAM is initialized, you can crash early. You must guarantee PSRAM bring‑up happens before anything that touches that memory.

exmple of the STM32 deriver
https://docs.zephyrproject.org/latest/build/dts/api/bindings/memory-controllers/st%2Cstm32-ospi-psram.html

[ineskhou]

1. Configure the device tree
2. Implement the PSRAM driver
   Talks to your RPI2350 QSPI peripheral (Implements APS1604M read/write commands, Optionally supports quad I/O and burst transfers, jiust simple read and write)
3. Init the driver
4. Test read/write functionality
5. Wrap in a simple PSRAM heap
   6 wrap heap in sys_multi_heap

[ineskhou]

espressif/developer-portal#378

Hints on how to check where RAM allocation is coming from

[ineskhou]

Can reply to this issue later with solution if compatible one found, however it is external PSRAM

zephyrproject-rtos/zephyr#101576

[ineskhou]

MAKING A DRIVER:

1. Devicetree binding (YAML) – Describes the node and its properties so the build can validate the DTS and generate DT_* macros.
2. Kconfig – Option (e.g. CONFIG_PSRAM_APS1604M) so the driver can be enabled; usually depends on DTHAS_ENABLED.
3. CMake – Make sure the driver .c file is compiled and linked. For an app-local driver, the simplest is target_sources(app PRIVATE drivers/psram/aps1604m.c) in the app’s CMakeLists.txt.
4. Driver C code – Use DT_DRV_COMPAT, config from DTINST*, an init function, and DEVICE_DT_INST_DEFINE / DT_INST_FOREACH_STATUS_OKAY.

[ineskhou]

RAM Chip:
APS1604M-3SQR-SN_C18214056
https://www.apmemory.com/tw/downloadFiles/0324112119bq388733

[ineskhou]

From the beginning of power ramp to the end of the
150μs period, CLK should remain LOW, CE# should remain HIGH (track VDD within 200mV) and SI/SO/SIO[3:0]
should remain LOW

ddress Space
SPI/QPI PSRAM device is byte-addressable. 16M device is addressed with A[20:0].
9.2 Page Length
Read and write operations are default page size of 512 bytes.
9.3 Drive Strength
The device powers up in 50Ω.
9.4 Power-on Status
The device powers up in SPI Mode. It is required to have CE# high before beginning any operations.

SPI Mode Operations
The device powers up into SPI mode by default but can also be switched into QPI mode.

RP2350:
4.4.2. QSPI Memory Interface (QMI)
Uncached accesses and cache misses require access to external memory. The QSPI memory interface (QMI) provides
this access, as documented in Section 12.14. The QMI supports:
• Up to two external QSPI devices, with separate chip selects and shared clock/data pins
◦ Banked configuration registers, including different SCK frequencies and QSPI opcodes
• Memory-mapped reads and writes (writes must be enabled via CTRL.WRITABLE_M0/CTRL.WRITABLE_M1)
• Serial/dual/quad-SPI transfer formats
• SCK speeds as high as clk_sys
• 8/16/32-bit accesses for uncached accesses, and 64-bit accesses for cache line fills
• Automatic chaining of sequentially addressed accesses into a single QSPI transfer
• Address translation (4 × 4 MB windows per QSPI device)
◦ Flash storage addresses can differ from runtime addresses, e.g. for multiple OTA upgrade image slots
◦ Allows code and data segments, or Secure and Non-secure images, to be mapped separately
• Direct-mode FIFO interface for programming and configuring external QSPI devices
XIP accesses via the two cache AHB ports, and from the DMA streaming hardware, arbitrate for access to the QMI. A
separate APB port configures the QMI.
The QMI is a new memory interface designed for RP2350, replacing the SSI peripheral on RP2040.

[ineskhou]

Zephyr’s RP2350 pinctrl headers don’t define pins 55–60 used for QSPI. (see # "rpi-pico-pinctrl-common.h", "rpi-pico-rp2350-pinctrl-common.h", "rpi-pico-rp2350a-pinctrl.h")

I added proves_flight_control_board_v5-qspi-pinctrl.h with macros (e.g. QSPI_SCK_P56, QSPI_SD0_P57, …) using RP2XXX_PINMUX and the HSTX function, and included that header in the pinctrl dtsi.

[ineskhou]

Need to make sure the pico flash --> https://github.com/zephyrproject-rtos/zephyr/blob/main/drivers/flash/flash_rpi_pico.c
and the PSRAM do not hit each other on implemntation

[ineskhou]

https://forums.raspberrypi.com/viewtopic.php?t=378249