On Tue, May 15, 2007 at 12:34:12PM +0200, Peter Stuge wrote:
On Tue, May 15, 2007 at 12:11:26PM +0200, Luc
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)
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
"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
We're just pushing the "unable to identify" boundary slightly
further, as there will still be cases where dmidecode will be
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
* 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
* 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 :)