[LinuxBIOS] [PATCH] flashrom: board specific enables based on matching pci-ids.

[Luc Verhaegen]

On Fri, Mar 23, 2007 at 06:42:46PM +0100, Stefan Reinauer wrote:
> * Luc Verhaegen <libv at skynet.be> [070323 06:47]:
> > This patch adds initial flashrom support for matching mainboards based 
> > on pci-ids and pci subsystem/card ids.
>  
> > This code works correctly on:
> > * EPIA-M with original BIOS. Matched and enabled correctly:
> >   $ Found "VIA EPIA M/MII/...": Enabling flash write... OK.
> > * EPIA-M with linuxbios: not matched - pci subsystem ids not set 
> >   correctly (yet!) - but not a problem as linuxbios never disabled write 
> >   in the first place.
> 
> Ok, so do I get this right: all boards below might be supported by
> LinuxBIOS as well, if we create ports for them based on the Epia-M
> and start setting correct subsystem vendor ids?

No, this is just flashrom working on them. If users want to read/write 
prorietary bioses from linux directly, then they can. It's only the 
various flash enables that need to be written for flashrom to become a 
general tool.

With what you pointed out about how the flash utilities of different
bios makers work, it's easy, no searching involved.

The code for the Asus board is based on what i've seen in the bios. This 
is all for interoperability, so allowed under most copyright regimes 
afaik. There's enough difference between what the assembler looks like 
and what the C code looks like. It's just clearing one bit on the isa 
bridge and setting one bit on the super io, with the superio 
documentation freely available anyway.

As for the other devices: The Shuttle and the Asus have VIAs KM400 
northbridge, if time permits, i will try to implement them fully.

The K8M800 might be fun after that, but i doubt that i will have time 
for that, besides, i currently have just the laptop. The other board in 
this house is a KT600 (not mine), i'm not sure what brand any more. I'm 
just going to implement flash_enable for that too. That's at most an 
hour or so now if it's also an award/phoenix.

> do you have all these devices available for testing?
 
Yes, what kind of X driver developer would i be if i didn't have the 
hardware :) -ENOHW is my mantra when asked why i don't support a given 
unichrome version. The only thing you do when developing drivers without 
the hardware is shoot yourself in the foot all the time.

> > There is one more VT823x based device in this house that might get 
> > tested, and possibly implemented, this weekend.
> > 
> > The Island Aruma support is currently kept as is.
>  
> fine.
> 
> > When no match has been made, or an error occured, then the name based 
> > matching is still attempted.
> 
> so no regressions. Good.

Well, it's poking the winbond superio through 0x2E/0x2F. It doesn't 
depend on anything. It's all about correctly identifying the board here.

> I trust the user more on knowing what he bought than the board vendors
> on always creating a sane design for something they would never see the
> need for.

Well, you know how i feel about both chip and board vendors :) I still 
have a lot of trust in pci-ids. Two full sets are a very good match 
indeed.

> Also: This is nothing that the user would manually choose, except during
> migration process. Later these strings are read from the linuxbios
> table, which is "the one correct answer" rather than a solution based on
> heuristics..

Right, depend on the linuxbios table. On the other hand, it's too easy 
to copy over a mainboards Options.lb and forget about adjusting the name 
:)
 
Maybe the linuxbios name is added to the pci-id table as well, NULL if 
unknown.

If there's a linuxbios table present, then just try to match main ids 
and the name. Otherwise, try to match both main and card ids.

> > Testing here should imho involve editing flash_enable.c directly.
> 
> Testing?

Testing of flashrom, when it doesn't work straight away. Enabling random 
io bits, as you too pointed out, is not without hazard and should not be 
done lightly. I was lucky that lid events work ok on this laptop when 
i lowered GPIO15 :)

> > Island aruma code can be converted with little effort, all it takes is 
> > the output of lspci -vn.
> 
> No need to do so. There is no more legacy bios for the island aruma.
> It's a LinuxBIOS only machine.
>  
> One issue with subsystem IDs: In LinuxBIOS they are board wide.
> All devices on a board get the same subsystem id. I would assume this is
> a wrong approach, from reading your code. Is it?

They don't always do that for some reason. It is either a vendor messing 
up or it is done deliberately. But this is exactly the issue that the 
dual id check is supposed to catch. 2 matches give a very very high 
degree of certainty.

Board wide is what makes sense. Not that sense and vendors always go 
together :)

Luc Verhaegen.