If you decide to use MemoryDown, you need to provide the SPD data to FSP in a buffer.
If you use normal DIMM configuration, FSP is able to read SPD data form the SPD EEPROM on
So yes, I can confirm that FSP handles SPD EEPROM on its own.
Von: Naveen Chaudhary <naveenchaudhary2010(a)hotmail.com>
Gesendet: Donnerstag, 24. Oktober 2019 06:28
An: Zeh, Werner (DI MC MTS R&D HW 1) <werner.zeh(a)siemens.com>om>;
Betreff: Re: Call to FSP_FSP_INIT never returns back
I found answers to part of my question that the .bsf file defines all the default values
which can be opened in a normal text editor. In fact, the Windows based GUI BCT tool also
shows all the default values using this file (till now I was using command line BCT
unaware of the other side).
Still I couldn't find a way to initialize DIMMs. There is only one field called
MemDdrMemoryType which looks relevant but after this will the FSP automatically read SPD
from the RAM sticks? Will setting MemDownEnable=0 will autmatically make FSP look for RAM
sticks and read SPD on its own? (MemDownCh*Dimm*SpdPtr is related to soldered RAM and
can't be used).
Can someone please confirm this last thing. Thanks.
From: Naveen Chaudhary <mailto:email@example.com>
Sent: Wednesday, October 23, 2019 9:02 PM
To: mailto:firstname.lastname@example.org <mailto:email@example.com>;
Subject: Re: Call to FSP_FSP_INIT never returns back
The crux of the problem is that I am currently seeing a hack immediately after
FSP_FSP_INIT is called and the next function ChipsetFspReturnPoint( ) never gets called,
which indicates its hanged in FSP. Now how can I debug the situation as what's going
I was reading the BroadwellDE FSP Integration guide and there is this paragraph :
Debug serial port resource type. Select 'None' to have FSP generate no output.
'I/O' to have FSP generate output via a legacy I/O output (i.e. 0x2f8/0x3f8).
Now again there is no discussion as what integer value does I/O is represented with? Is it
0x1 ? 0x2 ? We don't know. There is no enum in the FSP headers as well. So I gave up
on the FSP log part, and assumed it could be because of missing RAM settings. Since I
disabled MemDownEnable, I should be passing UPD for DIMM slots. But again there is no
field I could find in the UPD_DATA_REGION which seems related to be accepting DIMM
Also referring the code in coreboot, if MEMDOWN is disabled, it simply sets
MemDownEnable=0 and then directly calls FSP_FSP_INIT with no reading of DIMM SPD or
hardcoded values. This left me clueless as how coreboot initializes DIMM memory for
BroadwellDE ? Is it unimplemented or am I missing something?
I request the community to please help and guide.
From: mailto:firstname.lastname@example.org <mailto:email@example.com>
Sent: Wednesday, October 23, 2019 10:49 AM
To: Naveen Chaudhary <mailto:NaveenChaudhary2010@hotmail.com>;
Subject: AW: Call to FSP_FSP_INIT never returns back
I am not sure that FSP supports mixed setup with both memory down and DIMMs at the same
time. At least there is just one UPD parameter telling that you either have DIMM or memory
down enabled (MemDownEnable).
So I haven't figured out how to tell FSP which channel is memory down and which is
using normal DIMMs. That might be already your problem.
You can try to just use the channel that is of the same type and disable the other one
(e.g. just use the DIMM and let FSP do its work) to see if that might bring a bit more
light into the darkness of FSP.
For the default values of FSP BCT should be able to help you. What are the issues you are
You need to open your binary blob (the .fd file) with BCT and then all the values should
Von: Naveen Chaudhary <mailto:NaveenChaudhary2010@hotmail.com>
Gesendet: Dienstag, 22. Oktober 2019 20:46
Betreff: [coreboot] Call to FSP_FSP_INIT never returns back
Need some guidance. Please read.
I am porting coreboot for a "Broadwell D 1519" based motherboard which has both
Memory Down as well as 2 DIMM slots. Hence, I built an image for Facebook Watson since its
the closest mainboard with no code changes. The call from FSP_FSP_INIT never returns to
the ChipsetFspReturnPoint( ). Probably something crashed inside the FSP or something
This is possibly happening because I have passed no information regarding the RAM chips
(down or DIMM) from romstage_fsp_rt_buffer_callback(). I have following 2 questions :
1. How can I see the default values for FSP UDP structure, so that I get to know what I
need to modify? BCT tool does not dump that info.
2. In intel/soc/fsp_broadwell/ , the save_dimm_info() is done after FSP_FSP_INIT returns.
Shouldn't the SPD details have been fetched before and passed to the FSP_FSP_INIT, as
it is this API that handles the memory init.