I'm currently debugging a problem with a flashrom user who has a Bus-Pirate V3 with Firmware v4.5. The problem manifests itself as an all-0x00 read from SPI for the first SPI command.
flashrom essentially does the following:
- Enter raw bitbang mode (0x00)
- Enter raw SPI mode (0x01)
- Set SPI peripherals config: Power, CS high, AUX (0x40)
- Set SPI speed (0x60)
- Set SPI config: output type, idle, clock edge, sample (0x80)
- De-assert CS# (0x03)
Execute SPI command:
- Assert CS# (0x02)
- SPI read/write (0x10)
- De-assert CS# (0x03)
The Bus pirate answers 0x01 for every command, so I think it claims everything is OK. Full logs available on request. IIRC this worked with older Bus Pirate hardware/firmware versions.
Ideas I have so far about why this problem exists:
- The flash chip needs time to settle after receiving power. According to the data sheet the settle time of the SST25VF080B is 10 us, and the chip gets power at step 3 of the init, which is (due to usb frame delays) at least a few ms before we send the first command to the flash chip.
- CS# is not asserted the first time and thus the flash chip output is tristate.
- The Bus Pirate somehow has problems sending the first command or receiving a response, or it always returns success even on failure.
- That flash chip is evil.
Some I2C chips first wants a stop condition before reacting proper. Could you run into the SPI equivalent?
Yes, I know SPI doesn't have a start/stop condition, but perhaps it needs a proper reset. or wait longer to do the CS?
Hum, I've added it to the list and I'll take a look. There weren't changes to the SPI mode in v4 at all, that I can think of. It could be starting up in the incorrect state (clock high) or something. Does it work if you send a dummy byte while CS is not active for the flash chip and avoid the broken first byte?
How many bytes are you send/reading with 0x10? The Bus Pirate should respond to the 0x10 with 0x01 and then respond to each send/read with a byte from the bus.
I'd be happy to take a look at a full log.
I just wanted to follow up on this. It looks like other people are noticing an issue. Can I get a capture of the port traffic to see what's going on?
I spent time looking this over today in the forum thread here:
http://dangerousprototypes.com/forum/in ... 99#msg6699 (http://dangerousprototypes.com/forum/index.php?topic=154.msg6699#msg6699)
I couldn't find anything, but that doesn't mean there's a bug. Flashrom reads JEDEC IDs ok for me with the latest firmware (there aren't any changes though).
Here's the latest nightly version (will be v5.2 tomorrow probably) if you'd like to try it:
Bus Pirate v3a
Firmware v5.2RC (r419) Bootloader v4.3
DEVID:0x0447 REVID:0x3043 (B5)
http://the-bus-pirate.googlecode.com/sv ... e-v5.2.hex (http://the-bus-pirate.googlecode.com/svn/trunk/firmware/v5-nightly/BPv3&v2go/BPv3-Firmware-v5.2.hex)
I am trying to find someone who is seeing the problem and willing to provide verbose logs for a flashrom run where the -c option is _not_ specified. MrHijet did that, but it would make sense to find someone else as well.