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 would like to see an universal function-pointer approach for the >> flash-dev handling, as I stated before in this mailing list. >> >> > > We already have that. > > >> For detection of flash the flash-identification according to the >> manufacturers can be used, so all functionpointers for the >> detect-routines can be tried. >> >> > > We already do that. > > >> 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...
> >> 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. > >> 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". >> 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 :-) > >> 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. > >> Who is in charge for flashboot? >> >> > > Do you mean flashrom? If so, your patches can be reviewed by the list. > > Yes, beeing stupid I f*cked it up :-) >> 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 > > Regards, > Carl-Daniel > > Cheeres Ludwig -- coreboot mailing list [email protected] http://www.coreboot.org/mailman/listinfo/coreboot
