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.