[coreboot] r3393 - trunk/util/flashrom

[Carl-Daniel Hailfinger]

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