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

Fri Aug 19 08:37:48 CEST 2011

Hi,

I patched my flashrom an here is the output of the new code:

---snip---
0x00: 0x03ff0200 (BFPR)
0x00200000-0x003fffff
---snip---

Is this, what you expected?

If I want to hack my flashrom:
- will it be possible to read the flash, or only to write it?
- where will I have to change and what exactly, to have the quick, dirty and ugly hack working?
(I tried to search for "limit" and changed it to 0x3fffff and 0x7fffff - but nothing changed in behavior)

Best regards

Thomas

P.S.: I know Helge Wagner, he is a colleague of me, but he is very  busy, because he is our local one man BIOS/UEFI department. His Boss told me, not to bother him.

-----Original Message-----
From: Stefan Tauner [mailto:stefan.tauner at student.tuwien.ac.at] 
Sent: Mittwoch, 17. August 2011 04:38
To: Frei, Thomas (GE Germany)
Cc: flashrom at flashrom.org
Subject: Re: [flashrom] report for Intel QM67 | Winbond W25Q64 ([PATCH] (not for merge) ichspi: print BFPR (BIOS Flash Primary Region Register))

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