flashrom needs to find out the Bus Pirate firmware version and hardware version to apply workarounds for various SPI mode bugs. Unfortunately this is only possible in user terminal mode and not BBIO mode. The only way to return from BBIO mode to user terminal mode is to reset the Bus Pirate. For BPv3, this works fine because the FTDI chip is not reset. For BPv4, this resets the USB-serial connection which means flashrom has to reconnect to the Bus Pirate. Unfortunately this is not possible to do in a generic way because after USB re-enumeration the Bus Pirate usually has a different device node (/dev/ttyACM0 vs. /dev/ttyACM1 on Linux if only one Bus Pirate is used). With multiple Bus Pirates attached to a single machine, it is technically impossible to guess the right device node.
What I'm looking for is a way on BPv4 to return to user terminal mode from BBIO mode without killing the USB-serial connection. I see two possible ways to do that: Either add a "soft reset" command which keeps USB alive or a "return to user terminal mode" command inside BBIO mode.
I had a discussion with TitanMKD on IRC #dangerousprototypes about that topic on May 26. If more info is needed, I can provide the IRC logs from that time.
many modern monitors offer a feature called "dynamic contrast" which is achieved by reducing brightness of the backlight if the displayed image is dark. Of course the LCD opacity has to be adjusted as well to achieve consistent results. In theory, that is a great way to handle almost-black image regions. In practice, hardware vendors screw up the implementation. I've seen TV sets advertising "400 Hz motion rate", and doing PWM of the backlight at less than 50 Hz. Some laptop screens are guilty of that as well. With old CCFL backlights and high PWM frequencies, the afterglow of the phosphor and other effects lasted long enough to smooth out any possibly visible effects of the PWM. With modern LED backlights, there is no afterglow at all, and in a dark environment you can see a distinct stroboscopic effect by waving your hand in front of an affected display. Even worse are some manufacturers which try to smooth out power usage by having a phase shift for each color of their backlight RGB LEDs, leading to a colored stroboscopic effect when PWM is active.
http://http://www.tftcentral.co.uk/articles/pulse_width_modulation.htm has a nice description of the issue and some suggestions on how to measure flicker. The only catch is that if you want to buy a monitor/TV you have to take all those measurement photos in the store. Most electronics stores won't allow that, so you can either buy a monitor and test it at home or bring a separate testing device (which is apparently totally acceptable in the stores I asked).
Right now I'm using a photo transistor based ad-hoc wiring attached to the microphone input of my laptop, and the results are pretty abysmal because I'm picking up 50 Hz line noise everywhere.
Having a small circuit with a photo transistor or photo diode and directly attached ADC should fix the line noise issue and give me some really usable output.
Suggestions on how to implement this reliably are very welcome. (A modded USB sound card attached directly to the photo receiver circuit is the next step I'm planning for...)
(Just in case you're wondering why I'm doing this: I get a headache from low-frequency flicker, and I'd rather buy monitors which don't exhibit that problem.)
To get a reasonably fast speed for flashing, please note the following minimum requirements:
flashrom r0.9.6.1-r1621 or newer
Bus Pirate firmware 6.2 or newer (6.2 beta firmware should be sufficient)
If you use older flashrom versions and/or Bus Pirate firmware versions below 5.5, you will suffer from really long read/write times, sometimes more than 20 hours! Even if you can't (or don't want to) upgrade your Bus Pirate firmware, make sure you use latest flashrom to work the bugs in older BP firmware.
Bus Pirate hardware v3b Bus Pirate firmware v5.5 (5.5)
When I abort flashrom in the middle of some SPI commands without a clean shutdown, the Bus Pirate behaves in a very weird way: Sending 0x00 (the classic command to exit binary SPI mode and enter BBIO mode) gets me a "BBIO1" response as expected. That's OK, and exactly what I expect. However, any character sent after that gets me a "BBIO1" response as well, regardless of whether I send 0x0f (reset), 0x20, or any binary garbage. I sent kilobytes of random garbage to the Bus Pirate, and all I got was one "BBIO1" response per byte of random garbage I sent. Looking at the Bus Pirate firmware source code, this behaviour seems to be impossible, yet I have sent literally one Megabyte of 0x0f (reset) commands at the Bus Pirate, and I got 1 million "BBIO1" responses back.
The 115200 Baud limitation in host <-> Bus Pirate communication is the bottleneck for all bitbang modes shifting around bulk data. OpenOCD got a special command in bitbang mode which increases communication speed to 921600 Baud (8 % FT232/PIC clock speed skew) and apparently that works fine.
I created a flashrom patch which drives both the PIC and FT232 at 2 MBaud (zero FT232/PIC clock speed skew) without any firmware changes. The trick is to set BRG of the PIC in user terminal mode to 1 (which is 2 MBaud), and to set the Baud rate of the FT232 to 2 MBaud as well. The user terminal mode settings are carried over to bitbang mode, and I got a 10x speedup in flashrom for bulk flash chip reads.
Caveat: You need Bus Pirate firmware v5.2 or newer which allows setting BRG to 1, and you need some way to change FT232 Baud rate to 2 MBaud (easy on Linux/*BSD, no idea how to do it with the FTDI VCP drivers on Windows). If someone can write C code which makes the Windows FTDI VCP drivers talk at 2 MBaud, please share!
I'm looking for a list of firmware version banners, especially versions before 4.0. This is needed for reliable firmware version detection in flashrom (to enable workarounds for firmware bugs in specific firmware versions).
AFAICS all v4-or-newer firmwares should be up-/downgradeable without bootloader changes and I plan to post them all in this thread unless someone beats me to it, but I have no idea if a downgrade to a v3-or-older firmware/bootloader is even possible.
I have collected the following banners and would be thankful if you could post more:
I couldn't find any docs for binmode (specifically SPI) buffering in the wiki. Do you have any pointers? I'd like to add flashrom support for this feature because it has the potential to speed up some writes by a factor of 4, maybe more.
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: Init:
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.
I'm currently investigating whether it is possible to do some reverse engineering with the help of the Bus Pirate. Basically, we need to correlate an USB data stream (PC to undocumented device) with a SPI data stream (undocumented device to documented SPI flash chip). I'm not sure whether the undocumented device is just a stupid SPI master which receives SPI commands over USB and passes them through or whether it actually has builtin "intelligence". Dumping the USB data stream is already taken care of, so only the SPI data stream remains, and for that we'd like to use the Bus Pirate.
Some things about the Bus Pirate SPI sniffer mode remain unclear, though: [quote author="http://dangerousprototypes.com/2009/11/05/bus-pirate-i2c-spi-sniffer-updates/"] The SPI sniffer is implemented in hardware and should work up to 10MHz. It follows the configuration settings you entered for SPI mode.[/quote]
Does this mean the SPI clock must be set in the SPI mode before sniffing, or will the sniffer work at any frequency below 10 MHz regardless of SPI mode speed settings?
[quote author="http://dangerousprototypes.com/2009/11/05/bus-pirate-i2c-spi-sniffer-updates/"] The I2C and SPI sniffers now use a 4096byte output ring buffer. Sniffer output goes into the ring buffer and gets pushed to the PC when the UART is free. This should eliminate problems with dropped bytes, regardless of UART speed or display mode. A long enough stream of data will eventually overtake the buffer, after which new bytes will be dropped until space is available.[...]
Both sniffers use the user input buffer as a ring buffer. Any commands entered after the sniffer macro will be lost. If the ring buffer is full, bytes are simply dropped until thereâ€™s free space. The MODE LED turns off if this happens.[/quote]
Since I want to correlate logs, dropped data is a problem, made more severe by the fact that there will be an almost sustained (that is, there will be a delay in the order of microseconds after each 260-byte communication chunk) data rate of 10 Mbit/s in each direction (MISO+MOSI) with a total length of ~2 MByte per direction. That means I will overrun the 4096 byte ring buffer easily.
After that, will the Bus Pirate empty and fill the ring buffer bytewise and thus end up with a random selection of bytes from the stream being filled in to the freed byte(s) in the ring buffer each time one byte becomes free in the ring buffer? Such a random selection would mean anything past the first 4096 bytes is unusable as trace. OTOH, if the ring buffer is emptied in n-byte chunks (preferably larger than 260) the chunks are still useful.
It seems the MODE LED is the only indicator of a buffer overrun and there is no way to detect such a condition from the Bus Pirate output on the virtual serial port. That makes finding the chunk boundary impossible AFAICS.
The Bus Pirate is well-designed, so it is entirely possible I'm just misunderstanding the docs. Any answers are appreciated. Thanks!
Disclaimer: I haven't tried SPI sniffing with the Bus Pirate yet, and I wish to apologize if any of my questions have an obvious answer once we test on hardware.
I noticed that the Bus Pirate is being used by some people to read/write BIOS flash chips (the SPI variant). It seems that everyone is writing their own code to support these flash chips, and the incompatibilities between various chips on the market make reusing the code difficult.
The flashrom project has support for quite a few programmers and hundreds of flash chips and runs under Linux/OSX/*BSD/Solaris/Windows. It seems quite a natural fit to add Bus Pirate support to flashrom. The FT2232H-based SPI support in flashrom may provide a good starting point for Bus Pirate support. flashrom is open source (GPL). The flashrom developers are friendly, and patches are merged pretty rapidly.
flashrom is a command-line utility, but it is non-interactive, so anyone wanting to wrap a flashrom + Bus Pirate instance with a GUI (or some script) can do so easily.