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.
Agreed.
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.
Regards, Carl-Daniel