From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: mx.groups.io; dkim=pass header.i=@gmail.com header.s=20161025 header.b=EW5CrhXk; spf=pass (domain: gmail.com, ip: 209.85.167.196, mailfrom: rafaelrodrigues.machado@gmail.com) Received: from mail-oi1-f196.google.com (mail-oi1-f196.google.com [209.85.167.196]) by groups.io with SMTP; Thu, 22 Aug 2019 07:09:41 -0700 Received: by mail-oi1-f196.google.com with SMTP id t24so4411716oij.13 for ; Thu, 22 Aug 2019 07:09:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=QSmluTzY0uc0WKzYM5bz9dBkAZPHBWH6VwmA7P9RSIk=; b=EW5CrhXklyS1UW6MhxooQF3M4k/gDZvowxiZHrGi2k/GaiQ8rbWdv0HWDR8jlmUgKl VSDZ8s263PCEzz4dPWT9UhVQq6Rie/ISuVYtFyJ/Vz8ae4apeEgsTia9HvrZRRiVj2f7 5qpgEgN5eis5iH+obt1LPreHLfZ8yQjwJZn0k5Geep7CksHfI6xDoeaZ7MVrOL7VegQB xmtYjQnxPusKJFUWlkgyJ8MErClV0kUIsAS+t8OH5qMtimolSbNe4j82Ys835Y2WfcF1 QXJcvstfvmFIUiVkVjBMiTMOqxBniqkfvsalBdQwy2+uNk0khPsa37tOiDeV5Nxp7Uno 4/Iw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=QSmluTzY0uc0WKzYM5bz9dBkAZPHBWH6VwmA7P9RSIk=; b=Y5r/1PX99tph7lSGuz+C7dGVebCk0FPxxPzxDwBEYmcgCiD2DG+vwQZ3tfoIZR1yPh 2PIWfH4cFRUCXN39Ly6NZ5yxSBYgHLtLT6ry/ROZe8K1ZCHMnb6z1TwMe5npai14stFN FpSsJGeiMbidSgcobF0yjpWs2NxgpkyxYXqc42tSt+kH6grYLEpHHEFgG/mYQqbAuY1I caLUzk4yNzGmgU6Yb2zF1PsmwnzTBB12x0vxb0Mxqg8xZz92OiBGlTqnHArrAPNCaKg4 uUSrNKnSTu8KyFOFXcQ5Iy1Q0erLq5u1tBLEL6K8xIwdy4k8cprRorCu1ThO+LbTh8wo Kpmg== X-Gm-Message-State: APjAAAUXlgPnIxJzboxqfkG/eLtceLBhtdbX4B9gDyG65Esu+ZOF3hDF EH4C46PeSvRSu5CPuNxN2NkFevQ0howpapEPqk4= X-Google-Smtp-Source: APXvYqzuStjW4IKUws5xmbl4Lu8BcXCQMOtqU3pTb85bPwMVmdQeyPJcXBneexqPeLVuVguLOSw50G1UtLpnuHSprh4= X-Received: by 2002:aca:4e0a:: with SMTP id c10mr3742203oib.61.1566482980376; Thu, 22 Aug 2019 07:09:40 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: "Rafael Machado" Date: Thu, 22 Aug 2019 11:09:29 -0300 Message-ID: Subject: Re: [edk2-devel] Memory Operation Mode To: Andrew Fish Cc: devel@edk2.groups.io Content-Type: multipart/alternative; boundary="0000000000009793940590b53d7d" --0000000000009793940590b53d7d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 =E2=80=94 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 no= t 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 Chipse= t 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 present= s 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 =C3=A0s 16:56, Andrew Fish esc= reveu: > > > 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 wi= th > 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 onl= y > 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 SMBI= OS > 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 wa= y > to communicate this info is via SMBIOS. > > Thanks, > > Andrew Fish > > Thanks and Regards > Rafael R. Machado >=20 > > > --0000000000009793940590b53d7d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Andrew

Thanks for the information an= d clarification!

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

&quo= t;7.18.7 Memory Device =E2=80=94 Memory Operating Mode Capability
=C2=A0Table 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 n= ot indicate the current
configured operating mode(s).=C2=A0 "= ;

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

The strang= e 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 pr= oblems), 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 s= oftware, the operating mode is presented at a tab named Chipset on a sectio= n named "Memory Controller", with the following content:

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

At this sam= e software their is a tab named North bridge with several information.

So my understanding is that these softwares are gettin= g to the conclusion about the current operating mode in some indirect way. = Maybe=C2=A0
considering the DIMM location and bank. At this syste= m, the SMBIOS presents the following information at Type17 (two memory devi= ces attached to the motherboard):

Device Locato= r 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 woul= d be safe to consider some logic simply based on the BANK and Channel infor= mation.
There are some registers that indicate if the platform su= pports dual channel, and other register that say if the platform supports d= ual channel but limits one DIMM per channel.
From my perspective = the conclusion of the current operating mode should consider both informati= on (smbios + chipset registers), and even this way I am not 100% it would w= ork correctly.
The problem with this is that the chipset register= s would be different, creating some complexity to maintain this code. (I kn= ow this is commond at HDS (hardware dependent software aka. BIOS/UEFI, but = I woud like to avoid it if possible).

Could someon= e please clarify if it would be safe to consider 2 DIMM at the same bank an= d at the same channel as a confirmation that the platform is operating in d= ual channel, without considering
chipset registers?
Thanks and Regards
Rafael

Em qua, 21 de ago d= e 2019 =C3=A0s 16:56, Andrew Fish <af= ish@apple.com> escreveu:


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

Hi everyon= e

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

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

Any idea abou= t how to have this information?


Rafael,

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

In general the kind of info you are looking for would onl= y 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 on= ly standard way to communicate this info is via SMBIOS.=C2=A0
Thanks,

Andrew Fish

Thanks and Regards
Ra= fael R. Machado

--0000000000009793940590b53d7d--