I found buffer overflow at at45db module. Error was in chunk length calculation.
Patch is attached.
Chip AT45DB041D: reading, writing and erasing operations works correctly.
Best regards, Alexander Irenkov
On Wed, 23 Apr 2014 20:40:26 +0530
Rajasekhar Pulluru <pullururajasekhar(a)gmail.com> wrote:
> Hi Stefan,
> Attached the full logs (excluding dmi). My observation is that:
> 1) reading spi flash seems to be good.
> 2) erasing spi flash : only first 64kb erases successfully, after that
> erase reports failure.
> 3) programming spi flash: only first 64kb programs fine, after that erase
> reports failure.
Hi, your output is missing the lines that are printed to stderr instead
of stdout and you should probably use the -o option of flashrom to
create logfiles ;)
... but anyway, it seems to me as if the ME region starts exactly where
you have problems. And I assume that it is at least not writable. You
can make that r/w by changing the flash descriptor (i.e. the first 4kB
which are apparently writable).
Kind regards/Mit freundlichen Grüßen, Stefan Tauner
Am 21.07.2011 17:54 schrieb Stefan Tauner:
> previously the dummies were initialized to be empty (all ones), which makes writes skip
> erasing altogether. with this patch the default is to fill it with random bytes instead and the
> old behavior can be enforced with stating "empty=yes" on the command line.
> Signed-off-by: Stefan Tauner <stefan.tauner(a)student.tuwien.ac.at>
Does the following not work for you?
dd if=/dev/urandom bs=1k count=4k of=oldimage.bin
flashrom -p dummy:emulate=SST25VF032B,image=oldimage.bin -w newimage.bin
On Fri, 30 Aug 2013 02:00:34 +0200
Stefan Tauner <stefan.tauner(a)student.tuwien.ac.at> wrote:
> This was mainly driven by getting rid of cli_classic_abort_usage() in cli_classic.c.
I forgot to mention something and give a rationale for it:
Thereby we also get rid of teasing the user to run flashrom again to
show usage information.
If we think the user should see the usage information we should show it
to him or at least a short syntax summary (which we pretty much lack
currently: the programmer parameter syntax is not really well
explained). (Small) GNU apps seem to favor printing a similar message
like we do. nmap, rsync give their whole usage information which is a
bit of a pain because it is so long (unlike flashrom's), ping and hd
are examples that just print a syntax summary (but they lack a complete
usage help). All of the above is stupid. :P Printing a wall of text
does not help and is even counterproductive if one can not scroll.
Printing how to print help is also a little bit silly if that help text
is not very long anyway. The right™ thing in the case of flashrom is
IMHO to print the complete usage help (after improving it to explain
the programmer parameter syntax better).
> This makes the whole main function more consistent and fixes a myriad of
> (theoretical) memory leaks. This slightly changes output in most error cases.
> doit() stops calling programmer_shutdown() with this patch, beware.
Kind regards/Mit freundlichen Grüßen, Stefan Tauner
This patch adds support for the SST25WF080 1 Mbyte SPI flash chip. It
has been very minimally tested (basically one each read/write/verify),
on Windows XP with a USB Blaster as the programmer. It worked,
although it was horribly slow (at least 15 minutes to program 1 MB) -
but I have not otherwise used this hardware/software combination to
program anything, so that might be normal.
- Jason Harper
This message was sent using IMP, the Internet Messaging Program.
I've added a new definition for the Macronix MX23L3254 chip (4M). Since
it is a mask ROM, it doesn't support write or erase. Let me know if the
definition is incorrect in describing this.
Here's the datasheet for reference:
Probe and read works when tested on a real chip:
$ ./flashrom -p buspirate_spi:dev=/dev/ttyUSB0 -r trying_again2.bin
flashrom v0.9.7-r1767 on Linux 3.8.0-37-generic (x86_64)
flashrom is free software, get the source code at http://www.flashrom.org
Calibrating delay loop... OK.
Found Macronix flash chip "MX23L3254" (4096 kB, SPI) on buspirate_spi.
This flash part has status UNTESTED for operations: ERASE WRITE
The test status of this chip may have been updated in the latest development
version of flashrom. If you are running the latest development version,
please email a report to flashrom(a)flashrom.org if any of the above
work correctly for you with this flash part. Please include the flashrom
output with the additional -V option for all operations you tested (-V, -Vr,
-VE, -Vw), and mention which mainboard or programmer you tested.
Please mention your board in the subject line. Thanks for your help!
Reading flash... done.
Signed-off-by: Michael Coppola <michael.n.coppola(a)gmail.com>
Thanks for your IRC help a couple days ago. I have been partially successful in using the ROM layout file (-l) feature in flashrom to segment the writes to the flash in my HP Z820 workstation. It evident the HP Z820 flash has two ‘regions’: that below 0x510000 and that 0x510000 and above. The lower portion contains the coding for the Intel AMT/ME features and other data. The attached lower.txt file is log of the successful write flash addresses below 0x510000.
But writing to the space above 0x510000 is still a problem. In that space I tried writing just to the bootblock area (which is all I am seeking to update in this flash) and while flashrom tags it initially as read/write, the write fails. See the attached upper.txt logfile. I did attempt writing to the entire upper section (not just the bootblock) and got the same results.
The flash is hardware write enabled or I could not have written to the area below 0x510000. It seems something else seems needs enabling. Any thoughts would be helpful.
Thanks again ...
Hello flashrom developers!
I am currently hacking flashrom support for a National Instrments
USB-8451 USB-SPI converter. I have found an AT25DF081A in the drawer to
be used as a medical rabbit for my experiments.
Probing, reading works fine, but the chip is sector protected. The
flashrom tries to disable the protection with clearing the 7th bit
(SPRL) in the status register, but as the datasheet states:
/As a safeguard against accidental or erroneous locking or unlocking of
sectors, the Sector Protection Registers can themselves be locked from
updates by using the SPRL (Sector Protection Registers Locked) bit of
the Status Register (refer to "Status Register Commands" on page 16 for
more details). If the Sector Protection Registers are locked, then any
attempts to issue the Unprotect Sector command will be ignored, and the
device will reset the WEL bit in the Status////Register back to a
logical "0" and return to the idle state once the CS pin has been
So to unlock my flash I would have to walk through the sectors and issue
an Unprotect sector command with the sector's address.
My problem is that the erase blocks addresses and the sector addresses
are different things. In my case it has 64Kbyte block feature and the
sectors are 64Kbyte, but it also has 4KByte block feature too.
What would you recommend how to implement the sector unlocking mode?
My proposal is the following:
- Add a sector describing structure to the flashchip structure. It would
contain the sector count and sector size.
- Create a new unlock method:
spi_disable_blockprotect_at2x_sector_unprotect for e.g. which clears the
SPRL, then (if SWP is not 0) loops through the sectors and unlock them.
- If we want to be nice after the write we can reprotect the device.
Please let me know your opinion on this topic!
Hi, I am seeking an answer to an apparently obscure question. If I install coreboot on my BIOS (UEFI motherboard) and the computer fails to boot, can I reset the BIOS flash to its default image? I've read about possibly changing jumper positions or removing the BIOS battery, but I can't seem to establish if these are sure-fire ways of restoring the original BIOS flash image. I'd like to attempt to install coreboot on a motherboard that doesn't appear to be coreboot-supported, but only if I know I can completely undo this. Is the default BIOS flash image preserved somewhere on a ROM chip or can it only be restored with special equipment? I definitely do not want to end up with an unusable machine. Thanks!