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 michal.zygowski@3mdeb.com Sent: Thursday, October 31, 2019 3:38 PM To: coreboot@coreboot.org coreboot@coreboot.org 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/cannonlake_rvp/spd/samsung_ddr4_4GB.spd.hex
coreboot/coreboot https://github.com/coreboot/coreboot/blob/master/src/mainboard/intel/cannonlake_rvp/spd/samsung_ddr4_4GB.spd.hex 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 david.hendricks@gmail.com *Sent:* Wednesday, 30 October, 2019, 12:44 PM *To:* Naveen Chaudhary *Cc:* Wim Vervoorn; Nico Huber; coreboot@coreboot.org *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 <naveenchaudhary2010@hotmail.com mailto:naveenchaudhary2010@hotmail.com> 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 <wvervoorn@eltan.com <mailto:wvervoorn@eltan.com>> *Sent:* Tuesday, October 29, 2019 3:47:34 PM *To:* Naveen Chaudhary <naveenchaudhary2010@hotmail.com <mailto:naveenchaudhary2010@hotmail.com>>; Nico Huber <nico.h@gmx.de <mailto:nico.h@gmx.de>>; David Hendricks <david.hendricks@gmail.com <mailto:david.hendricks@gmail.com>> *Cc:* coreboot@coreboot.org <mailto:coreboot@coreboot.org> <coreboot@coreboot.org <mailto:coreboot@coreboot.org>> *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:naveenchaudhary2010@hotmail.com <mailto:naveenchaudhary2010@hotmail.com>] *Sent:* Tuesday, October 29, 2019 10:44 AM *To:* Wim Vervoorn <wvervoorn@eltan.com <mailto:wvervoorn@eltan.com>>; Nico Huber <nico.h@gmx.de <mailto:nico.h@gmx.de>>; David Hendricks <david.hendricks@gmail.com <mailto:david.hendricks@gmail.com>> *Cc:* coreboot@coreboot.org <mailto:coreboot@coreboot.org> *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 <wvervoorn@eltan.com <mailto:wvervoorn@eltan.com>> *Sent:* Tuesday, October 29, 2019 3:07:44 PM *To:* Nico Huber <nico.h@gmx.de <mailto:nico.h@gmx.de>>; Naveen Chaudhary <naveenchaudhary2010@hotmail.com <mailto:naveenchaudhary2010@hotmail.com>>; David Hendricks <david.hendricks@gmail.com <mailto:david.hendricks@gmail.com>> *Cc:* coreboot@coreboot.org <mailto:coreboot@coreboot.org> <coreboot@coreboot.org <mailto:coreboot@coreboot.org>> *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:nico.h@gmx.de] Sent: Sunday, October 27, 2019 11:33 AM To: Naveen Chaudhary <naveenchaudhary2010@hotmail.com <mailto:naveenchaudhary2010@hotmail.com>>; David Hendricks <david.hendricks@gmail.com <mailto:david.hendricks@gmail.com>> Cc: coreboot@coreboot.org <mailto:coreboot@coreboot.org> 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 -- coreboot@coreboot.org <mailto:coreboot@coreboot.org> To unsubscribe send an email to coreboot-leave@coreboot.org <mailto:coreboot-leave@coreboot.org>
coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
-- Michał Żygowski Firmware Engineer http://3mdeb.com | @3mdeb_com
_______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org