[LinuxBIOS] [patch] flashrom: add support for Asus P5A

[Luc Verhaegen]

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.