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:[email protected]]
On Behalf Of David Scully
Sent: Friday, August 14, 2015 2:35 PM
To: [email protected]
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
[email protected]
http://lists.elinux.org/mailman/listinfo/elinux-minnowboard
_______________________________________________
elinux-MinnowBoard mailing list
[email protected]
http://lists.elinux.org/mailman/listinfo/elinux-minnowboard
_______________________________________________
elinux-MinnowBoard mailing list
[email protected]
http://lists.elinux.org/mailman/listinfo/elinux-minnowboard
