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.
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.
------- 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,
-
Anastasia Klimchuk -
Leonard Frumkin