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