Am 09.03.2011 02:52 schrieb Michael Karcher:
> As the comment indicates, that function is not a chip erase function
> at all, but a function calling a block eraser in a loop. So it adds
> no extra value to what we already have in the block_eraser
> Furthermore, that function assumes a uniform sector size layout, but
> is referenced from flash chip with non-uniform sector size layout, which
> is just wrong.
Great, even more code killed. Thanks for your patch.
> Signed-off-by: Michael Karcher<flashrom(a)mkarcher.dialup.fu-berlin.de>
Acked-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006(a)gmx.net>
Please compile test, then commit.
The attached patch adds support for the following Eon SPI flash chips:
EN25Q40, EN25Q80, EN25Q32A/B, EN25Q64, and EN25Q128
I was going to add support for the EN25Q16 as well, but found that it shares
the same ID as the EN25D16 but has different write protection capabilities.
So I added a comment instead.
I do not have real hardware to test with at the moment, so I left the status
Datasheets available from Eon @ http://www.eonssi.com/products/products.aspx
David Hendricks (dhendrix)
Systems Software Engineer, Google Inc.
Currently messages like "Writing flash chip..." that don't end with a
newline are buffered until the operation is complete, unless the
particular write function generates status output in the meantime.
Flushing stdout after each message ensures that the message appears
Signed-off-by: Ed Swierk <eswierk(a)aristanetworks.com>
@@ -47,5 +47,6 @@ int print(int type, const char *fmt, ...
ret = vfprintf(output_type, fmt, ap);
During discussion on IRC channel found out, that K7S41GX uses the same
bios chip and the same super I/O chip as K7S41. Tested reading, writing
and verification, all worked fine.
Signed-off-by: Pawel Rozanski <rozie(a)poczta.onet.pl>
BTW for K7S41 match string is "^K7S41 $", probably should be "^K7S41$",
but cannot test it.
On 5/14/10 3:06 PM, Michael Karcher wrote:
> Am Freitag, den 14.05.2010, 14:48 +0200 schrieb Stefan Reinauer:
>> On 4/16/10 6:21 PM, Stefan Reinauer wrote:
>>> Look at the return value of wait_82802ab()
>>> Index: sst49lfxxxc.c
>>> --- sst49lfxxxc.c (revision 993)
>>> +++ sst49lfxxxc.c (working copy)
>>> @@ -84,6 +84,7 @@
>>> chip_writeb(0xD0, bios + address);
>>> status = wait_82802ab(bios);
>>> + print_status_82802ab(status);
> basically a good idea, but printing one status dump per erased block
> seems a bit excessive, even in verbose mode, as there are some chips
> with 4K sector size. Could you limit status printing to "status !=
> 0x80", as this is "ready, no error bits"?
That's what the 82802ab and sharp lhf00l04 do, too. So if you think the
behavior should be changed, you should change it in all three places.
I just wanted to say thanks and report that I just successfully flashed
the BIOS of my brand-new mainboard Supermicro X7SPA-HF¹ using flashrom.
After wasting a whole evening trying to make a 4MB BIOS image fit onto a
(virtual) floppy, I stumbled upon flashrom again and, without much
thought, decided to give it a try. I tried reading the current BIOS
first and after that worked I flashed the file X7SPA0.526 from the
current zip download. I ignored the message that erasing is untested and
another one that suggested that a single block or something like that
couldn't be eraed. After five minutes of waiting I became a little bit
nervous, but two or three minutes later flashrom was finished and I
could reboot successfully.
So, thanks again, flashrom saved my day. If you need any further
information for your documentation, please Cc me as I am not subscribed.
When I am doing sex I wonder if my emotions can be detected by alien
Just flashed my ASUS M4A78-EM using flashrom (Ubuntu packed version
0.9.1+r946-1ubuntu1, with latest rev. 2101 ROM from ASUS), and
everything went fine. Just thought I'd send this note since the
motherboard isn't listed in the wiki yet. Reading the old image from
chip also worked fine.