FAQ: Difference between revisions

Jump to navigation Jump to search
Content added Content deleted
No edit summary
Line 21:
The RDRAM initialization is performed by [[IPL3]], a piece of the Nintendo 64 secure boot code (there are a few variants to its contents but the differences are not related to RAM management). IPL3 does the RDRAM chip initialization using a process called "current calibration", and then map them into the (phyisical) address space, by giving to each chip its own address. Nintendo's IPL3 can correctly handle up to 4 2-MiB chips (it also has buggy support for 1 MiB chips, which probably were never released by Rambus, so the code was never tested).
 
For a long time, it was then believed that changing IPL3 would be enough to allow more chips to be mapped, assuming somebody built an expansion pak card with more chips in it. Instead, late work on [Libdragon's open source IPL3](https://github.com/DragonMinded/libdragon/tree/preview/boot) Libdragon's open source IPL3]brought more reverse engineering of the RI chip, which eventually proven that RI *internally* runs a state machine that tracks RDRAM bank status, and only has enough room for 8 1-MiB banks (each 2-MiB chip is logically made of 2 1-MiB bank). More details can be found in the [RI bank status tracking]([[RDRAM Interface#Bank Status Tracking]]) wiki section.
 
On top of this, Rasky (who authored Libdragon's IPL3) also got the chance to test a custom made expansion pak with 8 MiB of RAM in it, designed by LambBraink. This pak uses donor chips from official expansion paks, and is correctly recognized by Nintendo IPL3, though just as a 4 MiB pak. Anyway, by hacking Libdragon's open source IPL3, it can be seen that the extra banks were indeed present on the bus, but it turned out to be inaccessible after bus mapping. This is further proof that RI is not actually able to handle more than 8 MiB of RAM.