[flashrom] [PATCH] fix kontron 986lcd-m and winbond w39v080fa

[Carl-Daniel Hailfinger]

Short summary:
The DMI non-match behaviour you're seeing is either by design or by
accident. Not sure yet. There are patches floating around which would
allow a DMI match without subsystem IDs.
Will ping you once this is resolved.

On 04.02.2010 03:30, Stefan Reinauer wrote:
> On 2/4/10 3:07 AM, Carl-Daniel Hailfinger wrote:
>   
>> On 04.02.2010 01:51, Stefan Reinauer wrote:
>>   
>>     
>>> * get Kontron 986LCD-M recognized by ID detection again. This was apparently broken in r796
>>>   
>>>     
>>>       
>> Just a short question: The Kontron 986LCD-M appeared to be running
>> coreboot. Is that correct? Quoting from the failure log you sent earlier:
>>   
>>     
> No. The run that requires the IDs are with vendor BIOS. coreboot can
> detect the board through coreboot table.
>
> The subsystem IDs are only required when running flashrom on a not yet
> migrated board.
>
> I tried not changing the subsystem IDs and simply adding a DMI match
> string, but that won't work because the DMI matching code is never
> executed because the subsystem vendor ID matching code already decided
> it's not a kontron board
>   

Ah, right. I'm not 100% familiar with the code. Looking at it again, the
rules are:
- Provide subsystem IDs even if they are bogus (e.g. copy of chipset
vendor/device ID)
- Since the above will match too many boards, DMI will be consulted as well.
- DMI without subsystem IDs is too dangerous (multiple matches), so
subsystem IDs are required even if they are bogus.

Given that there seems to be some confusion about whether requiring
subsystem IDs even in the presence of DMI is a good idea, the rules may
change.

Side note: the coreboot ID matching code needs some revamping to be more
readable (and with DMI, some abuses can be eliminated).


>> Apparently it finds the Kontron board just fine if the board is running
>> coreboot.
>>
>> From the above, I guess that Kontron detection fails if the board is
>> running classic BIOS. In that case, a verbose run of flashrom (probe is
>> enough) on a 986LCD-M with factory BIOS should give us the DMI strings
>> we need to match without problems even if coreboot is not running.
>>   
>>     
> See above.
>   

Unless I'm mistaken, the flashrom log you sent was from a board with
coreboot, but I need a flashrom log from a board with factory BIOS.

Short summary:
- With the current DMI matching code, we need the sort-of-bogus
subsystem IDs rejected by Luc.
- The subsystem requirement may change tomorrow.
- Additionally, that entry needs a DMI string as well.

Caveat: If subsystem IDs differ between vendor BIOS and coreboot, we
need two entries with the current policy.


>>> * tested SST49LF008A and Winbond W39V080FA
>>>     
>>>       
>> Thanks. Given that we're currently rewriting probe to be more robust
>> (reset before and after probe)
>>     
>
> Playing the devils advocate ;-) So then probing will fail if reset
> fails, and if probe fails.
> Now probe fails only if probe fails. So the code gets more robust by
> adding more potential failure points? ;-)
>   

Yes and no. The problem is that sometimes a chip may be in an undefined
state because of previous probe sequences it didn't understand (happened
on some Alix board with an Amic chip). Resetting it before probing could
fix that case. Fortunately, the variability of reset sequences is much
lower than the variability of probe sequences (I think only 3 reset
sequences exist in total).
Besides that, probe_xxx() right now is probe/reset, and afterwards it
will be reset/probe/reset.

Regards,
Carl-Daniel

-- 
Developer quote of the year:
"We are juggling too many chainsaws and flaming arrows and tigers."