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 -- coreboot mailing list [email protected] http://www.coreboot.org/mailman/listinfo/coreboot
