[flashrom] DMI matching patch
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
I would like to see a single string match, because this maximalises our
effectivity, while minimising the impact on our already large board
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
> 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.
More information about the flashrom