We have had board enable routines and our board enable table for more
than two years now. And thanks to the good work of carldani and uwe
and the release(s) (one done, one pending) this list is growing fast.
We have 47 boards in our board enable table today.
Board enables have the following format today:
<pci id set 1> <pci id set 2> <coreboot name> <pretty print name>
<board enable callback>
one pci id set is the following:
<vendor> <device> <card/subsystem vendor> <card/subsystem device>
While most of the time, the vendor and device ids are fixed, the
subsystem pair is set by the bios. It can be write-once or it can be
locked by some other bit in the device config space. Because subsystem
ids are relatively new to the pci spec (second half of the 90s iirc),
not all vendors have been using them. Most last-millenium boards will
not have them filled in. Or often vendor bioses just copy main ids over.
Many consumer board makers today do their job really well while embedded
board makers tend to ignore subsystem ids.
Because of what i saw in my unichrome graphics driver (where i started
using subsystem ids in 2004 to see which outputs were wired up), i knew
that matching a single device was never going to work. So two were added
here, but we only require a single set to be filled in.
There is a situation with some gigabyte boards for which carldani
suggested to add a third set, which is imho a good solution, but we are
trying to hold this one off until we really need it.
After the pair of pci ids, there are the board names.
The coreboot name is used two-fold. On a coreboot rom, this name is
matched to the coreboot info. On a legacy bios, the user can provide the
board name on the command line and therefor force flashrom to use a
specific board enable. In both cases, the device and vendor ids of pci
devices are matched as well as a safeguard.
So, three ways of matching boards:
* main ids + subsystem ids.
* legacy bios + command line name + main ids (ignoring subsystem ids).
* coreboot + coreboot name + main ids (ignoring subsystem ids).
Now that we have a more sizable table and a bigger and quickly growing
userbase, i believe that we should look into tightening this up.
We are no longer part of the main coreboot project and are reaching a
changed public now with the exposure we are getting. Average Joe User
might end up abusing our board enable table and land himself in trouble
and then will blame us. While we of course are not liable, it is still
bad publicity and something we should try to avoid.
We also can see how board matches have been written over time, and i
believe that we should be stricter about them. Quite a few people have
just added a single main pci id, and then added a coreboot name to the
table as this was the absolute minimal effort required to make it work
for them. This is how humans are, and how humans will continue to
be, so we should make it harder for this to happen.
So in order to make it safer for Average Joe User, and in order to
force developers to be less lazy here, i propose some changes;
* require 2 sets of pci-ids.
Can anyone name a motherboard which has only a single pci device that
even comes close to our target hardware (in as far as we have target
hardware). By requiring 2 sets, we improve safety and we force
developers to be less lazy.
* if one value of any of the 4 subsystem ids is filled in, assume that
the rest should be matched as is.
When subsystem ids are not filled in correctly, they sometimes remain
null. Null values should not mean "match anything" they should mean null
when even one of the value is valid.
I am a bit weary of adding a #define for 0xFFFF (the pciid "match
anything"). I do not wish to encourage people to create an entry like:
blah, blah, 0xFFFF, 0xFFFF, blah, blah, 0xFFFF, 0xFFFF
and get away with it.
Multiple similar boards should be matched separately. And, since we
usually have more than just a few pci devices in our device tree,
chances are extremely good that at least two of them can be matched in
some way or another, without a catchall.
* on legacy bioses, do not allow both pci subsystem ids and a name.
The most efficient way to do this seems the following:
If a name is provided, we should go over the table, checking for devices
with both subsystem id sets nulled, and try to match the name. If the
name matches, try to match main pci ids.
* Add separate logic for coreboot name matching.
This to still allow subsystem ids to be present, and thus to offset the
previous point. We really will end up with three different ways of
Apart from actual code changes, we should apply the following:
* Be extremely weary of patches.
* We need at least an lspci -vvnnxxxx.
We have started to do this anyway now, collecting info for our
current table, while retaining info for future table alteration.
* Do not accept missing subsystem ids for recent boards.
Motherboards of this millenium tend to have subsystem ids filled in.
* Usage of a coreboot name when coreboot is supported.
Why would a coreboot developer set a separate write protect on the
rom? The board enable could be valid though, but not for flash write
protection. If developers want to bring up a board, and have this
write protection disabling as a todo, then they can hack their own
code into flashrom.
Even if we only apply some of the above, we still need to clean up our
board enable table.
Here is a list of boards with questionable matching, as a quick list. I
will be digging each of them out properly and try to contact the
original authors for more information. If you are the original author
and happen to be reading this, then by all means, feel free to contact
us right away.
Artec Group DBE61
Artec Group DBE62
HP DL145 G3
Kontron 986LCD-M (yes, twice)
MSI MS-6590 (KT4 Ultra)
MSI MS-6712 (KT4V)
MSI MS-7135 (K8N Neo3)
The following two devices are known to be valid, as they predate pci
subsystem ids: the ASUS P5A (which i own) and the EPoX EP-BX3.
On Mon, Oct 05, 2009 at 11:34:14PM +0100, Putlinuxonit wrote:
> Hi Luc,
> Find attached.
> Keep up the good work.
I am able to easily find the int16h hook, but once there i am unable to
track down the code for ah=0xE0.
You should get a multimeter out and check whether your bios chip really
has one of its write protection lines set.
On Mon, Oct 05, 2009 at 03:24:47PM +0200, Martin S. wrote:
> On Mon, 2009-10-05 at 13:52 +0200, Luc Verhaegen wrote:
> > Can you attach the output of lspci -vvnnxxx?
> > I will soon send in a patch for the chipset enable.
> Got it. Going to test now.
> > When the full lspci is provided, i will be able to quickly provide you
> > with a board enable for your board.
> > Oh, and about your blog entry: my first linux box was a SuSE 6.0, but
> > undoubtedly Stepan can easily trump that as i believe he was working
> > for SuSE (already/still) at the time.
> Nice, looking for evidence. ;)
> > Also, please use your real and full name for acknowledging patches later
> > on.
> Sure. Thanks for your efforts.
Here is the board specific patch.
Also included is your lspci for the ml.