diff mbox series

Some flashrom issues reported and a couple of patches

Message ID pmWqI0TGUDRmqMI5DLqXqdO5cOjz01CFAXQG_Dj8z7dw4RCzNgL0Cat-qdakb4vtI9iGbOAJ_YCAKYdjTyhLK0zyLs5sgILc20CJT9s8zNo=@proton.me
State New
Headers show
Series Some flashrom issues reported and a couple of patches | expand

Commit Message

Leonard Frumkin June 11, 2023, 8:32 p.m. UTC
Hi!

I've encountered some issues in my recent experience with flashrom and wanted to drop you a line, just on the off chance that someone on your side cares. I'm also attaching a couple of patches I've been using. I realize you have a provenance policy in place. This is a pseudonymous account. You're welcome to use this patches for any purpose, under any license/terms of your choosing, including putting your own name on the commits. If that's not good enough - hey, I tried.

1. Certain popular chips (W25Q128.V/GD25Q128, others) support a `fast_read` (0xb command),
which simply adds a dummy cycle on the bus before data is returned. This command must be used
for reads performed above some threshold speed (e.g. 50Mhz for W25Q128JV).
This is mentioned for some in flashchips.c. But there's no support for it (perhaps there was once?).
Nicer programmers (like CH347) can read at over 50Mhz (through the last time I checked, the
driver had a fixed default frequency which is 15Mhz - slower but safe). It's possible that
some users will configure the programmer to a higher speed and violate this constraint.
It'd be nicer to use the fast_read command whenever available. Patch attached.

2. The Winbond Chips W25Q16 (same datasheet as W25Q80, 2007), W25Q16V (Datasheet 2009), W25Q16BV (2010),W25Q16JV (2019) all return the same flash ID (0x1540ef), but are different
in some "advanced" ways. For one thing, the older W25Q16/W25Q16BV chips have only 2 status registers,
while W25Q16JV has 3. The chips are all treated the same in `flashchips.c`. I wasted a day with a salvaged
(old) chip, after I used flashrom to ID the chip and ended up looking at the wrong datasheet.
The absence of the 3rd status register suggests a way to "sniff" for which chip is present. When status3 is missing, the (invalid) read_SR3 command returns 0xff, which is an invalid value.

3. With W25Q128.V, If SRL=1 in STATUS2, `flashrom --wp-status` reports that the
chip is locked until a power cycle. However, the datasheet explains that one can
do an OTP write to status register 2, which permanently locks the status register(s?).
I had to figure this out with a salvaged chip, when flashrom suggested a
power-cycle is all that is required. In fact the chip has its status registers permantently
locked. a better message would be nice.

4. When using -c to specify a particular device, the device name param can be onerous for
entries which span multiplechips, see for example the device name for `MX25L12833F/etc`.
It'd be nice if specifying the name for any one chip covered by an entry would also be
accepted. Better for self-documenting scripts too. It's also more future-proof, if it turns
out some chips aren't fully compatible and need to be split into separate entries. Any
script would still work, and would automatically switch to the new entry. That could be
a good or bad thing. Just a thought.
Thanks for your work! Flashrom is incredibly useful.

Sent with [Proton Mail](https://proton.me/) secure email.

Comments

Anastasia Klimchuk June 16, 2023, 11:06 a.m. UTC | #1
Leonard,
Thank you so much for your ideas and patches! Will have a look at these.
As for signing off the patches, we recently updated the policy (in the
same way as Linux did) so now it doesn't have to be a real real name.
However it still needs to be a known identity, for example if everyone
knows you by the nickname that's fine.
If at any point in future you decide to send a patch for review from
yourself, you are very welcome.
Leonard Frumkin June 16, 2023, 3:52 p.m. UTC | #2
------- Original Message -------
On Friday, June 16th, 2023 at 2:06 PM, Anastasia Klimchuk <aklm@chromium.org> wrote:


> Leonard,
> Thank you so much for your ideas and patches! Will have a look at these.
> As for signing off the patches, we recently updated the policy (in the
> same way as Linux did) so now it doesn't have to be a real real name.
> However it still needs to be a known identity, for example if everyone
> knows you by the nickname that's fine.
> If at any point in future you decide to send a patch for review from
> yourself, you are very welcome.
> 
> --
> Anastasia.

Hi Anastasia,

Thank you for responding.  I hope my notes will end up being of some use. 

Thank you also for clarifying your contribution policy, though I'm afraid it still doesn't apply in my case.

There's another issue I've encountered since my e-mail. Since you indicates it's not a total waste of time to report such issues, I will.

Currently, if any write-protection mechanism is active on a chip, flashrom will try to read the WP state, unlock it, and then restore the WP protection state. 

There's a corner case which the logic doesn't handle well. It's possible for WP ranges to be *locked* via OTP, but that actually the "protection" allows access everywhere (or anywhere needed, anyway). Currently, flashrom produces a warning message in `prepare_flash_access` with the notice "Failed to unlock flash status reg with wp support". However, there's no actual reason to  try to unlock the register, since the "protection", while locked,  doesn't hinder any access. In other words, flashrom tries to unlock the register seemingly  only because it's locked, and not because a region targeted for write is protected. 

Even stranger is the fact that `prepare_flash_access` is called from `flashrom_image_read`. That mean trying to *read* such a chip produces a warning about failing to disable write-protection. 

The read does succeed though, so this is would be a low-priority quirk.

Kind regards,
diff mbox series

Patch

From: woot <woot@whitehouse.gov>
Subject: [PATCH 2/2] Add FEATURE_0B_FAST_READ, and use it in spi_nbyte_read

---
 flashchips.c    |  4 ++--
 include/flash.h |  3 +++
 spi25.c         | 16 ++++++++++++++--
 3 files changed, 19 insertions(+), 4 deletions(-)

diff --git a/flashchips.c b/flashchips.c
index 6a5cf495..b0688f04 100644
--- a/flashchips.c
+++ b/flashchips.c
@@ -17690,7 +17690,7 @@  const struct flashchip flashchips[] = {
 		.page_size	= 256,
 		/* supports SFDP */
 		/* OTP: 1024B total, 256B reserved; read 0x48; write 0x42, erase 0x44, read ID 0x4B */
-		.feature_bits	= FEATURE_WRSR_WREN | FEATURE_OTP |
+		.feature_bits	= FEATURE_WRSR_WREN | FEATURE_OTP | FEATURE_0B_FAST_READ |
 				  FEATURE_WRSR_EXT2 | FEATURE_WRSR2 | FEATURE_WRSR3,
 		.tested		= TEST_OK_PREWB,
 		.probe		= PROBE_SPI_RDID,
@@ -17888,7 +17888,7 @@  const struct flashchip flashchips[] = {
 		.page_size	= 256,
 		/* supports SFDP */
 		/* OTP: 1024B total, 256B reserved; read 0x48; write 0x42, erase 0x44, read ID 0x4B */
-		.feature_bits	= FEATURE_WRSR_WREN | FEATURE_OTP,
+		.feature_bits	= FEATURE_WRSR_WREN | FEATURE_0B_FAST_READ | FEATURE_OTP,
 		.tested		= TEST_OK_PREW,
 		.probe		= PROBE_SPI_RDID,
 		.probe_timing	= TIMING_ZERO,
diff --git a/include/flash.h b/include/flash.h
index 0eace15d..46775745 100644
--- a/include/flash.h
+++ b/include/flash.h
@@ -164,6 +164,9 @@  enum write_granularity {
 /* Whether chip has configuration register (RDCR/WRSR_EXT2 commands) */
 #define FEATURE_CFGR	    (1 << 25)

+/* Non-4BA Fast Read (0x0b) Support, with 3 byte address followed by dummy byte */
+#define FEATURE_0B_FAST_READ	(1 << 26)
+
 #define ERASED_VALUE(flash)	(((flash)->chip->feature_bits & FEATURE_ERASED_ZERO) ? 0x00 : 0xff)
 #define UNERASED_VALUE(flash)	(((flash)->chip->feature_bits & FEATURE_ERASED_ZERO) ? 0xff : 0x00)

diff --git a/spi25.c b/spi25.c
index 6a6ee75d..6a358ad0 100644
--- a/spi25.c
+++ b/spi25.c
@@ -661,15 +661,27 @@  static int spi_nbyte_program(struct flashctx *flash, unsigned int addr, const ui
 int spi_nbyte_read(struct flashctx *flash, unsigned int address, uint8_t *bytes,
 		   unsigned int len)
 {
+	uint8_t cmd[1 + JEDEC_MAX_ADDR_LEN] = { JEDEC_READ, };
+	int dummy_len = 0;
 	const bool native_4ba = flash->chip->feature_bits & FEATURE_4BA_READ && spi_master_4ba(flash);
-	uint8_t cmd[1 + JEDEC_MAX_ADDR_LEN] = { native_4ba ? JEDEC_READ_4BA : JEDEC_READ, };
+	const bool fast_read_0b = flash->chip->feature_bits & FEATURE_0B_FAST_READ;
+
+	if (native_4ba) { // prefer 4ba if available, so we always support max flash size
+		cmd[0] = JEDEC_READ_4BA;
+	} else if (fast_read_0b) {
+		cmd[0] = JEDEC_READ_FAST;
+		dummy_len = 1;
+	} else {
+		cmd[0] = JEDEC_READ;
+	}

 	const int addr_len = spi_prepare_address(flash, cmd, native_4ba, address);
 	if (addr_len < 0)
 		return 1;

 	/* Send Read */
-	return spi_send_command(flash, 1 + addr_len, len, cmd, bytes);
+	int cmd_len = 1 + addr_len + dummy_len;
+	return spi_send_command(flash, cmd_len, len, cmd, bytes);
 }

 /*
--
2.40.1