[MinnowBoard] Purpose of EEPROM

[Krau, Michael P]

Clarification:  Point #2 - When I said: " This is the normal case for MinnowBoards as shipped form the factory."

I meant that to my knowledge, the EEPROM is left blank, leaving the firmware to use mechanism #3. 

Sincerely, 


Michael Krau
 
-----Original Message-----
From: Krau, Michael P 
Sent: Friday, August 14, 2015 3:23 PM
To: MinnowBoard Development and Community Discussion
Subject: RE: [MinnowBoard] Purpose of EEPROM

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.  This is 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