Helllo,
I'm porting core boot to a bay trail board.
I noticed that starting from version 4.9, I can set the debug level of FSP.
I downloaded FSP for Bay trail and used Intel's BCT to modify it. But coreboot hangs after calling to the FSP binary.
How can I use the "FSP debug level" ?
Thank you, Zvika
Hi Zvika,
On 09.02.19 12:23, Zvi Vered wrote:
I noticed that starting from version 4.9, I can set the debug level of FSP.
I downloaded FSP for Bay trail and used Intel's BCT to modify it. But coreboot hangs after calling to the FSP binary.
How can I use the "FSP debug level" ?
This option is only implemented for the Broadwell-DE FSP. I've pushed a patch to move it accordingly[1], sorry for the confusion.
Also, generally, you need a build of FSP with debugging enabled. The public builds usually are not.
Nico
Hello! Nico you said here, "Also, generally, you need a build of FSP with debugging enabled. The public builds usually are not."
I agree that the public builds usually are not so enabled. What would need to be done to enable such a function?
Obviously to further dig into these issues, I'm going to need to be more involved, but, ah, that's not doable this month. ----- Gregg C Levine gregg.drwho8@gmail.com"This signature fought the Time Wars, time and again." On Sat, Feb 9, 2019 at 7:25 AM Nico Huber nico.h@gmx.de wrote:
Hi Zvika,
On 09.02.19 12:23, Zvi Vered wrote:
I noticed that starting from version 4.9, I can set the debug level of FSP.
I downloaded FSP for Bay trail and used Intel's BCT to modify it. But coreboot hangs after calling to the FSP binary.
How can I use the "FSP debug level" ?
This option is only implemented for the Broadwell-DE FSP. I've pushed a patch to move it accordingly[1], sorry for the confusion.
Also, generally, you need a build of FSP with debugging enabled. The public builds usually are not.
Nico
[1] https://review.coreboot.org/c/coreboot/+/31300 _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
Hi Nico, All,
I tried an FSP.fd with debug infro I got from Intel. For this purpose I had to change the "FSP location in CBFS" to 0xFFFB0000 (default was 0xFFFC0000) Following is the information I got via UART:
============= PEIM FSP v1.0 (VLYVIEW0 v0.0.3.5) ============= Register PPI Notify: DCD0BE23-9586-40F4-B643-06522CED4EDE Install PPI: 8C8CE578-8A3D-4F1C-9935-896185C32DD3 Install PPI: 5473C07A-3DCB-4DCA-BD6F-1E9689E7349A The 0th FV start address is 0x000FFFE0400, size is 0x00017C00, handle is 0x0 Register PPI Notify: 49EDB1C1-BF21-4761-BB12-EB0031AABB39 Register PPI Notify: EA7CA24B-DED5-4DAD-A389-BF827E8F9B38 Install PPI: B9E0ABFE-5979-4914-977F-6DEE78C278A6 Install PPI: DBE23AA9-A345-4B97-85B6-B226F1617389
Install PPI: 06E81C58-4AD7-44BC-8390-F10265F72480 Install PPI: 01F34D25-4DE2-23AD-3FF3-36353FF323F1
Install PPI: 49EDB1C1-BF21-4761-BB12-EB0031AABB39 Notify: PPI Guid: 49EDB1C1-BF21-4761-BB12-EB0031AABB39, Peim notify entry point: FFFE0FE4 The 1th FV start address is 0x000FFFB0000, size is 0x0002F400, handle is 0xFFFB0000
Install PPI: A55D6970-1306-440C-8C72-8F51FAFB2926
PcdMrcInitTsegSize = 8 PcdMrcInitMmioSize = 800 PcdMrcInitSPDAddr1 = A0 PcdMrcInitSPDAddr2 = A2 Setting BootMode to 0 Install PPI: 1F4C6F90-B06B-48D8-A201-BAE5F1CD7D56 Register PPI Notify: F894643D-C449-42D1-8EA8-85BDD8C65BDE About to call MrcInit(); BayleyBay Platform Type AutoSelfRefreshEnable = 0x2 RID = 0x11. Reg_EFF_DualCH_EN = 0x100301C0. CurrentMrcData.BootMode = 4 C0.D0: SPD not present. C1.D0: SPD not present. ============================================================================= What should be my next step ? Do you think the above info is what I need in order to configure FSP ?
Thank you, Zvika
On Sat, Feb 9, 2019 at 5:33 PM Gregg Levine gregg.drwho8@gmail.com wrote:
Hello! Nico you said here, "Also, generally, you need a build of FSP with debugging enabled. The public builds usually are not."
I agree that the public builds usually are not so enabled. What would need to be done to enable such a function?
Obviously to further dig into these issues, I'm going to need to be more involved, but, ah, that's not doable this month.
Gregg C Levine gregg.drwho8@gmail.com"This signature fought the Time Wars, time and again." On Sat, Feb 9, 2019 at 7:25 AM Nico Huber nico.h@gmx.de wrote:
Hi Zvika,
On 09.02.19 12:23, Zvi Vered wrote:
I noticed that starting from version 4.9, I can set the debug level of
FSP.
I downloaded FSP for Bay trail and used Intel's BCT to modify it. But coreboot hangs after calling to the FSP binary.
How can I use the "FSP debug level" ?
This option is only implemented for the Broadwell-DE FSP. I've pushed a patch to move it accordingly[1], sorry for the confusion.
Also, generally, you need a build of FSP with debugging enabled. The public builds usually are not.
Nico
[1] https://review.coreboot.org/c/coreboot/+/31300 _______________________________________________ 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
I had a discussion once with Russ Cox, a fairly well known person in this business :-), as he was reviewing some kernel code I'd written which was chock full of
#if DEBUG
as is the custom in so many kernels.
He really disliked the style and let me know so. His point was that in many cases, cpp-based debug macros are abused. They turn off code not in the critical path, so there is not a real performance-based justification for using them. In many cases, compiling out debug code means that, most of the time, when you really needed it, it is not there -- as in this case.
Which gets to my question: why on earth are there debug builds of FSP? Why isn't debugging always on? Debug stuff should always be on IMHO. As we've discovered, a lot of UEFI debug code *won't compile any more* because people got in the habit of leaving it out. You turn on debug macros and the UEFI build fails. We can imagine a day in which it's no longer possible to build a debug FSP either.
I realize we have the same kind of "debug build' behavior in coreboot, but we only ever enabled turning the debug level down in coreboot, ca. 2001, because FLASH space was tight -- this is why we have, e.g., the MAX console log level stuff. But turning down debug prints in coreboot was always a problem for me because, as always, the one time you really needed those prints, you found they were compiled out! But don't we leave all that stuff enabled by default nowadays? That's what I recall anyway ...
If anyone from Intel is reading this ... what's the reason for debug builds of FSP vs. non-debug? That approach has not worked tremendously well in UEFI, why have it in FSP?
On Sat, Feb 9, 2019 at 11:43 AM Zvi Vered veredz72@gmail.com wrote:1FAFB2926
C0.D0: SPD not present. C1.D0: SPD not present.
oh boy. No SPD? Do you need to set up some fake SPD then?
ron
Hello All,
Using the information from debug version of FSP, in the BCT I set: Tseg Size: 8MB MMIO Size: 2.0GB
For all other fields I used the default values. I created an FSP rom file and also checked the option in Core boot configuration: Configure defaults for the Intel FSP package'
With this scenario I managed to see the following coreboot output via console: -------------------------------------------------------------------------------------------------------------------------------------- coreboot-4.9-539-gde3ace0-dirty Mon Jan 28 13:44:10 UTC 2019 romstage starting (log level: 7)... RTC Init Starting the Intel FSP (early_init) CBFS: 'Master Header Locator' located CBFS at [200:200000) CBFS: Locating 'cpu_microcode_blob.bin' CBFS: Found @ offset 1fe00 size cc00 microcode: sig=0x30679 pf=0x1 revision=0x90a PM1_STS = 0x2100 PM1_CNT = 0x0 GEN_PMCON1 = 0x45008 prev_sleep_state = S5 Configure Default UPD Data PcdMrcInitSPDAddr1: 0xa0 (default) PcdMrcInitSPDAddr2: 0xa2 (default) PcdSataMode: 0x01 (set) PcdLpssSioEnablePciMode: 0x01 (default) PcdMrcInitMmioSize: 0x800 (default) PcdIgdDvmt50PreAlloc: 0x02 (default) PcdApertureSize: 0x02 (default) PcdGttSize: 0x02 (default) SerialDebugPortAddress: 0x3f8 (default) SerialDebugPortType: 0x01 (default) PcdMrcDebugMsg: 0x00 (default) PcdSccEnablePciMode: 0x01 (default) IgdRenderStandby: 0x00 (default) TxeUmaEnable: 0x00 (default) PcdOsSelection: 0x04 (default) PcdEMMC45DDR50Enabled: 0x01 (default) PcdEMMC45HS200Enabled: 0x00 (default) PcdEMMC45RetuneTimerValue: 0x08 (default) PcdEnableIgd: 0x01 (default) AutoSelfRefreshEnable: 0x00 (default) APTaskTimeoutCnt: 0x00 (default) GTT Size: 2 MB Tseg Size: 8 MB Aperture Size: 256 MB IGD Memory Size: 64 MB MMIO Size: 2048 MB MIPI/ISP: Disabled Sdio: Enabled Sdcard: Enabled SATA: Enabled SIO Dma 0: Enabled SIO I2C0: Enabled SIO I2C1: Enabled SIO I2C2: Enabled SIO I2C3: Enabled SIO I2C4: Enabled SIO I2C5: Enabled SIO I2C6: Enabled Azalia: Enabled SIO Dma1: Enabled Pwm0: Enabled Pwm1: Enabled Hsuart0: Enabled Hsuart1: Enabled Spi: Enabled Lpe: Disabled eMMC Mode: eMMC 4.5 SATA Mode: AHCI Xhci: Enabled CBFS: 'Master Header Locator' located CBFS at [200:200000) CBFS: Locating 'mrc.cache' CBFS: Found @ offset fdc0 size 10000 find_current_mrc_cache_local: No valid fast boot cache found. FSP MRC cache not present. ----------------------------------------------------------------------------------------------------------------------------------- And then nothing. Currently I configured "SeaBIOS" as payload.
What is the meaning of the last messages from coreboot ? Is it an error ?
Thank you, Zvika
On Sun, Feb 10, 2019 at 9:19 PM ron minnich rminnich@gmail.com wrote:
I had a discussion once with Russ Cox, a fairly well known person in this business :-), as he was reviewing some kernel code I'd written which was chock full of
#if DEBUG
as is the custom in so many kernels.
He really disliked the style and let me know so. His point was that in many cases, cpp-based debug macros are abused. They turn off code not in the critical path, so there is not a real performance-based justification for using them. In many cases, compiling out debug code means that, most of the time, when you really needed it, it is not there -- as in this case.
Which gets to my question: why on earth are there debug builds of FSP? Why isn't debugging always on? Debug stuff should always be on IMHO. As we've discovered, a lot of UEFI debug code *won't compile any more* because people got in the habit of leaving it out. You turn on debug macros and the UEFI build fails. We can imagine a day in which it's no longer possible to build a debug FSP either.
I realize we have the same kind of "debug build' behavior in coreboot, but we only ever enabled turning the debug level down in coreboot, ca. 2001, because FLASH space was tight -- this is why we have, e.g., the MAX console log level stuff. But turning down debug prints in coreboot was always a problem for me because, as always, the one time you really needed those prints, you found they were compiled out! But don't we leave all that stuff enabled by default nowadays? That's what I recall anyway ...
If anyone from Intel is reading this ... what's the reason for debug builds of FSP vs. non-debug? That approach has not worked tremendously well in UEFI, why have it in FSP?
On Sat, Feb 9, 2019 at 11:43 AM Zvi Vered veredz72@gmail.com wrote:1FAFB2926
C0.D0: SPD not present. C1.D0: SPD not present.
oh boy. No SPD? Do you need to set up some fake SPD then?
ron
Hi Ron.
For me the reason of decreasing the log level is boot time and not flash size. As we dump the log over the slow UART, a default log level of 7 or even 8 would mean several more seconds of boot time. In the past I had thought a few times about it and had the idea of separating CBMEM log from UART log with own log levels. In this scenario you can have a low level on UART which gives you boot time benefits while you can get the full log from CBMEM once you made it into the OS. I admit that in this case you will lose the needed debug information once your board will not boot, but this is a case which needs to be treated in a special way anyway.
Werner
-----Ursprüngliche Nachricht----- Von: ron minnich [mailto:rminnich@gmail.com] Gesendet: Sonntag, 10. Februar 2019 20:20 An: Zvi Vered Cc: Gregg Levine; coreboot Betreff: [coreboot] Re: 4.9: FSP debug level (0-3) Wichtigkeit: Hoch
I had a discussion once with Russ Cox, a fairly well known person in this business :-), as he was reviewing some kernel code I'd written which was chock full of
#if DEBUG
as is the custom in so many kernels.
He really disliked the style and let me know so. His point was that in many cases, cpp-based debug macros are abused. They turn off code not in the critical path, so there is not a real performance-based justification for using them. In many cases, compiling out debug code means that, most of the time, when you really needed it, it is not there -- as in this case.
Which gets to my question: why on earth are there debug builds of FSP? Why isn't debugging always on? Debug stuff should always be on IMHO. As we've discovered, a lot of UEFI debug code *won't compile any more* because people got in the habit of leaving it out. You turn on debug macros and the UEFI build fails. We can imagine a day in which it's no longer possible to build a debug FSP either.
I realize we have the same kind of "debug build' behavior in coreboot, but we only ever enabled turning the debug level down in coreboot, ca. 2001, because FLASH space was tight -- this is why we have, e.g., the MAX console log level stuff. But turning down debug prints in coreboot was always a problem for me because, as always, the one time you really needed those prints, you found they were compiled out! But don't we leave all that stuff enabled by default nowadays? That's what I recall anyway ...
If anyone from Intel is reading this ... what's the reason for debug builds of FSP vs. non-debug? That approach has not worked tremendously well in UEFI, why have it in FSP?
On Sat, Feb 9, 2019 at 11:43 AM Zvi Vered veredz72@gmail.com wrote:1FAFB2926
C0.D0: SPD not present. C1.D0: SPD not present.
oh boy. No SPD? Do you need to set up some fake SPD then?
ron _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
On Sun, Feb 10, 2019 at 10:46 PM Zeh, Werner werner.zeh@siemens.com wrote:
Hi Ron.
For me the reason of decreasing the log level is boot time and not flash size.
Werner, this is a good reason to ensure that debug messages can be turned off. This is why coreboot has console loglevel controls.
So it makes sense to be able to control the log level, no question. I'm not arguing that.
What I'm saying is that the concept of a 'debug build', which seems to derive from windows practice (I'm not kidding!), is a bad idea for FSP. There should not be a debug build. There should always be one build, not least because sometimes debug builds can fail in odd ways at build or boot time, due to design or programming errors. I've seen this in practice in UEFI, where enabling debug messages breaks the UEFI build.
FSP should create a single build with a tunable console print level. I am hoping someone from Intel will take note.
IMHO debug builds are a bad idea.
I agree Ron, there is no need of a debug build. It should be just one build.
Werner
-----Ursprüngliche Nachricht----- Von: ron minnich [mailto:rminnich@gmail.com] Gesendet: Montag, 11. Februar 2019 16:20 An: Zeh, Werner (DF MC MTS R&D HW 1) Cc: Zvi Vered; Gregg Levine; coreboot Betreff: Re: [coreboot] Re: 4.9: FSP debug level (0-3) Wichtigkeit: Hoch
On Sun, Feb 10, 2019 at 10:46 PM Zeh, Werner werner.zeh@siemens.com wrote:
Hi Ron.
For me the reason of decreasing the log level is boot time and not flash size.
Werner, this is a good reason to ensure that debug messages can be turned off. This is why coreboot has console loglevel controls.
So it makes sense to be able to control the log level, no question. I'm not arguing that.
What I'm saying is that the concept of a 'debug build', which seems to derive from windows practice (I'm not kidding!), is a bad idea for FSP. There should not be a debug build. There should always be one build, not least because sometimes debug builds can fail in odd ways at build or boot time, due to design or programming errors. I've seen this in practice in UEFI, where enabling debug messages breaks the UEFI build.
FSP should create a single build with a tunable console print level. I am hoping someone from Intel will take note.
IMHO debug builds are a bad idea.
Hi Zvika,
On 09.02.19 20:40, Zvi Vered wrote:
PcdMrcInitSPDAddr1 = A0 PcdMrcInitSPDAddr2 = A2 ... C0.D0: SPD not present. C1.D0: SPD not present.
Did you solve this SPD problem yet? If not, this is likely still where your later logs end, i.e. in FSP's raminit. It seems you try to tell FSP to read them from the SMBus addresses above. If the addresses are cor- rect and the SPD chips present, it might not find them because the SMBus is not functional. IIRC, you have to configure the SoC pads explicitly to be used for SMBus. This is the first thing I'd investigate.
If you could push your code to Gerrit, or any public Git repository, we might be able to help you better.
Nico
Hi Nico,
I did not do any code changes in coreboot. The messages are coming from a debug version of FSP I got from Intel. I did not patch this fsp.fd at all.
I expected that this version will help me to patch my FSP using BCT. Can you tell how to use the above FSP messages to patch FSP ? For example: what are RID , Reg_EFF_DualCH_EN ?
Attached the output of dmidecode and decode-dimms I ran on this board under ubuntu. Hope I can attach files here.
Thank you, Zvika
On Tue, Feb 12, 2019 at 8:35 PM Nico Huber nico.h@gmx.de wrote:
Hi Zvika,
On 09.02.19 20:40, Zvi Vered wrote:
PcdMrcInitSPDAddr1 = A0 PcdMrcInitSPDAddr2 = A2 ... C0.D0: SPD not present. C1.D0: SPD not present.
Did you solve this SPD problem yet? If not, this is likely still where your later logs end, i.e. in FSP's raminit. It seems you try to tell FSP to read them from the SMBus addresses above. If the addresses are cor- rect and the SPD chips present, it might not find them because the SMBus is not functional. IIRC, you have to configure the SoC pads explicitly to be used for SMBus. This is the first thing I'd investigate.
If you could push your code to Gerrit, or any public Git repository, we might be able to help you better.
Nico
Hello Zvi,
The Baytrail FSP doesn’t support the debug levels.
So unfortunately this will not help you.
Most likely your issue is in the memory configuration. What you can do is have a look at the port 80 codes. This provides an indication of where the problem is in the FSP.
Best regards,
Wim Vervoorn
From: Zvi Vered [mailto:veredz72@gmail.com] Sent: Saturday, February 9, 2019 12:24 PM To: coreboot@coreboot.org Subject: [coreboot] 4.9: FSP debug level (0-3)
Helllo,
I'm porting core boot to a bay trail board.
I noticed that starting from version 4.9, I can set the debug level of FSP.
I downloaded FSP for Bay trail and used Intel's BCT to modify it. But coreboot hangs after calling to the FSP binary.
How can I use the "FSP debug level" ?
Thank you, Zvika
Hi Wim,
Thank you very much for your reply.
Best regards. Zvika
On Wed, Feb 20, 2019 at 10:14 AM Wim Vervoorn wvervoorn@eltan.com wrote:
Hello Zvi,
The Baytrail FSP doesn’t support the debug levels.
So unfortunately this will not help you.
Most likely your issue is in the memory configuration. What you can do is have a look at the port 80 codes. This provides an indication of where the problem is in the FSP.
Best regards,
Wim Vervoorn
*From:* Zvi Vered [mailto:veredz72@gmail.com] *Sent:* Saturday, February 9, 2019 12:24 PM *To:* coreboot@coreboot.org *Subject:* [coreboot] 4.9: FSP debug level (0-3)
Helllo,
I'm porting core boot to a bay trail board.
I noticed that starting from version 4.9, I can set the debug level of FSP.
I downloaded FSP for Bay trail and used Intel's BCT to modify it.
But coreboot hangs after calling to the FSP binary.
How can I use the "FSP debug level" ?
Thank you,
Zvika
coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
-
Gregg Levine -
Nico Huber -
ron minnich -
Wim Vervoorn -
Zeh, Werner -
Zvi Vered