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