[flashrom] DMI matching patch

Luc Verhaegen libv at skynet.be
Thu Jan 7 11:13:37 CET 2010


On Fri, Jan 01, 2010 at 01:27:44AM +0100, Michael Karcher wrote:
> > 
> > On 30.12.2009 15:02, Michael Karcher wrote:
> > > Matching via DMI: If a board is not uniquely identifiable by PCI
> > > device/subsystem IDs, a string can be specified to be looked for
> > > (case-sensitive, substring) for now in one of the following items:
> > >  - System Manufacturer
> > >  - System Product Name
> > >  - System Version
> > >  - Baseboard Manufacturer
> > >  - Baseboard Product Name
> > >  - Baseboard Version
> > I believe the substring match is suboptimal.
> You got a point there.

I wouldn't use any word related to optimal in relationship to the board 
enable table.

I would like to see a single string match, because this maximalises our 
effectivity, while minimising the impact on our already large board 
enable table.

That being said, sticking the dmi substring selection in the matching 
string, is contrived and will only lead to problems. If this really is 
what is wanted, then please use an enum.

But for the time being, i believe that it is not needed. And it can be 
added easily later on if we start collecting dmi info.

> > For example, if you want to
> > differentiate between the Asus M2A-VM and the Asus M2A-VM HDMI, only the
> > HDMI variant can be matched safely.
> The idea was that some manufacturers (HP I think) seem to put board ID
> and some revision or different ID into the same string, so we can't
> match full strings only.

The HDMI variant here is implemented through a pci-express riser, so no 
difference whatsoever for us flashrommers. Egbert Eich (fellow radeonhd 
developer) has had a board like this for a few years now.

> They don't do like we do. The vendor tools don't need to match the board
> to find out how to program it, because all vendor tools call into the
> BIOS or some code snippet provided with the BIOS update to do the board
> enable stuff. The only thing they have to check is whether the new BIOS
> matches the board. They do that by simply comparing some magic strings.
> 
> Vendors found out that one flash program that supports all boards is a
> horrible, unmaintainable mess of special cases, and as vendors can rely
> on their own BIOS in the running system, they just put the board enable
> code for that board into the BIOS. That's something we can't do with
> flashrom, as flashrom should work with coreboot, and coreboot currently
> does not support BIOS support.

We're finding out that the amount of board specific work is actually 
rather limited. With superio infrastructure (which i never seem to get 
round to testing) we can take out many more board enables. We then only 
are left with gpio lines, which, while common, are not needed for the 
majority of boards out there. And the infrastructure for them is a lot 
better already too.

> > I'd make that warning conditional on the absence of a coreboot table.
> > Otherwise you'll get a warning on a lot of systems with coreboot.
>
> You will only get that warning if the PCI IDs match and the DMI is
> missing.
> When you run on coreboot, you don't even get into
> board_match_pci_card_ids(), as board_match_coreboot_name() already has
> chosen the right board.

Sounds all good.

The matching functions is also still on my todo list. Splitting the 
matching functions from two (named/coreboot, pciid) into three 
(coreboot, named, pciid), to tighten up the board enable table. I never 
seem to get round to doing these things any more. I should make time, as 
it is rather important.

Luc Verhaegen.




More information about the flashrom mailing list