[OpenPower-Firmware] Undocumented SCOM registers and DIMM addressing

[Klaus Heinrich Kiwi]

Dean and Dan,

  can you help direct the questions below to the right people that can help answer them?

Thanks,

  -Klaus

On 1/28/2021 11:45 AM, Krystian Hebel wrote:
> Update: I have found out that the way MCAs are mapped is calculated in istep 7.4 and put into appropriate registers in 14.5. All other questions are still open.
> 
> On 19.01.2021 15:22, Krystian Hebel wrote:
>> Hello,
>>
>> I'm analyzing memory initialization code as a part of preparation for coreboot port for Talos II. I have encountered a few undocumented registers, all of them (so far) have SCOM addresses 0x0501082X. In the part of code I am analyzing, the first write to those registers happens in istep 13.8, but as it is done by an initfile, I didn't pay too much attention and assumed that this is just the default, non-configurable value.
>>
>> Registers from the same group appear again in 13.13 for setting up the translation between controller addresses and DIMM addresses. This time they are at least named by constants: MCA_MBA_MCP0XLT{0,1,2}. Field names can also be found in header files, but without any explanation as to what they exactly configure. I haven't analyzed further code yet so can't tell if this is the last place where they are accessed.
>>
>> I have decoded, more or less, which port address is assigned to which DIMM bit and under what circumstances, but there are still some unanswered questions, or assumptions I would like to confirm. Nevertheless, it would be nice to have a proper documentation of all pieces required for the initialization of the platform.
>>
>> How many port address bits there are? Is it either 40 or 56 bits, as mentioned in section 10.2 of POWER9 Processor User's Manual? How are port addresses from all ports (MCAs) mapped to the address space seen by CPU?
>>
>> Which bit numbers are more significant? I assume lower port address bit number is more significant, seeing that the highest numbers are always allocated, and lower only if needed. On the other hand, if that is the case, wouldn't assigning higher number/less significant address to D-bit improve performance due to interleaving? Assuming that both DIMMs have the same size to avoid holes, of course.
>>
>> I assume that bits which are not encoded in `enum xlate_bit_maps` are hardwired to column bits 0-3 and row bits 0-14. There is also `PORT_ADDRESS_22` in enumeration that isn't used anywhere in the code, is it also hardwired? Also, why some of the map fields in registers are 5 bits, while other are only 3 bits long? Given that the registers are sparsely filled (at least from what can be decoded from the header files) I don't think this is done just to pack more data in one register.
>>
>> I have also noticed that both BG bits are mapped, even for 16Gb devices, which according to DDR4 specification have only two bank groups, so they should use just BG0. Was this an overlook or is there any purpose for mapping both bank group bits?
>>
>> I hope that wasn't too much questions for one email.
>>
>> Best regards,
>>

-- 
Klaus Heinrich Kiwi <klaus at linux.vnet.ibm.com>