casaroli opened a new pull request, #20478: URL: https://github.com/apache/nuttx/pull/20478
## Summary Two fixes to the RP2350 PSRAM driver. I found them when I compared it with the `hardware_psram` library of the Pico SDK 2.3.1. - Wait for `DIRECT_CSR.BUSY` to go low after the driver enables the QMI direct mode. The datasheet (12.14.5) requires this wait, and the SDK does it. The driver did not wait at the two places where it enables direct mode. The three BUSY loops that were already there now use one RAM-resident helper. - Compute the QMI M1 timing from `BOARD_SYS_FREQ` with the SDK formula. The constant `0x61a07102` did not match the SDK, but its comment said it did. At 150 MHz the SDK value is `0x60242202`: RX delay 2 (was 1), minimum deselect 2 (was 7), maximum select 18 (was 16), select hold 0 (was 3). The clock divisor stays 2. This PR is independent of the flash MTD PR (apache/nuttx#FLASHPR). They merge in either order without conflict. ## Impact RP2350 boards with `CONFIG_RP23XX_PSRAM`. The PSRAM read sample point moves half a `clk_sys` cycle later, to the SDK value. The timing now follows `BOARD_SYS_FREQ`. If a field is out of range for that clock, the build stops with an error. ## Testing Host: macOS arm64, Arm GNU Toolchain 13.2.rel1 (the CI version). - `pimoroni-pico-2-plus:nsh` (PSRAM on) builds with no warnings. The object holds `0x60242202`, and all PSRAM functions link at `0x2000xxxx` (SRAM). - A host program that expands the new macros gives the same value as the SDK formula at 48, 125, 150, 200, 266 and 300 MHz. - `tools/checkpatch.sh -c -u -m -g` passes. I did not run this on a board yet. It is a draft until I run `ramtest` on the PSRAM of a Pimoroni Pico Plus 2. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
