Hi All,
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 else.
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.
Regards, Naveen
Hi Naveen.
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 running in? You need to open your binary blob (the .fd file) with BCT and then all the values should be loaded.
Werner
Von: Naveen Chaudhary NaveenChaudhary2010@hotmail.com Gesendet: Dienstag, 22. Oktober 2019 20:46 An: coreboot@coreboot.org Betreff: [coreboot] Call to FSP_FSP_INIT never returns back
Hi All,
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 else.
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.
Regards, Naveen
Hi,
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 wrong?
I was reading the BroadwellDE FSP Integration guide and there is this paragraph :
SerialPortType Debug serial port resource type. Select 'None' to have FSP generate no output. Select '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 configurations.
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.
Regards, Naveen ________________________________ From: werner.zeh@siemens.com werner.zeh@siemens.com Sent: Wednesday, October 23, 2019 10:49 AM To: Naveen Chaudhary NaveenChaudhary2010@hotmail.com; coreboot@coreboot.org coreboot@coreboot.org Subject: AW: Call to FSP_FSP_INIT never returns back
Hi Naveen.
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 running in? You need to open your binary blob (the .fd file) with BCT and then all the values should be loaded.
Werner
Von: Naveen Chaudhary NaveenChaudhary2010@hotmail.com Gesendet: Dienstag, 22. Oktober 2019 20:46 An: coreboot@coreboot.org Betreff: [coreboot] Call to FSP_FSP_INIT never returns back
Hi All,
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 else.
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.
Regards, Naveen
Hi,
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.
Regards, Naveen ________________________________ From: Naveen Chaudhary naveenchaudhary2010@hotmail.com Sent: Wednesday, October 23, 2019 9:02 PM To: werner.zeh@siemens.com werner.zeh@siemens.com; coreboot@coreboot.org coreboot@coreboot.org Subject: Re: Call to FSP_FSP_INIT never returns back
Hi,
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 wrong?
I was reading the BroadwellDE FSP Integration guide and there is this paragraph :
SerialPortType Debug serial port resource type. Select 'None' to have FSP generate no output. Select '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 configurations.
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.
Regards, Naveen ________________________________ From: werner.zeh@siemens.com werner.zeh@siemens.com Sent: Wednesday, October 23, 2019 10:49 AM To: Naveen Chaudhary NaveenChaudhary2010@hotmail.com; coreboot@coreboot.org coreboot@coreboot.org Subject: AW: Call to FSP_FSP_INIT never returns back
Hi Naveen.
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 running in? You need to open your binary blob (the .fd file) with BCT and then all the values should be loaded.
Werner
Von: Naveen Chaudhary NaveenChaudhary2010@hotmail.com Gesendet: Dienstag, 22. Oktober 2019 20:46 An: coreboot@coreboot.org Betreff: [coreboot] Call to FSP_FSP_INIT never returns back
Hi All,
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 else.
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.
Regards, Naveen
Hi.
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 its own. So yes, I can confirm that FSP handles SPD EEPROM on its own.
Werner
Von: Naveen Chaudhary naveenchaudhary2010@hotmail.com Gesendet: Donnerstag, 24. Oktober 2019 06:28 An: Zeh, Werner (DI MC MTS R&D HW 1) werner.zeh@siemens.com; coreboot@coreboot.org Betreff: Re: Call to FSP_FSP_INIT never returns back
Hi,
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.
Regards, Naveen ________________________________________ From: Naveen Chaudhary mailto:naveenchaudhary2010@hotmail.com Sent: Wednesday, October 23, 2019 9:02 PM To: mailto:werner.zeh@siemens.com mailto:werner.zeh@siemens.com; mailto:coreboot@coreboot.org mailto:coreboot@coreboot.org Subject: Re: Call to FSP_FSP_INIT never returns back Hi,
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 wrong?
I was reading the BroadwellDE FSP Integration guide and there is this paragraph :
SerialPortType Debug serial port resource type. Select 'None' to have FSP generate no output. Select '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 configurations.
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.
Regards, Naveen ________________________________________ From: mailto:werner.zeh@siemens.com mailto:werner.zeh@siemens.com Sent: Wednesday, October 23, 2019 10:49 AM To: Naveen Chaudhary mailto:NaveenChaudhary2010@hotmail.com; mailto:coreboot@coreboot.org mailto:coreboot@coreboot.org Subject: AW: Call to FSP_FSP_INIT never returns back Hi Naveen.
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 running in? You need to open your binary blob (the .fd file) with BCT and then all the values should be loaded.
Werner
Von: Naveen Chaudhary mailto:NaveenChaudhary2010@hotmail.com Gesendet: Dienstag, 22. Oktober 2019 20:46 An: mailto:coreboot@coreboot.org Betreff: [coreboot] Call to FSP_FSP_INIT never returns back
Hi All,
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 else.
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.
Regards, Naveen
Thanks for confirming that. I had some success enabling the logs this time and I get the following logs from FSP.
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
Was it able to read the SPD properly? If yes, what went wrong? "Unknown DIMM population seems scary".
Regards, Naveen ________________________________ From: werner.zeh@siemens.com werner.zeh@siemens.com Sent: Thursday, October 24, 2019 11:16 AM To: Naveen Chaudhary naveenchaudhary2010@hotmail.com Cc: coreboot@coreboot.org coreboot@coreboot.org Subject: AW: Call to FSP_FSP_INIT never returns back
Hi.
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 its own. So yes, I can confirm that FSP handles SPD EEPROM on its own.
Werner
Von: Naveen Chaudhary naveenchaudhary2010@hotmail.com Gesendet: Donnerstag, 24. Oktober 2019 06:28 An: Zeh, Werner (DI MC MTS R&D HW 1) werner.zeh@siemens.com; coreboot@coreboot.org Betreff: Re: Call to FSP_FSP_INIT never returns back
Hi,
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.
Regards, Naveen ________________________________________ From: Naveen Chaudhary mailto:naveenchaudhary2010@hotmail.com Sent: Wednesday, October 23, 2019 9:02 PM To: mailto:werner.zeh@siemens.com mailto:werner.zeh@siemens.com; mailto:coreboot@coreboot.org mailto:coreboot@coreboot.org Subject: Re: Call to FSP_FSP_INIT never returns back
Hi,
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 wrong?
I was reading the BroadwellDE FSP Integration guide and there is this paragraph :
SerialPortType Debug serial port resource type. Select 'None' to have FSP generate no output. Select '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 configurations.
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.
Regards, Naveen ________________________________________ From: mailto:werner.zeh@siemens.com mailto:werner.zeh@siemens.com Sent: Wednesday, October 23, 2019 10:49 AM To: Naveen Chaudhary mailto:NaveenChaudhary2010@hotmail.com; mailto:coreboot@coreboot.org mailto:coreboot@coreboot.org Subject: AW: Call to FSP_FSP_INIT never returns back
Hi Naveen.
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 running in? You need to open your binary blob (the .fd file) with BCT and then all the values should be loaded.
Werner
Von: Naveen Chaudhary mailto:NaveenChaudhary2010@hotmail.com Gesendet: Dienstag, 22. Oktober 2019 20:46 An: mailto:coreboot@coreboot.org Betreff: [coreboot] Call to FSP_FSP_INIT never returns back
Hi All,
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 else.
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.
Regards, Naveen
Attaching bigger chunk of logs :
forceColdBoot bit set Get socket PPIN N0: PPIN Hi = 0xC91DCC7A, PPIN Lo = 0x4B9C9A6C setupChanged: 1 Clearing the MRC NVRAM structure.
sizeof sysNvram = 136441
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
Regards, Naveen ________________________________ From: Naveen Chaudhary naveenchaudhary2010@hotmail.com Sent: Thursday, October 24, 2019 1:13 PM To: werner.zeh@siemens.com werner.zeh@siemens.com Cc: coreboot@coreboot.org coreboot@coreboot.org Subject: Re: Call to FSP_FSP_INIT never returns back
Thanks for confirming that. I had some success enabling the logs this time and I get the following logs from FSP.
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
Was it able to read the SPD properly? If yes, what went wrong? "Unknown DIMM population seems scary".
Regards, Naveen ________________________________ From: werner.zeh@siemens.com werner.zeh@siemens.com Sent: Thursday, October 24, 2019 11:16 AM To: Naveen Chaudhary naveenchaudhary2010@hotmail.com Cc: coreboot@coreboot.org coreboot@coreboot.org Subject: AW: Call to FSP_FSP_INIT never returns back
Hi.
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 its own. So yes, I can confirm that FSP handles SPD EEPROM on its own.
Werner
Von: Naveen Chaudhary naveenchaudhary2010@hotmail.com Gesendet: Donnerstag, 24. Oktober 2019 06:28 An: Zeh, Werner (DI MC MTS R&D HW 1) werner.zeh@siemens.com; coreboot@coreboot.org Betreff: Re: Call to FSP_FSP_INIT never returns back
Hi,
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.
Regards, Naveen ________________________________________ From: Naveen Chaudhary mailto:naveenchaudhary2010@hotmail.com Sent: Wednesday, October 23, 2019 9:02 PM To: mailto:werner.zeh@siemens.com mailto:werner.zeh@siemens.com; mailto:coreboot@coreboot.org mailto:coreboot@coreboot.org Subject: Re: Call to FSP_FSP_INIT never returns back
Hi,
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 wrong?
I was reading the BroadwellDE FSP Integration guide and there is this paragraph :
SerialPortType Debug serial port resource type. Select 'None' to have FSP generate no output. Select '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 configurations.
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.
Regards, Naveen ________________________________________ From: mailto:werner.zeh@siemens.com mailto:werner.zeh@siemens.com Sent: Wednesday, October 23, 2019 10:49 AM To: Naveen Chaudhary mailto:NaveenChaudhary2010@hotmail.com; mailto:coreboot@coreboot.org mailto:coreboot@coreboot.org Subject: AW: Call to FSP_FSP_INIT never returns back
Hi Naveen.
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 running in? You need to open your binary blob (the .fd file) with BCT and then all the values should be loaded.
Werner
Von: Naveen Chaudhary mailto:NaveenChaudhary2010@hotmail.com Gesendet: Dienstag, 22. Oktober 2019 20:46 An: mailto:coreboot@coreboot.org Betreff: [coreboot] Call to FSP_FSP_INIT never returns back
Hi All,
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 else.
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.
Regards, Naveen
Hi fellow engineers,
I got that RAM stick working when I changed the fourth byte of SPD from from mini-UDIMM (0x06) to SO-DIMM (0x03) and its working fine... But still I am curious why mini-UDIMM didn't work out. Perhaps this form factor was not supported by FSP?
Another thing I observed that the call to FSP_FSP_INIT takes 7-8 seconds to return back. Is that expected? What could be the possible ways to optimize it (even an inflexible solution is welcome). The total boot time from power-on to loading payload is around 20 seconds with logs disabled.
Regards, Naveen
Hello Naveen,
The longer time is expected on the first boot. After that this should not take that long.
If every boot takes that long please check if the MRC information is preserved in flash and properly restored before making the FSP call.
Best Regards, Wim Vervoorn
From: Naveen Chaudhary [mailto:naveenchaudhary2010@hotmail.com] Sent: Thursday, November 7, 2019 7:02 AM To: werner.zeh@siemens.com Cc: coreboot@coreboot.org Subject: [coreboot] Re: Call to FSP_FSP_INIT never returns back
Hi fellow engineers,
I got that RAM stick working when I changed the fourth byte of SPD from from mini-UDIMM (0x06) to SO-DIMM (0x03) and its working fine... But still I am curious why mini-UDIMM didn't work out. Perhaps this form factor was not supported by FSP?
Another thing I observed that the call to FSP_FSP_INIT takes 7-8 seconds to return back. Is that expected? What could be the possible ways to optimize it (even an inflexible solution is welcome). The total boot time from power-on to loading payload is around 20 seconds with logs disabled.
Regards, Naveen
Hi,
Sorry for long pause, but back on the job.
Yes, after reading your suggestion, I reminded of reading the same thing in the FSP integration guide. I had : UpdData->MemFastBoot = 1;
but I also had this : FspInitParams.NvsBufferPtr = NULL;
I believe once I pass some NVRAM buffer, it should work. But I have few doubts :
1. What sized-buffer should be good? 2. How do I refer the chunk of memory from SPI flash to act as the NvsBuffer? Any sample code will be appreciated.
Regards, Naveen ________________________________ From: Wim Vervoorn wvervoorn@eltan.com Sent: Thursday, November 7, 2019 1:56 PM To: Naveen Chaudhary naveenchaudhary2010@hotmail.com; werner.zeh@siemens.com werner.zeh@siemens.com Cc: coreboot@coreboot.org coreboot@coreboot.org Subject: RE: Call to FSP_FSP_INIT never returns back
Hello Naveen,
The longer time is expected on the first boot. After that this should not take that long.
If every boot takes that long please check if the MRC information is preserved in flash and properly restored before making the FSP call.
Best Regards,
Wim Vervoorn
From: Naveen Chaudhary [mailto:naveenchaudhary2010@hotmail.com] Sent: Thursday, November 7, 2019 7:02 AM To: werner.zeh@siemens.com Cc: coreboot@coreboot.org Subject: [coreboot] Re: Call to FSP_FSP_INIT never returns back
Hi fellow engineers,
I got that RAM stick working when I changed the fourth byte of SPD from from mini-UDIMM (0x06) to SO-DIMM (0x03) and its working fine... But still I am curious why mini-UDIMM didn't work out. Perhaps this form factor was not supported by FSP?
Another thing I observed that the call to FSP_FSP_INIT takes 7-8 seconds to return back. Is that expected? What could be the possible ways to optimize it (even an inflexible solution is welcome). The total boot time from power-on to loading payload is around 20 seconds with logs disabled.
Regards,
Naveen
Hello Naveen,
You should pass in the MRC data that was output on the first boot. Normally this is preserved in flash.
Best Regards, Wim Vervoorn
Eltan B.V. Ambachtstraat 23 5481 SM Schijndel The Netherlands
T : +31-(0)73-594 46 64 E : wvervoorn@eltan.com W : http://www.eltan.comhttp://www.eltan.com/
From: Naveen Chaudhary [mailto:naveenchaudhary2010@hotmail.com] Sent: Friday, December 13, 2019 12:45 PM To: Wim Vervoorn wvervoorn@eltan.com; werner.zeh@siemens.com Cc: coreboot@coreboot.org Subject: Re: Call to FSP_FSP_INIT never returns back
Hi,
Sorry for long pause, but back on the job.
Yes, after reading your suggestion, I reminded of reading the same thing in the FSP integration guide. I had : UpdData->MemFastBoot = 1;
but I also had this : FspInitParams.NvsBufferPtr = NULL;
I believe once I pass some NVRAM buffer, it should work. But I have few doubts :
1. What sized-buffer should be good? 2. How do I refer the chunk of memory from SPI flash to act as the NvsBuffer? Any sample code will be appreciated. Regards, Naveen ________________________________ From: Wim Vervoorn <wvervoorn@eltan.commailto:wvervoorn@eltan.com> Sent: Thursday, November 7, 2019 1:56 PM To: Naveen Chaudhary <naveenchaudhary2010@hotmail.commailto:naveenchaudhary2010@hotmail.com>; werner.zeh@siemens.commailto:werner.zeh@siemens.com <werner.zeh@siemens.commailto:werner.zeh@siemens.com> Cc: coreboot@coreboot.orgmailto:coreboot@coreboot.org <coreboot@coreboot.orgmailto:coreboot@coreboot.org> Subject: RE: Call to FSP_FSP_INIT never returns back
Hello Naveen,
The longer time is expected on the first boot. After that this should not take that long.
If every boot takes that long please check if the MRC information is preserved in flash and properly restored before making the FSP call.
Best Regards,
Wim Vervoorn
From: Naveen Chaudhary [mailto:naveenchaudhary2010@hotmail.com] Sent: Thursday, November 7, 2019 7:02 AM To: werner.zeh@siemens.commailto:werner.zeh@siemens.com Cc: coreboot@coreboot.orgmailto:coreboot@coreboot.org Subject: [coreboot] Re: Call to FSP_FSP_INIT never returns back
Hi fellow engineers,
I got that RAM stick working when I changed the fourth byte of SPD from from mini-UDIMM (0x06) to SO-DIMM (0x03) and its working fine... But still I am curious why mini-UDIMM didn't work out. Perhaps this form factor was not supported by FSP?
Another thing I observed that the call to FSP_FSP_INIT takes 7-8 seconds to return back. Is that expected? What could be the possible ways to optimize it (even an inflexible solution is welcome). The total boot time from power-on to loading payload is around 20 seconds with logs disabled.
Regards,
Naveen
-
Naveen Chaudhary -
Naveen Chaudhary
-
werner.zeh＠siemens.com -
Wim Vervoorn