[flashrom] [PATCH 00/11] ichspi patches 4.0 - logs showing the new output

Carl-Daniel Hailfinger c-d.hailfinger.devel.2006 at gmx.net
Sun May 29 17:51:46 CEST 2011


Am 29.05.2011 02:31 schrieb Stefan Tauner:
> the two logs appended show the differences in the output between
> current head (r1322) and after all of these have been applied.
>
> Found chipset "Intel QS57", enabling flash write... chipset PCI ID is 8086:3b0f, 
> 0xfff80000/0xffb80000 FWH IDSEL: 0x0
> 0xfff00000/0xffb00000 FWH IDSEL: 0x0
> 0xffe80000/0xffa80000 FWH IDSEL: 0x0
> 0xffe00000/0xffa00000 FWH IDSEL: 0x0
> 0xffd80000/0xff980000 FWH IDSEL: 0x0
> 0xffd00000/0xff900000 FWH IDSEL: 0x0
> 0xffc80000/0xff880000 FWH IDSEL: 0x0
> 0xffc00000/0xff800000 FWH IDSEL: 0x0
> 0xff700000/0xff300000 FWH IDSEL: 0x4
> 0xff600000/0xff200000 FWH IDSEL: 0x5
> 0xff500000/0xff100000 FWH IDSEL: 0x6
> 0xff400000/0xff000000 FWH IDSEL: 0x7
> 0xfff80000/0xffb80000 FWH decode enabled
> 0xfff00000/0xffb00000 FWH decode enabled
> 0xffe80000/0xffa80000 FWH decode enabled
> 0xffe00000/0xffa00000 FWH decode enabled
> 0xffd80000/0xff980000 FWH decode enabled
> 0xffd00000/0xff900000 FWH decode enabled
> 0xffc80000/0xff880000 FWH decode enabled
> 0xffc00000/0xff800000 FWH decode enabled
> 0xff700000/0xff300000 FWH decode enabled
> 0xff600000/0xff200000 FWH decode enabled
> 0xff500000/0xff100000 FWH decode enabled
> 0xff400000/0xff000000 FWH decode enabled
> Maximum FWH chip size: 0x400000 bytes
> BIOS Lock Enable: disabled, BIOS Write Enable: enabled, BIOS_CNTL is 0x1
>
> Root Complex Register Block address = 0xfed1c000
> GCS = 0xc61: BIOS Interface Lock-Down: enabled, BOOT BIOS Straps: 0x3 (LPC)
> Top Swap : not enabled
> SPIBAR = 0xfed1c000 + 0x3800
> 0x04: 0xe008 (HSFS)
> HSFS: FDONE=0, FCERR=0, AEL=0, BERASE=1, SCIP=0, FDOPSS=1, FDV=1, FLOCKDN=1
> WARNING: SPI Configuration Lockdown activated.
> 0x06: 0x3f04 (HSFC)
> HSFC: FGO=0, FCYCLE=2, FDBC=63, SME=0
> 0x50: 0x00000a0b (FRAP)
> BMWAG 0x00, BMRAG 0x00, BRWA 0x0a, BRRA 0x0b
> 0x54: 0x00000000 (FREG0: Flash Descriptor)
> 0x00000000-0x00000fff is read-only
> 0x58: 0x07ff0500 (FREG1: BIOS)
> 0x00500000-0x007fffff is read-write
> 0x5C: 0x04ff0003 (FREG2: Management Engine)
> 0x00003000-0x004fffff is locked
> 0x60: 0x00020001 (FREG3: Gigabit Ethernet)
> 0x00001000-0x00002fff is read-write
> 0x64: 0x00000fff (FREG4: Platform Data)
> Platform Data region is unused.
> 0x74: 0x9fff07d0 (PR0)
> 0x78: 0x00000000 (PR1)
> 0x7C: 0x00000000 (PR2)
> 0x80: 0x00000000 (PR3)
> 0x84: 0x00000000 (PR4)
> 0x90: 0x04 (SSFS)
> SSFS: SCIP=0, FDONE=1, FCERR=0, AEL=0
> 0x91: 0xf84240 (SSFC)
> SSFC: SCGO=0, ACS=0, SPOP=0, COP=4, DBC=2, SME=0, SCF=0
> 0x94: 0x5006     (PREOP)
> 0x96: 0x143b     (OPTYPE)
> 0x98: 0x05200302 (OPMENU)
> 0x9C: 0x0601209f (OPMENU+4)
> 0xA0: 0x00000000 (BBAR)
> 0xC4: 0x00802005 (LVSCC)
> LVSCC: EBS=0x1, WG=1, WSR=0, WEWS=0, EO=0x20, VCL=1
> 0xC8: 0x00002005 (UVSCC)
> UVSCC: EBS=0x1, WG=1, WSR=0, WEWS=0, EO=0x20, VCL=0
> 0xD0: 0x00000000 (FPB)
>
> Reading flash descriptors mapped by the chipset via FDOC/FDOD... done
> === FDBAR ===
> FLVALSIG 0x0ff0a55a
> FLMAP0   0x03040002
> FLMAP1   0x10100206
> FLMAP2   0x00000020
>
> --- FDBAR details ---
> 0x03        NR    Number of Regions
> 0x00000040  FRBA  Flash Region Base Address
> 0x00        NC    Number of Components
> 0x00000020  FCBA  Flash Component Base Address
>
> 0x10        ISL   ICH Strap Length
> 0x00000100  FISBA Flash ICH Strap Base Address
> 0x02        NM    Number of Masters
> 0x00000060  FMBA  Flash Master Base Address
>
> 0x00        MSL   MCH Strap Length
> 0x00000200  FMSBA Flash MCH Strap Base Address
>
> === FCBA ===
> FLCOMP   0x0990001c
> FLILL    0x00000000
>
> --- FCBA details ---
> 0x01    freq_read_id   33 MHz
> 0x01    freq_write     33 MHz
> 0x04    freq_fastread  50 MHz
> 0x01    fastread       supported
> 0x00    freq_read      20 MHz
> 0x04    comp 1 density 8 MB
> 0x03    comp 2 is not used (FLMAP0.NC=0)
>
> 0x00    invalid instr 0
> 0x00    invalid instr 1
> 0x00    invalid instr 2
> 0x00    invalid instr 3
>
> === FRBA ===
>   

Please drop the empty line and the section heading. You can prefix each
of the following lines with FRBA if you think that's needed.


> FLREG0   0x00000000
> FLREG1   0x07ff0500
> FLREG2   0x04ff0003
> FLREG3   0x00020001
>
> --- FRBA details ---
> 0x00000000  region 0 limit (descr)
> 0x00000000  region 0 base  (descr)
> 0x007ff000  region 1 limit ( BIOS)
> 0x00500000  region 1 base  ( BIOS)
> 0x004ff000  region 2 limit ( ME  )
> 0x00003000  region 2 base  ( ME  )
> 0x00002000  region 3 limit ( GbE )
> 0x00001000  region 3 base  ( GbE )
>
> === FMBA ===
> FLMSTR1  0x0a0b0000
> FLMSTR2  0x0c0d0000
> FLMSTR3  0x08080118
>
> --- FMBA details ---
> BIOS can     write GbE
> BIOS can NOT write ME
> BIOS can     write BIOS
> BIOS can NOT write descr
> BIOS can     read  GbE
> BIOS can NOT read  ME
> BIOS can     read  BIOS
> BIOS can     read  descr
> ME   can     write GbE
> ME   can     write ME
> ME   can NOT write BIOS
> ME   can NOT write descr
> ME   can     read  GbE
> ME   can     read  ME
> ME   can NOT read  BIOS
> ME   can     read  descr
> GbE  can     write GbE
> GbE  can NOT write ME
> GbE  can NOT write BIOS
> GbE  can NOT write descr
> GbE  can     read  GbE
> GbE  can NOT read  ME
> GbE  can NOT read  BIOS
> GbE  can NOT read  descr
>
>
>   

With all due respect, this is too long to be useful. We want verbose
output to be as short as possible for any given piece of info. ICH
verbose output was already too much, but 89 additional lines are a real
problem for cut-n-paste.

Right now we have the following message levels:
ERR, INFO, DEBUG, BARF.
-V gives you everything up to (including) DEBUG.
-VV gives you really everything and is useless unless you're debugging a
driver.

We could introduce an additional message level DEBUG2 (msg_[pcg]dbg2)
between DEBUG and BARF and require -VVV for BARF. Quite a few ICH debug
messages could be moved to DEBUG2 and we'd keep the normal verbose
output readable. That would remove some of the pressure for keeping
messages terse. However, even with DEBUG2 we want a reasonable set of
DEBUG messages.

I'd like to open a discussion about this before we proceed.

Regards,
Carl-Daniel

-- 
http://www.hailfinger.org/





More information about the flashrom mailing list