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 <rminn...@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 <vered...@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-le...@coreboot.org
