Other #402
openTesting of FM25Q chip series
0%
Description
Problem encountered¶
I had to reprogram an FM25Q08B, and ran in a somewhat weird issue:
- the chip was detected
- the registers were properly read,
- the memory reading operation was hanging (I let it run for 20 minutes, with no result).
I added some debugging code across the function path that leads to spi_read_chunked, and discovered that only the first 2048 bytes could be read, then the chip stopped responding.
Solution¶
After some more digging, I found out that this chip requires paged reading (chunks of 256 bits, similarly to the write process). Note that I've only tried one sample so far (more will come later this week), so I'm currently unable to say if this is a hardware issue or intended.
In the end, my workaround was to override chunksize in spi_read_chunked. After that, everything went fine: I was able to dump the existing content, erase the chip, write new content, and verify it back.
I'm sorry for not being able to provide a patch. I'm not familiar enough with the codebase & coding style.
(Maybe) Useful details¶
- A BusPirate was used as the SPI interface
- Flashrom was running on Fedora 35, built from edcea80 (latest master at the time of writing)
- The chip was wired as shown on the wiki page with 6.8k resistors for 3.3V pull-up
Logs: I've run all my tests in verbose mode, so I'll send those later on (I have to transfer them across PCs).
Updated by Nico Huber over 2 years ago
Just a quick note: SPI25 flashes have no means to report any success or failure of a read command. The whole transaction is controlled by the SPI master, in this case the BusPirate. Also, from the FM25Q08B datasheet:
The address is automatically incremented to the next higher address after each byte of data
is shifted out allowing for a continuous stream of data. This means that the entire memory
can be accessed with a single instruction as long as the clock continues.
So the actual problem would be in the BusPirate, the PC or between the both. I remember a similar story but with an FT*232H based programmer. It might be a problem with the USB stack.
Samantaz, any chance you can tell us the model of the USB-UART chip on your BusPirate?
Updated by Samantaz Fox over 2 years ago
The address is automatically incremented to the next higher address after each byte of data is shifted out allowing for a continuous stream of data. This means that the entire memory can be accessed with a single instruction as long as the clock continues.
Yes, I've read that part ^^ However, I didn't find a continuous SPI read function. All of the functions I found seem to be chunked.
So the actual problem would be in the BusPirate, the PC or between the both. I remember a similar story but with an FT*232H based programmer. It might be a problem with the USB stack.
Is there an easy way to monitor what's going on?
Samantaz, any chance you can tell us the model of the USB-UART chip on your BusPirate?
It's a BusPirate v3.6 bought this year from adafruit, so from the looks of it, it's the FTDI FT232RL that's installed on it (I can't check right now, as I don't have the hardware nearby at the moment).
Updated by Nico Huber over 2 years ago
Samantaz Fox wrote in #note-2:
The address is automatically incremented to the next higher address after each byte of data is shifted out allowing for a continuous stream of data. This means that the entire memory can be accessed with a single instruction as long as the clock continues.Yes, I've read that part ^^ However, I didn't find a continuous SPI read function. All of the functions I found seem to be chunked.
Do you mean in flashrom code? those functions chunk the reads because most programmers can't read all at once.
So the actual problem would be in the BusPirate, the PC or between the both. I remember a similar story but with an FT*232H based programmer. It might be a problem with the USB stack.
Is there an easy way to monitor what's going on?
There are ways, don't ask me if it's easy ;) on Linux there is the usbmon kernel interface. The traces can be decoded with wireshark, IIRC.
Samantaz, any chance you can tell us the model of the USB-UART chip on your BusPirate?
It's a BusPirate v3.6 bought this year from adafruit, so from the looks of it, it's the FTDI FT232RL that's installed on it (I can't check right now, as I don't have the hardware nearby at the moment).
Hmmm, that'd be the second product from adafruit with FTDI chips that's making trouble. Not sure if I'm overly sensitive about the topic, but if it turns out that the USB chip is causing the problem, maybe you should ask them to verify their suppliers sell genuine chips. For now, let's just hope the problem is in the software stack. You could also try different PCs with different OS's / versions to see if it makes a difference.
Here's the discussion about the FT232H issue: https://review.coreboot.org/c/flashrom/+/63798 Alas, we can't just reduce the transfer sizes as that would slow things down considerably for everyone :-/
Updated by Samantaz Fox over 2 years ago
Do you mean in flashrom code? those functions chunk the reads because most programmers can't read all at once.
Yes, in flashrom's code.
So the actual problem would be in the BusPirate, the PC or between the both. I remember a similar story but with an FT*232H based programmer. It might be a problem with the USB stack.
Ok, so after more testing (3 different distros) I managed to make it work.
As you said, It's very likely caused by the USB stack.
For the record, the first two distros I tried were Fedora WS and Debian (both latest stable), in VirtualBox, with the USB device being passed through.
In these two cases, I ended up with flashrom waiting for data indefinitely after the first 2048 bytes.
I then tried on my home machine, running Ubuntu on bare metal, and everything works as expected.
So it's safe to say that the chip is perfectly supported, but that some VM / USB passthrough configs could cause issues ^^