On Fri, Mar 23, 2007 at 06:42:46PM +0100, Stefan Reinauer wrote:
- Luc Verhaegen libv@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 general tool.
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.
fine.
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 indeed.
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 heuristics..
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 unknown.
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?
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 together :)
Luc Verhaegen.