Hi Andrew

Thanks for the information and clarification!

The strange is that at some systems I have checked these SMBIOS tables, have nothing that would indicate the current mode of operation in a direct way.
The closest to this is this field, taken from "Type 17" from SMBIOS spec 3.2.0  :

"7.18.7 Memory Device — Memory Operating Mode Capability
 Table 79 shows what the word bit positions mean for the Memory Device - Memory Operating Mode
Capability field. This field indicates the supported operating mode(s); it does not indicate the current
configured operating mode(s).
  "


But as mentioned at the spec, just the supported modes are present, and not the currently used operating mode.

The strange is that there are some tools that run at OS level that present this kind of information.
At one software (I will not say names to avoid problems), the current operating mode is presented at a tab named Memory with the following content:

Type: DDR4
Size: 8 GBytes
Channel #: Single
NB Frequency: 2593.0 MHz

At this software the field "Channel #" changes to "Dual" when adding the memory devices to the correct slots.

At another software, the operating mode is presented at a tab named Chipset on a section named "Memory Controller", with the following content:

Type: Dual Channel (128-bit)
Active Mode: Single Channel (64-bit)

At this same software their is a tab named North bridge with several information.

So my understanding is that these softwares are getting to the conclusion about the current operating mode in some indirect way. Maybe 
considering the DIMM location and bank. At this system, the SMBIOS presents the following information at Type17 (two memory devices attached to the motherboard):

Device Locator String1 - "ChannelA-DIMM0"
Bank Locator String2 - "BANK 0"

Device Locator String1 - "ChannelB-DIMM0"
Bank Locator String2 - "BANK 2"



But I am not sure if it would be safe to consider some logic simply based on the BANK and Channel information.
There are some registers that indicate if the platform supports dual channel, and other register that say if the platform supports dual channel but limits one DIMM per channel.
From my perspective the conclusion of the current operating mode should consider both information (smbios + chipset registers), and even this way I am not 100% it would work correctly.
The problem with this is that the chipset registers would be different, creating some complexity to maintain this code. (I know this is commond at HDS (hardware dependent software aka. BIOS/UEFI, but I woud like to avoid it if possible).

Could someone please clarify if it would be safe to consider 2 DIMM at the same bank and at the same channel as a confirmation that the platform is operating in dual channel, without considering
chipset registers?

Thanks and Regards
Rafael

Em qua, 21 de ago de 2019 às 16:56, Andrew Fish <afish@apple.com> escreveu:


On Aug 21, 2019, at 11:55 AM, Rafael Machado <rafaelrodrigues.machado@gmail.com> wrote:

Hi everyone

I would like to ask for some help regarding one question.
How do I know how the memory communication was set by the BIOS/MRC/FSP during the initialization process?
For example, I would like to know if the memory controller is working with the memories in single channel or dual channel mode.

Didn't find anything related to this at the uefi spec.
And seems the registers that may have this information are platform dependent, so no generic solution seems to be currently available.

Any idea about how to have this information?


Rafael,

This is probably more of a PI kind of spec question, but the PI spec only really deals in how memory is discovered and registered with the PEI/DXE Core etc. There is not any infrastructure that abstracts this level of detail in PI. 

In general the kind of info you are looking for would only exist in SMBIOS records. You could start with the Type 16, 17, 18, and 19 SMBIOS records. The code that configure the memory knows a lot, but the only standard way to communicate this info is via SMBIOS. 

Thanks,

Andrew Fish

Thanks and Regards
Rafael R. Machado