WIP: add psram support

[jakezhu9]

Background

To run more complex applications like the Linux kernel, we need more memory. Therefore, we plan to support PSRAM (Pseudo-Static Random Access Memory).

Progress

By analyzing the code in bouffalo_sdk, we have a basic understanding of the PSRAM initialization process and ported it to Rust, completing the psram-demo. This program initializes PSRAM by directly reading and writing memory, runs a simple test and outputs the result through the serial port. We flashed it into the sipeed M1s DOCK board, and it ran successfully. However, the program has some issues, including a 0.3%~1% error rate in memory read/write operations and unexpected read/write latency (likely due to clock configuration). We will continue to improve it.

TODO

• fix memory read/write error rate
• optimize read/write latency
• organize the code as a support library, avoid hard-coded memory read/write operations

[jakezhu9]

Progress Update (10.13)

To address the memory read and write error rate, we tried adjusting various registers, but this didn't lead to significant improvements. We then analyzed the bouffalo_sdk code. However, its complexity and size made it difficult to pinpoint the issue, especially since some initialization code is scattered across different files.

We decided to take a new approach: register comparison. With support from the chip and development board's JTAG function, we used T-Head Debug Server and GDB to directly read the chip's register values and compare them with the original firmware that has been correctly initialized.

From our analysis, we identified that the PSRAM-related registers are mainly located in a 4KB memory range starting at 0x20000000, 0x3000F000, and 0x2000E000. We dumped this memory using GDB and the commands like dump memory memory_dump_0x20000000.bin 0x20000000 0x20000FFF

When comparing the two memory dumps, we noticed some register values were different:

Since investigating each specific register value would be very time-consuming, we chose to generate the necessary write code directly based on the file comparison:

However, when we implemented this code, the program encountered a blockage at certain points. It seemed that modifying some specific register values might be the cause. To troubleshoot, we added output statements after each memory write, which helped us isolate the problem. We discovered that addresses 0x3000F130 and 0x3000F134 were causing the issues, but we couldn't find relevant instructions in the official manual to clarify their functions. Therefore, we decided to exclude writing to these locations for now.

After persistent efforts, we finally achieved stable read and write operations for 64MB of PSRAM!

Next Steps

• optimize read/write latency
• Analyze and confirm the function of certain memory areas
• Organize the code into a support library to avoid hard-coded memory operations

[luojia65]

Great thanks! It's a huge and nice work.