conathan at gmail.com
Mon Apr 28 05:56:21 CEST 2008
On Sun, Apr 27, 2008 at 6:16 PM, Peter Stuge <peter at 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
> 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."
> 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.
> coreboot mailing list
> coreboot at coreboot.org
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)
ICH6-M southbridge, and one user reported having a WinBond W25x40
Nathan Coulson (conathan)
Location: Alberta, Canada
Timezone: MST (-7)
More information about the coreboot