My pull request has already been created that had occurred *several months*
previously. I added support for ST 95XXX chips . The following chipsets
have been successfully tested for read, erase and write operations: ST [
95080, 95160, 95320, 95640, 95128, 95256 ]. I would like to discuss a new
Maybe someone in the community will spent a bit of time and review my pull
request. Don't worry about the conflicting files. The part of the code has
already been merged into effect.
*I'm open-minded and ready. *
Please see the report below. I've tried flashing 2 eproms but get the
Calibrating delay loop... OK.
Found Macronix flash chip "MX25U6435E/F" (8192 kB, SPI) on ch341a_spi.
Reading old flash chip contents... done.
Erasing and writing flash chip... Erase/write done.
Verifying flash... FAILED at 0x00000010! Expected=0x5a, Found=0x5b,
failed byte count from 0x00000000-0x007fffff: 0x332be2
Your flash chip is in an unknown state.
Please report this on IRC at chat.freenode.net (channel #flashrom) or
mail flashrom(a)flashrom.org, thanks!
commit e28d75ed7204d7fac2c0fac13978098530b0574e dropped some logic
PCI-based programmers now fail to initialize IFF the desired PCI device
not the last one enumerated by libpci.
Given that this refactoring was done to make unit tests easier, I'd
expect the unit tests to have caught that problem.
This raises a few questions:
- Why did unit tests not find that problem?
- If there are no unit tests testing for such a problem, why was the
code refactored in the first place?
- Do we need CI tests with real hardware or at least with qemu to avoid
such problems in the future?
Dear flashrom community,
I regret to tell you that I won't do any further upstream flashrom work
in the foreseeable future. Compared to the last few months that won't
change much, as I didn't spend as much time on flashrom as I wanted to.
TL;DR Maintaining flashrom was always a bit of a drag, mostly reviewing,
organizing tests and releases, didn't leave much time for personal deve-
lopment. Still, it was mostly fun. Until I flew too close to the sun
and burned all my fuel that I had left for the project, trying to help
converging the Chromium fork with upstream flashrom. I really hoped it
wouldn't become another episode of "Nice! somebody else does the work".
Not - a - chance.
I was once told not to blame a company for the actions of individuals.
However, there is forming a pattern, of people complaining to me how
hard their job is; after I just did part of their job in my spare time!
I don't think they are to blame, but they happen to all have the same
employer. If we are pushed hard enough that we don't see anymore what
we ask from one another, it's time to quit. At least regarding flash-
rom I won't do any more work for them just because somebody said to
be done in no time.
About half a year ago people started to push patches from Chromium
upstream. I tried to welcome them and, as usual, to encouraged them
to announce their plans on the mailing list so we could all work better
together. Pipe dreams.
Obviously they wanted a fast lane, so the fork wouldn't cause too much
more friction (for them!). No time to wait for other patches (including
conflicting ones) to be reviewed. No [...] to do it by themselves. There
was a decision to be made, either they would have to wait and rebase or
other contributors would have to wait even longer and rebase. I chose
wrong, and feel sorry about it. I prioritized the upstreaming, did fewer
reviews for other contributors, let my own patches rot, didn't invest in
further flashrom releases.
Around the same time, somebody (who happens to have administration
rights) gave submit rights to the flashrom repository to one of them.
I tried to stay calm and to be nice. (Edward, nothing personal, I
actually was glad that it was you. I was just annoyed because of the
way it happened, I had to dig up what is going on instead of reading
it in a nice email.)
Up to now, I guess roughly 40~50 patches landed upstream. Most of
them in one of these categories:
o New features
o Flash chip support
o Remaining diff between the branches
The former turned out to be ok'ish, even though it's tedious to repeat
every time that patches should be organized to ease review, and should
have known issues fixed already.
The flash chip additions started with a weird idea, sort the
`flashchips.c` on both sides to make it easier comparable. I didn't
want to squabble about other people's workflow and, in good faith,
The last category produced some odd patches with creative commit
messages. It seems the idea was to diff individual files between
the branches and if it was small enough to turn it into a commit.
Now I have no idea how many sides their dice had that they used to
decide which branch would be patched. The result was that I had
to either complain about the commit message and hope to get answers
(unlikely) or to dig into it by myself, spending hours staring at
the history of the two branches to make some sense of it. I had to
do exactly what the uploaders avoided to do because of their time
constraints. Sometimes to find out that a commit effectively rever-
ted good upstream work! If that wasn't discovered during review,
that's the community's fault of course, and theirs to fix. The
uploaders have no time; remember, their job is hard, yours is not.
When I started maintaining flashrom, I set myself a rule: At least
have a look at every patch that lands on Gerrit. I broke that rule
at least with the patch train for AMD graphics cards, sorry Luc.
Obviously I regret prioritizing Chromium patches, before they
proved to be valuable community members. My biggest regret is the
re-sorting of `flashchips.c`. Given the few patches in that area
that landed, it didn't pan out. Also, it was a pure convenience
stunt, one can as well re-sort on-the-fly for comparison. OTOH,
it breaks the Git history, making it much harder to check for
reasons, e.g. why is this feature set? which variants of this
chip were really tested?
If anybody wants to roll back master to fix that, you'd have my
full support to make it happen without losing anything that was
I've left at least two of my patch trains rotting: A set to
overhaul internal layout handling and one for IFWI layouts. I've
seen that they were commented on eventually. Thank you Angel and
David, and sorry in advance if I wasted your time in case the
patches won't make it. The IFWI patches were written first, but
they made me realize that layout changes are necessary and should
come first. If I had spent more time on it, I would have rebased
I'll have to maintain a flashrom branch for my employer. It might
take some time before I rebase anything, but if anyone wants me to
keep things published somewhere, I can arrange that.
For upstream, future's all up to you!
Thank you all for the time we spent together on the project!
I am working on bringing up new board and everything seems to work.
I would like to test the functionality to make sure. There is https://www.flashrom.org/Board_Testing_HOWTO, but that is very general. Do you have some specific list of tests to run?
Board Testing HOWTO - flashrom<https://www.flashrom.org/Board_Testing_HOWTO>
This page gives you mainly hints on how to test flashrom support on mainboards. Testing for graphics / network / SATA cards and external programmer devices is similar but less dangerous.
I've tried to add an Intel EEPROM 28F200B5 top and bottom boot to the list of
supported chips. Therefore I modified the source codes flashchips.c and
flashchips.h based on your latest stable release 1.1 and attached to this
Email. But the Flashrom program still can't find any EEPROM/Flash device. I
also attach the logged output to this Email. Is there anything else in the
source code which I have to modify to make it work ?
----------------- Mail powered by Mutt for Debian GNU/Linux ------------------
-- Dipl.Ing. --
-- THORSTEN KOHL --
-- Radio Circuits and Systems
-- IMST GmbH --
-- Carl-Friedrich-Gauß Str. 2 --
-- D-47475 Kamp-Lintfort --
-- Germany --
-- Phone: +49-2842-981-446 --
-- Fax: +49-2842-981-299 --
-- EMail: kohl(a)imst.de --
-- PGP public key: DE193000 --
-- Internet: www.imst.de --
-- Geschaeftsfuehrer: --
-- Dr. Peter Waldow --
-- Amtsgericht Kleve HRB 6737 --
-- USt.-ID: DE 811348335 --
-- Wir weisen darauf hin, dass rechtsverbindliche Erklaerungen namens --
-- unseres Hauses grundsaetzlich der Unterschriften zweier ausreichend --
-- bevollmaechtigter Vertreter unseres Hauses beduerfen. Wir verschicken --
-- daher keine rechtsverbindlichen Erklaerungen per E-Mail an Dritte. --
-- Demgemaess nehmen wir per E-Mail auch keine rechtsverbindlichen --
-- Erklaerungen oder Auftraege von Dritten entgegen. Diese E-Mail dient --
-- einzig dem unverbindlichen Informationsaustausch zwischen Sender und --
-- Empfaenger. Sie entfaltet keine Rechtswirksamkeit. --
-- Diese E-Mail ist vertraulich zu behandeln. Sollten Sie nicht der --
-- vorgesehene Empfaenger sein, bitten wir Sie, den Versender zu informieren --
-- und die Nachricht zu loeschen. Die Weitergabe sowie Vervielfaeltigung, --
-- Verwertung und Mitteilung seines Inhalts ist nur mit unserer --
-- ausdruecklichen Genehmigung gestattet. Alle Rechte vorbehalten, --
-- insbesondere für den Fall der Schutzrechtsanmeldung. --
-- This document has to be treated confidentially. If you are not the --
-- intended recipient, please immediately notify the sender and delete this --
-- message. Its contents are not to be passed on, duplicated, exploited or --
-- disclosed without our expressed permission. All rights reserved, --
-- especially the right to apply for protective rights. --
On Wed, Jan 22, 2020 at 8:46 PM Dennis Dale-Green
> The BIOS I'm trying to flash is for a Gigabyte Brix mini PC. I originally tried flashing with the surface mounted chip in place using windows software but the flash failed to verify the data so would not compete the operation. I unsoldered the chip and tried again with the same failed result. I thought perhaps the chip was broken so I bought a new one and tried programming it again through windows. This also failed.
> So I thought I'd try Flashing using Linux, both the old and new chip failed with the result shown in my original email.
> I'll solder the chip onto the programmer's piggyback board and give that a try (got nothing to loose!) that will bypass any test clip issue.
> On Wed, 22 Jan 2020 at 15:04, Mike Banon <mikebdp2(a)gmail.com> wrote:
>> On Wed, Jan 22, 2020 at 2:07 PM Dennis <dennistravel(a)gmail.com> wrote:
>> > Hi. Please see the report below. I've tried flashing 2 eproms but get the
>> > same result. Any ideas? Thanks, Dennis
>> > Calibrating delay loop... OK.
>> > Found Macronix flash chip "MX25U6435E/F" (8192 kB, SPI) on ch341a_spi.
>> > Reading old flash chip contents... done.
>> > Erasing and writing flash chip... Erase/write done.
>> > Verifying flash... FAILED at 0x00000010! Expected=0x5a, Found=0x5b,
>> > failed byte count from 0x00000000-0x007fffff: 0x332be2
>> > Your flash chip is in an unknown state.
>> > Please report this on IRC at chat.freenode.net (channel #flashrom) or
>> > mail flashrom(a)flashrom.org, thanks!
>> Please describe your flashing setup. Are you trying the ISP (in-system
>> programming) using a SOIC clip? Maybe the wires between ch341a and
>> this test clip are too long or poor quality (have a high resistance,
>> i.e. aluminium has 1.5x higher resistance than copper)
Yes, flashing using Linux is preferable. Some faulty CH341A are giving
5V instead of 3.3V, please test yours with a multimeter. Have you ever
successfully flashed any chip with your CH341A? By the way I've
stumbled upon two CH341A (two posts on reddit's r/coreboot), one
CH341A had a badly soldered chip leg and another was missing a
capacitor. Easy to fix, but only if you have at least one working
CH341A to compare i.e. the voltages at various points of a faulty vs