* Re: [edk2-devel] Memory Operation Mode
2019-08-21 19:55 ` [edk2-devel] " Andrew Fish
@ 2019-08-22 14:09 ` Rafael Machado
0 siblings, 0 replies; 3+ messages in thread
From: Rafael Machado @ 2019-08-22 14:09 UTC (permalink / raw)
To: Andrew Fish; +Cc: devel
[-- Attachment #1: Type: text/plain, Size: 4321 bytes --]
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
ModeCapability field. This field indicates the supported operating mode(s);
it does not indicate the currentconfigured 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
>
>
>
>
[-- Attachment #2: Type: text/html, Size: 6377 bytes --]
^ permalink raw reply [flat|nested] 3+ messages in thread