[MinnowBoard] Purpose of EEPROM

[Grigory V. Korotov]

Hi.
Regarding SPD usage it seems like SPD don't used until  set 
gVlvRefCodePkgTokenSpaceGuid.PcdEnableMemoryDown|0. But in this case i 
get the following output
*C1.D0: SPD not present.**
**MRC getting memory size from SeC ...**
**SeC Device ID: F18**
**SeC UMA Size Requested: 16384 KB**
**MRC SeCUmaSize memory size from SeC ... 10**
**MRC getting fTPM memory size from SeC ...**
**MRC SeCfTPMUmaSize memory size from SeC ... 0**
**PROGRESS CODE: V51002 I0**
**POSTCODE=<0025>**
**PROGRESS CODE: V51003 I0**
**POSTCODE=<0027>**
**Configuring Memory...**
*.....
*Current function  is MMRC_RcvnTrain*

And firmware hangs in last red function. But i belive that SPD is ok and 
programmed because when i use hardcoded memory settings 
gVlvRefCodePkgTokenSpaceGuid.PcdMemoryParameterPatchable|TRUE memtest86 
and HWINFO shows me content of SPD.

How can i force firmware to use of SPD?

Grigory

15.08.2015 1:22, Krau, Michael P пишет:
> Hello David,
>
> Per your statement: "Our plan is to use the EDKII firmware and I see that memory parameters are hard-coded in the Vlv2TbltDevicePkg/PlatformPkgX64.dsc file. That seems to imply that if we did use different memories and set the MRC parameters correctly then the SPD data would not be essential (or required)."
>
> You are correct.  There are three methods used in the firmware to configure memory in the MinnowBoard MAX firmware code:
>
> 1) The file: Vlv2TbltDevicePkg/PlatformPkgX64.dsc can be used to override all settings of the firmware and fix the memory parameters.  This is NOT The normal configuration of the code, as this mechanism has highest priority.
> The switch " gVlvRefCodePkgTokenSpaceGuid.PcdMemoryParameterPatchable" controls this mechanism.  When set to TRUE the Values set in the .dsc will be used, (while mechanisms 2 and 3 are disregarded).  When set to FALSE, the values will be ignored and mechanisms 2 and 3 will be used.
>
> 2) The SPD data in the EEPROM will be used to configure the memory.  If the EEPROM  is blank (or the data is nonsensical) , this mechanism is skipped, and the mechanism 3 is used.  THisis the normal case for MinnowBoards as shipped form the factory.
>
> Note, if the EEPROM contains data that is valid for (some) memory configuration, but not the configuration of the existing platform, there is a very real danger of "bricking the board".  Basically,  the memory reference will assume the data in the EEPROM is correct, and will use it to configure memory.  Since the configuration would match  the actual hardware memory components, the memory initialization will not be correct, and the memory subsystem will not work properly (if at all.  My advice, best leave this method alone, unless you have access to a hardware lab that can replace or reprogram the EEPROM to a configuration that is either correct, or blank.
>
> 3) The MinnowBoard MAX has several configurations set in the code.  The product is using a 2MB configuration, which is the standard configuration (which is identified by the use of the BOM_OPTION settings  several GPIO pins).  This is  both the standard mechanism for the production units as well as the general the fallback position for the firmware.
>
> The multiple mechanisms were established for the following reasons:
> 1) Allows developers to create derivative designs with different memory configurations and still use the standard Firmware sources.
> 2) This is the industry mechanism for memory configuration.  The EEPROM acts like the configuration storage on the memory DIMMs, I those systems that have 'plug-able DDR3 DIMMS' in their memory.  (this maintains the standard)
> 3) The MinnowBoard MAX used this system as it is straight forward, and it makes a good safety net for the firmware.
>
> Thank you,
>
>
>
> Michael Krau
>   
> -----Original Message-----
> From: elinux-MinnowBoard [mailto:elinux-minnowboard-bounces at lists.elinux.org] On Behalf Of David Scully
> Sent: Friday, August 14, 2015 2:35 PM
> To: elinux-minnowboard at lists.elinux.org
> Subject: Re: [MinnowBoard] Purpose of EEPROM
>
> Thank you both for your response.
>
> John,
> I wanted to clarify. Did you mean to say that if we're *not* using the exactly the same memory and same CPU then we'd need to populate the EEPROM with SPD data? I think a word might have been dropped there...
>
> Our plan is to use the EDKII firmware and I see that memory parameters are hard-coded in the Vlv2TbltDevicePkg/PlatformPkgX64.dsc file. That seems to imply that if we did use different memories and set the MRC parameters correctly then the SPD data would not be essential (or required).
>
> Though we do plan to use the same memory/CPU, so I think we'll be OK!
>
> As for SMBus, I see now that Linux kernel support was one of the GSoC2015 proposals. Makes sense why we we're having trouble.
>
> Thanks again!
>
>
>
> --
> View this message in context: http://minnowboard.57273.x6.nabble.com/Purpose-of-EEPROM-tp1823p1831.html
> Sent from the MinnowBoard mailing list archive at Nabble.com.
> _______________________________________________
> elinux-MinnowBoard mailing list
> elinux-MinnowBoard at lists.elinux.org
> http://lists.elinux.org/mailman/listinfo/elinux-minnowboard
> _______________________________________________
> elinux-MinnowBoard mailing list
> elinux-MinnowBoard at lists.elinux.org
> http://lists.elinux.org/mailman/listinfo/elinux-minnowboard


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.elinux.org/pipermail/elinux-minnowboard/attachments/20170208/02304a35/attachment.html>