[LinuxBIOS] [PATCH] flashrom: board specific enables based on matching pci-ids.
libv at skynet.be
Fri Mar 23 21:18:35 CET 2007
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
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.
> > 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
> 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
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
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 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
More information about the coreboot