The last time the DDR3 memory on PS4 pro has a critical problem it was capped under 11mb/s speed how much I tied I failed every time
then I notice something while debugging through the southbridge well it turns out DDR3 has it's own southbridge DMA engine but I don't really notice at first.
and after some more debugging it turns out my DDR3 chip (1 GB on the southbridge) was being read by the CPU personally, 8 bytes at a time, through a tiny PCI window ~10.6 MB/s. and that was the main bottleneck of all.
now it feels like I almost fix the issue but nope the southbridge DMA engine has no Linux driver for PS4 to use it.
and after more debugging it turns out Sony's PS4 gameOS aka orbis uses that chip (their sbram driver), but the code is closed.
So, I used AI to reverse engineer the kernel binary and everything started making sense now
the chip lives at 0xC0000000 + offset on the internal bus and everything moves through the southbridge DMA engine with exact protocol byte-count, source, dest, then the 0x1d40 "go" register, and write 0x11 to the interrupt-mask register.
after that it's time to do the main patch The implementation
On the ps4linux it sees the southbridge DMA engine as a pci device: 104d:90cd. The driver asks linux for it, switches it on, and maps its register memory. Now the engine can't touch program memory directly. everything goes through one special buffer the driver allocates at startup a small chunk of RAM that is always below 4 GB and always coherent (DMA-visible) think of it as the loading dock between the CPU and the DDR3.
After the patch bake into the kernel and the result
| old patch | new patch |
|---|
| reads | 10.6 MB/s | 504 MB/s |
| writes | ~138 MB/s | 425 MB/s |
| ceiling | unknown | ~1.4 GB/s (65,408 B jobs @ 1,383 MB/s) |
The engine itself moves data at up to ~1.4 GB/s. what used to be a 10.6 MB/s unusable brick is now a fast little swap chip on PS4linux
