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