Hi Stefan, First of all: thank you for the quick response. Yes I work on a prototype from GE :-)
OK - now to your questions: - the flashchip is connected as follows: SPI_CLK + SPI_MOSI are connected via a FET_busswitch, and SPI_MISI is connected directly to the chipset. - I can use FPT.EXE from intel, and it successfully reads the content of the flashchip - but only 4MB!!! - the file, I got from the hardware development, that should be used here, also has 4MB!!!??? Best regards Thomas P.S.: Bist Du etwa ein Student an der TU Wien - sprichst Du also Deutsch? -----Original Message----- From: Stefan Tauner [mailto:[email protected]] Sent: Mittwoch, 17. August 2011 04:38 To: Frei, Thomas (GE Germany) Cc: [email protected] 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)" <[email protected]> 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 [email protected] > 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.@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 _______________________________________________ flashrom mailing list [email protected] http://www.flashrom.org/mailman/listinfo/flashrom
