flashrom April 2014

flashrom@flashrom.org

32 participants
121 discussions

at45db buffer overflow
by degener_trash＠mail.ru 10 May '14

10 May '14

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

3 4

Re: [flashrom] flashrom support for Intel Rangeley/Avoton/C2000
by Stefan Tauner 09 May '14

09 May '14

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

2 1

Re: [flashrom] [PATCH] dummyflasher.c: add an "empty" parameter and initialize with random bytes by default
by Carl-Daniel Hailfinger 09 May '14

09 May '14

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 Regards, Carl-Daniel -- http://www.hailfinger.org/

5 8

Re: [flashrom] [PATCH] Reorganize shutting down.
by Stefan Tauner 07 May '14

07 May '14

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). RFC. > > 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

2 1

[PATCH] Added SST25WF080
by jharper＠iseis.com 03 May '14

03 May '14

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.

3 3

[PATCH] Added support for MX23L3254
by Michael Coppola 03 May '14

03 May '14

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: http://www.macronix.com/Lists/DataSheet/Attachments/1233/MX23L3254,%203.0-3… 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 operations 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>

2 3

Re: [flashrom] W836xx : HP Z820 : flashrom -V
by Roberto Denis 03 May '14

03 May '14

iwer, stefacnt: 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 ... Roberto

3 2

Sector unprotect@AT25DF081A
by Márton Miklós 03 May '14

03 May '14

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 deasserted.// / 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! Thanks! -- Üdvözlettel, Márton Miklós

2 1

Compatibility with ECS Socket AM2+
by Leif Middelschulte 03 May '14

03 May '14

Hi, firstofall thanks for your effort with flashrom. It’s really great to be able to flash a bios image independently of Windows. Sorry I didn’t catch the entire/verbose output. Nevertheless I could successfully flash a vendor bios for the following Motherboard: http://www.ecs.com.tw/ECSWebSite/Product/Product_Detail.aspx?DetailID=865&M… Regards, Leif

3 2

Is there a sure-fire way to reset any BIOS flash image to its default, out-of-the-box state with no special equipment?
by linx255＠nym.hush.com 03 May '14

03 May '14

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! Jim

3 3

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

flashrom April 2014