Coreboot FSP fails to initialize RAM - "Configuration not in POR table"

[Naveen Chaudhary]

I am using Faceboot Watson image (with no code changes) on a custom BroadwellDE based motherboard. Current the FSP_FSP_INIT api never returns back. I enabled the FSP logs and got the following messages :

bootMode = NormalBoot
subBootMode = ColdBoot
Dispatch Slaves -- Started
Dispatch Slaves - 0ms
Promote Warning Exception List -- Started
Promote Warning Exception List - 0ms
Initialize Throttling Early -- Started
Initialize Throttling Early - 0ms
Detect DIMM Configuration -- Started
Checkpoint Code: Socket 0, 0xB0, 0x00, 0x0000
N0: IMC 0 SMB Clock Period = 0x1F2C
Socket | Channel | DIMM |  Bus Segment | SMBUS Address
-------|---------|------|--------------|--------------
   0   |     0   |   0  |      0       |       0      - Present
N0.C0.D0: NVDIMM:N(380)=0x0
   0   |     0   |   1  |      0       |       1      - Not Present
   0   |     1   |   0  |      0       |       2      - Present
N0.C1.D0: NVDIMM:N(380)=0x0
   0   |     1   |   1  |      0       |       3      - Not Present
Entering no zone 1
Detect DIMM Configuration - 238ms
Get Slave Data -- Started
Get Slave Data - 0ms
Check POR Compatibility -- Started
primaryWidthDDR4: 1, rowBitsDDR4: 16, columnBitsDDR4: 10, bankGroupsDDR4: 4
primaryWidthDDR4: 1, rowBitsDDR4: 16, columnBitsDDR4: 10, bankGroupsDDR4: 4
Unknown DIMM population
Check POR Compatibility - 17ms
Initialize DDR Clocks -- Started
Checkpoint Code: Socket 0, 0xB1, 0x00, 0x0000
Configuration not in POR table!
Memory Configuration: Vdd = 3, procType = 0x5066, socketType = 3, dramType = 12, spc = 2, dpc = 1, dimmType = 5, numRanks = 2
GetPORDDRFreq returns ddrfreq = 255
N0.C0: FPT: DisableChannel()
N0.C0.D0: FPT: DisableDIMM()

A warning has been logged! Warning Code = 0x7, Minor Warning Code = 0x8, Data = 0xFFFF
S0 Ch0

Warning upgraded to Fatal Error!

FatalError: SocketId = 0 registered Major Code = 0x 7, Minor Code = 0x 8

What does "Configuration not in POR table mean? Does this mean that FSP can no longer initialize my DRAM automatically? If yes, what's the solution here? Or shall I try tweaking other settings such as MemEccSupport, MemDdrMemoryType, etc.


Regards,
Naveen

[David Hendricks]

Hi Naveen,

What does "Configuration not in POR table mean? Does this mean that FSP can
> no longer initialize my DRAM automatically? If yes, what's the solution
> here? Or shall I try tweaking other settings such as MemEccSupport,
> MemDdrMemoryType, etc.

Intel validates several configurations of DRAM to go with their SoCs, and
AFAIK validated parts are considered "POR" (plan of record?). 'ddrfreq =
255' is a weird value for DRAM frequency, so I suspect that is really an
error code that indicates a problem with the frequency passed in via your
configuration or SPDs.

So you may need to adjust the value to match common DDR4 timings, such as
DDR4 2133 or DDR4 2400.

The following documents might help to figure out a valid configuration for
your SoC (you'll need to download them from Intel yourself, of course):
Document number 543448 - Grangeville Platform Design Guide
Document number 557970 - Xeon D-1500 Specification update

[Naveen Chaudhary]

Thanks David for the response.

Does this mean that there is a way in FSP to define custom settings(configs) for DIMMs? In the FSP integration guide for BroadwellDE (https://github.com/IntelFsp/FSP/tree/master/BroadwellDEFspBinPkg/Docs) I don't see any relevant data member where we could define pointer to custom SPD settings or pass individual DIMMs configurations.

Hence, I was assuming that the only way DIMM memory could be initialized is that FSP itself will locate SPD and will apply the whatever read settings.

Meanwhile, I am going through the documents. Since I also have the datasheet available for the DIMMs, I can try playing with different settings, but I need to know a way to do that, which till now I was assuming that there is no such way.

Waiting to hear back. Many thanks.

Regards,
Naveen
[https://avatars1.githubusercontent.com/u/19785541?s=400&v=4]<https://github.com/IntelFsp/FSP/tree/master/BroadwellDEFspBinPkg/Docs>
FSP/BroadwellDEFspBinPkg/Docs at master · IntelFsp/FSP - github.com<https://github.com/IntelFsp/FSP/tree/master/BroadwellDEFspBinPkg/Docs>
Intel(R) Firmware Support Package (FSP). Contribute to IntelFsp/FSP development by creating an account on GitHub.
github.com

________________________________
From: David Hendricks <[e-mail]>
Sent: Saturday, October 26, 2019 7:29 AM
To: Naveen Chaudhary <[e-mail]>
Cc: [e-mail] <[e-mail]>
Subject: Re: [coreboot] Coreboot FSP fails to initialize RAM - "Configuration not in POR table"

Hi Naveen,

What does "Configuration not in POR table mean? Does this mean that FSP can no longer initialize my DRAM automatically? If yes, what's the solution here? Or shall I try tweaking other settings such as MemEccSupport, MemDdrMemoryType, etc.

Intel validates several configurations of DRAM to go with their SoCs, and AFAIK validated parts are considered "POR" (plan of record?). 'ddrfreq = 255' is a weird value for DRAM frequency, so I suspect that is really an error code that indicates a problem with the frequency passed in via your configuration or SPDs.

So you may need to adjust the value to match common DDR4 timings, such as DDR4 2133 or DDR4 2400.

The following documents might help to figure out a valid configuration for your SoC (you'll need to download them from Intel yourself, of course):
Document number 543448 - Grangeville Platform Design Guide
Document number 557970 - Xeon D-1500 Specification update

[Nico Huber]

Hello Naveen,

On 27.10.19 05:02, Naveen Chaudhary wrote:
> Does this mean that there is a way in FSP to define custom settings(configs) for DIMMs? In the FSP integration guide for BroadwellDE (https://github.com/IntelFsp/FSP/tree/master/BroadwellDEFspBinPkg/Docs) I don't see any relevant data member where we could define pointer to custom SPD settings or pass individual DIMMs configurations.

there is the memory-down option. It seems undocumented if that does more
than switching from on-DIMM SPDs to SPD files. Maybe it's worth a try.
If that doesn't work out, you can always overwrite the SPDs on your
DIMM's EEPROMs. Always keep a backup, though.

Hope that helps,
Nico

[Naveen Chaudhary]

Hi,

Perhaps you are right. I was going through "Embedded Firmware Solutions" and on Page 43 :

"This S3 resume path (i.e., resume from a sleep state using existing
memory contents) is used to optimize the boot speed by using the memory parameters
passed in (instead of going through the memory training code). It can also be used for
soldered-down memory configuration, or after the first boot when there is no change
in memory configuration and when memory training parameters remain valid. There is
not a “Fast Boot” flag to reflect the need to skip memory training, but FSP will look at the
input parameter, NvsBufferPtr, to determine if it should skip memory training or not. If it
is NULL, it will not skip, and if there is a valid pointer stored in NvsBufferPtr, it will skip
the memory training code. This can save potential boot time up to 100 milliseconds."

And for recent SoCs, we even have FastBoot flag now. This could be the way out. This way we can prevent the FSP from reading SPD and rather read from the NVRAM. But I am not sure what should be the structure for NvsBuffer pointer. Perhaps, I may create a structure of 512 bytes on stack as per JEDEC spec for DIMMs, and then pass that to the API.  If my assumption is correct, to begin with I can pass the exact same SPD data as on the RAM SPD (by referring the datasheet), so that I get the same behaviour. Next, I can experiment changing the values.

Has anyone on this mailing thread experience working with custom DIMMs that aren't POR for FSP? How did you come through this problem? Need your experience here guys. Please help.

Regards,
Naveen
________________________________
From: Nico Huber <[e-mail]>
Sent: Sunday, October 27, 2019 4:03 PM
To: Naveen Chaudhary <[e-mail]>; David Hendricks <[e-mail]>
Cc: [e-mail] <[e-mail]>
Subject: Re: [coreboot] Re: Coreboot FSP fails to initialize RAM - "Configuration not in POR table"

Hello Naveen,

On 27.10.19 05:02, Naveen Chaudhary wrote:
> Does this mean that there is a way in FSP to define custom settings(configs) for DIMMs? In the FSP integration guide for BroadwellDE (https://github.com/IntelFsp/FSP/tree/master/BroadwellDEFspBinPkg/Docs) I don't see any relevant data member where we could define pointer to custom SPD settings or pass individual DIMMs configurations.

there is the memory-down option. It seems undocumented if that does more
than switching from on-DIMM SPDs to SPD files. Maybe it's worth a try.
If that doesn't work out, you can always overwrite the SPDs on your
DIMM's EEPROMs. Always keep a backup, though.

Hope that helps,
Nico

[Wim Vervoorn]

Hello Naveen,

You should use the "MemDownCh0Dimm0SpdPtr" to point to a buffer containing the SPD data and set MemDownEnable" to 1.

Best Regards,
Wim Vervoorn



-----Original Message-----
From: Nico Huber [mailto:[e-mail]] 
Sent: Sunday, October 27, 2019 11:33 AM
To: Naveen Chaudhary <[e-mail]>; David Hendricks <[e-mail]>
Cc: [e-mail]
Subject: [coreboot] Re: Coreboot FSP fails to initialize RAM - "Configuration not in POR table"

Hello Naveen,

On 27.10.19 05:02, Naveen Chaudhary wrote:
> Does this mean that there is a way in FSP to define custom settings(configs) for DIMMs? In the FSP integration guide for BroadwellDE (https://github.com/IntelFsp/FSP/tree/master/BroadwellDEFspBinPkg/Docs) I don't see any relevant data member where we could define pointer to custom SPD settings or pass individual DIMMs configurations.

there is the memory-down option. It seems undocumented if that does more than switching from on-DIMM SPDs to SPD files. Maybe it's worth a try.
If that doesn't work out, you can always overwrite the SPDs on your DIMM's EEPROMs. Always keep a backup, though.

Hope that helps,
Nico
_______________________________________________
coreboot mailing list -- [e-mail] To unsubscribe send an email to [e-mail]

[Naveen Chaudhary]

Thanks Wim.

I will give a try and pass a 512 byte hex block corresponding to the SPD data and if it works, I can play with the hex values to find out the right configuration.

BTW, any idea which field can impact the ddrfreq which was reported as error in the initial logs?

Regards,
Naveen

Get Outlook for Android<https://aka.ms/ghei36>

________________________________
From: Wim Vervoorn <[e-mail]>
Sent: Tuesday, October 29, 2019 3:07:44 PM
To: Nico Huber <[e-mail]>; Naveen Chaudhary <[e-mail]>; David Hendricks <[e-mail]>
Cc: [e-mail] <[e-mail]>
Subject: RE: [coreboot] Re: Coreboot FSP fails to initialize RAM - "Configuration not in POR table"

Hello Naveen,

You should use the "MemDownCh0Dimm0SpdPtr" to point to a buffer containing the SPD data and set MemDownEnable" to 1.

Best Regards,
Wim Vervoorn



-----Original Message-----
From: Nico Huber [mailto:[e-mail]]
Sent: Sunday, October 27, 2019 11:33 AM
To: Naveen Chaudhary <[e-mail]>; David Hendricks <[e-mail]>
Cc: [e-mail]
Subject: [coreboot] Re: Coreboot FSP fails to initialize RAM - "Configuration not in POR table"

Hello Naveen,

On 27.10.19 05:02, Naveen Chaudhary wrote:
> Does this mean that there is a way in FSP to define custom settings(configs) for DIMMs? In the FSP integration guide for BroadwellDE (https://github.com/IntelFsp/FSP/tree/master/BroadwellDEFspBinPkg/Docs) I don't see any relevant data member where we could define pointer to custom SPD settings or pass individual DIMMs configurations.

there is the memory-down option. It seems undocumented if that does more than switching from on-DIMM SPDs to SPD files. Maybe it's worth a try.
If that doesn't work out, you can always overwrite the SPDs on your DIMM's EEPROMs. Always keep a backup, though.

Hope that helps,
Nico
_______________________________________________
coreboot mailing list -- [e-mail] To unsubscribe send an email to [e-mail]

[Wim Vervoorn]

Hello Naveen,

This is the important part. This indicates the what you selected is not supported.

Please review your settings carefully. This isn't a single check. The code validates the SPD settings against the other settings you made.
So please make sure you are passing in a DDR4 SPD when you select DDR4 mode. Also please make sure the SPD settings are in
The list of supported configuration for the chip.

Check POR Compatibility -- Started
primaryWidthDDR4: 1, rowBitsDDR4: 16, columnBitsDDR4: 10, bankGroupsDDR4: 4
primaryWidthDDR4: 1, rowBitsDDR4: 16, columnBitsDDR4: 10, bankGroupsDDR4: 4
Unknown DIMM population *****
Check POR Compatibility - 17ms
Initialize DDR Clocks -- Started
Checkpoint Code: Socket 0, 0xB1, 0x00, 0x0000
Configuration not in POR table!  *** (This basically indicates you are trying to do something that is not supported by the chipset).

Best regards,

Wim

From: Naveen Chaudhary [mailto:[e-mail]]
Sent: Tuesday, October 29, 2019 10:44 AM
To: Wim Vervoorn <[e-mail]>; Nico Huber <[e-mail]>; David Hendricks <[e-mail]>
Cc: [e-mail]
Subject: Re: [coreboot] Re: Coreboot FSP fails to initialize RAM - "Configuration not in POR table"

Thanks Wim.
I will give a try and pass a 512 byte hex block corresponding to the SPD data and if it works, I can play with the hex values to find out the right configuration.
BTW, any idea which field can impact the ddrfreq which was reported as error in the initial logs?
Regards,
Naveen
Get Outlook for Android<https://aka.ms/ghei36>

________________________________
From: Wim Vervoorn <[e-mail]<mailto:[e-mail]>>
Sent: Tuesday, October 29, 2019 3:07:44 PM
To: Nico Huber <[e-mail]<mailto:[e-mail]>>; Naveen Chaudhary <[e-mail]<mailto:[e-mail]>>; David Hendricks <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Subject: RE: [coreboot] Re: Coreboot FSP fails to initialize RAM - "Configuration not in POR table"

Hello Naveen,

You should use the "MemDownCh0Dimm0SpdPtr" to point to a buffer containing the SPD data and set MemDownEnable" to 1.

Best Regards,
Wim Vervoorn



-----Original Message-----
From: Nico Huber [mailto:[e-mail]]
Sent: Sunday, October 27, 2019 11:33 AM
To: Naveen Chaudhary <[e-mail]<mailto:[e-mail]>>; David Hendricks <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>
Subject: [coreboot] Re: Coreboot FSP fails to initialize RAM - "Configuration not in POR table"

Hello Naveen,

On 27.10.19 05:02, Naveen Chaudhary wrote:
> Does this mean that there is a way in FSP to define custom settings(configs) for DIMMs? In the FSP integration guide for BroadwellDE (https://github.com/IntelFsp/FSP/tree/master/BroadwellDEFspBinPkg/Docs) I don't see any relevant data member where we could define pointer to custom SPD settings or pass individual DIMMs configurations.

there is the memory-down option. It seems undocumented if that does more than switching from on-DIMM SPDs to SPD files. Maybe it's worth a try.
If that doesn't work out, you can always overwrite the SPDs on your DIMM's EEPROMs. Always keep a backup, though.

Hope that helps,
Nico
_______________________________________________
coreboot mailing list -- [e-mail]<mailto:[e-mail]> To unsubscribe send an email to [e-mail]<mailto:[e-mail]>

[Naveen Chaudhary]

Sorry I didn't get the point completely. Do you mean the settings are not compatible with FSP code? Or do you mean the settings might be conflicting themselves.

Since the above settings were read from SPD and the chip vendor must have definitely set them correctly, I assume you meant first sentence.

Please correct me.

Regards,
Naveen

Get Outlook for Android<https://aka.ms/ghei36>

________________________________
From: Wim Vervoorn <[e-mail]>
Sent: Tuesday, October 29, 2019 3:47:34 PM
To: Naveen Chaudhary <[e-mail]>; Nico Huber <[e-mail]>; David Hendricks <[e-mail]>
Cc: [e-mail] <[e-mail]>
Subject: RE: [coreboot] Re: Coreboot FSP fails to initialize RAM - "Configuration not in POR table"


Hello Naveen,



This is the important part. This indicates the what you selected is not supported.



Please review your settings carefully. This isn't a single check. The code validates the SPD settings against the other settings you made.

So please make sure you are passing in a DDR4 SPD when you select DDR4 mode. Also please make sure the SPD settings are in

The list of supported configuration for the chip.



Check POR Compatibility -- Started

primaryWidthDDR4: 1, rowBitsDDR4: 16, columnBitsDDR4: 10, bankGroupsDDR4: 4

primaryWidthDDR4: 1, rowBitsDDR4: 16, columnBitsDDR4: 10, bankGroupsDDR4: 4

Unknown DIMM population *****

Check POR Compatibility - 17ms

Initialize DDR Clocks -- Started

Checkpoint Code: Socket 0, 0xB1, 0x00, 0x0000

Configuration not in POR table!  *** (This basically indicates you are trying to do something that is not supported by the chipset).



Best regards,

Wim



From: Naveen Chaudhary [mailto:[e-mail]]
Sent: Tuesday, October 29, 2019 10:44 AM
To: Wim Vervoorn <[e-mail]>; Nico Huber <[e-mail]>; David Hendricks <[e-mail]>
Cc: [e-mail]
Subject: Re: [coreboot] Re: Coreboot FSP fails to initialize RAM - "Configuration not in POR table"



Thanks Wim.

I will give a try and pass a 512 byte hex block corresponding to the SPD data and if it works, I can play with the hex values to find out the right configuration.

BTW, any idea which field can impact the ddrfreq which was reported as error in the initial logs?

Regards,

Naveen

Get Outlook for Android<https://aka.ms/ghei36>



________________________________

From: Wim Vervoorn <[e-mail]<mailto:[e-mail]>>
Sent: Tuesday, October 29, 2019 3:07:44 PM
To: Nico Huber <[e-mail]<mailto:[e-mail]>>; Naveen Chaudhary <[e-mail]<mailto:[e-mail]>>; David Hendricks <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Subject: RE: [coreboot] Re: Coreboot FSP fails to initialize RAM - "Configuration not in POR table"



Hello Naveen,

You should use the "MemDownCh0Dimm0SpdPtr" to point to a buffer containing the SPD data and set MemDownEnable" to 1.

Best Regards,
Wim Vervoorn



-----Original Message-----
From: Nico Huber [mailto:[e-mail]]
Sent: Sunday, October 27, 2019 11:33 AM
To: Naveen Chaudhary <[e-mail]<mailto:[e-mail]>>; David Hendricks <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>
Subject: [coreboot] Re: Coreboot FSP fails to initialize RAM - "Configuration not in POR table"

Hello Naveen,

On 27.10.19 05:02, Naveen Chaudhary wrote:
> Does this mean that there is a way in FSP to define custom settings(configs) for DIMMs? In the FSP integration guide for BroadwellDE (https://github.com/IntelFsp/FSP/tree/master/BroadwellDEFspBinPkg/Docs) I don't see any relevant data member where we could define pointer to custom SPD settings or pass individual DIMMs configurations.

there is the memory-down option. It seems undocumented if that does more than switching from on-DIMM SPDs to SPD files. Maybe it's worth a try.
If that doesn't work out, you can always overwrite the SPDs on your DIMM's EEPROMs. Always keep a backup, though.

Hope that helps,
Nico
_______________________________________________
coreboot mailing list -- [e-mail]<mailto:[e-mail]> To unsubscribe send an email to [e-mail]<mailto:[e-mail]>

[David Hendricks]

Hi Naveen,
Yes, the first sentence. The DIMMs you are using appear to have geometry or
timings incompatible with Broadwell-DE, based on the SPD values that the
vendor programmed. Chapter 6 of the PDG (docid 543448) should help clarify
what kinds of DIMMs are supported and how they should be populated.

On Tue, Oct 29, 2019 at 5:07 AM Naveen Chaudhary <
[e-mail]> wrote:
> Sorry I didn't get the point completely. Do you mean the settings are not
> compatible with FSP code? Or do you mean the settings might be conflicting
> themselves.
>
> Since the above settings were read from SPD and the chip vendor must have
> definitely set them correctly, I assume you meant first sentence.
>
> Please correct me.
>
> Regards,
> Naveen
>
> Get Outlook for Android <https://aka.ms/ghei36>
>
> ------------------------------
> *From:* Wim Vervoorn <[e-mail]>
> *Sent:* Tuesday, October 29, 2019 3:47:34 PM
> *To:* Naveen Chaudhary <[e-mail]>; Nico Huber <
> [e-mail]>; David Hendricks <[e-mail]>
> *Cc:* [e-mail] <[e-mail]>
> *Subject:* RE: [coreboot] Re: Coreboot FSP fails to initialize RAM -
> "Configuration not in POR table"
>
> Hello Naveen,
>
> This is the important part. This indicates the what you selected is not
> supported.
>
> Please review your settings carefully. This isn't a single check. The code
> validates the SPD settings against the other settings you made.
>
> So please make sure you are passing in a DDR4 SPD when you select DDR4
> mode. Also please make sure the SPD settings are in
>
> The list of supported configuration for the chip.
>
> Check POR Compatibility -- Started
>
> primaryWidthDDR4: 1, rowBitsDDR4: 16, columnBitsDDR4: 10, bankGroupsDDR4:
> 4
>
> primaryWidthDDR4: 1, rowBitsDDR4: 16, columnBitsDDR4: 10, bankGroupsDDR4:
> 4
>
> Unknown DIMM population *****
>
> Check POR Compatibility - 17ms
>
> Initialize DDR Clocks -- Started
>
> Checkpoint Code: Socket 0, 0xB1, 0x00, 0x0000
>
> Configuration not in POR table!  *** (This basically indicates you are
> trying to do something that is not supported by the chipset).
>
> Best regards,
>
> Wim
>
> *From:* Naveen Chaudhary [mailto:[e-mail]]
> *Sent:* Tuesday, October 29, 2019 10:44 AM
> *To:* Wim Vervoorn <[e-mail]>; Nico Huber <[e-mail]>;
> David Hendricks <[e-mail]>
> *Cc:* [e-mail]
> *Subject:* Re: [coreboot] Re: Coreboot FSP fails to initialize RAM -
> "Configuration not in POR table"
>
> Thanks Wim.
>
> I will give a try and pass a 512 byte hex block corresponding to the SPD
> data and if it works, I can play with the hex values to find out the right
> configuration.
>
> BTW, any idea which field can impact the ddrfreq which was reported as
> error in the initial logs?
>
> Regards,
>
> Naveen
>
> Get Outlook for Android <https://aka.ms/ghei36>
>
> ------------------------------
>
> *From:* Wim Vervoorn <[e-mail]>
> *Sent:* Tuesday, October 29, 2019 3:07:44 PM
> *To:* Nico Huber <[e-mail]>; Naveen Chaudhary <
> [e-mail]>; David Hendricks <
> [e-mail]>
> *Cc:* [e-mail] <[e-mail]>
> *Subject:* RE: [coreboot] Re: Coreboot FSP fails to initialize RAM -
> "Configuration not in POR table"
>
> Hello Naveen,
>
> You should use the "MemDownCh0Dimm0SpdPtr" to point to a buffer containing
> the SPD data and set MemDownEnable" to 1.
>
> Best Regards,
> Wim Vervoorn
>
> -----Original Message-----
> From: Nico Huber [mailto:[e-mail] <[e-mail]>]
> Sent: Sunday, October 27, 2019 11:33 AM
> To: Naveen Chaudhary <[e-mail]>; David Hendricks <
> [e-mail]>
> Cc: [e-mail]
> Subject: [coreboot] Re: Coreboot FSP fails to initialize RAM -
> "Configuration not in POR table"
>
> Hello Naveen,
>
> On 27.10.19 05:02, Naveen Chaudhary wrote:
> > Does this mean that there is a way in FSP to define custom
> > settings(configs) for DIMMs? In the FSP integration guide for BroadwellDE (
> > https://github.com/IntelFsp/FSP/tree/master/BroadwellDEFspBinPkg/Docs) I
> > don't see any relevant data member where we could define pointer to custom
> > SPD settings or pass individual DIMMs configurations.
>
> there is the memory-down option. It seems undocumented if that does more
> than switching from on-DIMM SPDs to SPD files. Maybe it's worth a try.
> If that doesn't work out, you can always overwrite the SPDs on your DIMM's
> EEPROMs. Always keep a backup, though.
>
> Hope that helps,
> Nico
> _______________________________________________
> coreboot mailing list -- [e-mail] To unsubscribe send an
> email to [e-mail]

[Naveen Chaudhary]

Thanks David.

Since some proprietary BIOS already works on this motherboard, this implies that I can use a different set of settings (timings, latency, etc) to make it work, as you suggested.

I found that the flag called FSP_MEMORY_DOWN_CH0DIMM0_SPD_PRESENT is there which I can make use of, to pass an SPD bin. I am not sure how to prepare that binary but I am assuming we can put all the 512 hex bytes of SPD as per DDR4 SPD spec into a text file and name it as spd.bin and pass along. (example : https://github.com/coreboot/coreboot/blob/master/src/mainboard/intel/cannonl...) Coreboot build system will automatically pack it. Compilation passed for me and will test it now, if the SPD data is read properly.
[https://avatars3.githubusercontent.com/u/6484311?s=400&v=4]<https://github.com/coreboot/coreboot/blob/master/src/mainboard/intel/cannonlake_rvp/spd/samsung_ddr4_4GB.spd.hex>
coreboot/coreboot<https://github.com/coreboot/coreboot/blob/master/src/mainboard/intel/cannonl...>
github mirror of coreboot.org's master repository. Contribute to coreboot/coreboot development by creating an account on GitHub.
github.com


In case this is not the correct way, the alternative way could be to create a UINT8 buff [512] and typecast to
UpdData->MemDownCh0Dimm0SpdPtr = (UINT32) buff;
directly.

While I am testing all this, anyone please correct me on the .bin part, so that it helps future contributors as well, as its not documented anywhere in coreboot.

Regards,
Naveen
________________________________
From: David Hendricks <[e-mail]>
Sent: Wednesday, 30 October, 2019, 12:44 PM
To: Naveen Chaudhary
Cc: Wim Vervoorn; Nico Huber; [e-mail]
Subject: Re: [coreboot] Re: Coreboot FSP fails to initialize RAM - "Configuration not in POR table"

Hi Naveen,
Yes, the first sentence. The DIMMs you are using appear to have geometry or timings incompatible with Broadwell-DE, based on the SPD values that the vendor programmed. Chapter 6 of the PDG (docid 543448) should help clarify what kinds of DIMMs are supported and how they should be populated.

On Tue, Oct 29, 2019 at 5:07 AM Naveen Chaudhary <[e-mail]<mailto:[e-mail]>> wrote:
Sorry I didn't get the point completely. Do you mean the settings are not compatible with FSP code? Or do you mean the settings might be conflicting themselves.

Since the above settings were read from SPD and the chip vendor must have definitely set them correctly, I assume you meant first sentence.

Please correct me.

Regards,
Naveen

Get Outlook for Android<https://aka.ms/ghei36>

________________________________
From: Wim Vervoorn <[e-mail]<mailto:[e-mail]>>
Sent: Tuesday, October 29, 2019 3:47:34 PM
To: Naveen Chaudhary <[e-mail]<mailto:[e-mail]>>; Nico Huber <[e-mail]<mailto:[e-mail]>>; David Hendricks <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Subject: RE: [coreboot] Re: Coreboot FSP fails to initialize RAM - "Configuration not in POR table"


Hello Naveen,



This is the important part. This indicates the what you selected is not supported.



Please review your settings carefully. This isn't a single check. The code validates the SPD settings against the other settings you made.

So please make sure you are passing in a DDR4 SPD when you select DDR4 mode. Also please make sure the SPD settings are in

The list of supported configuration for the chip.



Check POR Compatibility -- Started

primaryWidthDDR4: 1, rowBitsDDR4: 16, columnBitsDDR4: 10, bankGroupsDDR4: 4

primaryWidthDDR4: 1, rowBitsDDR4: 16, columnBitsDDR4: 10, bankGroupsDDR4: 4

Unknown DIMM population *****

Check POR Compatibility - 17ms

Initialize DDR Clocks -- Started

Checkpoint Code: Socket 0, 0xB1, 0x00, 0x0000

Configuration not in POR table!  *** (This basically indicates you are trying to do something that is not supported by the chipset).



Best regards,

Wim



From: Naveen Chaudhary [mailto:[e-mail]<mailto:[e-mail]>]
Sent: Tuesday, October 29, 2019 10:44 AM
To: Wim Vervoorn <[e-mail]<mailto:[e-mail]>>; Nico Huber <[e-mail]<mailto:[e-mail]>>; David Hendricks <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>
Subject: Re: [coreboot] Re: Coreboot FSP fails to initialize RAM - "Configuration not in POR table"



Thanks Wim.

I will give a try and pass a 512 byte hex block corresponding to the SPD data and if it works, I can play with the hex values to find out the right configuration.

BTW, any idea which field can impact the ddrfreq which was reported as error in the initial logs?

Regards,

Naveen

Get Outlook for Android<https://aka.ms/ghei36>



________________________________

From: Wim Vervoorn <[e-mail]<mailto:[e-mail]>>
Sent: Tuesday, October 29, 2019 3:07:44 PM
To: Nico Huber <[e-mail]<mailto:[e-mail]>>; Naveen Chaudhary <[e-mail]<mailto:[e-mail]>>; David Hendricks <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Subject: RE: [coreboot] Re: Coreboot FSP fails to initialize RAM - "Configuration not in POR table"



Hello Naveen,

You should use the "MemDownCh0Dimm0SpdPtr" to point to a buffer containing the SPD data and set MemDownEnable" to 1.

Best Regards,
Wim Vervoorn



-----Original Message-----
From: Nico Huber [mailto:[e-mail]]
Sent: Sunday, October 27, 2019 11:33 AM
To: Naveen Chaudhary <[e-mail]<mailto:[e-mail]>>; David Hendricks <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>
Subject: [coreboot] Re: Coreboot FSP fails to initialize RAM - "Configuration not in POR table"

Hello Naveen,

On 27.10.19 05:02, Naveen Chaudhary wrote:
> Does this mean that there is a way in FSP to define custom settings(configs) for DIMMs? In the FSP integration guide for BroadwellDE (https://github.com/IntelFsp/FSP/tree/master/BroadwellDEFspBinPkg/Docs) I don't see any relevant data member where we could define pointer to custom SPD settings or pass individual DIMMs configurations.

there is the memory-down option. It seems undocumented if that does more than switching from on-DIMM SPDs to SPD files. Maybe it's worth a try.
If that doesn't work out, you can always overwrite the SPDs on your DIMM's EEPROMs. Always keep a backup, though.

Hope that helps,
Nico
_______________________________________________
coreboot mailing list -- [e-mail]<mailto:[e-mail]> To unsubscribe send an email to [e-mail]<mailto:[e-mail]>

[Michal Zygowski]

On 30.10.2019 08:31, Naveen Chaudhary wrote:
> Thanks David.
>
> Since some proprietary BIOS already works on this motherboard, this
> implies that I can use a different set of settings (timings, latency,
> etc) to make it work, as you suggested.
> Unfortunately it doesn't imply that. Vendor BIOS != FSP. The BIOS vendor
> could obtain different memory initialization code from Intel with some
> bug fixes and it is very likely that it was not propagated back into the
> FSP. This is how this werid system works. Bugs and issues are not
> propagated back into older trees and vendors are creating tons of
> unmaintainable forks for the firmware. Applying the same changed SPD
> parameters may give different results of memory training with FSP and
> vendor BIOS. The best way to go is to get the hands on the papers David
> pointed to (if possible) and do trial-by-error. It may take time but
> there is a chance to succeed. Good thing is you have debug output from
> FSP so at least you know what is wrong.

Regards,
Michał
> I found that the flag called FSP_MEMORY_DOWN_CH0DIMM0_SPD_PRESENT is
> there which I can make use of, to pass an SPD bin. I am not sure how
> to prepare that binary but I am assuming we can put all the 512 hex
> bytes of SPD as per DDR4 SPD spec into a text file and name it as
> spd.bin and pass along. (example :
> https://github.com/coreboot/coreboot/blob/master/src/mainboard/intel/cannonl...)
> Coreboot build system will automatically pack it. Compilation passed
> for me and will test it now, if the SPD data is read properly.
> <https://github.com/coreboot/coreboot/blob/master/src/mainboard/intel/cannonl...>
>
> coreboot/coreboot
> <https://github.com/coreboot/coreboot/blob/master/src/mainboard/intel/cannonl...>
> github mirror of coreboot.org's master repository. Contribute to
> coreboot/coreboot development by creating an account on GitHub.
> github.com
>
> In case this is not the correct way, the alternative way could be to
> create a UINT8 buff [512] and typecast to
> UpdData->MemDownCh0Dimm0SpdPtr = (UINT32) buff;
> directly.
>
> While I am testing all this, anyone please correct me on the .bin
> part, so that it helps future contributors as well, as its not
> documented anywhere in coreboot.
>
> Regards,
> Naveen
> ------------------------------------------------------------------------
> *From:* David Hendricks <[e-mail]>
> *Sent:* Wednesday, 30 October, 2019, 12:44 PM
> *To:* Naveen Chaudhary
> *Cc:* Wim Vervoorn; Nico Huber; [e-mail]
> *Subject:* Re: [coreboot] Re: Coreboot FSP fails to initialize RAM -
> "Configuration not in POR table"
>
> Hi Naveen,
> Yes, the first sentence. The DIMMs you are using appear to have
> geometry or timings incompatible with Broadwell-DE, based on the SPD
> values that the vendor programmed. Chapter 6 of the PDG (docid 543448)
> should help clarify what kinds of DIMMs are supported and how they
> should be populated.
>
> On Tue, Oct 29, 2019 at 5:07 AM Naveen Chaudhary
> <[e-mail]
> <mailto:[e-mail]>> wrote:
>
> Sorry I didn't get the point completely. Do you mean the settings
>     are not compatible with FSP code? Or do you mean the settings
>     might be conflicting themselves.
>
> Since the above settings were read from SPD and the chip vendor
>     must have definitely set them correctly, I assume you meant first
>     sentence.
>
> Please correct me.
>
> Regards,
>     Naveen
>
> Get Outlook for Android <https://aka.ms/ghei36>
>
> ------------------------------------------------------------------------
>     *From:* Wim Vervoorn <[e-mail]
>     <mailto:[e-mail]>>
>     *Sent:* Tuesday, October 29, 2019 3:47:34 PM
>     *To:* Naveen Chaudhary <[e-mail]
>     <mailto:[e-mail]>>; Nico Huber
>     <[e-mail] <mailto:[e-mail]>>; David Hendricks
>     <[e-mail] <mailto:[e-mail]>>
>     *Cc:* [e-mail] <mailto:[e-mail]>
>     <[e-mail] <mailto:[e-mail]>>
>     *Subject:* RE: [coreboot] Re: Coreboot FSP fails to initialize RAM
>     - "Configuration not in POR table"
>      
>
> Hello Naveen,
>
>  
>
> This is the important part. This indicates the what you selected
>     is not supported.
>
>  
>
> Please review your settings carefully. This isn't a single check.
>     The code validates the SPD settings against the other settings you
>     made.
>
> So please make sure you are passing in a DDR4 SPD when you select
>     DDR4 mode. Also please make sure the SPD settings are in
>
> The list of supported configuration for the chip.
>
>  
>
> Check POR Compatibility -- Started
>
> primaryWidthDDR4: 1, rowBitsDDR4: 16, columnBitsDDR4: 10,
>     bankGroupsDDR4: 4
>
> primaryWidthDDR4: 1, rowBitsDDR4: 16, columnBitsDDR4: 10,
>     bankGroupsDDR4: 4
>
> Unknown DIMM population *****
>
> Check POR Compatibility - 17ms
>
> Initialize DDR Clocks -- Started
>
> Checkpoint Code: Socket 0, 0xB1, 0x00, 0x0000
>
> Configuration not in POR table!  *** (This basically indicates you
>     are trying to do something that is not supported by the chipset).
>
>  
>
> Best regards,
>
> Wim
>
>  
>
> *From:*Naveen Chaudhary [mailto:[e-mail]
>     <mailto:[e-mail]>]
>     *Sent:* Tuesday, October 29, 2019 10:44 AM
>     *To:* Wim Vervoorn <[e-mail]
>     <mailto:[e-mail]>>; Nico Huber <[e-mail]
>     <mailto:[e-mail]>>; David Hendricks
>     <[e-mail] <mailto:[e-mail]>>
>     *Cc:* [e-mail] <mailto:[e-mail]>
>     *Subject:* Re: [coreboot] Re: Coreboot FSP fails to initialize RAM
>     - "Configuration not in POR table"
>
>  
>
> Thanks Wim.
>
> I will give a try and pass a 512 byte hex block corresponding to
>     the SPD data and if it works, I can play with the hex values to
>     find out the right configuration.
>
> BTW, any idea which field can impact the ddrfreq which was
>     reported as error in the initial logs?
>
> Regards,
>
> Naveen
>
> Get Outlook for Android <https://aka.ms/ghei36>
>
>  
>
> ------------------------------------------------------------------------
>
> *From:*Wim Vervoorn <[e-mail] <mailto:[e-mail]>>
>     *Sent:* Tuesday, October 29, 2019 3:07:44 PM
>     *To:* Nico Huber <[e-mail] <mailto:[e-mail]>>; Naveen
>     Chaudhary <[e-mail]
>     <mailto:[e-mail]>>; David Hendricks
>     <[e-mail] <mailto:[e-mail]>>
>     *Cc:* [e-mail] <mailto:[e-mail]>
>     <[e-mail] <mailto:[e-mail]>>
>     *Subject:* RE: [coreboot] Re: Coreboot FSP fails to initialize RAM
>     - "Configuration not in POR table"
>
>  
>
> Hello Naveen,
>
> You should use the "MemDownCh0Dimm0SpdPtr" to point to a buffer
>     containing the SPD data and set MemDownEnable" to 1.
>
> Best Regards,
>     Wim Vervoorn
>
> -----Original Message-----
>     From: Nico Huber [mailto:[e-mail]]
>     Sent: Sunday, October 27, 2019 11:33 AM
>     To: Naveen Chaudhary <[e-mail]
>     <mailto:[e-mail]>>; David Hendricks
>     <[e-mail] <mailto:[e-mail]>>
>     Cc: [e-mail] <mailto:[e-mail]>
>     Subject: [coreboot] Re: Coreboot FSP fails to initialize RAM -
>     "Configuration not in POR table"
>
> Hello Naveen,
>
> On 27.10.19 05:02, Naveen Chaudhary wrote:
>     > Does this mean that there is a way in FSP to define custom
>     settings(configs) for DIMMs? In the FSP integration guide for
>     BroadwellDE
>     (https://github.com/IntelFsp/FSP/tree/master/BroadwellDEFspBinPkg/Docs)
>     I don't see any relevant data member where we could define pointer
>     to custom SPD settings or pass individual DIMMs configurations.
>
> there is the memory-down option. It seems undocumented if that
>     does more than switching from on-DIMM SPDs to SPD files. Maybe
>     it's worth a try.
>     If that doesn't work out, you can always overwrite the SPDs on
>     your DIMM's EEPROMs. Always keep a backup, though.
>
> Hope that helps,
>     Nico
>     _______________________________________________
>     coreboot mailing list -- [e-mail]
>     <mailto:[e-mail]> To unsubscribe send an email to
>     [e-mail] <mailto:[e-mail]>
>
> _______________________________________________
> coreboot mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]

[Desimone, Nathaniel L]

On 10/30/2019 3:11 AM, Michal Zygowski wrote:
> Unfortunately it doesn't imply that. Vendor BIOS != FSP. The BIOS vendor
> could obtain different memory initialization code from Intel with some
> bug fixes and it is very likely that it was not propagated back into the
> FSP. This is how this werid system works. Bugs and issues are not
> propagated back into older trees and vendors are creating tons of
> unmaintainable forks for the firmware.

For the newer Intel SOCs (Kaby Lake and newer) I have mostly eliminated this issue. The binaries posted on github.com/IntelFsp are up to date with same version of memory code that the BIOS vendors get for Kaby Lake, Coffee Lake, Amber Lake, Whiskey Lake, Comet Lake, and Ice Lake. The one exception being if the BIOS vendor changes the memory code and doesn't upstream their changes back to Intel. Intel obviously can't do anything about that.

I'm not involved in the development for the Broadwell-DE FSP so unfortunately I can't help on this specific platform.

Regards,

Nate
> Applying the same changed SPD
> parameters may give different results of memory training with FSP and
> vendor BIOS. The best way to go is to get the hands on the papers David
> pointed to (if possible) and do trial-by-error. It may take time but
> there is a chance to succeed. Good thing is you have debug output from
> FSP so at least you know what is wrong.
>
> Regards,
> Michał
> > I found that the flag called FSP_MEMORY_DOWN_CH0DIMM0_SPD_PRESENT is
> > there which I can make use of, to pass an SPD bin. I am not sure how
> > to prepare that binary but I am assuming we can put all the 512 hex
> > bytes of SPD as per DDR4 SPD spec into a text file and name it as
> > spd.bin and pass along. (example :
> > https://github.com/coreboot/coreboot/blob/master/src/mainboard/intel/cannonl...)
> > Coreboot build system will automatically pack it. Compilation passed
> > for me and will test it now, if the SPD data is read properly.
> > <https://github.com/coreboot/coreboot/blob/master/src/mainboard/intel/cannonl...>
> >
> > coreboot/coreboot
> > <https://github.com/coreboot/coreboot/blob/master/src/mainboard/intel/cannonl...>
> > github mirror of coreboot.org's master repository. Contribute to
> > coreboot/coreboot development by creating an account on GitHub.
> > github.com
> >
> > In case this is not the correct way, the alternative way could be to
> > create a UINT8 buff [512] and typecast to
> > UpdData->MemDownCh0Dimm0SpdPtr = (UINT32) buff;
> > directly.
> >
> > While I am testing all this, anyone please correct me on the .bin
> > part, so that it helps future contributors as well, as its not
> > documented anywhere in coreboot.
> >
> > Regards,
> > Naveen
> > ------------------------------------------------------------------------
> > *From:* David Hendricks <[e-mail]>
> > *Sent:* Wednesday, 30 October, 2019, 12:44 PM
> > *To:* Naveen Chaudhary
> > *Cc:* Wim Vervoorn; Nico Huber; [e-mail]
> > *Subject:* Re: [coreboot] Re: Coreboot FSP fails to initialize RAM -
> > "Configuration not in POR table"
> >
> > Hi Naveen,
> > Yes, the first sentence. The DIMMs you are using appear to have
> > geometry or timings incompatible with Broadwell-DE, based on the SPD
> > values that the vendor programmed. Chapter 6 of the PDG (docid 543448)
> > should help clarify what kinds of DIMMs are supported and how they
> > should be populated.
> >
> > On Tue, Oct 29, 2019 at 5:07 AM Naveen Chaudhary
> > <[e-mail]
> > <mailto:[e-mail]>> wrote:
> >
> > Sorry I didn't get the point completely. Do you mean the settings
> >     are not compatible with FSP code? Or do you mean the settings
> >     might be conflicting themselves.
> >
> > Since the above settings were read from SPD and the chip vendor
> >     must have definitely set them correctly, I assume you meant first
> >     sentence.
> >
> > Please correct me.
> >
> > Regards,
> >     Naveen
> >
> > Get Outlook for Android <https://aka.ms/ghei36>
> >
> > ------------------------------------------------------------------------
> >     *From:* Wim Vervoorn <[e-mail]
> >     <mailto:[e-mail]>>
> >     *Sent:* Tuesday, October 29, 2019 3:47:34 PM
> >     *To:* Naveen Chaudhary <[e-mail]
> >     <mailto:[e-mail]>>; Nico Huber
> >     <[e-mail] <mailto:[e-mail]>>; David Hendricks
> >     <[e-mail] <mailto:[e-mail]>>
> >     *Cc:* [e-mail] <mailto:[e-mail]>
> >     <[e-mail] <mailto:[e-mail]>>
> >     *Subject:* RE: [coreboot] Re: Coreboot FSP fails to initialize RAM
> >     - "Configuration not in POR table"
> >      
> >
> > Hello Naveen,
> >
> >  
> >
> > This is the important part. This indicates the what you selected
> >     is not supported.
> >
> >  
> >
> > Please review your settings carefully. This isn't a single check.
> >     The code validates the SPD settings against the other settings you
> >     made.
> >
> > So please make sure you are passing in a DDR4 SPD when you select
> >     DDR4 mode. Also please make sure the SPD settings are in
> >
> > The list of supported configuration for the chip.
> >
> >  
> >
> > Check POR Compatibility -- Started
> >
> > primaryWidthDDR4: 1, rowBitsDDR4: 16, columnBitsDDR4: 10,
> >     bankGroupsDDR4: 4
> >
> > primaryWidthDDR4: 1, rowBitsDDR4: 16, columnBitsDDR4: 10,
> >     bankGroupsDDR4: 4
> >
> > Unknown DIMM population *****
> >
> > Check POR Compatibility - 17ms
> >
> > Initialize DDR Clocks -- Started
> >
> > Checkpoint Code: Socket 0, 0xB1, 0x00, 0x0000
> >
> > Configuration not in POR table!  *** (This basically indicates you
> >     are trying to do something that is not supported by the chipset).
> >
> >  
> >
> > Best regards,
> >
> > Wim
> >
> >  
> >
> > *From:*Naveen Chaudhary [mailto:[e-mail]
> >     <mailto:[e-mail]>]
> >     *Sent:* Tuesday, October 29, 2019 10:44 AM
> >     *To:* Wim Vervoorn <[e-mail]
> >     <mailto:[e-mail]>>; Nico Huber <[e-mail]
> >     <mailto:[e-mail]>>; David Hendricks
> >     <[e-mail] <mailto:[e-mail]>>
> >     *Cc:* [e-mail] <mailto:[e-mail]>
> >     *Subject:* Re: [coreboot] Re: Coreboot FSP fails to initialize RAM
> >     - "Configuration not in POR table"
> >
> >  
> >
> > Thanks Wim.
> >
> > I will give a try and pass a 512 byte hex block corresponding to
> >     the SPD data and if it works, I can play with the hex values to
> >     find out the right configuration.
> >
> > BTW, any idea which field can impact the ddrfreq which was
> >     reported as error in the initial logs?
> >
> > Regards,
> >
> > Naveen
> >
> > Get Outlook for Android <https://aka.ms/ghei36>
> >
> >  
> >
> > ------------------------------------------------------------------------
> >
> > *From:*Wim Vervoorn <[e-mail] <mailto:[e-mail]>>
> >     *Sent:* Tuesday, October 29, 2019 3:07:44 PM
> >     *To:* Nico Huber <[e-mail] <mailto:[e-mail]>>; Naveen
> >     Chaudhary <[e-mail]
> >     <mailto:[e-mail]>>; David Hendricks
> >     <[e-mail] <mailto:[e-mail]>>
> >     *Cc:* [e-mail] <mailto:[e-mail]>
> >     <[e-mail] <mailto:[e-mail]>>
> >     *Subject:* RE: [coreboot] Re: Coreboot FSP fails to initialize RAM
> >     - "Configuration not in POR table"
> >
> >  
> >
> > Hello Naveen,
> >
> > You should use the "MemDownCh0Dimm0SpdPtr" to point to a buffer
> >     containing the SPD data and set MemDownEnable" to 1.
> >
> > Best Regards,
> >     Wim Vervoorn
> >
> > -----Original Message-----
> >     From: Nico Huber [mailto:[e-mail]]
> >     Sent: Sunday, October 27, 2019 11:33 AM
> >     To: Naveen Chaudhary <[e-mail]
> >     <mailto:[e-mail]>>; David Hendricks
> >     <[e-mail] <mailto:[e-mail]>>
> >     Cc: [e-mail] <mailto:[e-mail]>
> >     Subject: [coreboot] Re: Coreboot FSP fails to initialize RAM -
> >     "Configuration not in POR table"
> >
> > Hello Naveen,
> >
> > On 27.10.19 05:02, Naveen Chaudhary wrote:
> >     > Does this mean that there is a way in FSP to define custom
> >     settings(configs) for DIMMs? In the FSP integration guide for
> >     BroadwellDE
> >     (https://github.com/IntelFsp/FSP/tree/master/BroadwellDEFspBinPkg/Docs)
> >     I don't see any relevant data member where we could define pointer
> >     to custom SPD settings or pass individual DIMMs configurations.
> >
> > there is the memory-down option. It seems undocumented if that
> >     does more than switching from on-DIMM SPDs to SPD files. Maybe
> >     it's worth a try.
> >     If that doesn't work out, you can always overwrite the SPDs on
> >     your DIMM's EEPROMs. Always keep a backup, though.
> >
> > Hope that helps,
> >     Nico
> >     _______________________________________________
> >     coreboot mailing list -- [e-mail]
> >     <mailto:[e-mail]> To unsubscribe send an email to
> >     [e-mail] <mailto:[e-mail]>
> >
> > _______________________________________________
> > coreboot mailing list -- [e-mail]
> > To unsubscribe send an email to [e-mail]
>
> _______________________________________________
> coreboot mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]

[Michal Zygowski]

On 31.10.2019 03:13, Desimone, Nathaniel L wrote:
> On 10/30/2019 3:11 AM, Michal Zygowski wrote:
> > Unfortunately it doesn't imply that. Vendor BIOS != FSP. The BIOS vendor
> > could obtain different memory initialization code from Intel with some
> > bug fixes and it is very likely that it was not propagated back into the
> > FSP. This is how this werid system works. Bugs and issues are not
> > propagated back into older trees and vendors are creating tons of
> > unmaintainable forks for the firmware.
> > For the newer Intel SOCs (Kaby Lake and newer) I have mostly eliminated this issue. The binaries posted on github.com/IntelFsp are up to date with same version of memory code that the BIOS vendors get for Kaby Lake, Coffee Lake, Amber Lake, Whiskey Lake, Comet Lake, and Ice Lake. The one exception being if the BIOS vendor changes the memory code and doesn't upstream their changes back to Intel. Intel obviously can't do anything about that.
>
> I'm not involved in the development for the Broadwell-DE FSP so unfortunately I can't help on this specific platform.
>
> Regards,
>
> Nate
> I'm not blaming Intel. As you said Nate, there is nothing you can do.
> Just pointing out that "vendors are creating tons of forks" where by
> vendor I had IBVs in mind (in some particular cases Intel may be an IBV,
> but this time I implicitly excluded Intel as IBV, sorry I didn't clarify).

Regards,
Michał
> > Applying the same changed SPD
> > parameters may give different results of memory training with FSP and
> > vendor BIOS. The best way to go is to get the hands on the papers David
> > pointed to (if possible) and do trial-by-error. It may take time but
> > there is a chance to succeed. Good thing is you have debug output from
> > FSP so at least you know what is wrong.
> >
> > Regards,
> > Michał
> > > I found that the flag called FSP_MEMORY_DOWN_CH0DIMM0_SPD_PRESENT is
> > > there which I can make use of, to pass an SPD bin. I am not sure how
> > > to prepare that binary but I am assuming we can put all the 512 hex
> > > bytes of SPD as per DDR4 SPD spec into a text file and name it as
> > > spd.bin and pass along. (example :
> > > https://github.com/coreboot/coreboot/blob/master/src/mainboard/intel/cannonl...)
> > > Coreboot build system will automatically pack it. Compilation passed
> > > for me and will test it now, if the SPD data is read properly.
> > > <https://github.com/coreboot/coreboot/blob/master/src/mainboard/intel/cannonl...>
> > >
> > > coreboot/coreboot
> > > <https://github.com/coreboot/coreboot/blob/master/src/mainboard/intel/cannonl...>
> > > github mirror of coreboot.org's master repository. Contribute to
> > > coreboot/coreboot development by creating an account on GitHub.
> > > github.com
> > >
> > > In case this is not the correct way, the alternative way could be to
> > > create a UINT8 buff [512] and typecast to
> > > UpdData->MemDownCh0Dimm0SpdPtr = (UINT32) buff;
> > > directly.
> > >
> > > While I am testing all this, anyone please correct me on the .bin
> > > part, so that it helps future contributors as well, as its not
> > > documented anywhere in coreboot.
> > >
> > > Regards,
> > > Naveen
> > > ------------------------------------------------------------------------
> > > *From:* David Hendricks <[e-mail]>
> > > *Sent:* Wednesday, 30 October, 2019, 12:44 PM
> > > *To:* Naveen Chaudhary
> > > *Cc:* Wim Vervoorn; Nico Huber; [e-mail]
> > > *Subject:* Re: [coreboot] Re: Coreboot FSP fails to initialize RAM -
> > > "Configuration not in POR table"
> > >
> > > Hi Naveen,
> > > Yes, the first sentence. The DIMMs you are using appear to have
> > > geometry or timings incompatible with Broadwell-DE, based on the SPD
> > > values that the vendor programmed. Chapter 6 of the PDG (docid 543448)
> > > should help clarify what kinds of DIMMs are supported and how they
> > > should be populated.
> > >
> > > On Tue, Oct 29, 2019 at 5:07 AM Naveen Chaudhary
> > > <[e-mail]
> > > <mailto:[e-mail]>> wrote:
> > >
> > > Sorry I didn't get the point completely. Do you mean the settings
> > >     are not compatible with FSP code? Or do you mean the settings
> > >     might be conflicting themselves.
> > >
> > > Since the above settings were read from SPD and the chip vendor
> > >     must have definitely set them correctly, I assume you meant first
> > >     sentence.
> > >
> > > Please correct me.
> > >
> > > Regards,
> > >     Naveen
> > >
> > > Get Outlook for Android <https://aka.ms/ghei36>
> > >
> > > ------------------------------------------------------------------------
> > >     *From:* Wim Vervoorn <[e-mail]
> > >     <mailto:[e-mail]>>
> > >     *Sent:* Tuesday, October 29, 2019 3:47:34 PM
> > >     *To:* Naveen Chaudhary <[e-mail]
> > >     <mailto:[e-mail]>>; Nico Huber
> > >     <[e-mail] <mailto:[e-mail]>>; David Hendricks
> > >     <[e-mail] <mailto:[e-mail]>>
> > >     *Cc:* [e-mail] <mailto:[e-mail]>
> > >     <[e-mail] <mailto:[e-mail]>>
> > >     *Subject:* RE: [coreboot] Re: Coreboot FSP fails to initialize RAM
> > >     - "Configuration not in POR table"
> > >      
> > >
> > > Hello Naveen,
> > >
> > >  
> > >
> > > This is the important part. This indicates the what you selected
> > >     is not supported.
> > >
> > >  
> > >
> > > Please review your settings carefully. This isn't a single check.
> > >     The code validates the SPD settings against the other settings you
> > >     made.
> > >
> > > So please make sure you are passing in a DDR4 SPD when you select
> > >     DDR4 mode. Also please make sure the SPD settings are in
> > >
> > > The list of supported configuration for the chip.
> > >
> > >  
> > >
> > > Check POR Compatibility -- Started
> > >
> > > primaryWidthDDR4: 1, rowBitsDDR4: 16, columnBitsDDR4: 10,
> > >     bankGroupsDDR4: 4
> > >
> > > primaryWidthDDR4: 1, rowBitsDDR4: 16, columnBitsDDR4: 10,
> > >     bankGroupsDDR4: 4
> > >
> > > Unknown DIMM population *****
> > >
> > > Check POR Compatibility - 17ms
> > >
> > > Initialize DDR Clocks -- Started
> > >
> > > Checkpoint Code: Socket 0, 0xB1, 0x00, 0x0000
> > >
> > > Configuration not in POR table!  *** (This basically indicates you
> > >     are trying to do something that is not supported by the chipset).
> > >
> > >  
> > >
> > > Best regards,
> > >
> > > Wim
> > >
> > >  
> > >
> > > *From:*Naveen Chaudhary [mailto:[e-mail]
> > >     <mailto:[e-mail]>]
> > >     *Sent:* Tuesday, October 29, 2019 10:44 AM
> > >     *To:* Wim Vervoorn <[e-mail]
> > >     <mailto:[e-mail]>>; Nico Huber <[e-mail]
> > >     <mailto:[e-mail]>>; David Hendricks
> > >     <[e-mail] <mailto:[e-mail]>>
> > >     *Cc:* [e-mail] <mailto:[e-mail]>
> > >     *Subject:* Re: [coreboot] Re: Coreboot FSP fails to initialize RAM
> > >     - "Configuration not in POR table"
> > >
> > >  
> > >
> > > Thanks Wim.
> > >
> > > I will give a try and pass a 512 byte hex block corresponding to
> > >     the SPD data and if it works, I can play with the hex values to
> > >     find out the right configuration.
> > >
> > > BTW, any idea which field can impact the ddrfreq which was
> > >     reported as error in the initial logs?
> > >
> > > Regards,
> > >
> > > Naveen
> > >
> > > Get Outlook for Android <https://aka.ms/ghei36>
> > >
> > >  
> > >
> > > ------------------------------------------------------------------------
> > >
> > > *From:*Wim Vervoorn <[e-mail] <mailto:[e-mail]>>
> > >     *Sent:* Tuesday, October 29, 2019 3:07:44 PM
> > >     *To:* Nico Huber <[e-mail] <mailto:[e-mail]>>; Naveen
> > >     Chaudhary <[e-mail]
> > >     <mailto:[e-mail]>>; David Hendricks
> > >     <[e-mail] <mailto:[e-mail]>>
> > >     *Cc:* [e-mail] <mailto:[e-mail]>
> > >     <[e-mail] <mailto:[e-mail]>>
> > >     *Subject:* RE: [coreboot] Re: Coreboot FSP fails to initialize RAM
> > >     - "Configuration not in POR table"
> > >
> > >  
> > >
> > > Hello Naveen,
> > >
> > > You should use the "MemDownCh0Dimm0SpdPtr" to point to a buffer
> > >     containing the SPD data and set MemDownEnable" to 1.
> > >
> > > Best Regards,
> > >     Wim Vervoorn
> > >
> > > -----Original Message-----
> > >     From: Nico Huber [mailto:[e-mail]]
> > >     Sent: Sunday, October 27, 2019 11:33 AM
> > >     To: Naveen Chaudhary <[e-mail]
> > >     <mailto:[e-mail]>>; David Hendricks
> > >     <[e-mail] <mailto:[e-mail]>>
> > >     Cc: [e-mail] <mailto:[e-mail]>
> > >     Subject: [coreboot] Re: Coreboot FSP fails to initialize RAM -
> > >     "Configuration not in POR table"
> > >
> > > Hello Naveen,
> > >
> > > On 27.10.19 05:02, Naveen Chaudhary wrote:
> > >     > Does this mean that there is a way in FSP to define custom
> > >     settings(configs) for DIMMs? In the FSP integration guide for
> > >     BroadwellDE
> > >     (https://github.com/IntelFsp/FSP/tree/master/BroadwellDEFspBinPkg/Docs)
> > >     I don't see any relevant data member where we could define pointer
> > >     to custom SPD settings or pass individual DIMMs configurations.
> > >
> > > there is the memory-down option. It seems undocumented if that
> > >     does more than switching from on-DIMM SPDs to SPD files. Maybe
> > >     it's worth a try.
> > >     If that doesn't work out, you can always overwrite the SPDs on
> > >     your DIMM's EEPROMs. Always keep a backup, though.
> > >
> > > Hope that helps,
> > >     Nico
> > >     _______________________________________________
> > >     coreboot mailing list -- [e-mail]
> > >     <mailto:[e-mail]> To unsubscribe send an email to
> > >     [e-mail] <mailto:[e-mail]>
> > >
> > > _______________________________________________
> > > coreboot mailing list -- [e-mail]
> > > To unsubscribe send an email to [e-mail]
> >
> > coreboot mailing list -- [e-mail]
> > To unsubscribe send an email to [e-mail]
>
> coreboot mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]

[Naveen Chaudhary]

Hope I am not over-populating the mailing list (please let me know if I am). Hope this thread helps someone in future starting on DIMM initialization like me.

So temporarily I put the SPD buff inside the fsp_early_init and set the UPD SPD pointer :
UpdData->MemDownCh0Dimm0SpdPtr = (UINT32) buff;
just before calling FSP_FSP_INIT.

I was able to get the same values in the logs as the FSP was reading from SPD earlier. This implies at least my SPD buff is getting passed perfectly. I decided to do a second test by passing a random SPD hex just to check if the behaviour changes which will imply that I can also play with the bits in the same local SPD buffer now and physical SPD chip on RAM has no role now. So I took this hex : https://github.com/coreboot/coreboot/blob/master/src/mainboard/intel/cannonl... and passed along.

To my surprise, this time it did not fail after GetPORDDRFreq( ) but instead went long way, until it failed with message "All channels disabled due to Memory Test failures!" which is expected since the channel/rank/etc settings are different for this chip.

Out of excitement, I went on to take the diff of the 2 SPD hex and there are not much differences. Since I have never worked on RAM init before, so I am thinking to study the diff bits referring the DDR4 SPD spec and try toggling them one by one. Its gonna take time but I believe I would definitely have some great takeaway.

But is there a possibility that at the end after I have tried all the settings, the FSP might still not be able to initialize the RAM and I have to give up using coreboot on this motherboard (or try with different RAM stick)? Michal's point is definitely important and makes sense. At the same time, I maybe wrong though, I am hopeful that we can make any RAM stick behave in a compatible manner by proper configuration.

Regards,
Naveen

________________________________
From: Michal Zygowski <[e-mail]>
Sent: Thursday, October 31, 2019 3:38 PM
To: [e-mail] <[e-mail]>
Subject: [coreboot] Re: Coreboot FSP fails to initialize RAM - "Configuration not in POR table"


On 31.10.2019 03:13, Desimone, Nathaniel L wrote:
> On 10/30/2019 3:11 AM, Michal Zygowski wrote:
> > Unfortunately it doesn't imply that. Vendor BIOS != FSP. The BIOS vendor
> > could obtain different memory initialization code from Intel with some
> > bug fixes and it is very likely that it was not propagated back into the
> > FSP. This is how this werid system works. Bugs and issues are not
> > propagated back into older trees and vendors are creating tons of
> > unmaintainable forks for the firmware.
> > For the newer Intel SOCs (Kaby Lake and newer) I have mostly eliminated this issue. The binaries posted on github.com/IntelFsp are up to date with same version of memory code that the BIOS vendors get for Kaby Lake, Coffee Lake, Amber Lake, Whiskey Lake, Comet Lake, and Ice Lake. The one exception being if the BIOS vendor changes the memory code and doesn't upstream their changes back to Intel. Intel obviously can't do anything about that.
>
> I'm not involved in the development for the Broadwell-DE FSP so unfortunately I can't help on this specific platform.
>
> Regards,
>
> Nate
> I'm not blaming Intel. As you said Nate, there is nothing you can do.
> Just pointing out that "vendors are creating tons of forks" where by
> vendor I had IBVs in mind (in some particular cases Intel may be an IBV,
> but this time I implicitly excluded Intel as IBV, sorry I didn't clarify).

Regards,
Michał
> > Applying the same changed SPD
> > parameters may give different results of memory training with FSP and
> > vendor BIOS. The best way to go is to get the hands on the papers David
> > pointed to (if possible) and do trial-by-error. It may take time but
> > there is a chance to succeed. Good thing is you have debug output from
> > FSP so at least you know what is wrong.
> >
> > Regards,
> > Michał
> > > I found that the flag called FSP_MEMORY_DOWN_CH0DIMM0_SPD_PRESENT is
> > > there which I can make use of, to pass an SPD bin. I am not sure how
> > > to prepare that binary but I am assuming we can put all the 512 hex
> > > bytes of SPD as per DDR4 SPD spec into a text file and name it as
> > > spd.bin and pass along. (example :
> > > https://github.com/coreboot/coreboot/blob/master/src/mainboard/intel/cannonl...)
> > > Coreboot build system will automatically pack it. Compilation passed
> > > for me and will test it now, if the SPD data is read properly.
> > > <https://github.com/coreboot/coreboot/blob/master/src/mainboard/intel/cannonl...>
> > >
> > > coreboot/coreboot
> > > <https://github.com/coreboot/coreboot/blob/master/src/mainboard/intel/cannonl...>
> > > github mirror of coreboot.org's master repository. Contribute to
> > > coreboot/coreboot development by creating an account on GitHub.
> > > github.com
> > >
> > > In case this is not the correct way, the alternative way could be to
> > > create a UINT8 buff [512] and typecast to
> > > UpdData->MemDownCh0Dimm0SpdPtr = (UINT32) buff;
> > > directly.
> > >
> > > While I am testing all this, anyone please correct me on the .bin
> > > part, so that it helps future contributors as well, as its not
> > > documented anywhere in coreboot.
> > >
> > > Regards,
> > > Naveen
> > > ------------------------------------------------------------------------
> > > *From:* David Hendricks <[e-mail]>
> > > *Sent:* Wednesday, 30 October, 2019, 12:44 PM
> > > *To:* Naveen Chaudhary
> > > *Cc:* Wim Vervoorn; Nico Huber; [e-mail]
> > > *Subject:* Re: [coreboot] Re: Coreboot FSP fails to initialize RAM -
> > > "Configuration not in POR table"
> > >
> > > Hi Naveen,
> > > Yes, the first sentence. The DIMMs you are using appear to have
> > > geometry or timings incompatible with Broadwell-DE, based on the SPD
> > > values that the vendor programmed. Chapter 6 of the PDG (docid 543448)
> > > should help clarify what kinds of DIMMs are supported and how they
> > > should be populated.
> > >
> > > On Tue, Oct 29, 2019 at 5:07 AM Naveen Chaudhary
> > > <[e-mail]
> > > <mailto:[e-mail]>> wrote:
> > >
> > > Sorry I didn't get the point completely. Do you mean the settings
> > >     are not compatible with FSP code? Or do you mean the settings
> > >     might be conflicting themselves.
> > >
> > > Since the above settings were read from SPD and the chip vendor
> > >     must have definitely set them correctly, I assume you meant first
> > >     sentence.
> > >
> > > Please correct me.
> > >
> > > Regards,
> > >     Naveen
> > >
> > > Get Outlook for Android <https://aka.ms/ghei36>
> > >
> > > ------------------------------------------------------------------------
> > >     *From:* Wim Vervoorn <[e-mail]
> > >     <mailto:[e-mail]>>
> > >     *Sent:* Tuesday, October 29, 2019 3:47:34 PM
> > >     *To:* Naveen Chaudhary <[e-mail]
> > >     <mailto:[e-mail]>>; Nico Huber
> > >     <[e-mail] <mailto:[e-mail]>>; David Hendricks
> > >     <[e-mail] <mailto:[e-mail]>>
> > >     *Cc:* [e-mail] <mailto:[e-mail]>
> > >     <[e-mail] <mailto:[e-mail]>>
> > >     *Subject:* RE: [coreboot] Re: Coreboot FSP fails to initialize RAM
> > >     - "Configuration not in POR table"
> > >
> > > Hello Naveen,
> > >
> > > This is the important part. This indicates the what you selected
> > >     is not supported.
> > >
> > > Please review your settings carefully. This isn't a single check.
> > >     The code validates the SPD settings against the other settings you
> > >     made.
> > >
> > > So please make sure you are passing in a DDR4 SPD when you select
> > >     DDR4 mode. Also please make sure the SPD settings are in
> > >
> > > The list of supported configuration for the chip.
> > >
> > > Check POR Compatibility -- Started
> > >
> > > primaryWidthDDR4: 1, rowBitsDDR4: 16, columnBitsDDR4: 10,
> > >     bankGroupsDDR4: 4
> > >
> > > primaryWidthDDR4: 1, rowBitsDDR4: 16, columnBitsDDR4: 10,
> > >     bankGroupsDDR4: 4
> > >
> > > Unknown DIMM population *****
> > >
> > > Check POR Compatibility - 17ms
> > >
> > > Initialize DDR Clocks -- Started
> > >
> > > Checkpoint Code: Socket 0, 0xB1, 0x00, 0x0000
> > >
> > > Configuration not in POR table!  *** (This basically indicates you
> > >     are trying to do something that is not supported by the chipset).
> > >
> > > Best regards,
> > >
> > > Wim
> > >
> > > *From:*Naveen Chaudhary [mailto:[e-mail]
> > >     <mailto:[e-mail]>]
> > >     *Sent:* Tuesday, October 29, 2019 10:44 AM
> > >     *To:* Wim Vervoorn <[e-mail]
> > >     <mailto:[e-mail]>>; Nico Huber <[e-mail]
> > >     <mailto:[e-mail]>>; David Hendricks
> > >     <[e-mail] <mailto:[e-mail]>>
> > >     *Cc:* [e-mail] <mailto:[e-mail]>
> > >     *Subject:* Re: [coreboot] Re: Coreboot FSP fails to initialize RAM
> > >     - "Configuration not in POR table"
> > >
> > > Thanks Wim.
> > >
> > > I will give a try and pass a 512 byte hex block corresponding to
> > >     the SPD data and if it works, I can play with the hex values to
> > >     find out the right configuration.
> > >
> > > BTW, any idea which field can impact the ddrfreq which was
> > >     reported as error in the initial logs?
> > >
> > > Regards,
> > >
> > > Naveen
> > >
> > > Get Outlook for Android <https://aka.ms/ghei36>
> > >
> > > ------------------------------------------------------------------------
> > >
> > > *From:*Wim Vervoorn <[e-mail] <mailto:[e-mail]>>
> > >     *Sent:* Tuesday, October 29, 2019 3:07:44 PM
> > >     *To:* Nico Huber <[e-mail] <mailto:[e-mail]>>; Naveen
> > >     Chaudhary <[e-mail]
> > >     <mailto:[e-mail]>>; David Hendricks
> > >     <[e-mail] <mailto:[e-mail]>>
> > >     *Cc:* [e-mail] <mailto:[e-mail]>
> > >     <[e-mail] <mailto:[e-mail]>>
> > >     *Subject:* RE: [coreboot] Re: Coreboot FSP fails to initialize RAM
> > >     - "Configuration not in POR table"
> > >
> > > Hello Naveen,
> > >
> > > You should use the "MemDownCh0Dimm0SpdPtr" to point to a buffer
> > >     containing the SPD data and set MemDownEnable" to 1.
> > >
> > > Best Regards,
> > >     Wim Vervoorn
> > >
> > > -----Original Message-----
> > >     From: Nico Huber [mailto:[e-mail]]
> > >     Sent: Sunday, October 27, 2019 11:33 AM
> > >     To: Naveen Chaudhary <[e-mail]
> > >     <mailto:[e-mail]>>; David Hendricks
> > >     <[e-mail] <mailto:[e-mail]>>
> > >     Cc: [e-mail] <mailto:[e-mail]>
> > >     Subject: [coreboot] Re: Coreboot FSP fails to initialize RAM -
> > >     "Configuration not in POR table"
> > >
> > > Hello Naveen,
> > >
> > > On 27.10.19 05:02, Naveen Chaudhary wrote:
> > >     > Does this mean that there is a way in FSP to define custom
> > >     settings(configs) for DIMMs? In the FSP integration guide for
> > >     BroadwellDE
> > >     (https://github.com/IntelFsp/FSP/tree/master/BroadwellDEFspBinPkg/Docs)
> > >     I don't see any relevant data member where we could define pointer
> > >     to custom SPD settings or pass individual DIMMs configurations.
> > >
> > > there is the memory-down option. It seems undocumented if that
> > >     does more than switching from on-DIMM SPDs to SPD files. Maybe
> > >     it's worth a try.
> > >     If that doesn't work out, you can always overwrite the SPDs on
> > >     your DIMM's EEPROMs. Always keep a backup, though.
> > >
> > > Hope that helps,
> > >     Nico
> > >     _______________________________________________
> > >     coreboot mailing list -- [e-mail]
> > >     <mailto:[e-mail]> To unsubscribe send an email to
> > >     [e-mail] <mailto:[e-mail]>
> > >
> > > _______________________________________________
> > > coreboot mailing list -- [e-mail]
> > > To unsubscribe send an email to [e-mail]
> >
> > coreboot mailing list -- [e-mail]
> > To unsubscribe send an email to [e-mail]
>
> coreboot mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]

[Desimone, Nathaniel L]

On 10/31/2019 3:08 AM, Michal Zygowski wrote:
> I'm not blaming Intel. As you said Nate, there is nothing you can do.
> Just pointing out that "vendors are creating tons of forks" where by
> vendor I had IBVs in mind (in some particular cases Intel may be an IBV,
> but this time I implicitly excluded Intel as IBV, sorry I didn't clarify).
>
> Regards,
> Michał

We are very aware of this issue, and we are trying very hard to reduce fragmentation in the firmware ecosystem for products based on Intel platforms.

Just to give a little more context on this, none of the IBVs actually implement the memory code from scratch anymore. Starting roughly in the Westmere/Sandy Bridge time-frame, everyone took Intel's memory code as a baseline and then started modifying on top of that. Starting with Haswell, that expanded from just memory code to all of the SOC initialization code. Also starting with Haswell, we changed our message that modification of the SOC initialization code was actively discouraged. Conversely, we actively encouraged upsteaming of changes in the SOC initialization code back to Intel. This shift created the preconditions necessary for the FSP to be created. The next big change came with Sky Lake, where we made a requirement that all the BIOS vendors moved from their custom implementation of EDK1 to the single open source EDK2 implementation developed by the TianoCore project.

For the newer Intel SOCs, there should be very little difference between the memory code provided by Intel and the memory code provided by other BIOS vendors. That said, we have noticed that some of the BIOS vendors hoard bugs.

Fast forward to today, we are encouraging all BIOS vendors to not only use FSP, but to use FSP binaries published by Intel directly. If and when we reach that goal, then the issues you mention about some BIOS vendors having a different fork of the memory code than what FSP has should go away.

In parallel, one of the primary criticisms of the TianoCore project is that nobody contributes a complete firmware implementation, just bits and pieces. We are working hard to change that. We have a new sub-project in TianoCore called "Minimum Platform" which aims to provide a complete, open source, lightweight, and modular UEFI firmware implementation purely based on EDK2 and FSP. Unlike past efforts, we are focused on hardware that you can actually buy, not just Intel reference boards or difficult to acquire small board computers. We are trying to build something that is actually useful for the community. Its still alpha stage at the moment; and we only have 6 motherboards and 3 chipsets supported thus far but we are trying to grow that list. If you are interested, here is the overview: https://osfc.io/talks/minimum-platform-open-source-uefi-firmware-for-intel-b... and the code: https://github.com/tianocore/edk2-platforms/tree/master/Platform/Intel . In time, our
hope is that Minimum Platform provides a viable alternative for the industry.

With Best Regards,

Nate
> > > Applying the same changed SPD
> > > parameters may give different results of memory training with FSP and
> > > vendor BIOS. The best way to go is to get the hands on the papers David
> > > pointed to (if possible) and do trial-by-error. It may take time but
> > > there is a chance to succeed. Good thing is you have debug output from
> > > FSP so at least you know what is wrong.
> > >
> > > Regards,
> > > Michał
> > > > I found that the flag called FSP_MEMORY_DOWN_CH0DIMM0_SPD_PRESENT is
> > > > there which I can make use of, to pass an SPD bin. I am not sure how
> > > > to prepare that binary but I am assuming we can put all the 512 hex
> > > > bytes of SPD as per DDR4 SPD spec into a text file and name it as
> > > > spd.bin and pass along. (example :
> > > > https://github.com/coreboot/coreboot/blob/master/src/mainboard/intel/cannonl...)
> > > > Coreboot build system will automatically pack it. Compilation passed
> > > > for me and will test it now, if the SPD data is read properly.
> > > > <https://github.com/coreboot/coreboot/blob/master/src/mainboard/intel/cannonl...>
> > > >
> > > > coreboot/coreboot
> > > > <https://github.com/coreboot/coreboot/blob/master/src/mainboard/intel/cannonl...>
> > > > github mirror of coreboot.org's master repository. Contribute to
> > > > coreboot/coreboot development by creating an account on GitHub.
> > > > github.com
> > > >
> > > > In case this is not the correct way, the alternative way could be to
> > > > create a UINT8 buff [512] and typecast to
> > > > UpdData->MemDownCh0Dimm0SpdPtr = (UINT32) buff;
> > > > directly.
> > > >
> > > > While I am testing all this, anyone please correct me on the .bin
> > > > part, so that it helps future contributors as well, as its not
> > > > documented anywhere in coreboot.
> > > >
> > > > Regards,
> > > > Naveen
> > > > ------------------------------------------------------------------------
> > > > *From:* David Hendricks <[e-mail]>
> > > > *Sent:* Wednesday, 30 October, 2019, 12:44 PM
> > > > *To:* Naveen Chaudhary
> > > > *Cc:* Wim Vervoorn; Nico Huber; [e-mail]
> > > > *Subject:* Re: [coreboot] Re: Coreboot FSP fails to initialize RAM -
> > > > "Configuration not in POR table"
> > > >
> > > > Hi Naveen,
> > > > Yes, the first sentence. The DIMMs you are using appear to have
> > > > geometry or timings incompatible with Broadwell-DE, based on the SPD
> > > > values that the vendor programmed. Chapter 6 of the PDG (docid 543448)
> > > > should help clarify what kinds of DIMMs are supported and how they
> > > > should be populated.
> > > >
> > > > On Tue, Oct 29, 2019 at 5:07 AM Naveen Chaudhary
> > > > <[e-mail]
> > > > <mailto:[e-mail]>> wrote:
> > > >
> > > > Sorry I didn't get the point completely. Do you mean the settings
> > > >     are not compatible with FSP code? Or do you mean the settings
> > > >     might be conflicting themselves.
> > > >
> > > > Since the above settings were read from SPD and the chip vendor
> > > >     must have definitely set them correctly, I assume you meant first
> > > >     sentence.
> > > >
> > > > Please correct me.
> > > >
> > > > Regards,
> > > >     Naveen
> > > >
> > > > Get Outlook for Android <https://aka.ms/ghei36>
> > > >
> > > > ------------------------------------------------------------------------
> > > >     *From:* Wim Vervoorn <[e-mail]
> > > >     <mailto:[e-mail]>>
> > > >     *Sent:* Tuesday, October 29, 2019 3:47:34 PM
> > > >     *To:* Naveen Chaudhary <[e-mail]
> > > >     <mailto:[e-mail]>>; Nico Huber
> > > >     <[e-mail] <mailto:[e-mail]>>; David Hendricks
> > > >     <[e-mail] <mailto:[e-mail]>>
> > > >     *Cc:* [e-mail] <mailto:[e-mail]>
> > > >     <[e-mail] <mailto:[e-mail]>>
> > > >     *Subject:* RE: [coreboot] Re: Coreboot FSP fails to initialize RAM
> > > >     - "Configuration not in POR table"
> > > >      
> > > >
> > > > Hello Naveen,
> > > >
> > > >  
> > > >
> > > > This is the important part. This indicates the what you selected
> > > >     is not supported.
> > > >
> > > >  
> > > >
> > > > Please review your settings carefully. This isn't a single check.
> > > >     The code validates the SPD settings against the other settings you
> > > >     made.
> > > >
> > > > So please make sure you are passing in a DDR4 SPD when you select
> > > >     DDR4 mode. Also please make sure the SPD settings are in
> > > >
> > > > The list of supported configuration for the chip.
> > > >
> > > >  
> > > >
> > > > Check POR Compatibility -- Started
> > > >
> > > > primaryWidthDDR4: 1, rowBitsDDR4: 16, columnBitsDDR4: 10,
> > > >     bankGroupsDDR4: 4
> > > >
> > > > primaryWidthDDR4: 1, rowBitsDDR4: 16, columnBitsDDR4: 10,
> > > >     bankGroupsDDR4: 4
> > > >
> > > > Unknown DIMM population *****
> > > >
> > > > Check POR Compatibility - 17ms
> > > >
> > > > Initialize DDR Clocks -- Started
> > > >
> > > > Checkpoint Code: Socket 0, 0xB1, 0x00, 0x0000
> > > >
> > > > Configuration not in POR table!  *** (This basically indicates you
> > > >     are trying to do something that is not supported by the chipset).
> > > >
> > > >  
> > > >
> > > > Best regards,
> > > >
> > > > Wim
> > > >
> > > >  
> > > >
> > > > *From:*Naveen Chaudhary [mailto:[e-mail]
> > > >     <mailto:[e-mail]>]
> > > >     *Sent:* Tuesday, October 29, 2019 10:44 AM
> > > >     *To:* Wim Vervoorn <[e-mail]
> > > >     <mailto:[e-mail]>>; Nico Huber <[e-mail]
> > > >     <mailto:[e-mail]>>; David Hendricks
> > > >     <[e-mail] <mailto:[e-mail]>>
> > > >     *Cc:* [e-mail] <mailto:[e-mail]>
> > > >     *Subject:* Re: [coreboot] Re: Coreboot FSP fails to initialize RAM
> > > >     - "Configuration not in POR table"
> > > >
> > > >  
> > > >
> > > > Thanks Wim.
> > > >
> > > > I will give a try and pass a 512 byte hex block corresponding to
> > > >     the SPD data and if it works, I can play with the hex values to
> > > >     find out the right configuration.
> > > >
> > > > BTW, any idea which field can impact the ddrfreq which was
> > > >     reported as error in the initial logs?
> > > >
> > > > Regards,
> > > >
> > > > Naveen
> > > >
> > > > Get Outlook for Android <https://aka.ms/ghei36>
> > > >
> > > >  
> > > >
> > > > ------------------------------------------------------------------------
> > > >
> > > > *From:*Wim Vervoorn <[e-mail] <mailto:[e-mail]>>
> > > >     *Sent:* Tuesday, October 29, 2019 3:07:44 PM
> > > >     *To:* Nico Huber <[e-mail] <mailto:[e-mail]>>; Naveen
> > > >     Chaudhary <[e-mail]
> > > >     <mailto:[e-mail]>>; David Hendricks
> > > >     <[e-mail] <mailto:[e-mail]>>
> > > >     *Cc:* [e-mail] <mailto:[e-mail]>
> > > >     <[e-mail] <mailto:[e-mail]>>
> > > >     *Subject:* RE: [coreboot] Re: Coreboot FSP fails to initialize RAM
> > > >     - "Configuration not in POR table"
> > > >
> > > >  
> > > >
> > > > Hello Naveen,
> > > >
> > > > You should use the "MemDownCh0Dimm0SpdPtr" to point to a buffer
> > > >     containing the SPD data and set MemDownEnable" to 1.
> > > >
> > > > Best Regards,
> > > >     Wim Vervoorn
> > > >
> > > > -----Original Message-----
> > > >     From: Nico Huber [mailto:[e-mail]]
> > > >     Sent: Sunday, October 27, 2019 11:33 AM
> > > >     To: Naveen Chaudhary <[e-mail]
> > > >     <mailto:[e-mail]>>; David Hendricks
> > > >     <[e-mail] <mailto:[e-mail]>>
> > > >     Cc: [e-mail] <mailto:[e-mail]>
> > > >     Subject: [coreboot] Re: Coreboot FSP fails to initialize RAM -
> > > >     "Configuration not in POR table"
> > > >
> > > > Hello Naveen,
> > > >
> > > > On 27.10.19 05:02, Naveen Chaudhary wrote:
> > > >     > Does this mean that there is a way in FSP to define custom
> > > >     settings(configs) for DIMMs? In the FSP integration guide for
> > > >     BroadwellDE
> > > >     (https://github.com/IntelFsp/FSP/tree/master/BroadwellDEFspBinPkg/Docs)
> > > >     I don't see any relevant data member where we could define pointer
> > > >     to custom SPD settings or pass individual DIMMs configurations.
> > > >
> > > > there is the memory-down option. It seems undocumented if that
> > > >     does more than switching from on-DIMM SPDs to SPD files. Maybe
> > > >     it's worth a try.
> > > >     If that doesn't work out, you can always overwrite the SPDs on
> > > >     your DIMM's EEPROMs. Always keep a backup, though.
> > > >
> > > > Hope that helps,
> > > >     Nico
> > > >     _______________________________________________
> > > >     coreboot mailing list -- [e-mail]
> > > >     <mailto:[e-mail]> To unsubscribe send an email to
> > > >     [e-mail] <mailto:[e-mail]>
> > > >
> > > > _______________________________________________
> > > > coreboot mailing list -- [e-mail]
> > > > To unsubscribe send an email to [e-mail]
> > >
> > > coreboot mailing list -- [e-mail]
> > > To unsubscribe send an email to [e-mail]
> >
> > coreboot mailing list -- [e-mail]
> > To unsubscribe send an email to [e-mail]

[Naveen Chaudhary]

Hi,

Do I need to take care of endianness as well?

I made the following change with FSP_MEMORY_DOWN = 0 :

diff --git a/src/soc/intel/fsp_broadwell_de/fsp/chipset_fsp_util.c b/src/soc/intel/fsp_broadwell_de/fsp/chipset_fsp_util.c
index edb313e7d5..822be48ed2 100644
--- a/src/soc/intel/fsp_broadwell_de/fsp/chipset_fsp_util.c
+++ b/src/soc/intel/fsp_broadwell_de/fsp/chipset_fsp_util.c
@@ -77,7 +77,43 @@ static void ConfigureDefaultUpdData(UPD_DATA_REGION *UpdData)
        if (CONFIG(FSP_MEMORY_DOWN)) {
                UpdData->MemDownEnable = 1;

-               if (CONFIG(FSP_MEMORY_DOWN_CH0DIMM0_SPD_PRESENT))
+       UINT8 buff[512] = {
+               0x23, 0x11, 0x0C, 0x06, 0x85, 0x21, 0x00, 0x08, 0x00, 0x60, 0x00, 0x03, 0x09, 0x0B, 0x80, 0x00,
+0x00, 0x00, 0x07, 0x0D, 0xA8, 0x0A, 0x00, 0x00, 0x6E, 0x6E, 0x6E, 0x11, 0x00, 0x6E, 0xF0, 0x0A,
+0x20, 0x08, 0x00, 0x05, 0x00, 0xA8, 0x1B, 0x28, 0x28, 0x00, 0x78, 0x00, 0x14, 0x3C, 0x00, 0x00,
+0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x0C, 0x2C, 0x0C, 0x36,
+0x0C, 0x2C, 0x0C, 0x2C, 0x0C, 0x2C, 0x0C, 0x2C, 0x0C, 0x2C, 0x0C, 0x2C, 0x0C, 0x2C, 0x00, 0x00,
+0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x9C, 0xB5, 0x00, 0x00, 0x00, 0x00, 0xE7, 0xD6, 0xDE, 0xDA,
+0x04, 0x11, 0x1F, 0x01, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0xF1, 0x05,
+0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+0x01, 0x94, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x53, 0x48, 0x35, 0x37, 0x32, 0x32, 0x47,
+0x38, 0x32, 0x4B, 0x41, 0x4D, 0x46, 0x55, 0x4D, 0x53, 0x42, 0x30, 0x20, 0x20, 0x00, 0x80, 0xCE,
+0x00, 0x53, 0x4D, 0x41, 0x52, 0x54, 0x4D, 0x6F, 0x64, 0x75, 0x6C, 0x61, 0x72, 0x54, 0x65, 0x63,
+0x68, 0x6E, 0x6F, 0x6C, 0x6F, 0x67, 0x69, 0x65, 0x73, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00
+       };
+       UpdData->MemDownCh0Dimm0SpdPtr = (UINT32)(buff);
+       UpdData->MemDownCh1Dimm0SpdPtr = (UINT32)(buff);
+               /*if (CONFIG(FSP_MEMORY_DOWN_CH0DIMM0_SPD_PRESENT))
                        UpdData->MemDownCh0Dimm0SpdPtr
                        = (UINT32)cbfs_boot_map_with_leak("spd_ch0_dimm0.bin", CBFS_TYPE_SPD, NULL);
                if (CONFIG(FSP_MEMORY_DOWN_CH0DIMM1_SPD_PRESENT))
@@ -88,10 +124,11 @@ static void ConfigureDefaultUpdData(UPD_DATA_REGION *UpdData)
                        = (UINT32)cbfs_boot_map_with_leak("spd_ch1_dimm0.bin", CBFS_TYPE_SPD, NULL);
                if (CONFIG(FSP_MEMORY_DOWN_CH1DIMM1_SPD_PRESENT))
                        UpdData->MemDownCh1Dimm1SpdPtr
-                       = (UINT32)cbfs_boot_map_with_leak("spd_ch1_dimm1.bin", CBFS_TYPE_SPD, NULL);
+                       = (UINT32)cbfs_boot_map_with_leak("spd_ch1_dimm1.bin", CBFS_TYPE_SPD, NULL);*/
        } else {
                UpdData->MemDownEnable = 0;
        }

But looks like my SPD Data is not read properly because FSP gives me the following logs. As can be seen I get all zeroes in the mem parameters

bootMode = NormalBoot
subBootMode = ColdBoot
Dispatch Slaves -- Started
Dispatch Slaves - 0ms
Promote Warning Exception List -- Started
Promote Warning Exception List - 0ms
Initialize Throttling Early -- Started
Initialize Throttling Early - 0ms
Detect DIMM Configuration -- Started
Checkpoint Code: Socket 0, 0xB0, 0x00, 0x0000
N0: IMC 0 SMB Clock Period = 0x1F2C
Socket | Channel | DIMM |  Bus Segment | SMBUS Address
-------|---------|------|--------------|--------------
   0   |     0   |   0  |      0       |       0      - Present
N0.C0.D0: NVDIMM:N(174)=0xD0
   0   |     0   |   1  |      0       |       1      - Not Present
   0   |     1   |   0  |      0       |       2      - Present
N0.C1.D0: NVDIMM:N(174)=0xD0
   0   |     1   |   1  |      0       |       3      - Not Present
Entering no zone 1
Detect DIMM Configuration - 46ms
Get Slave Data -- Started
Get Slave Data - 0ms
Check POR Compatibility -- Started
primaryWidthDDR4: 0, rowBitsDDR4: 0, columnBitsDDR4: 0, bankGroupsDDR4: 0
N0.C0.D0: DIMM not supported!

A warning has been logged! Warning Code = 0x7, Minor Warning Code = 0x0, Data = 0xFF
S0 Ch0 DIMM0

Warning upgraded to Fatal Error!

FatalError: SocketId = 0 registered Major Code = 0x 7, Minor Code = 0x 0

This is the same SPD data as programmed on the chip which was failing earlier. I just put the same data in the initial attempt to see if the values are getting read properly. But why I get all zeros, is this expected?

Regards,
Naveen
________________________________
From: Naveen Chaudhary <[e-mail]>
Sent: Wednesday, October 30, 2019 1:01 PM
To: David Hendricks <[e-mail]>
Cc: Wim Vervoorn <[e-mail]>; Nico Huber <[e-mail]>; [e-mail] <[e-mail]>
Subject: Re: [coreboot] Re: Coreboot FSP fails to initialize RAM - "Configuration not in POR table"

Thanks David.

Since some proprietary BIOS already works on this motherboard, this implies that I can use a different set of settings (timings, latency, etc) to make it work, as you suggested.

I found that the flag called FSP_MEMORY_DOWN_CH0DIMM0_SPD_PRESENT is there which I can make use of, to pass an SPD bin. I am not sure how to prepare that binary but I am assuming we can put all the 512 hex bytes of SPD as per DDR4 SPD spec into a text file and name it as spd.bin and pass along. (example : https://github.com/coreboot/coreboot/blob/master/src/mainboard/intel/cannonl...) Coreboot build system will automatically pack it. Compilation passed for me and will test it now, if the SPD data is read properly.
[https://avatars3.githubusercontent.com/u/6484311?s=400&v=4]<https://github.com/coreboot/coreboot/blob/master/src/mainboard/intel/cannonlake_rvp/spd/samsung_ddr4_4GB.spd.hex>
coreboot/coreboot<https://github.com/coreboot/coreboot/blob/master/src/mainboard/intel/cannonl...>
github mirror of coreboot.org's master repository. Contribute to coreboot/coreboot development by creating an account on GitHub.
github.com


In case this is not the correct way, the alternative way could be to create a UINT8 buff [512] and typecast to
UpdData->MemDownCh0Dimm0SpdPtr = (UINT32) buff;
directly.

While I am testing all this, anyone please correct me on the .bin part, so that it helps future contributors as well, as its not documented anywhere in coreboot.

Regards,
Naveen
________________________________
From: David Hendricks <[e-mail]>
Sent: Wednesday, 30 October, 2019, 12:44 PM
To: Naveen Chaudhary
Cc: Wim Vervoorn; Nico Huber; [e-mail]
Subject: Re: [coreboot] Re: Coreboot FSP fails to initialize RAM - "Configuration not in POR table"

Hi Naveen,
Yes, the first sentence. The DIMMs you are using appear to have geometry or timings incompatible with Broadwell-DE, based on the SPD values that the vendor programmed. Chapter 6 of the PDG (docid 543448) should help clarify what kinds of DIMMs are supported and how they should be populated.

On Tue, Oct 29, 2019 at 5:07 AM Naveen Chaudhary <[e-mail]<mailto:[e-mail]>> wrote:
Sorry I didn't get the point completely. Do you mean the settings are not compatible with FSP code? Or do you mean the settings might be conflicting themselves.

Since the above settings were read from SPD and the chip vendor must have definitely set them correctly, I assume you meant first sentence.

Please correct me.

Regards,
Naveen

Get Outlook for Android<https://aka.ms/ghei36>

________________________________
From: Wim Vervoorn <[e-mail]<mailto:[e-mail]>>
Sent: Tuesday, October 29, 2019 3:47:34 PM
To: Naveen Chaudhary <[e-mail]<mailto:[e-mail]>>; Nico Huber <[e-mail]<mailto:[e-mail]>>; David Hendricks <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Subject: RE: [coreboot] Re: Coreboot FSP fails to initialize RAM - "Configuration not in POR table"


Hello Naveen,



This is the important part. This indicates the what you selected is not supported.



Please review your settings carefully. This isn't a single check. The code validates the SPD settings against the other settings you made.

So please make sure you are passing in a DDR4 SPD when you select DDR4 mode. Also please make sure the SPD settings are in

The list of supported configuration for the chip.



Check POR Compatibility -- Started

primaryWidthDDR4: 1, rowBitsDDR4: 16, columnBitsDDR4: 10, bankGroupsDDR4: 4

primaryWidthDDR4: 1, rowBitsDDR4: 16, columnBitsDDR4: 10, bankGroupsDDR4: 4

Unknown DIMM population *****

Check POR Compatibility - 17ms

Initialize DDR Clocks -- Started

Checkpoint Code: Socket 0, 0xB1, 0x00, 0x0000

Configuration not in POR table!  *** (This basically indicates you are trying to do something that is not supported by the chipset).



Best regards,

Wim



From: Naveen Chaudhary [mailto:[e-mail]<mailto:[e-mail]>]
Sent: Tuesday, October 29, 2019 10:44 AM
To: Wim Vervoorn <[e-mail]<mailto:[e-mail]>>; Nico Huber <[e-mail]<mailto:[e-mail]>>; David Hendricks <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>
Subject: Re: [coreboot] Re: Coreboot FSP fails to initialize RAM - "Configuration not in POR table"



Thanks Wim.

I will give a try and pass a 512 byte hex block corresponding to the SPD data and if it works, I can play with the hex values to find out the right configuration.

BTW, any idea which field can impact the ddrfreq which was reported as error in the initial logs?

Regards,

Naveen

Get Outlook for Android<https://aka.ms/ghei36>



________________________________

From: Wim Vervoorn <[e-mail]<mailto:[e-mail]>>
Sent: Tuesday, October 29, 2019 3:07:44 PM
To: Nico Huber <[e-mail]<mailto:[e-mail]>>; Naveen Chaudhary <[e-mail]<mailto:[e-mail]>>; David Hendricks <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Subject: RE: [coreboot] Re: Coreboot FSP fails to initialize RAM - "Configuration not in POR table"



Hello Naveen,

You should use the "MemDownCh0Dimm0SpdPtr" to point to a buffer containing the SPD data and set MemDownEnable" to 1.

Best Regards,
Wim Vervoorn



-----Original Message-----
From: Nico Huber [mailto:[e-mail]]
Sent: Sunday, October 27, 2019 11:33 AM
To: Naveen Chaudhary <[e-mail]<mailto:[e-mail]>>; David Hendricks <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>
Subject: [coreboot] Re: Coreboot FSP fails to initialize RAM - "Configuration not in POR table"

Hello Naveen,

On 27.10.19 05:02, Naveen Chaudhary wrote:
> Does this mean that there is a way in FSP to define custom settings(configs) for DIMMs? In the FSP integration guide for BroadwellDE (https://github.com/IntelFsp/FSP/tree/master/BroadwellDEFspBinPkg/Docs) I don't see any relevant data member where we could define pointer to custom SPD settings or pass individual DIMMs configurations.

there is the memory-down option. It seems undocumented if that does more than switching from on-DIMM SPDs to SPD files. Maybe it's worth a try.
If that doesn't work out, you can always overwrite the SPDs on your DIMM's EEPROMs. Always keep a backup, though.

Hope that helps,
Nico
_______________________________________________
coreboot mailing list -- [e-mail]<mailto:[e-mail]> To unsubscribe send an email to [e-mail]<mailto:[e-mail]>

[Naveen Chaudhary]

Oops... that buff would get destroyed as its on stack...missed that.

Is there a better way?

Globals are also not getting accepted.

/home/naveen/repos/coreboot/util/crossgcc/xgcc/bin/i386-elf-ld.bfd: section .illegal_globals VMA wraps around address space
    OBJCOPY    ramstage/cpu/x86/smm/smmstub.manual
src/arch/x86/Makefile.inc:246: recipe for target 'build/cbfs/fallback/romstage.debug' failed

Regards,
Naveen
________________________________
From: Naveen Chaudhary <[e-mail]>
Sent: Thursday, October 31, 2019 9:46 AM
To: David Hendricks <[e-mail]>
Cc: Wim Vervoorn <[e-mail]>; Nico Huber <[e-mail]>; [e-mail] <[e-mail]>
Subject: Re: [coreboot] Re: Coreboot FSP fails to initialize RAM - "Configuration not in POR table"

Hi,

Do I need to take care of endianness as well?

I made the following change with FSP_MEMORY_DOWN = 0 :

diff --git a/src/soc/intel/fsp_broadwell_de/fsp/chipset_fsp_util.c b/src/soc/intel/fsp_broadwell_de/fsp/chipset_fsp_util.c
index edb313e7d5..822be48ed2 100644
--- a/src/soc/intel/fsp_broadwell_de/fsp/chipset_fsp_util.c
+++ b/src/soc/intel/fsp_broadwell_de/fsp/chipset_fsp_util.c
@@ -77,7 +77,43 @@ static void ConfigureDefaultUpdData(UPD_DATA_REGION *UpdData)
        if (CONFIG(FSP_MEMORY_DOWN)) {
                UpdData->MemDownEnable = 1;

-               if (CONFIG(FSP_MEMORY_DOWN_CH0DIMM0_SPD_PRESENT))
+       UINT8 buff[512] = {
+               0x23, 0x11, 0x0C, 0x06, 0x85, 0x21, 0x00, 0x08, 0x00, 0x60, 0x00, 0x03, 0x09, 0x0B, 0x80, 0x00,
+0x00, 0x00, 0x07, 0x0D, 0xA8, 0x0A, 0x00, 0x00, 0x6E, 0x6E, 0x6E, 0x11, 0x00, 0x6E, 0xF0, 0x0A,
+0x20, 0x08, 0x00, 0x05, 0x00, 0xA8, 0x1B, 0x28, 0x28, 0x00, 0x78, 0x00, 0x14, 0x3C, 0x00, 0x00,
+0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x0C, 0x2C, 0x0C, 0x36,
+0x0C, 0x2C, 0x0C, 0x2C, 0x0C, 0x2C, 0x0C, 0x2C, 0x0C, 0x2C, 0x0C, 0x2C, 0x0C, 0x2C, 0x00, 0x00,
+0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x9C, 0xB5, 0x00, 0x00, 0x00, 0x00, 0xE7, 0xD6, 0xDE, 0xDA,
+0x04, 0x11, 0x1F, 0x01, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0xF1, 0x05,
+0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+0x01, 0x94, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x53, 0x48, 0x35, 0x37, 0x32, 0x32, 0x47,
+0x38, 0x32, 0x4B, 0x41, 0x4D, 0x46, 0x55, 0x4D, 0x53, 0x42, 0x30, 0x20, 0x20, 0x00, 0x80, 0xCE,
+0x00, 0x53, 0x4D, 0x41, 0x52, 0x54, 0x4D, 0x6F, 0x64, 0x75, 0x6C, 0x61, 0x72, 0x54, 0x65, 0x63,
+0x68, 0x6E, 0x6F, 0x6C, 0x6F, 0x67, 0x69, 0x65, 0x73, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00
+       };
+       UpdData->MemDownCh0Dimm0SpdPtr = (UINT32)(buff);
+       UpdData->MemDownCh1Dimm0SpdPtr = (UINT32)(buff);
+               /*if (CONFIG(FSP_MEMORY_DOWN_CH0DIMM0_SPD_PRESENT))
                        UpdData->MemDownCh0Dimm0SpdPtr
                        = (UINT32)cbfs_boot_map_with_leak("spd_ch0_dimm0.bin", CBFS_TYPE_SPD, NULL);
                if (CONFIG(FSP_MEMORY_DOWN_CH0DIMM1_SPD_PRESENT))
@@ -88,10 +124,11 @@ static void ConfigureDefaultUpdData(UPD_DATA_REGION *UpdData)
                        = (UINT32)cbfs_boot_map_with_leak("spd_ch1_dimm0.bin", CBFS_TYPE_SPD, NULL);
                if (CONFIG(FSP_MEMORY_DOWN_CH1DIMM1_SPD_PRESENT))
                        UpdData->MemDownCh1Dimm1SpdPtr
-                       = (UINT32)cbfs_boot_map_with_leak("spd_ch1_dimm1.bin", CBFS_TYPE_SPD, NULL);
+                       = (UINT32)cbfs_boot_map_with_leak("spd_ch1_dimm1.bin", CBFS_TYPE_SPD, NULL);*/
        } else {
                UpdData->MemDownEnable = 0;
        }

But looks like my SPD Data is not read properly because FSP gives me the following logs. As can be seen I get all zeroes in the mem parameters

bootMode = NormalBoot
subBootMode = ColdBoot
Dispatch Slaves -- Started
Dispatch Slaves - 0ms
Promote Warning Exception List -- Started
Promote Warning Exception List - 0ms
Initialize Throttling Early -- Started
Initialize Throttling Early - 0ms
Detect DIMM Configuration -- Started
Checkpoint Code: Socket 0, 0xB0, 0x00, 0x0000
N0: IMC 0 SMB Clock Period = 0x1F2C
Socket | Channel | DIMM |  Bus Segment | SMBUS Address
-------|---------|------|--------------|--------------
   0   |     0   |   0  |      0       |       0      - Present
N0.C0.D0: NVDIMM:N(174)=0xD0
   0   |     0   |   1  |      0       |       1      - Not Present
   0   |     1   |   0  |      0       |       2      - Present
N0.C1.D0: NVDIMM:N(174)=0xD0
   0   |     1   |   1  |      0       |       3      - Not Present
Entering no zone 1
Detect DIMM Configuration - 46ms
Get Slave Data -- Started
Get Slave Data - 0ms
Check POR Compatibility -- Started
primaryWidthDDR4: 0, rowBitsDDR4: 0, columnBitsDDR4: 0, bankGroupsDDR4: 0
N0.C0.D0: DIMM not supported!

A warning has been logged! Warning Code = 0x7, Minor Warning Code = 0x0, Data = 0xFF
S0 Ch0 DIMM0

Warning upgraded to Fatal Error!

FatalError: SocketId = 0 registered Major Code = 0x 7, Minor Code = 0x 0

This is the same SPD data as programmed on the chip which was failing earlier. I just put the same data in the initial attempt to see if the values are getting read properly. But why I get all zeros, is this expected?

Regards,
Naveen
________________________________
From: Naveen Chaudhary <[e-mail]>
Sent: Wednesday, October 30, 2019 1:01 PM
To: David Hendricks <[e-mail]>
Cc: Wim Vervoorn <[e-mail]>; Nico Huber <[e-mail]>; [e-mail] <[e-mail]>
Subject: Re: [coreboot] Re: Coreboot FSP fails to initialize RAM - "Configuration not in POR table"

Thanks David.

Since some proprietary BIOS already works on this motherboard, this implies that I can use a different set of settings (timings, latency, etc) to make it work, as you suggested.

I found that the flag called FSP_MEMORY_DOWN_CH0DIMM0_SPD_PRESENT is there which I can make use of, to pass an SPD bin. I am not sure how to prepare that binary but I am assuming we can put all the 512 hex bytes of SPD as per DDR4 SPD spec into a text file and name it as spd.bin and pass along. (example : https://github.com/coreboot/coreboot/blob/master/src/mainboard/intel/cannonl...) Coreboot build system will automatically pack it. Compilation passed for me and will test it now, if the SPD data is read properly.
[https://avatars3.githubusercontent.com/u/6484311?s=400&v=4]<https://github.com/coreboot/coreboot/blob/master/src/mainboard/intel/cannonlake_rvp/spd/samsung_ddr4_4GB.spd.hex>
coreboot/coreboot<https://github.com/coreboot/coreboot/blob/master/src/mainboard/intel/cannonl...>
github mirror of coreboot.org's master repository. Contribute to coreboot/coreboot development by creating an account on GitHub.
github.com


In case this is not the correct way, the alternative way could be to create a UINT8 buff [512] and typecast to
UpdData->MemDownCh0Dimm0SpdPtr = (UINT32) buff;
directly.

While I am testing all this, anyone please correct me on the .bin part, so that it helps future contributors as well, as its not documented anywhere in coreboot.

Regards,
Naveen
________________________________
From: David Hendricks <[e-mail]>
Sent: Wednesday, 30 October, 2019, 12:44 PM
To: Naveen Chaudhary
Cc: Wim Vervoorn; Nico Huber; [e-mail]
Subject: Re: [coreboot] Re: Coreboot FSP fails to initialize RAM - "Configuration not in POR table"

Hi Naveen,
Yes, the first sentence. The DIMMs you are using appear to have geometry or timings incompatible with Broadwell-DE, based on the SPD values that the vendor programmed. Chapter 6 of the PDG (docid 543448) should help clarify what kinds of DIMMs are supported and how they should be populated.

On Tue, Oct 29, 2019 at 5:07 AM Naveen Chaudhary <[e-mail]<mailto:[e-mail]>> wrote:
Sorry I didn't get the point completely. Do you mean the settings are not compatible with FSP code? Or do you mean the settings might be conflicting themselves.

Since the above settings were read from SPD and the chip vendor must have definitely set them correctly, I assume you meant first sentence.

Please correct me.

Regards,
Naveen

Get Outlook for Android<https://aka.ms/ghei36>

________________________________
From: Wim Vervoorn <[e-mail]<mailto:[e-mail]>>
Sent: Tuesday, October 29, 2019 3:47:34 PM
To: Naveen Chaudhary <[e-mail]<mailto:[e-mail]>>; Nico Huber <[e-mail]<mailto:[e-mail]>>; David Hendricks <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Subject: RE: [coreboot] Re: Coreboot FSP fails to initialize RAM - "Configuration not in POR table"


Hello Naveen,



This is the important part. This indicates the what you selected is not supported.



Please review your settings carefully. This isn't a single check. The code validates the SPD settings against the other settings you made.

So please make sure you are passing in a DDR4 SPD when you select DDR4 mode. Also please make sure the SPD settings are in

The list of supported configuration for the chip.



Check POR Compatibility -- Started

primaryWidthDDR4: 1, rowBitsDDR4: 16, columnBitsDDR4: 10, bankGroupsDDR4: 4

primaryWidthDDR4: 1, rowBitsDDR4: 16, columnBitsDDR4: 10, bankGroupsDDR4: 4

Unknown DIMM population *****

Check POR Compatibility - 17ms

Initialize DDR Clocks -- Started

Checkpoint Code: Socket 0, 0xB1, 0x00, 0x0000

Configuration not in POR table!  *** (This basically indicates you are trying to do something that is not supported by the chipset).



Best regards,

Wim



From: Naveen Chaudhary [mailto:[e-mail]<mailto:[e-mail]>]
Sent: Tuesday, October 29, 2019 10:44 AM
To: Wim Vervoorn <[e-mail]<mailto:[e-mail]>>; Nico Huber <[e-mail]<mailto:[e-mail]>>; David Hendricks <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>
Subject: Re: [coreboot] Re: Coreboot FSP fails to initialize RAM - "Configuration not in POR table"



Thanks Wim.

I will give a try and pass a 512 byte hex block corresponding to the SPD data and if it works, I can play with the hex values to find out the right configuration.

BTW, any idea which field can impact the ddrfreq which was reported as error in the initial logs?

Regards,

Naveen

Get Outlook for Android<https://aka.ms/ghei36>



________________________________

From: Wim Vervoorn <[e-mail]<mailto:[e-mail]>>
Sent: Tuesday, October 29, 2019 3:07:44 PM
To: Nico Huber <[e-mail]<mailto:[e-mail]>>; Naveen Chaudhary <[e-mail]<mailto:[e-mail]>>; David Hendricks <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Subject: RE: [coreboot] Re: Coreboot FSP fails to initialize RAM - "Configuration not in POR table"



Hello Naveen,

You should use the "MemDownCh0Dimm0SpdPtr" to point to a buffer containing the SPD data and set MemDownEnable" to 1.

Best Regards,
Wim Vervoorn



-----Original Message-----
From: Nico Huber [mailto:[e-mail]]
Sent: Sunday, October 27, 2019 11:33 AM
To: Naveen Chaudhary <[e-mail]<mailto:[e-mail]>>; David Hendricks <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>
Subject: [coreboot] Re: Coreboot FSP fails to initialize RAM - "Configuration not in POR table"

Hello Naveen,

On 27.10.19 05:02, Naveen Chaudhary wrote:
> Does this mean that there is a way in FSP to define custom settings(configs) for DIMMs? In the FSP integration guide for BroadwellDE (https://github.com/IntelFsp/FSP/tree/master/BroadwellDEFspBinPkg/Docs) I don't see any relevant data member where we could define pointer to custom SPD settings or pass individual DIMMs configurations.

there is the memory-down option. It seems undocumented if that does more than switching from on-DIMM SPDs to SPD files. Maybe it's worth a try.
If that doesn't work out, you can always overwrite the SPDs on your DIMM's EEPROMs. Always keep a backup, though.

Hope that helps,
Nico
_______________________________________________
coreboot mailing list -- [e-mail]<mailto:[e-mail]> To unsubscribe send an email to [e-mail]<mailto:[e-mail]>