the two logs appended show the differences in the output between current head (r1322) and after all of these have been applied.
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
On Sun, 29 May 2011 17:51:46 +0200 Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net wrote:
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.
i have said ichspi is too verbose multiple times in the past and everybody told me "nah, we want all possible output that helps debugging". the descriptor contents are important if we debug hardware sequencing and/or descriptor mode and the output in my log is only produced if descriptors are enabled (iirc). regarding the format itself... that is based on mazzoo's work and i have not changed much. i can look into it and trim/compress it where i think it does make sense.
but copy&paste should not be considered as a problematic use case imho. the output should be captured by a logfile option (on my growing todo list :P) or with redirection. but too verbose output is a usability problem in itself, because not seeing the forest for the trees etc., so i basically agree with you.
i could live with using barf for the moment, but imho it does make sense to differentiate more too (it's just more work and ichspi would be the only user for now).
-
Carl-Daniel Hailfinger -
Stefan Tauner