March 2016 - flashrom - mail.coreboot.org

80/100/132 column line width policy
by Carl-Daniel Hailfinger Dec. 15, 2018

Dec. 15, 2018

Hi, we're hitting the 80 column limit in our code in ways which actually reduce readability for the code. Examples are various multiline messages and complicated nested code where refactoring to a separate function doesn't make sense. Keeping the old 80 column limit is not really an option anymore. Standard terminal sizes have one of 80, 100 or 132 columns. Given the monitor resolutions many people have nowadays, I think it is safe to say that you can fit two xterms with 100 columns horizonally next to each other. 100 columns should also be sufficient for a msg_p* of roughly 80 columns of text. 132 columns provide more leeway, but IMHO that would be too wide for good readability (and my screen can't fit two xterms side-by-side anymore). Of course some files have sections where any column limit is not acceptable (board lists etc.), but the column limit violations should be limited to the affected file sections, not whole files. Comments? I'd like to get this decided today or tomorrow so we know where we need line breaks in Stefan Tauner's new struct flashchip patch. Regards, Carl-Daniel -- http://www.hailfinger.org/

7 9

Spansion S25FL128P......X
by The Raven April 24, 2017

April 24, 2017

I have a spansion S25FL128P......X chip and can do some tests. The "problem" is that i don't know if its an 0 or an 1. On the chip i see only "FL128PIF" and one line lower i see "00299012 C". Probing works (id1 0x01, id2 0x2018): Calibrating delay loop... OK. serprog: Programmer name is "serprog-duino" Found Spansion flash chip "S25FL128P......0" (16384 kB, SPI) on serprog. Found Spansion flash chip "S25FL128P......1" (16384 kB, SPI) on serprog. Found Spansion flash chip "S25FL128S......0" (16384 kB, SPI) on serprog. Found Spansion flash chip "S25FL128S......1" (16384 kB, SPI) on serprog. Found Spansion flash chip "S25FL129P......0" (16384 kB, SPI) on serprog. Found Spansion flash chip "S25FL129P......1" (16384 kB, SPI) on serprog. Multiple flash chip definitions match the detected chip(s): "S25FL128P......0", "S25FL128P......1", "S25FL128S......0", "S25FL128S......1", "S25FL129P......0", "S25FL129P......1" Please specify which chip definition to use with the -c <chipname> option. BTW: Chip was fund on a Dell-Systemboard.

3 6

New SPI NOR Flash product Support
by Victor Lim May 9, 2016

May 9, 2016

Hi, Flashrom team, I am the FAE manager for Gigadevice and would like to know how I can work with you to add our part # to your support list. A customer of mine is looking to program our GD25VQ41B with your tool and found that it is not supported by your tools. It would like grateful if you can support our entire SPI NOR portfolio. Regards, Victor Lim(Gigadevice/MK IV/FAE Manager) Gigadevice Semiconductor Inc. Tel: 408-855-8336 Mobile: 408-883-3856 Website: <http://www.gigadevice.com/> www.gigadevice.com 2975 Bowers Ave,Suite 323 Santa Clara, CA 95051, USA This email was sent to you by GigaDevice, A Global Innovative Memory Architect _____ The information contained in this e-mail message (and any attachment transmitted herewith) is privileged and confidential and is intended for the exclusive use of the addressee(s). If you are not an intended addressee, any disclosure, reproduction, distribution or other dissemination or use of this communication is strictly prohibited. If you have received this communication in error, please delete this communication and contact us by replying to this e-mail immediately.

4 12

[PATCH 0/1] Add support for reading the current flash contents from a file
by Paul Kocialkowski April 23, 2016

April 23, 2016

Here is an example script that I'm using to read the flash contents to a file once and update it as I flash newer versions of the software: #!/bin/sh flashrom="flashrom" programmer="ft2232_spi:type=openmoko,divisor=8" contents="/home/paulk/embedded-freedom/Devices/G505s/kb9012/flashrom/flash-contents.img" image="$1" if [ -z $image ] then echo "Reading initial flash contents" timeb=$( date +%s ) $flashrom -p $programmer -r $contents timea=$( date +%s ) echo "Time: "$(( $timea - $timeb ))" seconds" else echo "Writing new flash contents" timeb=$( date +%s ) $flashrom -p $programmer -w $image -C $contents --noverify rc=$? timea=$( date +%s ) if [ "$rc" -eq "0" ] then echo "Copying new flash contents" cp $image $contents fi echo "Time: "$(( $timea - $timeb ))" seconds" fi

4 6

[PATCH v3 1/2] Add support for selecting the erased bit value with a flag
by Paul Kocialkowski April 19, 2016

April 19, 2016

Most flash chips are erased to ones and programmed to zeros. However, some other flash chips, such as the ENE KB9012 internal flash, work the opposite way. Signed-off-by: Paul Kocialkowski <contact(a)paulk.fr> --- flash.h | 5 ++++- flashrom.c | 39 +++++++++++++++++++++------------------ 2 files changed, 25 insertions(+), 19 deletions(-) diff --git a/flash.h b/flash.h index da049d1..dc5c140 100644 --- a/flash.h +++ b/flash.h @@ -123,6 +123,9 @@ enum write_granularity { #define FEATURE_WRSR_EITHER (FEATURE_WRSR_EWSR | FEATURE_WRSR_WREN) #define FEATURE_OTP (1 << 8) #define FEATURE_QPI (1 << 9) +#define FEATURE_ERASED_ZERO (1 << 10) + +#define ERASED_VALUE(flash) (((flash)->chip->feature_bits & FEATURE_ERASED_ZERO) ? 0x00 : 0xff) enum test_state { OK = 0, @@ -275,7 +278,7 @@ int probe_flash(struct registered_master *mst, int startchip, struct flashctx *f int read_flash_to_file(struct flashctx *flash, const char *filename); char *extract_param(const char *const *haystack, const char *needle, const char *delim); int verify_range(struct flashctx *flash, const uint8_t *cmpbuf, unsigned int start, unsigned int len); -int need_erase(const uint8_t *have, const uint8_t *want, unsigned int len, enum write_granularity gran); +int need_erase(const uint8_t *have, const uint8_t *want, unsigned int len, enum write_granularity gran, const uint8_t erased_value); void print_version(void); void print_buildinfo(void); void print_banner(void); diff --git a/flashrom.c b/flashrom.c index 25e53f2..d5c3238 100644 --- a/flashrom.c +++ b/flashrom.c @@ -696,12 +696,13 @@ int check_erased_range(struct flashctx *flash, unsigned int start, { int ret; uint8_t *cmpbuf = malloc(len); + const uint8_t erased_value = ERASED_VALUE(flash); if (!cmpbuf) { msg_gerr("Could not allocate memory!\n"); exit(1); } - memset(cmpbuf, 0xff, len); + memset(cmpbuf, erased_value, len); ret = verify_range(flash, cmpbuf, start, len); free(cmpbuf); return ret; @@ -754,7 +755,7 @@ out_free: } /* Helper function for need_erase() that focuses on granularities of gran bytes. */ -static int need_erase_gran_bytes(const uint8_t *have, const uint8_t *want, unsigned int len, unsigned int gran) +static int need_erase_gran_bytes(const uint8_t *have, const uint8_t *want, unsigned int len, unsigned int gran, const uint8_t erased_value) { unsigned int i, j, limit; for (j = 0; j < len / gran; j++) { @@ -764,7 +765,7 @@ static int need_erase_gran_bytes(const uint8_t *have, const uint8_t *want, unsig continue; /* have needs to be in erased state. */ for (i = 0; i < limit; i++) - if (have[j * gran + i] != 0xff) + if (have[j * gran + i] != erased_value) return 1; } return 0; @@ -784,7 +785,7 @@ static int need_erase_gran_bytes(const uint8_t *have, const uint8_t *want, unsig * @gran write granularity (enum, not count) * @return 0 if no erase is needed, 1 otherwise */ -int need_erase(const uint8_t *have, const uint8_t *want, unsigned int len, enum write_granularity gran) +int need_erase(const uint8_t *have, const uint8_t *want, unsigned int len, enum write_granularity gran, const uint8_t erased_value) { int result = 0; unsigned int i; @@ -799,31 +800,31 @@ int need_erase(const uint8_t *have, const uint8_t *want, unsigned int len, enum break; case write_gran_1byte: for (i = 0; i < len; i++) - if ((have[i] != want[i]) && (have[i] != 0xff)) { + if ((have[i] != want[i]) && (have[i] != erased_value)) { result = 1; break; } break; case write_gran_128bytes: - result = need_erase_gran_bytes(have, want, len, 128); + result = need_erase_gran_bytes(have, want, len, 128, erased_value); break; case write_gran_256bytes: - result = need_erase_gran_bytes(have, want, len, 256); + result = need_erase_gran_bytes(have, want, len, 256, erased_value); break; case write_gran_264bytes: - result = need_erase_gran_bytes(have, want, len, 264); + result = need_erase_gran_bytes(have, want, len, 264, erased_value); break; case write_gran_512bytes: - result = need_erase_gran_bytes(have, want, len, 512); + result = need_erase_gran_bytes(have, want, len, 512, erased_value); break; case write_gran_528bytes: - result = need_erase_gran_bytes(have, want, len, 528); + result = need_erase_gran_bytes(have, want, len, 528, erased_value); break; case write_gran_1024bytes: - result = need_erase_gran_bytes(have, want, len, 1024); + result = need_erase_gran_bytes(have, want, len, 1024, erased_value); break; case write_gran_1056bytes: - result = need_erase_gran_bytes(have, want, len, 1056); + result = need_erase_gran_bytes(have, want, len, 1056, erased_value); break; case write_gran_1byte_implicit_erase: /* Do not erase, handle content changes from anything->0xff by writing 0xff. */ @@ -1470,6 +1471,7 @@ static int erase_and_write_block_helper(struct flashctx *flash, unsigned int starthere = 0, lenhere = 0; int ret = 0, skip = 1, writecount = 0; enum write_granularity gran = flash->chip->gran; + const uint8_t erased_value = ERASED_VALUE(flash); /* curcontents and newcontents are opaque to walk_eraseregions, and * need to be adjusted here to keep the impression of proper abstraction @@ -1477,7 +1479,7 @@ static int erase_and_write_block_helper(struct flashctx *flash, curcontents += start; newcontents += start; msg_cdbg(":"); - if (need_erase(curcontents, newcontents, len, gran)) { + if (need_erase(curcontents, newcontents, len, gran, erased_value)) { msg_cdbg("E"); ret = erasefn(flash, start, len); if (ret) @@ -1487,7 +1489,7 @@ static int erase_and_write_block_helper(struct flashctx *flash, return -1; } /* Erase was successful. Adjust curcontents. */ - memset(curcontents, 0xff, len); + memset(curcontents, erased_value, len); skip = 0; } /* get_next_write() sets starthere to a new value after the call. */ @@ -1984,6 +1986,7 @@ int doit(struct flashctx *flash, int force, const char *filename, int read_it, int ret = 0; unsigned long size = flash->chip->total_size * 1024; int read_all_first = 1; /* FIXME: Make this configurable. */ + const uint8_t erased_value = ERASED_VALUE(flash); if (chip_safety_check(flash, force, read_it, write_it, erase_it, verify_it)) { msg_cerr("Aborting.\n"); @@ -2010,15 +2013,15 @@ int doit(struct flashctx *flash, int force, const char *filename, int read_it, msg_gerr("Out of memory!\n"); exit(1); } - /* Assume worst case: All bits are 0. */ - memset(oldcontents, 0x00, size); + /* Assume worst case: All bits are not erased. */ + memset(oldcontents, ~erased_value, size); newcontents = malloc(size); if (!newcontents) { msg_gerr("Out of memory!\n"); exit(1); } - /* Assume best case: All bits should be 1. */ - memset(newcontents, 0xff, size); + /* Assume best case: All bits should be erased. */ + memset(newcontents, erased_value, size); /* Side effect of the assumptions above: Default write action is erase * because newcontents looks like a completely erased chip, and * oldcontents being completely 0x00 means we have to erase everything -- 2.6.4

1 2

[PATCH] 4 byte address mode for Macronix MX25L25735F
by Tim Chick April 5, 2016

April 5, 2016

Hi List, Flashrom would not detect this chip. When the definition was added, everything failed as the chip only supports 4 byte address operation. The attached patch adds 4 byte address support for 4 byte only chips, as determined by the JEDEC flash parameter table, and support for this chip specifically. I've only allowed it to work with the SPI_CONTROLLER_FT2232 controller, as that is the only one I have to test. I've also only ported spi_block_erase_20 - the other block erase functions will fail. Please let me know what you think! Thanks, Tim

2 1

Re: [flashrom] Programming N25Q256 ?
by Steve Miller April 1, 2016

April 1, 2016

Thanks David for the very quick feedback. For others that might see a similar symptom of MISO not toggling, here is what I did wrong. This part is a QSPI. It can work in a number of modes, for single bit SPI, up through four bit SPI. On the board, there were some missing pullup resistors. MISO, #HOLD, and #WP did not have pullups. When I added 4.7K ohm pullups to those three pins, the MISO started toggling and flashrom reported that “This flash part has status NOT WORKING for operations: PROBE READ ERASE WRITE “ This is to be expected, as the N25Q256 is not supported. On this Micron part, the #HOLD, and #WIP pins are dual function. In four bit mode, they are data bits. Therefore, the need for pullups is not obvious. However, until I added them, the part was dead as a mackerel. I could not find the Chromium branch, so I could not try that version. I did try the latest release candidate, but it operated the same. However, we don’t really need that large a PROM, so we have N25Q128 chips on order for delivery tomorrow. I believe that one is supported, so we should be able to program after swapping the chip. From: David Hendricks [mailto:dhendrix@google.com] Sent: Wednesday, March 30, 2016 06:11 PM To: Steve Miller Cc: flashrom(a)flashrom.org Subject: Re: [flashrom] Programming N25Q256 ? On Wed, Mar 30, 2016 at 3:14 PM, Steve Miller <stevem(a)tanisys.com<mailto:stevem@tanisys.com>> wrote: Hi, I have the code built and running on a Raspberry PI. Unfortunately, the target part I am trying to program is a Micron N25Q256. I don’t see that part in the list. When I execute the program with –VV it seems to scan lots of devices. I see activity on CLK, CS, MOSI with an oscilloscope. But MISO remains logic low. When the program terminates, it just tells me No EEPROM/Flash device found. Stupid Noob Questions: 1. Is the static level on MISO to be expected? Or should it at least toggle? You should definitely see some activity on MISO. Flashrom sends identification instructions (RDID, REMS, etc) to the chip and the chip should respond with its JEDEC-assigned manufacturer ID and vendor-specific device info. That said, the N25Q256 is not currently added in upstream flashrom. There is limited support in the Chromium branch, though. 2. Is there any hope with this device? Can I perhaps force it to think the chip is smaller? Yep, that's what we currently do in the Chromium branch*. The chip uses 24-bit addresses unless either a bit in a nonvolatile config register is set or alternate instructions which accept 32-bit addresses are used. *Full 4-byte address support should be ready soon, I just need to find a few spare cycles to finish up what I have written... -- David Hendricks (dhendrix) Systems Software Engineer, Google Inc.

1 0

Programming N25Q256 ?
by Steve Miller March 31, 2016

March 31, 2016

Hi, I have the code built and running on a Raspberry PI. Unfortunately, the target part I am trying to program is a Micron N25Q256. I don't see that part in the list. When I execute the program with -VV it seems to scan lots of devices. I see activity on CLK, CS, MOSI with an oscilloscope. But MISO remains logic low. When the program terminates, it just tells me No EEPROM/Flash device found. Stupid Noob Questions: 1. Is the static level on MISO to be expected? Or should it at least toggle? 2. Is there any hope with this device? Can I perhaps force it to think the chip is smaller? Thanks for any help or suggestions. ----- Steve P.S. This device is not on a production Motherboard. It is on an ARM processor board that we are developing. The board is a new design that will not boot. I am attempting to program this SPI EEPROM to at least get into a UBOOT environment.

2 1

Re: [flashrom] [2/2] Add support for GD25D05B and GD25D10B
by sean boree March 30, 2016

March 30, 2016

Hello Hatim, I have checked your patch; I only have one small remark (and I might be very wrong on this, but I felt it best to discuss). 1 You use spi_prettyprint_status_register_bp2_srwd for both devices, however this function also prints the bits 5, 6 (with spi_prettyprint_status_register_bit). The datasheets of GD25D05B and GD25D10B note that these bits are reserved. So I think either they should not be used (thus different print function) or it should be noted somewhere that these are reserved bits. Acked-by: Sean Boree <seanboree(a)gmail.com> > Hatim Kanchwala <hatim(a)hatimak.me> - 2016-03-16 15:39:23 > Signed-off-by: Hatim Kanchwala <hatim(a)hatimak.me>

1 0

Re: [flashrom] [PATCH] adding support for AT25DQ321
by Hatim Kanchwala March 27, 2016

March 27, 2016

Dear Sean, Thanks for your patch. Here's a few issues I found - 1. For patches that touch struct flashchip it is wise to include more context lines. Have a look here (https://www.flashrom.org/Development_Guidelines#Patch_submission) 2. Tabs were converted to spaces. You can have a look at the AT25F512 entry just below it to understand the differences. 3. Regarding total_size, we write it usually as "x * 1024" that is to be read as "x kB". 4. This particular chip supports dual and quad I/O, so the FEATURE_QPI bit should be set and you can also include a comment. Just have a look at other entries in flashchips.c. 5. IMHO, the FIXME comment in spi25_statusreg.c should only come at spi_prettyprint_status_register_at25df_sec and not spi_prettyprint_status_register_at25df, because AT25DQ321 really uses only the former. Apart from the above, the content looks fine to me. Thanks for the patch. :) Acked-by: Hatim Kanchwala <hatim(a)hatimak.me> On Sunday 27 March 2016 05:15 AM, sean boree wrote: > This patch adds support for the AT25DQ321 chip, as this is my first patch, I apologise > for any rookie mistakes I made. > > > Signed-off-by: Sean Boree <seanboree(a)gmail.com <mailto:seanboree@gmail.com>> > > > > _______________________________________________ > flashrom mailing list > flashrom(a)flashrom.org > https://www.flashrom.org/mailman/listinfo/flashrom > -- Kind Regards, Hatim Kanchwala http://hatimak.me B. Tech. Electrical Engineering Indian Institute of Technology Patna

1 0