On Fri, Jun 27, 2008 at 06:28:34PM +0200, svn@coreboot.org wrote:
Log:
- ICH7 SPI support
- fix some variable names in ichspi.c (Offset -> offset)
- Dump ICH7 SPI bar with -V
- Improve error message in case IOPL goes wrong.
Unfortunately this patch broke flashrom on ICH7 not using SPI for at least one user as reported on IRC just now. :(
Should we just back it out for now? Stefan, do you know what could cause the problem? Rudolf, maybe you have an idea since you know the chipset too?
Rudolf - if you have your ICH7 SPI patch in a version that applies to 3392, maybe the reporter should try that?
I asked the reporter to send a message to flashrom@ and I got a promise about testing patches to fix the problem. :)
//Peter
On Sat, Jun 28, 2008 at 06:38:01PM +0200, Peter Stuge wrote:
Unfortunately this patch broke flashrom on ICH7 not using SPI for at least one user as reported on IRC just now. :(
..
I asked the reporter to send a message to flashrom@ and I got a promise about testing patches to fix the problem. :)
I had an idea. The attached patch fixes flashrom 3393 on non-SPI ICH7 at least for the reporter.
The second hunk is needed for me to be able to compile flashrom with gcc 4.2.2. That should teach me to build test before I ack. Also there seems to be a bit of whitespace damage in the 3393 patch.
//Peter
Peter Stuge wrote:
On Sat, Jun 28, 2008 at 06:38:01PM +0200, Peter Stuge wrote:
Unfortunately this patch broke flashrom on ICH7 not using SPI for at least one user as reported on IRC just now. :(
..
I asked the reporter to send a message to flashrom@ and I got a promise about testing patches to fix the problem. :)
I had an idea. The attached patch fixes flashrom 3393 on non-SPI ICH7 at least for the reporter.
The second hunk is needed for me to be able to compile flashrom with gcc 4.2.2. That should teach me to build test before I ack. Also there seems to be a bit of whitespace damage in the 3393 patch.
Yes, that fix is fine, thanks.
I was having a cleanup of the whole SPI/LPC bus handling in mind:
we have _1_ global variable (per instance of "flashes"?) instead of one per supported chipset.
This variable is an ENUM
enum flash_bus { FLASH_BUS_LPC, FLASH_BUS_ICH7_SPI, FLASH_BUS_ICH9_SPI, FLASH_BUS_VIA_SPI, FLASH_BUS_IT87_SPI }
I think this matches the physical actualities much better than the design-less hack that is used at the moment. Also the code could be much nicer in many places, as we could use case statements instead of endless if () else if () else if() statements
But even without this: Instead of unconditionally setting ich7_detected, it should only be conditionally set if bbs == 1 (SPI) because the flag really means "spi_strapping_detected_on_ich7"
On Sat, Jun 28, 2008 at 07:37:53PM +0200, Stefan Reinauer wrote:
I had an idea. The attached patch fixes flashrom 3393 on non-SPI ICH7 at least for the reporter.
Yes, that fix is fine, thanks.
Is this an ack? :)
I was having a cleanup of the whole SPI/LPC bus handling in mind:
Oh yes, but we'll save it for later. :)
But even without this: Instead of unconditionally setting ich7_detected, it should only be conditionally set if bbs == 1 (SPI) because the flag really means "spi_strapping_detected_on_ich7"
Right! What does bbs == 0 mean? chipset_enable.c prints SPI for both 1 and 0 at the moment.
//Peter
On 28.06.2008 19:37, Stefan Reinauer wrote:
I was having a cleanup of the whole SPI/LPC bus handling in mind:
we have _1_ global variable (per instance of "flashes"?) instead of one per supported chipset.
This variable is an ENUM
enum flash_bus { FLASH_BUS_LPC, FLASH_BUS_ICH7_SPI, FLASH_BUS_ICH9_SPI, FLASH_BUS_VIA_SPI, FLASH_BUS_IT87_SPI }
Looks nice. Can we add a bus for those old (29*) parallel flash chips? I assume differentiating between LPC and FWH will be difficult because FWH is just a LPC variant and some chipsets do not allow us to detect FWH/LPC
I think this matches the physical actualities much better than the design-less hack that is used at the moment. Also the code could be much nicer in many places, as we could use case statements instead of endless if () else if () else if() statements
What happens if there is more than one flash bus? Do we call the probe functions compatible with the bus once per bus? If we do that, we can stop after the first detected chip.
for (i=0; i<buscount; i++) { for (j=0; j<chipcount; j++) { if (!compatible(bus[i], flashchips[j]) continue; found = flashchips[j].probe(bus[i], flashchips[j]); if (!found) continue; //add (chip,bus) pair to list of found chips break; } }
Benefits of that approach: * my "generic unknown flash chip" entries will work perfectly as expected * it allows us to integrate drivers for external flashers * probing for chips strapped to a non-default location (ID!=0) is trivial.
Regards Carl-Daniel
Carl-Daniel Hailfinger wrote:
On 28.06.2008 19:37, Stefan Reinauer wrote:
I was having a cleanup of the whole SPI/LPC bus handling in mind:
we have _1_ global variable (per instance of "flashes"?) instead of one per supported chipset.
This variable is an ENUM
enum flash_bus { FLASH_BUS_LPC, FLASH_BUS_ICH7_SPI, FLASH_BUS_ICH9_SPI, FLASH_BUS_VIA_SPI, FLASH_BUS_IT87_SPI }
Looks nice. Can we add a bus for those old (29*) parallel flash chips? I assume differentiating between LPC and FWH will be difficult because FWH is just a LPC variant and some chipsets do not allow us to detect FWH/LPC
I don't think it makes much sense to differentiate between 29* types, lpc and fwh: The physical bus looks exactly the same from a software perspective; until after you scanned the bus and know which category the chip you found belongs to. And then the data is not exactly interesting anymore.
I think this matches the physical actualities much better than the design-less hack that is used at the moment. Also the code could be much nicer in many places, as we could use case statements instead of endless if () else if () else if() statements
What happens if there is more than one flash bus? Do we call the probe functions compatible with the bus once per bus? If we do that, we can stop after the first detected chip.
Not necessarily. You can have multiple chips on the same FWH "bus", so stopping after you find the first chip is not an option.
But, I suggest we consider multiple flash busses once we see that happen in the real world. At least the ICH is always strapped to either FWH _or_ SPI.
Stefan
On 28.06.2008 22:30, Stefan Reinauer wrote:
Carl-Daniel Hailfinger wrote:
On 28.06.2008 19:37, Stefan Reinauer wrote:
I was having a cleanup of the whole SPI/LPC bus handling in mind:
we have _1_ global variable (per instance of "flashes"?) instead of one per supported chipset.
This variable is an ENUM
enum flash_bus { FLASH_BUS_LPC, FLASH_BUS_ICH7_SPI, FLASH_BUS_ICH9_SPI, FLASH_BUS_VIA_SPI, FLASH_BUS_IT87_SPI }
Looks nice. Can we add a bus for those old (29*) parallel flash chips? I assume differentiating between LPC and FWH will be difficult because FWH is just a LPC variant and some chipsets do not allow us to detect FWH/LPC
I don't think it makes much sense to differentiate between 29* types, lpc and fwh: The physical bus looks exactly the same from a software perspective; until after you scanned the bus and know which category the chip you found belongs to. And then the data is not exactly interesting anymore.
Differentiating between LPC/FWH is important for the unlock procedure of some chips. Keeping the 29* parallel flash chips in a separate category fixes the AMIC chip confusion by 29EE probing.
I think this matches the physical actualities much better than the design-less hack that is used at the moment. Also the code could be much nicer in many places, as we could use case statements instead of endless if () else if () else if() statements
What happens if there is more than one flash bus? Do we call the probe functions compatible with the bus once per bus? If we do that, we can stop after the first detected chip.
Not necessarily. You can have multiple chips on the same FWH "bus", so stopping after you find the first chip is not an option.
I meant bus/address pairs where appropriate. There can be only one chip per bus/address pair.
But, I suggest we consider multiple flash busses once we see that happen in the real world. At least the ICH is always strapped to either FWH _or_ SPI.
Except if you have a Kontron board (for which multiple flash chip support was written in the first place).
Regards, Carl-Daniel
Carl-Daniel Hailfinger wrote:
I don't think it makes much sense to differentiate between 29* types, lpc and fwh: The physical bus looks exactly the same from a software perspective; until after you scanned the bus and know which category the chip you found belongs to. And then the data is not exactly interesting anymore.
Differentiating between LPC/FWH is important for the unlock procedure of some chips. Keeping the 29* parallel flash chips in a separate category fixes the AMIC chip confusion by 29EE probing.
Ok, so make a suggestion how to determine the difference without probing for the chips themselfes and we can discuss that.
I meant bus/address pairs where appropriate. There can be only one chip per bus/address pair.
There can even only be one chip per address, as those are physical cpu addresses. The bus is not relevant here for any known design of flash device.
But, I suggest we consider multiple flash busses once we see that happen in the real world. At least the ICH is always strapped to either FWH _or_ SPI.
Except if you have a Kontron board (for which multiple flash chip support was written in the first place).
Ok, I just checked the mail traffic on that one. How do the bios straps look on those systems?
Is there any method of finding out whether there is something on the SPI bus physically?
Some systems seem to hang when probing the spi bus without devices attached to it. Which is the origin of this discussion.
On 28.06.2008 23:14, Stefan Reinauer wrote:
Carl-Daniel Hailfinger wrote:
I don't think it makes much sense to differentiate between 29* types, lpc and fwh: The physical bus looks exactly the same from a software perspective; until after you scanned the bus and know which category the chip you found belongs to. And then the data is not exactly interesting anymore.
Differentiating between LPC/FWH is important for the unlock procedure of some chips. Keeping the 29* parallel flash chips in a separate category fixes the AMIC chip confusion by 29EE probing.
Ok, so make a suggestion how to determine the difference without probing for the chips themselfes and we can discuss that.
Determine the info from the chipset? If a chipset doesn't support old-style parallel flash, there is no point probing for it.
I meant bus/address pairs where appropriate. There can be only one chip per bus/address pair.
There can even only be one chip per address, as those are physical cpu addresses. The bus is not relevant here for any known design of flash device.
You can have chips with no address, though. SPI ID accesses are inherently address-free. (If someone invents a SPI multiplexer, we can still think about that.)
But, I suggest we consider multiple flash busses once we see that happen in the real world. At least the ICH is always strapped to either FWH _or_ SPI.
Except if you have a Kontron board (for which multiple flash chip support was written in the first place).
Ok, I just checked the mail traffic on that one. How do the bios straps look on those systems?
Is there any method of finding out whether there is something on the SPI bus physically?
In theory every command which returns something should return a stream of 0xff if the bus is unpopulated.
Some systems seem to hang when probing the spi bus without devices attached to it. Which is the origin of this discussion.
Where exactly do these systems hang? If they hang while programming the opcodes, the probing itself is not the cause of the hang.
Regards, Carl-Daniel
Carl-Daniel Hailfinger wrote:
On 28.06.2008 23:14, Stefan Reinauer wrote:
Carl-Daniel Hailfinger wrote:
I don't think it makes much sense to differentiate between 29* types, lpc and fwh: The physical bus looks exactly the same from a software perspective; until after you scanned the bus and know which category the chip you found belongs to. And then the data is not exactly interesting anymore.
Differentiating between LPC/FWH is important for the unlock procedure of some chips. Keeping the 29* parallel flash chips in a separate category fixes the AMIC chip confusion by 29EE probing.
Ok, so make a suggestion how to determine the difference without probing for the chips themselfes and we can discuss that.
Determine the info from the chipset? If a chipset doesn't support old-style parallel flash, there is no point probing for it.
Ok, completely different story. But I like the idea. Then we need to add another field to the flashchips array describing the bus of such each chip.
What with the PMC chips that can be both FWH and LPC? 2 entries?
Ok, I just checked the mail traffic on that one. How do the bios straps look on those systems?
Is there any method of finding out whether there is something on the SPI bus physically?
In theory every command which returns something should return a stream of 0xff if the bus is unpopulated.
on ICH7 CDS does not go to 1.
Some systems seem to hang when probing the spi bus without devices attached to it. Which is the origin of this discussion.
Where exactly do these systems hang? If they hang while programming the opcodes, the probing itself is not the cause of the hang.
See the mail that was sent to flashrom@coreboot.org today.
Stefan
On 28.06.2008 23:46, Stefan Reinauer wrote:
Carl-Daniel Hailfinger wrote:
On 28.06.2008 23:14, Stefan Reinauer wrote:
Carl-Daniel Hailfinger wrote:
I don't think it makes much sense to differentiate between 29* types, lpc and fwh: The physical bus looks exactly the same from a software perspective; until after you scanned the bus and know which category the chip you found belongs to. And then the data is not exactly interesting anymore.
Differentiating between LPC/FWH is important for the unlock procedure of some chips. Keeping the 29* parallel flash chips in a separate category fixes the AMIC chip confusion by 29EE probing.
Ok, so make a suggestion how to determine the difference without probing for the chips themselfes and we can discuss that.
Determine the info from the chipset? If a chipset doesn't support old-style parallel flash, there is no point probing for it.
Ok, completely different story. But I like the idea. Then we need to add another field to the flashchips array describing the bus of such each chip.
What with the PMC chips that can be both FWH and LPC? 2 entries?
What about a bitfield? flashchip.compatible_with = FLASH_BUS_LPC|FLASH_BUS_FWH; or flashchip.compatible_with = FLASH_BUS_SPI;
Ok, I just checked the mail traffic on that one. How do the bios straps look on those systems?
Is there any method of finding out whether there is something on the SPI bus physically?
In theory every command which returns something should return a stream of 0xff if the bus is unpopulated.
on ICH7 CDS does not go to 1.
Hmmm. How about a timeout?
Some systems seem to hang when probing the spi bus without devices attached to it. Which is the origin of this discussion.
Where exactly do these systems hang? If they hang while programming the opcodes, the probing itself is not the cause of the hang.
See the mail that was sent to flashrom@coreboot.org today.
Unfortunately the debug output is not detailed enough to actually find the reason for the hang.
Pietro, can you try the patch below? Flashrom will still hang, but with that patch we will know why.
Add a debug marker after ICH SPI opcode programming. Signed-off-by: Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net
Index: ichspi.c =================================================================== --- ichspi.c (Revision 3393) +++ ichspi.c (Arbeitskopie) @@ -581,9 +581,10 @@
/* program opcodes if not already done */ if (curopcodes == NULL) { - printf_debug("Programming OPCODES\n"); + printf_debug("Programming OPCODES... "); curopcodes = &O_ST_M25P; program_opcodes(curopcodes); + printf_debug("done\n"); }
/* find cmd in opcodes-table */
Regards, Carl-Daniel
Carl-Daniel Hailfinger wrote:
What about a bitfield? flashchip.compatible_with = FLASH_BUS_LPC|FLASH_BUS_FWH; or flashchip.compatible_with = FLASH_BUS_SPI;
sounds reasonable.
Ok, I just checked the mail traffic on that one. How do the bios straps look on those systems?
Is there any method of finding out whether there is something on the SPI bus physically?
In theory every command which returns something should return a stream of 0xff if the bus is unpopulated.
on ICH7 CDS does not go to 1.
Hmmm. How about a timeout?
There is a timeout. But since it is very generic code, and some commands may take up to 30s according to the code, the timeout is currently 60s. So sleeps 60s for each SPI chip in the list. Not so good. Probing is pretty slow already.
See the mail that was sent to flashrom@coreboot.org today.
Unfortunately the debug output is not detailed enough to actually find the reason for the hang.
If you look at the code there are not many places where it could actually hang. program_opcodes is not one of them. The sparse debug printfs create a wrong impression here. It hangs in this function call:
if (run_opcode(opcode_index, *opcode, addr, count, data) != 0) { printf_debug("run OPCODE 0x%02x failed\n", opcode->opcode); return 1; }
And here is the loop we are talking about:
/* wait for cycle complete */ timeout = 1000 * 60; // 60s is a looong timeout. while (((REGREAD16(ICH7_REG_SPIS) & SPIS_CDS) == 0) && --timeout) { myusec_delay(1000); } if (!timeout) { printf_debug("timeout\n"); }
Pietro, can you try the patch below? Flashrom will still hang, but with that patch we will know why.
No need to try,... see above.
Stefan
On 29.06.2008 00:41, Stefan Reinauer wrote:
Carl-Daniel Hailfinger wrote:
Ok, I just checked the mail traffic on that one. How do the bios straps look on those systems?
Is there any method of finding out whether there is something on the SPI bus physically?
In theory every command which returns something should return a stream of 0xff if the bus is unpopulated.
on ICH7 CDS does not go to 1.
Hmmm. How about a timeout?
There is a timeout. But since it is very generic code, and some commands may take up to 30s according to the code, the timeout is currently 60s. So sleeps 60s for each SPI chip in the list. Not so good. Probing is pretty slow already.
Pietro, does the probing continue after a few minutes?
See the mail that was sent to flashrom@coreboot.org today.
Unfortunately the debug output is not detailed enough to actually find the reason for the hang.
If you look at the code there are not many places where it could actually hang. program_opcodes is not one of them.
Actually, the chipset documentation says it is perfectly valid to hang here. (Well, not directly, but writing the opcode table can trigger SMI which can wreak havoc.)
The sparse debug printfs create a wrong impression here.
Then we should definitely apply my patch to make sure nobody gets a wrong impression in the future.
It hangs in this function call:
if (run_opcode(opcode_index, *opcode, addr, count, data) != 0) { printf_debug("run OPCODE 0x%02x failed\n", opcode->opcode); return 1; }And here is the loop we are talking about:
/* wait for cycle complete */ timeout = 1000 * 60; // 60s is a looong timeout. while (((REGREAD16(ICH7_REG_SPIS) & SPIS_CDS) == 0) && --timeout) { myusec_delay(1000); } if (!timeout) { printf_debug("timeout\n"); }Pietro, can you try the patch below? Flashrom will still hang, but with that patch we will know why.
No need to try,... see above.
We don't know yet which timeouts (if any) Pietro is seeing.
Regards, Carl-Daniel
Carl-Daniel Hailfinger wrote:
The sparse debug printfs create a wrong impression here.
Then we should definitely apply my patch to make sure nobody gets a wrong impression in the future.
Absolutely; and a couple more like that.
We might also want to consider several log levels?
-v verbose -vv verbose and debug drivers -vvv verbose, debug drivers and dump registers at every chance to do so
On 29.06.2008 01:46, Stefan Reinauer wrote:
Carl-Daniel Hailfinger wrote:
The sparse debug printfs create a wrong impression here.
Then we should definitely apply my patch to make sure nobody gets a wrong impression in the future.
Absolutely; and a couple more like that.
Good. Care to ack my patch?
We might also want to consider several log levels?
-v verbose -vv verbose and debug drivers -vvv verbose, debug drivers and dump registers at every chance to do so
That's a pretty good idea. Perhaps we want to refine that proposal a bit more with debug bitmasks. Then again, that might be overkill.
More ICH SPI debug messages are definitely needed before 1.0. Log levels are post-1.0 material IMHO.
Regards, Carl-Daniel
Carl-Daniel Hailfinger wrote:
On 29.06.2008 01:46, Stefan Reinauer wrote:
Carl-Daniel Hailfinger wrote:
The sparse debug printfs create a wrong impression here.
Then we should definitely apply my patch to make sure nobody gets a wrong impression in the future.
Absolutely; and a couple more like that.
Good. Care to ack my patch?
Acked-by: Stefan Reinauer stepan@coresystems.de
That's a pretty good idea. Perhaps we want to refine that proposal a bit more with debug bitmasks. Then again, that might be overkill.
shouldn't make things much more complex, does it?
More ICH SPI debug messages are definitely needed before 1.0. Log levels are post-1.0 material IMHO.
yep
On 29.06.2008 12:38, Stefan Reinauer wrote:
Carl-Daniel Hailfinger wrote:
On 29.06.2008 01:46, Stefan Reinauer wrote:
Carl-Daniel Hailfinger wrote:
The sparse debug printfs create a wrong impression here.
Then we should definitely apply my patch to make sure nobody gets a wrong impression in the future.
Absolutely; and a couple more like that.
Good. Care to ack my patch?
Acked-by: Stefan Reinauer stepan@coresystems.de
Thanks, r3397.
That's a pretty good idea. Perhaps we want to refine that proposal a bit more with debug bitmasks. Then again, that might be overkill.
shouldn't make things much more complex, does it?
We'll cross that bridge when we come to it.
Regards, Carl-Daniel
After applying the patch, here is the output of flashrom -V... I launched and forgot the terminal for a while... I saw it back after an hour...
Calibrating delay loop... 455M loops per second. OK. No coreboot table found. Found chipset "Intel ICH7M", enabling flash write... Root Complex Register Block address = 0xfed1c000 GCS address = 0xfed1f410 GCS = 0xaa0c64: BIOS Interface Lock-Down: disabled, BOOT BIOS Straps: 0x3 (LPC) Top Swap : not enabled SPIBAR = 0xfed1c000 + 0x3020 0x00: 0x0009 (SPIS) 0x02: 0x4260 (SPIC) 0x04: 0x00000000 (SPIA) 0x08: 0x00000000 (SPID0) 0x0c: 0x00000000 (SPID0+4) 0x10: 0x00000000 (SPID1) 0x14: 0x00000000 (SPID1+4) 0x18: 0x00000000 (SPID2) 0x1c: 0x00000000 (SPID2+4) 0x20: 0x00000000 (SPID3) 0x24: 0x00000000 (SPID3+4) 0x28: 0x00000000 (SPID4) 0x2c: 0x00000000 (SPID4+4) 0x30: 0x00000000 (SPID5) 0x34: 0x00000000 (SPID5+4) 0x38: 0x00000000 (SPID6) 0x3c: 0x00000000 (SPID6+4) 0x40: 0x00000000 (SPID7) 0x44: 0x00000000 (SPID7+4) 0x50: 0x00000000 (BBAR) 0x54: 0x0006 (PREOP) 0x56: 0x463b (OPTYPE) 0x58: 0x05d80302 (OPMENU) 0x5c: 0xc79f01ab (OPMENU+4) 0x60: 0x00000000 (PBR0) 0x64: 0x00000000 (PBR1) 0x68: 0x00000000 (PBR2) 0x6c: 0x00000000 (PBR3)
SPI Read Configuration: prefetching disabled, caching enabled, BIOS Lock Enable: disabled, BIOS Write Enable: enabled, BIOS_CNTL is 0x1 OK. Probing for AMD Am29F016D, 2048 KB: probe_29f040b: id1 0xff, id2 0xff Probing for AMD Am29F040B, 512 KB: probe_29f040b: id1 0xff, id2 0xff Probing for AMD Am29LV040B, 512 KB: probe_29f040b: id1 0xff, id2 0xff Probing for ASD AE49F2008, 256 KB: probe_jedec: id1 0x9d, id2 0x6e Probing for Atmel AT29C020, 256 KB: probe_jedec: id1 0x9d, id2 0x6e Probing for Atmel AT29C040A, 512 KB: probe_jedec: id1 0x9d, id2 0x6e Probing for Atmel AT49F002(N), 256 KB: probe_jedec: id1 0x9d, id2 0x6e Probing for Atmel AT49F002(N)T, 256 KB: probe_jedec: id1 0x9d, id2 0x6e Probing for Atmel AT25DF321, 4096 KB: Programming OPCODES... done timeout Transaction error! run OPCODE 0x9f failed Probing for AMIC Technology A25L40P, 512 KB: timeout Transaction error! run OPCODE 0x9f failed Probing for AMIC Technology A49LF040A, 512 KB: probe_jedec: id1 0x9d, id2 0x6e Probing for AMIC Technology A29040B, 512 KB: probe_29f040b: id1 0xff, id2 0xff Probing for EMST F49B002UA, 256 KB: probe_jedec: id1 0x9d, id2 0x6e Probing for EON EN29F002(A)(N)B, 256 KB: probe_jedec: id1 0x9d, id2 0x6e Probing for EON EN29F002(A)(N)T, 256 KB: probe_jedec: id1 0x9d, id2 0x6e Probing for Fujitsu MBM29F400TC, 512 KB: probe_m29f400bt: id1 0xff, id2 0xff Probing for Intel 82802AB, 512 KB: probe_82802ab: id1 0xff, id2 0xff Probing for Intel 82802AC, 1024 KB: probe_82802ab: id1 0xff, id2 0xff Probing for Macronix MX25L4005, 512 KB: timeout Transaction error! run OPCODE 0x9f failed Probing for Macronix MX25L8005, 1024 KB: timeout Transaction error! run OPCODE 0x9f failed Probing for Macronix MX25L1605, 2048 KB: timeout Transaction error! run OPCODE 0x9f failed Probing for Macronix MX25L3205, 4096 KB: timeout Transaction error! run OPCODE 0x9f failed Probing for Macronix MX29F002, 256 KB: probe_29f002: id1 0x9d, id2 0x6e Probing for PMC Pm25LV010, 128 KB: timeout Transaction error! run OPCODE 0x9f failed Probing for PMC Pm25LV016B, 2048 KB: timeout Transaction error! run OPCODE 0x9f failed Probing for PMC Pm25LV020, 256 KB: timeout Transaction error! run OPCODE 0x9f failed Probing for PMC Pm25LV040, 512 KB: timeout Transaction error! run OPCODE 0x9f failed Probing for PMC Pm25LV080B, 1024 KB: timeout Transaction error! run OPCODE 0x9f failed Probing for PMC Pm25LV512, 64 KB: timeout Transaction error! run OPCODE 0x9f failed Probing for PMC Pm49FL002, 256 KB: probe_jedec: id1 0x9d, id2 0x6e Probing for PMC Pm49FL004, 512 KB: probe_jedec: id1 0x9d, id2 0x6e Found chip "PMC Pm49FL004" (512 KB) at physical address 0xfff80000. Probing for Sharp LHF00L04, 1024 KB: probe_lhf00l04: id1 0xff, id2 0xff Probing for Spansion S25FL016A, 2048 KB: timeout Transaction error! run OPCODE 0x9f failed Probing for SST SST25VF016B, 2048 KB: timeout Transaction error! run OPCODE 0x9f failed Probing for SST SST25VF040B, 512 KB: timeout Transaction error! run OPCODE 0x9f failed Probing for SST SST28SF040A, 512 KB: probe_28sf040: id1 0xff, id2 0xff Probing for SST SST29EE010, 128 KB: probe_jedec: id1 0x9d, id2 0x6e Probing for SST SST29LE010, 128 KB: probe_jedec: id1 0x9d, id2 0x6e Probing for SST SST29EE020A, 256 KB: probe_jedec: id1 0x9d, id2 0x6e Probing for SST SST29LE020, 256 KB: probe_jedec: id1 0x9d, id2 0x6e Probing for SST SST39SF010A, 128 KB: probe_jedec: id1 0x9d, id2 0x6e Probing for SST SST39SF020A, 256 KB: probe_jedec: id1 0x9d, id2 0x6e Probing for SST SST39SF040, 512 KB: probe_jedec: id1 0x9d, id2 0x6e Probing for SST SST39VF512, 64 KB: probe_jedec: id1 0x9d, id2 0x6e Probing for SST SST39VF010, 128 KB: probe_jedec: id1 0x9d, id2 0x6e Probing for SST SST39VF020, 256 KB: probe_jedec: id1 0x9d, id2 0x6e Probing for SST SST39VF040, 512 KB: probe_jedec: id1 0x9d, id2 0x6e Probing for SST SST49LF002A/B, 256 KB: probe_jedec: id1 0x9d, id2 0x6e Probing for SST SST49LF003A/B, 384 KB: probe_jedec: id1 0x9d, id2 0x6e Probing for SST SST49LF004A/B, 512 KB: probe_jedec: id1 0x9d, id2 0x6e Probing for SST SST49LF004C, 512 KB: probe_49lfxxxc: id1 0xff, id2 0xff Probing for SST SST49LF008A, 1024 KB: probe_jedec: id1 0xff, id2 0xff, id1 parity violation Probing for SST SST49LF008C, 1024 KB: probe_49lfxxxc: id1 0xff, id2 0xff Probing for SST SST49LF016C, 2048 KB: probe_49lfxxxc: id1 0xff, id2 0xff Probing for SST SST49LF020A, 256 KB: probe_jedec: id1 0x9d, id2 0x6e Probing for SST SST49LF040, 512 KB: probe_jedec: id1 0x9d, id2 0x6e Probing for SST SST49LF040B, 512 KB: probe_jedec: id1 0x9d, id2 0x6e Probing for SST SST49LF080A, 1024 KB: probe_jedec: id1 0xff, id2 0xff, id1 parity violation Probing for SST SST49LF160C, 2048 KB: probe_49lfxxxc: id1 0xff, id2 0xff Probing for ST M25P05-A, 64 KB: timeout Transaction error! run OPCODE 0x9f failed Probing for ST M25P10-A, 128 KB: timeout Transaction error! run OPCODE 0x9f failed Probing for ST M25P20, 256 KB: timeout Transaction error! run OPCODE 0x9f failed Probing for ST M25P40, 512 KB: timeout Transaction error! run OPCODE 0x9f failed Probing for ST M25P40-old, 512 KB: timeout Transaction error! run OPCODE 0x9f failed Probing for ST M25P80, 1024 KB: timeout Transaction error! run OPCODE 0x9f failed Probing for ST M25P16, 2048 KB: timeout Transaction error! run OPCODE 0x9f failed Probing for ST M25P32, 4096 KB: timeout Transaction error! run OPCODE 0x9f failed Probing for ST M25P64, 8192 KB: timeout Transaction error! run OPCODE 0x9f failed Probing for ST M25P128, 16384 KB: timeout Transaction error! run OPCODE 0x9f failed Probing for ST M29F002B, 256 KB: probe_jedec: id1 0x9d, id2 0x6e Probing for ST M29F002T/NT, 256 KB: probe_jedec: id1 0x9d, id2 0x6e Probing for ST M29F040B, 512 KB: probe_29f040b: id1 0xff, id2 0xff Probing for ST M29F400BT, 512 KB: probe_m29f400bt: id1 0xff, id2 0xff Probing for ST M29W010B, 128 KB: probe_jedec: id1 0x9d, id2 0x6e Probing for ST M29W040B, 512 KB: probe_jedec: id1 0x9d, id2 0x6e Probing for ST M50FLW040A, 512 KB: probe_stm50flw0x0x: id1 0x9d, id2 0x6e Probing for ST M50FLW040B, 512 KB: probe_stm50flw0x0x: id1 0x9d, id2 0x6e Probing for ST M50FLW080A, 1024 KB: probe_stm50flw0x0x: id1 0xff, id2 0xff Probing for ST M50FLW080B, 1024 KB: probe_stm50flw0x0x: id1 0xff, id2 0xff Probing for ST M50FW016, 2048 KB: probe_82802ab: id1 0xff, id2 0xff Probing for ST M50FW040, 512 KB: probe_82802ab: id1 0xff, id2 0xff Probing for ST M50FW080, 1024 KB: probe_82802ab: id1 0xff, id2 0xff Probing for ST M50LPW116, 2048 KB: probe_jedec: id1 0xff, id2 0xff, id1 parity violation Probing for SyncMOS S29C31004T, 512 KB: probe_jedec: id1 0x9d, id2 0x6e Probing for SyncMOS S29C51001T, 128 KB: probe_jedec: id1 0x9d, id2 0x6e Probing for SyncMOS S29C51002T, 256 KB: probe_jedec: id1 0x9d, id2 0x6e Probing for SyncMOS S29C51004T, 512 KB: probe_jedec: id1 0x9d, id2 0x6e Probing for Winbond W25x10, 128 KB: timeout Transaction error! run OPCODE 0x9f failed Probing for Winbond W25x20, 256 KB: timeout Transaction error! run OPCODE 0x9f failed Probing for Winbond W25x40, 512 KB: timeout Transaction error! run OPCODE 0x9f failed Probing for Winbond W25x80, 1024 KB: timeout Transaction error! run OPCODE 0x9f failed Probing for Winbond W29C011, 128 KB: probe_jedec: id1 0x9d, id2 0x6e Probing for Winbond W29C020C, 256 KB: probe_jedec: id1 0x9d, id2 0x6e Probing for Winbond W29C040P, 512 KB: probe_jedec: id1 0x9d, id2 0x6e Probing for Winbond W29EE011, 128 KB: === Probing disabled for Winbond W29EE011 because the probing sequence puts the AMIC A49LF040A in a funky state. Use 'flashrom -c W29EE011' if you have a board with this chip. === Probing for Winbond W39V040A, 512 KB: probe_jedec: id1 0x9d, id2 0x6e Probing for Winbond W39V040B, 512 KB: probe_jedec: id1 0x9d, id2 0x6e Probing for Winbond W39V040FA, 512 KB: probe_jedec: id1 0x9d, id2 0x6e Probing for Winbond W39V080A, 1024 KB: probe_jedec: id1 0xff, id2 0xff, id1 parity violation Probing for Winbond W49F002U, 256 KB: probe_jedec: id1 0x9d, id2 0x6e Probing for Winbond W49V002A, 256 KB: probe_jedec: id1 0x9d, id2 0x6e Probing for Winbond W49V002FA, 256 KB: probe_jedec: id1 0x9d, id2 0x6e Probing for Winbond W39V080FA, 1024 KB: probe_winbond_fwhub: vid 0xff, did 0xff Probing for Winbond W39V080FA (dual mode), 512 KB: probe_winbond_fwhub: vid 0x9d, did 0x6e Probing for EON unknown EON SPI chip, 0 KB: timeout Transaction error! run OPCODE 0x9f failed Probing for Macronix unknown Macronix SPI chip, 0 KB: timeout Transaction error! run OPCODE 0x9f failed Probing for PMC unknown PMC SPI chip, 0 KB: timeout Transaction error! run OPCODE 0x9f failed Probing for SST unknown SST SPI chip, 0 KB: timeout Transaction error! run OPCODE 0x9f failed Probing for ST unknown ST SPI chip, 0 KB: timeout Transaction error! run OPCODE 0x9f failed No operations were specified.
Hi Pietro,
thanks for testing my patch!
On 29.06.2008 18:25, Pietro wrote:
After applying the patch, here is the output of flashrom -V... I launched and forgot the terminal for a while... I saw it back after an hour...
Calibrating delay loop... 455M loops per second. OK. No coreboot table found. Found chipset "Intel ICH7M", enabling flash write... Root Complex Register Block address = 0xfed1c000 GCS address = 0xfed1f410 GCS = 0xaa0c64: BIOS Interface Lock-Down: disabled, BOOT BIOS Straps: 0x3 (LPC) [...]
SPI Read Configuration: prefetching disabled, caching enabled, BIOS Lock Enable: disabled, BIOS Write Enable: enabled, BIOS_CNTL is 0x1 OK. Probing for AMD Am29F016D, 2048 KB: probe_29f040b: id1 0xff, id2 0xff [...] Probing for Atmel AT25DF321, 4096 KB: Programming OPCODES... done timeout Transaction error! run OPCODE 0x9f failed Probing for AMIC Technology A25L40P, 512 KB: timeout Transaction error! run OPCODE 0x9f failed Probing for AMIC Technology A49LF040A, 512 KB: probe_jedec: id1 0x9d, id2 0x6e [...] No operations were specified.
OK, that confirms Stefan's suspicion that running the opcode is the problem.
Regards, Carl-Daniel
On 28.06.2008 19:08, Peter Stuge wrote:
On Sat, Jun 28, 2008 at 06:38:01PM +0200, Peter Stuge wrote:
Unfortunately this patch broke flashrom on ICH7 not using SPI for at least one user as reported on IRC just now. :(
..
I asked the reporter to send a message to flashrom@ and I got a promise about testing patches to fix the problem. :)
I had an idea. The attached patch fixes flashrom 3393 on non-SPI ICH7 at least for the reporter.
The second hunk is needed for me to be able to compile flashrom with gcc 4.2.2. That should teach me to build test before I ack. Also there seems to be a bit of whitespace damage in the 3393 patch.
//Peter
flashrom: Fix ICH7 non-SPI that broke in r3393
r3393 assumed that ICH7 always used SPI. This patch resets ich7_detected back to 0 when BOOT BIOS Straps indicate something else than SPI.
Also fixes a build error in ichspi.c with gcc 4.2.2.
Signed-off-by: Peter Stuge peter@stuge.se
Acked-by: Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net
I'd like to know where exactly the hang happens, though. That will allow us to understand the chipset better.
Regards, Carl-Daniel
On Sun, Jun 29, 2008 at 02:16:37AM +0200, Carl-Daniel Hailfinger wrote:
flashrom: Fix ICH7 non-SPI that broke in r3393
r3393 assumed that ICH7 always used SPI. This patch resets ich7_detected back to 0 when BOOT BIOS Straps indicate something else than SPI.
Also fixes a build error in ichspi.c with gcc 4.2.2.
Signed-off-by: Peter Stuge peter@stuge.se
Acked-by: Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net
Thanks, r3395.
-
Carl-Daniel Hailfinger -
Peter Stuge -
Pietro -
Stefan Reinauer