On Tue, May 15, 2007 at 12:34:12PM +0200, Peter Stuge wrote:
On Tue, May 15, 2007 at 12:11:26PM +0200, Luc Verhaegen wrote:
The Asus P5A also seriously messes up pci-ids, there is nothing dependable there, so people who want to use flashrom on this board should use -m asus:p5a
Did anyone have any ideas for more reliable detection?
All I can come up with is to try to extract something meaningful from the current BIOS in RAM.. (not the flash chip)
//Peter
Since nobody bothered to reply, i will now give you my take on this (in as far as this wasn't clear already :)).
DMI is probably what is needed here.
But i kind of am against elaborately depending on another thing which is: A) deprecated. http://www.dmtf.org/standards/dmi/
"Due to the rapid advancement of DMTF technologies, such as CIM, the DMTF defined an "End of Life" process for its Desktop Management Interface (DMI), which ended March 31, 2005"
B) just as easy to bugger up. I'm mostly worried about the same board having multiple names here, changed between bios revisions when developers notice a typo, or because there was yet another marketing u-turn.
We're just pushing the "unable to identify" boundary slightly further, as there will still be cases where dmidecode will be insufficient.
Also, when evaluating the current situation: * Agami aruma is linuxbios only, so name matched. * epia-M is matched properly on pci-ids. * asus A7V8X-MX is matched properly on pci-ids. * Iwill is a buggered up. * Asus P5A is buggered up too.
Now, the P5A is a socket 7 motherboard from 1999, it was hugely popular then, even though it only had half the L2 (L3 when using a K6-2/3) cache of other motherboards. The chance of people running into it again are very slim, i was already very amazed when a user popped up on irc talking about this device.
I think that asus people were little aware of pci-subsystem ids then. I'm not sure when they came into existence, but they weren't in the original pci spec.
So very few people will ever really bother about the P5A. I just added it because the hardware is running right here. It's also an ASUS_FLASH (first vector), which, i now found out first hand, is just as "trivial" as an AWDFLASH (second, full vector).
This only really leaves the Iwill board as the only board for which this is needed, and i don't think that this is enough of a reason to bump the complexity with dmi code _yet_.
On the other hand, if anyone writes up a suitable/cut down dmi decoder for linuxbios, one which: * runs only when the bios isn't linuxbios. * and runs after a failed pci subsystem id match as subsystem ids are a lot cheaper. * adds only a single string to the board enables struct * a single function which returns the board name only: we probably don't want to strcmp all dmi names in the table against all dmi devices known. That would be rather painful and it could lead to false positives. * adds only a single string to the board enables struct.
Then no-one should have much in the way of objections, i just don't want to go there myself (well, maybe if i'm really bored, but really really bored). It might not be too much work, but it isn't going to be as trivial as pci subsystem ids.
I'm not sure what the license of dmi decode is yet.
Also, we do want to make the entries of the board enables all sit on single, but very long lines. I know that this is sniffed at (uwe :p), but believe me, you do want this when more entries are in there. And when you add another string, entries would cover three lines and would be even harder to read.
(my) Conclusion: DMI is probably where we need to go if it is really necessary, but i'm not too keen on doing this myself as it is just more of the same "vendor buggering up" nonsense :)
Luc Verhaegen.