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