Using my rev8 BP and my SPI jig, I’d like to report some errors. See attached files for output of (1) and flash commands
Unable to get size of W25QXX chips. The 16K works, but others report 4194304 and 8388608 bytes. Winbond41.txt (2.3 KB) Winbond81.txt (1.8 KB)
unable to read SST25VF016B. See attached STT.txt (469 Bytes)
When you change the config to disable toolbar, exit and reconnect the BP, it shows the toolbar once when it starts and never updates it.
And some inconvenient issues
When in SPI mode, no way to get the main help menu without existing the SPI menu.
It would be nice to get the chipID (like flashrom --flash-name) if possible with both the (1) and flash commands
It would be nice to have some way to time how long it takes to read flash memory for benchmarking. 16K took a long time. If nothing else, you could use the LED’s to flash a pattern when done.
It would be nice to see how much “disk” space is left when dumping flash. Perhaps a command to show available space while in SPI mode.
I have 5 different W25QXX chips. One gives me inconsistent results. I need to hold the WP pin either high or low - else it doesn’t see the chip as all. It’s the only one like this. Strange.
Thank you so much, I am going to examine each of these in depth. I really appreciate the debug output, it helps a TON!
When in SPI mode, no way to get the main help menu without existing the SPI menu
The ? menu doesn’t work for you in SPI mode? Or maybe I misunderstand. There is a bit of a blob of help between h hd ? -h etc. I would like to get it unified.
It would be nice to get the chipID (like flashrom --flash-name) if possible with both the (1) and flash commands
This is on my todo list, totally agree.
It would be nice to have some way to time how long it takes to read flash memory for benchmarking. 16K took a long time. If nothing else, you could use the LED’s to flash a pattern when done.
I also want this. It wasn’t super straight forward how to do it when I wrote the app, though we also use a 1ms tick timer in the nand flash library, so the capability is there. I will add this when I update the progress indicators to adjust to the actual chip/file size (over/underrun).
It would be nice to see how much “disk” space is left when dumping flash. Perhaps a command to show available space while in SPI mode.
Agree, it should show disk space, and flash should look at free space to determine if the dump will fit, and abort if not. These should be universal functions available to all apps.
The BP says there were 8388608 in size. I thought this was an error because it wasn’t one of the sizes listed.
I’m reading a similar chip (W25Q64BV/W25Q64CV/W25Q64FV) that I removed from a device, and I used a Bruchetta board and flashrom, and it too was 8388608 bytes long, which is 8192*1024,
I’m not that good at reading spec sheets. So this may not be a bug at all.
Okay - now I am confused.
I was able to read and verify the contents of a “W25Q64BV/W25Q64CV/W25Q64FV” chip I removed from a device.
I used a Bruschetta board board with flashrom built with the github repo.
I also used by BP.
Trouble is - they both work, but they disagree. And it’s not that I am getting garbage from one, they both make sense. I used binwalk (which tries to decode a binary file) to look at the binary, and they both look reasonable. They show a UBOOT partition. They are both the same size. I used cmp to count how many bytes were different and it said 16% of the bytes are different. And it’s not just in one spot. I used vbindiff (Visual Binary Different Chcker) to look at the different bytes and they are all over the memory. And when I did a diff of the results of binwalk, look ah what it reports:
One found a LZMA compressed data, properties and the other found a JPEG file inside. There is a subtle difference in these tools and I don’t understand.
Will do. Today is a family day. I’ll try Monday.
and then read
I was going to try to flash write what the other board read and they see what it contains.
We could also create a flash image using an algorithm (byte values increasing), or using dd<.dev.random >flash
and then write and verify.
Unfortunately there was a bug introduced into recent builds in SPI mode. I believe the data is just the output of the bug. It is fixed in the latest build.
Bus Pirate 5 REV8
Firmware main branch (2024-04-02T13:07:15Z)
RP2040 with 264KB RAM, 128Mbit FLASH
S/N: 251821CB83B062E4 https://BusPirate.com/
Storage: 2.74GB (FAT32 File System)
Configuration file: Loaded
Available modes: HiZ 1-WIRE UART HDPLXUART I2C SPI 2WIRE LED
Active mode: spi (baudrate, clock polarity, clock phase, cs)=(122kHz, 1, 1, 2)
Display format: Auto
Data format: 8 bits, MSB bitorder
Pull-up resistors: OFF
Power supply: ON (3.2V/3.29V)
Current limit: OK (13.0mA/0.0mA)
Frequency generators: OFF
I’m still investigating. I noticed some file system errors. (I think I might have unmounted it improperly.). First of all, the BP told me it created a file and while it was still mounted, my Linux system, said the file I just created wasn’t there.) I ran fsck on it. Let’s see what happens.
There is caching in both the bus pirate fat driver and most operating systems. I haven’t figured out how or if it’s possible to make changes appear instantly on the PC side. I have a plan to trigger cache updates on the bus pirate side, but I’m not sure if there’s anything to be done on the PC side.
I wonder if it’s possible to just cycle the MSD usb connection without triggering the others. That would force the OS to reattach to the updated file system.
