[flashrom] report for Intel QM67 | Winbond W25Q64 ([PATCH] (not for merge) ichspi: print BFPR (BIOS Flash Primary Region Register))

[Stefan Tauner]

On Tue, 16 Aug 2011 15:06:32 +0200
"Frei, Thomas (GE Germany)" <Thomas.Frei at ge.com> wrote:

hello thomas and thanks for your report!

sorry for the lengthy mail... especially because it does not contain a
real solution yet, but maybe there will be one when we are done with
this thread :)

> -       Intel QM67 is supported but untested.

the basic SPI interface of the 6 series intel chipsets is not different
from the earlier series. they have changed a few things behind the
curtain though, which we don't understand fully yet. that could be the
cause here.

> -       Mainboard flash write protection is not existant

i beg to differ. there is a chipset protection in place, but we don't
know how it works exactly. :)

> […]
> 
> First I tried to read the flashcontent -> ERROR!!!
> 
> I didn't try to write jet - and I will not until the read is solved.

good idea, because it most certainly will fail.

> Please help me - I will provide you all information you will need.

that would be great, but i fear you just don't have the information we
need, or if you do you would be violating an NDA. :)

> flashrom v0.9.4-r1395 on Linux 2.6.34-TSW (i686), built with libpci 3.1.7, GCC 4.5.0 20100604 [gcc-4_5-branch revision 160292], little endian
> flashrom is free software, get the source code at http://www.flashrom.org
> 
> Calibrating delay loop... OS timer resolution is 1 usecs, 1496M loops per second, 10 myus = 10 us, 100 myus = 100 us, 1000 myus = 1001 us, 10000 myus = 10005 us, 4 myus = 4 us, OK.
> Initializing internal programmer
> No coreboot table found.
> DMI string system-manufacturer: ""
> DMI string system-product-name: ""
> DMI string system-version: ""
> DMI string baseboard-manufacturer: ""
> DMI string baseboard-product-name: ""
> DMI string baseboard-version: ""
> DMI string chassis-type: ""
> DMI chassis-type is not specific enough.
> Found chipset "Intel QM67" with PCI ID 8086:1c4f. 
> This chipset is marked as untested. If you are using an up-to-date version
> of flashrom please email a report to flashrom at flashrom.org including a
> verbose (-V) log. Thank you!

i guess you are working on a prototype for GE? in general we try to
detect laptops because we don't support them very well yet. please see
http://flashrom.org/Laptops for details why we care to detect them.
your DMI table seems to not indicate explicitly enough if it is a
laptop or not. that is not necessarily a problem in general, i just
wanted to mention it in case you are involved in the firmware design.

in case you know it, could you please tell us a bit about the hardware
design regarding the chipset<->flash connection? main question: is the
flash chip directly connected to the qm67? are there any (external) ECs
involved?

> Enabling flash write... 
> […]
> BIOS Lock Enable: disabled, BIOS Write Enable: disabled, BIOS_CNTL is 0x8
> 
> Root Complex Register Block address = 0xfed1c000
> GCS = 0xc21: BIOS Interface Lock-Down: enabled, BOOT BIOS Straps: 0x3 (LPC)

that's actually a bug. intel has changed the meaning of the bits in the GCS *again*.
i'll look into it.
afaics it is cosmetic only on all chipsets except ICH7, so it is not a
problem for you thomas.

> 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.

this is the first sign of the real problem. FDV=1 means the descriptor
in the flash is valid and FLOCKDN=1 means that we are restricted in
changing most of the relevant SPI settings. this is (officially)
required since at least ibex peak (5 series). alone, it is not a problem.
FDOPSS=1 is an override bit (Flash Descriptor Override Pin-Strap
Status), that is set by a hardware strap. is this accessible to you by
a switch of some sort (e.g. jumper)?

> 0x06: 0x0f00 (HSFC)
> HSFC: FGO=0, FCYCLE=0, FDBC=15, SME=0
> 0x08: 0x00400000 (FADDR)
> 0x50: 0x0000ffff (FRAP)
> BMWAG 0x00, BMRAG 0x00, BRWA 0xff, BRRA 0xff

0xffff comes from the FDOPSS=1 and (should) indicate that we are
allowed to access all regions of the flash (read and write).

> 0x54: 0x00000000 (FREG0: Flash Descriptor)
> 0x00000000-0x00000fff is read-write
> 0x58: 0x03ff0200 (FREG1: BIOS)
> 0x00200000-0x003fffff is read-write
> 0x5C: 0x01ff0001 (FREG2: Management Engine)
> 0x00001000-0x001fffff is read-write
> 0x60: 0x00000fff (FREG3: Gigabit Ethernet)
> Gigabit Ethernet region is unused.
> 0x64: 0x00000fff (FREG4: Platform Data)
> Platform Data region is unused.

the following registers indicate no protected address regions either.

> 0x74: 0x00000000 (PR0)
> 0x78: 0x00000000 (PR1)
> 0x7C: 0x00000000 (PR2)
> 0x80: 0x00000000 (PR3)
> 0x84: 0x00000000 (PR4)

> 0x90: 0x84 (SSFS)
> SSFS: SCIP=0, FDONE=1, FCERR=0, AEL=0
> 0x91: 0xf80000 (SSFC)
> SSFC: SCGO=0, ACS=0, SPOP=0, COP=0, DBC=0, SME=0, SCF=0
> 0x94: 0x0006     (PREOP)
> 0x96: 0x043b     (OPTYPE)
> 0x98: 0x05200302 (OPMENU)
> 0x9C: 0x0000019f (OPMENU+4)
> 0xA0: 0x00000000 (BBAR)
> 0xD0: 0x00000000 (FPB)
> Reading OPCODES... done
> preop0=0x06, preop1=0x00
> op[0]=0x02, 3, 0
> op[1]=0x03, 2, 0
> op[2]=0x20, 3, 0
> op[3]=0x05, 0, 0
> op[4]=0x9f, 0, 0
> op[5]=0x01, 1, 0
> op[6]=0x00, 0, 0
> op[7]=0x00, 0, 0
> 
> SPI Read Configuration: prefetching enabled, caching enabled, OK.
> This chipset supports the following protocols: FWH, SPI.
> […]
> Probing for Winbond W25Q64, 8192 kB: probe_spi_rdid_generic: id1 0xef, id2 0x4017
> Chip status register is 00
> […]
> Reading flash... SSFS: SCIP=0, FDONE=1, FCERR=1, AEL=0
> SSFC: SCGO=0, ACS=0, SPOP=0, COP=1, DBC=63, SME=0, SCF=0
> Running OPCODE 0x03 failed at address 0x400000 (payload length was 64).
> FAILED.

now the interesting part. let's repeat the output of the FREGs
ordered by address range:
> 0x54: 0x00000000 (FREG0: Flash Descriptor)
> 0x00000000-0x00000fff is read-write
> 0x5C: 0x01ff0001 (FREG2: Management Engine)
> 0x00001000-0x001fffff is read-write
> 0x58: 0x03ff0200 (FREG1: BIOS)
> 0x00200000-0x003fffff is read-write
transaction err. at 400000
so the first transaction after the bios region fails. not that this is
also the first address that is not described by any FREG. i can't
remember right now if this was ever a problem.
my suspicion is that the chipset prohibits any access to addresses that
are not mentioned/described by the FREGs. i have "only" two (retail)
boards with intel chipsets for testing. both have the whole address
range covered by the FREGs (but have other problems.. namely the known
write protection by FRAP/PR*). i will need to look into this further
(searching for other reports).

how big is the image you want to write? (it is obviously 8MB because
else flashrom would not continue, but did you modify it and was it 4MB
before?)
are you able to write the flash with intel's tool (iirc it is called
FIT) under windows/dos? do you have access to the firmware modules that
are combined to the full image and can you modify the descriptor part?
if so it would be interesting to see what happens when you increase the
FREG1.limit bits from 0x003fffff to 0x007fffff so that the bios region
covers the second half of the flash too (this can be done by modifying
the descriptor afaik). if i am right this would allow flashrom to access
the whole flash.

another thing you could test are my hardware sequencing patches posted
to this list and also accessible via
http://patchwork.coreboot.org/bundle/stefanct/hwseq/). but i doubt that
hwseq will behave different from swseq in this case. OTOH it would be
nice to confirm this.

if it is not too inconvenient i would like to see the verbose output of
a flashrom version modified by the attached patch to output BFPR. this
should be equal to FREG1 and therefor we do not print it normally.
it will certainly not change the general behavior in your case, i just
want to be sure we know every possible detail.

a workaround for your problem would be to change flashrom in a way
that it does not try to access addresses > 0x003fffff. currently this
is only possible while writing (see layout option in the manpage). so
you would probably want to hardcode the limit in flashrom to solve the
problem quickly but ugly.

-- 
Kind regards/Mit freundlichen Grüßen, Stefan Tauner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-not-for-merge-ichspi-print-BFPR-BIOS-Flash-Primary-R.patch
Type: text/x-patch
Size: 1028 bytes
Desc: not available
URL: <http://www.flashrom.org/pipermail/flashrom/attachments/20110817/57e216f6/attachment.patch>