I would like to release flashrom-1.0 before the weekend.
There was a bit of discussion on IRC tonight and I found there are others who are also looking forward to a release.
Not so much because we think flashrom is currently in a particularly awesome state, but rather because we would like to get it packaged, distributed, used and marketed more - and that is really all version numbers are good for anyway.
There are many pending patches in people's working copies that are on their way into the repo, and that is great. I would like nothing more than to make a 1.1 release shortly after 1.0, and I hope noone feels that flashrom should freeze somehow just because it now has a version number.
I think flashrom will always be work in progress to a high degree, especially since the probing can never be fool proof because of our dearest PC architecture, but I still would like to make releases.
While some parts of trunk flashrom may not be production quality, there are some parts that are indeed production quality and that have been heavily used. I think 1.0 is a nice round number and a great starting point for future improvements. It also communicates the fact that at least parts of flashrom are very good and quite usable, as has been the case for several years already. :)
I've made a preliminary roadmap or action plan for 1.0:
1 handle the possibility of NULL flash chip function pointer derefs 2 add a tested flag to the flash chip table, most will be untested now 3 Carl-Daniel has a patch with fake flash chips of different sizes that is good to let people at least read the flash chip even if there is no support. Either this goes in as is and we add a -C --force-chip option (or similar) or we could make a special --force-read command to avoid cluttering the flash chip list with dirty fake chips. 4 go over text output to find and do possible UI improvements 5 change -s and -e into -S and -E, and change -E into -e with the rationale that erase is much more common than "exclude end position" 6 make probes advisory rather than controlling? always have the user confirm the probed chipset before continuing?
I can do 1, 2 and 4. If there is agreement I'd love to do 5 too.
In 4 I include adding a message for the user about the mainboards that need to be specified manually when board probing fails.
Please share your thoughts - and in particular anything on 3 or 6.
The plan is to create a repos/tags/flashrom-1.0 tag of the rev that goes into release, and publish the release with a tarball on the Flashrom wiki page.
For a bit of fun (gotta have some fun! :) we can have codenames for releases when we feel like it, the 1.0 favorite is "apt apology."
Objections? More must-have stuff before 1.0?
I don't want to add too much stuff, just trim away the worst rough edges and make a release very soon.
//Peter
I like it! Will it be released with distros, etc? If so, every time it goes up a version we would need to release an update patch correct?
Thanks, Joseph Smith Set-Top-Linux www.settoplinux.org
-----Original Message----- From: coreboot-bounces@coreboot.org [mailto:coreboot-bounces@coreboot.org] On Behalf Of Peter Stuge Sent: Sunday, April 27, 2008 8:16 PM To: coreboot@coreboot.org Subject: [coreboot] flashrom-1.0
I would like to release flashrom-1.0 before the weekend.
There was a bit of discussion on IRC tonight and I found there are others who are also looking forward to a release.
Not so much because we think flashrom is currently in a particularly awesome state, but rather because we would like to get it packaged, distributed, used and marketed more - and that is really all version numbers are good for anyway.
There are many pending patches in people's working copies that are on their way into the repo, and that is great. I would like nothing more than to make a 1.1 release shortly after 1.0, and I hope noone feels that flashrom should freeze somehow just because it now has a version number.
I think flashrom will always be work in progress to a high degree, especially since the probing can never be fool proof because of our dearest PC architecture, but I still would like to make releases.
While some parts of trunk flashrom may not be production quality, there are some parts that are indeed production quality and that have been heavily used. I think 1.0 is a nice round number and a great starting point for future improvements. It also communicates the fact that at least parts of flashrom are very good and quite usable, as has been the case for several years already. :)
I've made a preliminary roadmap or action plan for 1.0:
1 handle the possibility of NULL flash chip function pointer derefs 2 add a tested flag to the flash chip table, most will be untested now 3 Carl-Daniel has a patch with fake flash chips of different sizes that is good to let people at least read the flash chip even if there is no support. Either this goes in as is and we add a -C --force-chip option (or similar) or we could make a special --force-read command to avoid cluttering the flash chip list with dirty fake chips. 4 go over text output to find and do possible UI improvements 5 change -s and -e into -S and -E, and change -E into -e with the rationale that erase is much more common than "exclude end position" 6 make probes advisory rather than controlling? always have the user confirm the probed chipset before continuing?
I can do 1, 2 and 4. If there is agreement I'd love to do 5 too.
In 4 I include adding a message for the user about the mainboards that need to be specified manually when board probing fails.
Please share your thoughts - and in particular anything on 3 or 6.
The plan is to create a repos/tags/flashrom-1.0 tag of the rev that goes into release, and publish the release with a tarball on the Flashrom wiki page.
For a bit of fun (gotta have some fun! :) we can have codenames for releases when we feel like it, the 1.0 favorite is "apt apology."
Objections? More must-have stuff before 1.0?
I don't want to add too much stuff, just trim away the worst rough edges and make a release very soon.
//Peter
-- coreboot mailing list coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
2008/4/28 Joe joe@settoplinux.org:
I like it! Will it be released with distros, etc?
Yes It will be released. BTW right now it included into Fedora and RHEL-compatible distros through standart repositories (with slightly outdated version though).
Peter Lemenkov wrote:
2008/4/28 Joe joe@settoplinux.org:
I like it! Will it be released with distros, etc?
Yes It will be released. BTW right now it included into Fedora and RHEL-compatible distros through standart repositories (with slightly outdated version though)
It's also in (Open)SUSE under the name of coreboot-utils
On Mon, Apr 28, 2008 at 02:49:01PM +0200, Stefan Reinauer wrote:
Yes It will be released. BTW right now it included into Fedora and RHEL-compatible distros through standart repositories (with slightly outdated version though)
It's also in (Open)SUSE under the name of coreboot-utils
And also Debian and Mandriva, to make the list complete.
Uwe.
Ühel kenal päeval, P, 2008-04-27 kell 20:32, kirjutas Joe:
I like it! Will it be released with distros, etc?
If the distro in question chooses to package it. Some already package arbitrary snapshots from SVN; after releases start to happen they can just dub these packages with a good version number.
If so, every time it goes up a version we would need to release an update patch correct?
That's the distributions choice if they will version bump it or not. I don't know about "update patch", I in Gentoo Linux would just package the next version, and not include any patches that bring it to the level of the next version. I think that's what you have meant too, but some distributions do include patches of code for some reason sometimes instead of just packaging the new version.
With his Gentoo developers hat on this time, Mart Raudsepp
On Sun, Apr 27, 2008 at 08:32:03PM -0400, Joe wrote:
I like it! Will it be released with distros, etc?
Yes, that's the plan. Having a version number (any number) helps make life so much easier for distributions, and thus it increases the chances for the utility to spread.
If so, every time it goes up a version we would need to release an update patch correct?
No, not really neccessary. The Linux kernel does this, for each releasy they also release a patch with all changes from the last release to the current, but I don't know a lot of other projects who do that, and I don't think there is much point to it.
One motivation could be size, but flashrom will be a small enough package for that not to matter.
I also don't know of any distributions that are patch based like that and would require it - rather I think most distributions prefer to have each version in a separate tarball.
//Peter
On Mon, 28 Apr 2008 10:13:45 +0200, Peter Stuge peter@stuge.se wrote:
On Sun, Apr 27, 2008 at 08:32:03PM -0400, Joe wrote:
I like it! Will it be released with distros, etc?
Yes, that's the plan. Having a version number (any number) helps make life so much easier for distributions, and thus it increases the chances for the utility to spread.
If so, every time it goes up a version we would need to release an update patch correct?
No, not really neccessary. The Linux kernel does this, for each releasy they also release a patch with all changes from the last release to the current, but I don't know a lot of other projects who do that, and I don't think there is much point to it.
One motivation could be size, but flashrom will be a small enough package for that not to matter.
I also don't know of any distributions that are patch based like that and would require it - rather I think most distributions prefer to have each version in a separate tarball.
Ok, that makes sense. So we probibly should lay down some ground rules for when the next version gets released. It might get a little crazy if each time the svn revision changes a new version is released??
My vote is every 10 svn revisions, qualifies for a new version. How does that sound?
On Mon, Apr 28, 2008 at 07:54:15AM -0400, Joe wrote:
So we probibly should lay down some ground rules for when the next version gets released. It might get a little crazy if each time the svn revision changes a new version is released??
Each svn revision should certainly not be a new release version.
My vote is every 10 svn revisions, qualifies for a new version. How does that sound?
I would prefer to not set a fixed rule at all and instead release simply when we feel that there's good reason for it, be it because of a new feature, an important commit with a serious enough bug fix or something else.
I was toying with the idea of monthly releases, sort of like the Linux kernel, but I dropped it - I just don't think it's very practical or even useful for flashrom.
//Peter
Peter Stuge wrote:
My vote is every 10 svn revisions, qualifies for a new version. How does that sound?
I would prefer to not set a fixed rule at all and instead release simply when we feel that there's good reason for it, be it because of a new feature, an important commit with a serious enough bug fix or something else.
I agree with Peter here. Since the util/ tree is in our v2 repository, any non-flashrom related patches would increase the svn revision count, too. So there might be new versions without any changes to flashrom. Making a new release every so many months might be an idea though. We can also create milestones in tracker.coreboot.org and attach bugs/features to these. whenever all tickets are closed, we make a new release. How does that sound?
Stefan
On Mon, 28 Apr 2008 14:54:00 +0200, Stefan Reinauer stepan@coresystems.de wrote:
Peter Stuge wrote:
My vote is every 10 svn revisions, qualifies for a new version. How does that sound?
I would prefer to not set a fixed rule at all and instead release simply when we feel that there's good reason for it, be it because of a new feature, an important commit with a serious enough bug fix or something else.
I agree with Peter here. Since the util/ tree is in our v2 repository, any non-flashrom related patches would increase the svn revision count, too. So there might be new versions without any changes to flashrom. Making a new release every so many months might be an idea though. We can also create milestones in tracker.coreboot.org and attach bugs/features to these. whenever all tickets are closed, we make a new release. How does that sound?
Yup, that would work. I deffinatly think there should be some kind of criteria laid down for new versions. That's just my two cents, though.
On Mon, Apr 28, 2008 at 08:59:59AM -0400, Joe wrote:
I deffinatly think there should be some kind of criteria laid down for new versions.
Why?
I don't think we will be able to set a criteria beforehand that will work out well later down the road. :\
Again, I consider version numbers to be more about improving accessibility and marketing than anything else, and it's difficult to know what users want beforehand.
I say let's get 1.0 out and see what happens. :) Real laid back I know, but it will be nice to see how it is received and go from there.
//Peter
On Mon, 28 Apr 2008 15:09:19 +0200, Peter Stuge peter@stuge.se wrote:
On Mon, Apr 28, 2008 at 08:59:59AM -0400, Joe wrote:
I deffinatly think there should be some kind of criteria laid down for new versions.
Why?
I don't think we will be able to set a criteria beforehand that will work out well later down the road. :\
Again, I consider version numbers to be more about improving accessibility and marketing than anything else, and it's difficult to know what users want beforehand.
I say let's get 1.0 out and see what happens. :) Real laid back I know, but it will be nice to see how it is received and go from there.
Well, for example we have rules laid down for submitting patches to the svn right? And, those rules serve a purpose right?
Maybe, it is just me then, I work in a very structured bussiness environment, where there are rules and guidlines to everything. And they serve their purpose for good reasons.
On Mon, Apr 28, 2008 at 10:24:55AM -0400, Joe wrote:
I deffinatly think there should be some kind of criteria laid down for new versions.
Why?
Well, for example we have rules laid down for submitting patches to the svn right? And, those rules serve a purpose right?
Yes, definately. But keep in mind they don't control _when_ patches are submitted. ;)
Maybe, it is just me then, I work in a very structured bussiness environment, where there are rules and guidlines to everything.
I'm not saying policy is always bad, I'm just saying I think it will be tough to create a useful one for this.
And they serve their purpose for good reasons.
My "why" question wasn't asking why rules in general, but rather if you had any suggestions about specific rules for this case - ie reasons and purposes that we would make rules for.
If we can come up with some good ones then great, but I think it will be tough. If not, no big deal I say.
//Peter
On Mon, 28 Apr 2008 16:36:32 +0200, Peter Stuge peter@stuge.se wrote:
On Mon, Apr 28, 2008 at 10:24:55AM -0400, Joe wrote:
I deffinatly think there should be some kind of criteria laid down for new versions.
Why?
Well, for example we have rules laid down for submitting patches to the svn right? And, those rules serve a purpose right?
Yes, definately. But keep in mind they don't control _when_ patches are submitted. ;)
Maybe, it is just me then, I work in a very structured bussiness environment, where there are rules and guidlines to everything.
I'm not saying policy is always bad, I'm just saying I think it will be tough to create a useful one for this.
And they serve their purpose for good reasons.
My "why" question wasn't asking why rules in general, but rather if you had any suggestions about specific rules for this case - ie reasons and purposes that we would make rules for.
If we can come up with some good ones then great, but I think it will be tough. If not, no big deal I say.
Ok, for now then can we go with Stefan's idea with tracker.coreboot.org and see where that goes?
On Mon, Apr 28, 2008 at 02:54:00PM +0200, Stefan Reinauer wrote:
Making a new release every so many months might be an idea though. We can also create milestones in tracker.coreboot.org and attach bugs/features to these. whenever all tickets are closed, we make a new release. How does that sound?
Great in theory! In practice it may become overhead that is always overlooked :\ but it could also be a success if we suddenly have more active users in trac. I like trac for management stuff like this so thumbs up.
//Peter
On Sun, Apr 27, 2008 at 6:16 PM, Peter Stuge peter@stuge.se wrote:
I would like to release flashrom-1.0 before the weekend.
There was a bit of discussion on IRC tonight and I found there are others who are also looking forward to a release.
Not so much because we think flashrom is currently in a particularly awesome state, but rather because we would like to get it packaged, distributed, used and marketed more - and that is really all version numbers are good for anyway.
There are many pending patches in people's working copies that are on their way into the repo, and that is great. I would like nothing more than to make a 1.1 release shortly after 1.0, and I hope noone feels that flashrom should freeze somehow just because it now has a version number.
I think flashrom will always be work in progress to a high degree, especially since the probing can never be fool proof because of our dearest PC architecture, but I still would like to make releases.
While some parts of trunk flashrom may not be production quality, there are some parts that are indeed production quality and that have been heavily used. I think 1.0 is a nice round number and a great starting point for future improvements. It also communicates the fact that at least parts of flashrom are very good and quite usable, as has been the case for several years already. :)
I've made a preliminary roadmap or action plan for 1.0:
1 handle the possibility of NULL flash chip function pointer derefs 2 add a tested flag to the flash chip table, most will be untested now 3 Carl-Daniel has a patch with fake flash chips of different sizes that is good to let people at least read the flash chip even if there is no support. Either this goes in as is and we add a -C --force-chip option (or similar) or we could make a special --force-read command to avoid cluttering the flash chip list with dirty fake chips. 4 go over text output to find and do possible UI improvements 5 change -s and -e into -S and -E, and change -E into -e with the rationale that erase is much more common than "exclude end position" 6 make probes advisory rather than controlling? always have the user confirm the probed chipset before continuing?
I can do 1, 2 and 4. If there is agreement I'd love to do 5 too.
In 4 I include adding a message for the user about the mainboards that need to be specified manually when board probing fails.
Please share your thoughts - and in particular anything on 3 or 6.
The plan is to create a repos/tags/flashrom-1.0 tag of the rev that goes into release, and publish the release with a tarball on the Flashrom wiki page.
For a bit of fun (gotta have some fun! :) we can have codenames for releases when we feel like it, the 1.0 favorite is "apt apology."
Objections? More must-have stuff before 1.0?
I don't want to add too much stuff, just trim away the worst rough edges and make a release very soon.
//Peter
-- coreboot mailing list coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
I just wanted to report my tests with flashrom.
Running on a EeePC 701 4G.
Calibrating delay loop... OK. No coreboot table found. Found chipset "Intel ICH6-M", enabling flash write... OK. No EEPROM/flash device found.
(Not my site, but it has the specs on the EeePC) http://beta.ivancover.com/wiki/index.php/Eee_PC_Research
ICH6-M southbridge, and one user reported having a WinBond W25x40
Hi Nathan,
On Sun, Apr 27, 2008 at 09:56:21PM -0600, Nathan Coulson wrote:
I just wanted to report my tests with flashrom.
Thank you for the report!
(Just a small request that you please keep in mind to start a new thread the next time you post on a new topic. Ie. post a brand new message to the list rather than replying. That way, it is easier to follow the discussion within your new thread. Thanks in advance! :)
Running on a EeePC 701 4G.
Calibrating delay loop... OK. No coreboot table found. Found chipset "Intel ICH6-M", enabling flash write... OK. No EEPROM/flash device found.
(Not my site, but it has the specs on the EeePC) http://beta.ivancover.com/wiki/index.php/Eee_PC_Research
ICH6-M southbridge, and one user reported having a WinBond W25x40
That wiki page mentions it has a Intel 915 chipset, I would have guessed that it's an ICH-8M rather than 6, but never mind. It's an SPI flash chip and flashrom does not have completely generic SPI support yet, so I am not surprised that flashrom does not work on the machine yet.
Sorry about these bad news. :\
//Peter
On Mon, Apr 28, 2008 at 2:10 AM, Peter Stuge peter@stuge.se wrote:
Hi Nathan,
On Sun, Apr 27, 2008 at 09:56:21PM -0600, Nathan Coulson wrote:
I just wanted to report my tests with flashrom.
Thank you for the report!
(Just a small request that you please keep in mind to start a new thread the next time you post on a new topic. Ie. post a brand new message to the list rather than replying. That way, it is easier to follow the discussion within your new thread. Thanks in advance! :)
Running on a EeePC 701 4G.
Calibrating delay loop... OK. No coreboot table found. Found chipset "Intel ICH6-M", enabling flash write... OK. No EEPROM/flash device found.
(Not my site, but it has the specs on the EeePC) http://beta.ivancover.com/wiki/index.php/Eee_PC_Research
ICH6-M southbridge, and one user reported having a WinBond W25x40
That wiki page mentions it has a Intel 915 chipset, I would have guessed that it's an ICH-8M rather than 6, but never mind. It's an SPI flash chip and flashrom does not have completely generic SPI support yet, so I am not surprised that flashrom does not work on the machine yet.
Sorry about these bad news. :\
//Peter
-- coreboot mailing list coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
no problem (and sorry for hijacking the thread).
Hi,
On 28.04.2008 10:10, Peter Stuge wrote:
Hi Nathan,
On Sun, Apr 27, 2008 at 09:56:21PM -0600, Nathan Coulson wrote:
I just wanted to report my tests with flashrom.
Thank you for the report!
Running on a EeePC 701 4G.
Calibrating delay loop... OK. No coreboot table found. Found chipset "Intel ICH6-M", enabling flash write... OK. No EEPROM/flash device found.
(Not my site, but it has the specs on the EeePC) http://beta.ivancover.com/wiki/index.php/Eee_PC_Research
ICH6-M southbridge, and one user reported having a WinBond W25x40
That wiki page mentions it has a Intel 915 chipset, I would have guessed that it's an ICH-8M rather than 6, but never mind. It's an SPI flash chip and flashrom does not have completely generic SPI support yet, so I am not surprised that flashrom does not work on the machine yet.
Sorry about these bad news. :\
The good news is that I think I understand what's happening here: The ICH6-M LPC cycles go to the Embedded Controller, which translates them to SPI cycles. That means we can't support flashing/identifying your chip until flashrom support for the Embedded Controller has been implemented. The good news is that we have programming info for a similar EC (the OLPC EC) and is should cost the implementer only a few days to add support to flashrom if he has access to the hardware, a LPC/SPI logic analyzer and a soldering iron in case flashing goes wrong.
Regards, Carl-Daniel
On 28.04.2008 18:19, Carl-Daniel Hailfinger wrote:
Hi,
On 28.04.2008 10:10, Peter Stuge wrote:
Hi Nathan,
On Sun, Apr 27, 2008 at 09:56:21PM -0600, Nathan Coulson wrote:
I just wanted to report my tests with flashrom.
Thank you for the report!
Running on a EeePC 701 4G.
Calibrating delay loop... OK. No coreboot table found. Found chipset "Intel ICH6-M", enabling flash write... OK. No EEPROM/flash device found.
(Not my site, but it has the specs on the EeePC) http://beta.ivancover.com/wiki/index.php/Eee_PC_Research
ICH6-M southbridge, and one user reported having a WinBond W25x40
That wiki page mentions it has a Intel 915 chipset, I would have guessed that it's an ICH-8M rather than 6, but never mind. It's an SPI flash chip and flashrom does not have completely generic SPI support yet, so I am not surprised that flashrom does not work on the machine yet.
Sorry about these bad news. :\
The good news is that I think I understand what's happening here: The ICH6-M LPC cycles go to the Embedded Controller, which translates them to SPI cycles. That means we can't support flashing/identifying your chip until flashrom support for the Embedded Controller has been implemented. The good news is that we have programming info for a similar EC (the OLPC EC) and is should cost the implementer only a few days to add support to flashrom if he has access to the hardware, a LPC/SPI logic analyzer and a soldering iron in case flashing goes wrong.
Try the attached patch for reading the flash chip.
Regards, Carl-Daniel
Index: flash.h =================================================================== --- flash.h (Revision 3210) +++ flash.h (Arbeitskopie) @@ -316,6 +316,7 @@
/* flashrom.c */ int map_flash_registers(struct flashchip *flash); +int probe_fake(struct flashchip *flash);
/* layout.c */ int show_id(uint8_t *bios, int size); Index: flashchips.c =================================================================== --- flashchips.c (Revision 3210) +++ flashchips.c (Arbeitskopie) @@ -137,6 +137,7 @@ {"PMC", "unknown SPI chip", PMC_ID, GENERIC_DEVICE_ID, 0, 0, probe_spi, NULL, NULL}, {"SST", "unknown SPI chip", SST_ID, GENERIC_DEVICE_ID, 0, 0, probe_spi, NULL, NULL}, {"ST", "unknown SPI chip", ST_ID, GENERIC_DEVICE_ID, 0, 0, probe_spi, NULL, NULL}, + {"Fake", "Fake flash chip", 0, 0, 512, 0, probe_fake, NULL, NULL},
{NULL,} }; Index: flashrom.c =================================================================== --- flashrom.c (Revision 3210) +++ flashrom.c (Arbeitskopie) @@ -99,6 +99,11 @@ return 0; }
+int probe_fake(struct flashchip *flash) +{ + return 1; +} + struct flashchip *probe_flash(struct flashchip *flash) { volatile uint8_t *bios;
-
Carl-Daniel Hailfinger -
Joe -
Mart Raudsepp -
Nathan Coulson -
Peter Lemenkov -
Peter Stuge -
Stefan Reinauer -
Uwe Hermann