[coreboot] r3393 - trunk/util/flashrom

[Carl-Daniel Hailfinger]

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 at 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

-- 
http://www.hailfinger.org/