N64brew Wiki

RDRAM: Difference between revisions

Page Discussion

RDRAM (view source)

Revision as of 07:37, 4 November 2023

1,139 bytes added ,  7 months ago
Provide better details about setting Delay after reset.
VisualWikitext
(SpecFunc commands)
(Provide better details about setting Delay after reset.)
Line 345:
}}
 
'''Reset Complications:'''
'''Programming caution:''' This is the first RDRAM register to configure, given that it configure RDRAM CAS timings. However, writing to this register (the first time?) may require the value to be written to have it's low hword and hi hword swapped (eg. to write 0xAABBCCDD we use 0xCCDDAABB instead) and the MI to be configured in a special way (MI_MODE = 0x10f, eg. SET_INIT_LENGTH | length = 0x0f) to make the write work with default RDRAM timings. Indeed, IPL3 configure this register using the following sequence:<br>
[MI_MODE_REG] = 0x10f<br>
[0xA3F80000 + RDRAM_DELAY_REG] = 0x18082838 // notice how low hword and high hword are swapped compared to the recommended value of 0x28381808<br>
But reading back the value written in RDRAM_DELAY_REG give 0x2B3B1A0B (which suggests that hwords got somehow swapped).
Also, trying to write 0x28381808 to RDRAM_DELAY_REG made the console freeze (tested using a modified version of hcs's boot_stub).
 
RI is hardwired to use a write delay of 1 TCycle, this means the Write request packet is send starting from (TCycle 0, RCP Cycle 0), finishing after 3 TCycles. 64bits of Data is send starting at (TCycle 4, RCP Cycle 1), finishing at (TCycle7, RCP Cycle 1.75)
Note also that, all RDRAM present on the channel should be configured with the same value (use a broadcast write to do so).
 
But the WriteDelay defaults to 4 TCycles after reset ''(probably<sup>[1]</sup>)'', Attempting to write a register will result in the Rambus device sampling 32bits of data during TCycles 7 and 8 (which is RCP Cycle 1.75 and 2.0), which is too late, It's going to be zeros or some other garbage.
 
Before we can do anything else at all, we need to somehow set the WriteDelay to the correct value of 001b, despite the fact the WregB command results in the Rambus device reading garbage. <Br>IPL3 gets around this problem by using MI's Repeat mode (called "Init mode" in some documentation), see [[MIPS_Interface#0x0430_0000_-_MI_MODE|MI_MODE]] for more details about MI's various modes.
 
By configuring a 16 byte repeat (<code>MI_MODE_REG] = 0x10f</code>), the next word written to an Rambus device register (or memory) will be repeated over 16 bytes. This causes RI to emit a 128bit burst request, with the data on the bus during TCycle 4-11. As the Rambus device is sampling the bus during TCycle 7 and 8, it will get valid data we control. <Br>But it's reading data halfway between two words. So IPL3 has to rotate the value by 16 bits to get the correct result. It wants to write <code>0x2838_1808</code>, but it actually writes <code>[0xA3F80000 + RDRAM_DELAY_REG] = 0x2808_2838</code>.
 
After updating WriteDelay with a broadcast write to all device, all future operations will have the correct timings.
 
''<sup>[1]</sup> I can't actually find any documentation that confirms WriteDelay defaults to 4 TCycles on reset. But the Toshiba 18Mbit datasheet shows that device only has 2 bits of WriteDelay, and defaults to 0b00. If we assume all version 1 Rambus devices share the same default WriteDelay, it's somewhat reasonable to assume 0b00 on a 2 bit device actually means 4 TCycles, and that devices with more bits default to 0b100 for compatibility. There is probably some way to design a hardware test for this. ''
 
==== <span style="display:none;">AdrS[9:2] 0x03 - Mode ====
Phire
22

edits

Retrieved from "https://n64brew.dev/wiki/Special:MobileDiff/4992"