hi list, after the nice flashrom demonstration on linuxtag in berlin. i have compiled flashrom and tested on several computer in the company. (simply using ./flashrom)
Is there anyone interested in collecting these data ? Motherboard (Manufacturer) + flashrom result ?
re, wh
walter harms wrote:
hi list, after the nice flashrom demonstration on linuxtag in berlin. i have compiled flashrom and tested on several computer in the company. (simply using ./flashrom)
Is there anyone interested in collecting these data ? Motherboard (Manufacturer) + flashrom result ?
Yes, post it here if you have the model numbers as well (with lspci would be even better).
-Bari
bari wrote:
walter harms wrote:
hi list, after the nice flashrom demonstration on linuxtag in berlin. i have compiled flashrom and tested on several computer in the company. (simply using ./flashrom)
Is there anyone interested in collecting these data ? Motherboard (Manufacturer) + flashrom result ?
Yes, post it here if you have the model numbers as well (with lspci would be even better).
my idea was to use dmidecode that i can get informations like that:
Handle 0x0100 DMI type 1, 25 bytes. System Information Manufacturer: Dell Inc. Product Name: OptiPlex GX280 Version: Not Specified
Handle 0x0200 DMI type 2, 8 bytes. Base Board Information Manufacturer: Dell Inc. Product Name: 0C7195 Version:
(Version is not filled, serial numbers removed)
re, wh
Hi together!
Lets rewrite / improve flashrom!
I would like to see an universal function-pointer approach for the flash-dev handling, as I stated before in this mailing list.
For detection of flash the flash-identification according to the manufacturers can be used, so all functionpointers for the detect-routines can be tried.
To detect the mainboard I would additionally suggest looking for strings in the bios (if original-bios is used). For Coreboot, I would suggest to have a short text with manufacturer, board model, chipset, cpu so string search can find something. 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.
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) 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.
Who is in charge for flashboot? We should organize and manage the change-requests for that little piece of soft.
Kind Regards
LuJa
walter harms schrieb:
bari wrote:
walter harms wrote:
hi list, after the nice flashrom demonstration on linuxtag in berlin. i have compiled flashrom and tested on several computer in the company. (simply using ./flashrom)
Is there anyone interested in collecting these data ? Motherboard (Manufacturer) + flashrom result ?
Yes, post it here if you have the model numbers as well (with lspci would be even better).
my idea was to use dmidecode that i can get informations like that:
Handle 0x0100 DMI type 1, 25 bytes. System Information Manufacturer: Dell Inc. Product Name: OptiPlex GX280 Version: Not Specified
Handle 0x0200 DMI type 2, 8 bytes. Base Board Information Manufacturer: Dell Inc. Product Name: 0C7195 Version:
(Version is not filled, serial numbers removed)
re, wh
On 06.06.2008 15:08, Ludwig Jaffe wrote:
Lets rewrite / improve flashrom!
A rewrite is unneccessary. Improvements are welcome.
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.
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.
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.
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.
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.
Who is in charge for flashboot?
Do you mean flashrom? If so, your patches can be reviewed by the list.
We should organize and manage the change-requests for that little piece of soft.
Please post patches. We can discuss them.
Regards, Carl-Daniel
it is nice to see that so many people like the idea ... :)
back to basics. my suggestion was to have a list and perhaps a utility that allows coreboot/flashrom to collect chip data from various box in the hope to seek out easy targets and give the developers a new incentive.
I do not thing that the myriad PC boards need that much support. A very interessting target could the std. desktop PC deployed by companies (DELL,HP, etc ..) That would open a whole new area: a desktop PC that boots linux instandly.
Since journey starts with the first step and coreboot simply need a database about deployed systems and there chipsets. To get many users as possible to submit data a *simple* script is need that collect the informations and sends it directly to coreboot.org.
Next question: who will write that script ?
re wh
Carl-Daniel Hailfinger wrote:
On 06.06.2008 15:08, Ludwig Jaffe wrote:
Lets rewrite / improve flashrom!
A rewrite is unneccessary. Improvements are welcome.
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.
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.
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.
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.
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.
Who is in charge for flashboot?
Do you mean flashrom? If so, your patches can be reviewed by the list.
We should organize and manage the change-requests for that little piece of soft.
Please post patches. We can discuss them.
Regards, Carl-Daniel
On 06.06.2008 16:43, walter harms wrote:
it is nice to see that so many people like the idea ... :)
back to basics. my suggestion was to have a list and perhaps a utility that allows coreboot/flashrom to collect chip data from various box in the hope to seek out easy targets and give the developers a new incentive.
We have two different problems: - Not enough developers for coreboot. Having more system data in a database will not help at all. We need more developers to complete existing targets or create new ones. - Not enough system data for flashrom. That's why we tell people to test flashrom and report success/failure.
I do not thing that the myriad PC boards need that much support. A very interessting target could the std. desktop PC deployed by companies (DELL,HP, etc ..) That would open a whole new area: a desktop PC that boots linux instandly.
Since journey starts with the first step and coreboot simply need a database about deployed systems and there chipsets. To get many users as possible to submit data a *simple* script is need that collect the informations and sends it directly to coreboot.org.
Next question: who will write that script ?
I wrote such a script a few months ago and sent it to the list.
The best thing someone new to coreboot/flashrom can do easily is testing flashrom everywhere. After that, the next step is to find a machine supported by coreboot and install coreboot there. Entering real coreboot development is difficult and comes later.
Regards, Carl-Daniel
Carl-Daniel Hailfinger wrote:
I do not thing that the myriad PC boards need that much support. A very interessting target could the std. desktop PC deployed by companies (DELL,HP, etc ..) That would open a whole new area: a desktop PC that boots linux instandly.
Since journey starts with the first step and coreboot simply need a database about deployed systems and there chipsets. To get many users as possible to submit data a *simple* script is need that collect the informations and sends it directly to coreboot.org.
Next question: who will write that script ?
I wrote such a script a few months ago and sent it to the list.
it should be available on coreboot.org/download or front page clearly visible ! it will clearly not help getting more people into coreboot development but if you can add a chip that is used in 1000 desktops you will certainly draw more attention than doing the same effort and reaching 10. If it works than you can find that chip. Even when you will never use the data collected by the script, so what ? it will waste only a few more bytes on the coreboot.org server.
re, wh
Dear Walter,
Am Dienstag, den 10.06.2008, 09:54 +0200 schrieb walter harms:
Next question: who will write that script ?
I wrote such a script a few months ago and sent it to the list.
can you send me that script ?
I am not sure, but maybe this [1] and [2] is the script, Carl-Daniel was talking about. (The thread is broken, so in [2] is the recent version, I think.)
Thanks,
Paul
[1] http://www.coreboot.org/pipermail/coreboot/2008-February/031507.html [2] http://www.coreboot.org/pipermail/coreboot/2008-March/031654.html
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
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
On Fri, Jun 06, 2008 at 09:42:35PM +0200, Carl-Daniel Hailfinger wrote:
That does not help because we still have to write routines for every special mainboard and then we can easily use PCI subsystem IDs.
Sadly, not always. Look at the various geode boards out there, for instance - a lot of them look very alike or even identical if you only look at PCI subsystem IDs, but are in fact made by different vendors and/or different models of the same vendor. Ask the artecgroup guys for their experience with that :/
Thanks, Ward.
Hi Walter,
On 06.06.2008 09:10, walter harms wrote:
bari wrote:
walter harms wrote:
hi list, after the nice flashrom demonstration on linuxtag in berlin. i have compiled flashrom and tested on several computer in the company. (simply using ./flashrom)
Great.
Is there anyone interested in collecting these data ? Motherboard (Manufacturer) + flashrom result ?
Yes, post it here if you have the model numbers as well (with lspci would be even better).
my idea was to use dmidecode that i can get informations like that:
Handle 0x0100 DMI type 1, 25 bytes. System Information Manufacturer: Dell Inc. Product Name: OptiPlex GX280 Version: Not Specified
Handle 0x0200 DMI type 2, 8 bytes. Base Board Information Manufacturer: Dell Inc. Product Name: 0C7195 Version:
(Version is not filled, serial numbers removed)
Sometimes dmidecode also has information on BIOS size. Having that info as well would be nice. lspci -nnv (not a typo, I really want -nnv) would help a lot to estimate testing coverage.
If there are machines where flashrom does not find a flash chip, please run flashrom -V.
Regards, Carl-Daniel
-
bari -
Carl-Daniel Hailfinger -
Ludwig Jaffe -
Paul Menzel -
walter harms -
Ward Vandewege