[coreboot] flashrom and list of computers

Carl-Daniel Hailfinger c-d.hailfinger.devel.2006 at gmx.net
Fri Jun 6 21:42:35 CEST 2008

On 06.06.2008 20:35, Ludwig Jaffe wrote:
> Hi all!
>> On 06.06.2008 15:08, Ludwig Jaffe wrote:
>>> Lets rewrite / improve flashrom!
>> A rewrite is unneccessary. Improvements are welcome.
> Yes, but there are some issues that are not straight enough.
> For example: write and erase  try themselves to unlock the flash.
> This should be handled by a generic unlock() which is
> function-pointered for the device in charge.


> Also with the method lock()

I think one function for lock/unlock is enough. It can take
"lock/unlock" as parameter.
>>> To detect the mainboard I would additionally suggest looking for
>>> strings in the bios (if original-bios is used).
>> Sorry, that will not work reliably. We have some known false positives
>> and some known false negatives.
> Ok, but if we have known positives, we can use it for them. If no
> known positive, we at least write "Could be" asus p2b.
> Like tcp-fingerprinting with nmap -O, the users report a fingerprint
> and nmap -O knows cisco PIX or what the hell...

PCI subsystem IDs are more reliable than random strings from memory. We
already use those in board_enable.
>>> For Coreboot, I would suggest to
>>> have a short text with manufacturer, board model, chipset, cpu so
>>> string search can find something.
>> We already have strings with board manufacturer+model. Chipset and CPU
>> strings do not make sense.
> OK, If you think so.

Chipset can be found by lspci, the CPU by /proc/cpuinfo. A coreboot
image can support multiple CPUs.
>>> Not to fall over all garbage the string search has to be filtered
>>> with known names as compaq, hp, ibm, asus, phoenix, award, and the
>>> like.
>>> Using DMI is better for newer boards having DMI.
>> Sorry, that will not work reliably. We have some known false positives
>> and some known false negatives.
> As written above:
> we can prompt "could be" + "Report if you know better".

That does not help because we still have to write routines for every
special mainboard and then we can easily use PCI subsystem IDs.

>>> So one can build different strategies for identifiing the mainboard.
>>> And use a functionpointer approach to do special tasks for the boards
>>> e.g. switching the bios to flash (some boards have a 2 bios-sockets)
>> We already do that.
> this should also be function-pointered :-)

It is.
>>> e.g. unprotecting the boot-block.  (e.g. my compaq SFF PC needs P34
>>> soldered in and closed.) So an appropriate text has to be printed,
>>> if the
>>> board can not automagically disable write-protection etc.
>>> e.g. do other fancy stuff like unlocking the case.
>> We already can do that if anyone commits a text message.
> OK, I will do so.
> How to check-out/check in stuff for flashrom? I would like to have a
> devel-account.

Usually someone first sends a few patches, one of the longtime
developers commits them, and after some time the new person gets svn
commit access.

svn repo is at svn://coreboot.org/repos/trunk/util/flashrom

>>> We should organize and manage the change-requests for that little
>>> piece of soft.
>> Please post patches. We can discuss them.
> I posted a little bit some days ago for ST29F002 BNT/BT in my Compaq
> SFF PC 600MHZ. BX-Chipset

Yes, that patch is still under review AFAICS.


More information about the coreboot mailing list