I was able to load and test this version today.
tl;dr: this version behaved fairly well, with a few hiccups, and I did not see any flash storage corruption.
First, to verify I’m running the correct version:
Bus Pirate 5 REV10
Firmware main branch @ 9c0bfa4 (2024-10-01T21:28:04Z)
RP2040 with 264KB RAM, 128Mbit FLASH
S/N: 264235D3012961E4
https://BusPirate.com/
Storage: 0.10GB (FAT16 File System)
Plugging the BP in to my Linux boxen:
[206813.157809] usb 3-3.4.1.4.3: new full-speed USB device number 36 using xhci_hcd
[206813.300190] usb 3-3.4.1.4.3: New USB device found, idVendor=1209, idProduct=7332, bcdDevice= 1.01
[206813.300208] usb 3-3.4.1.4.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[206813.300216] usb 3-3.4.1.4.3: Product: Bus Pirate 5
[206813.300221] usb 3-3.4.1.4.3: Manufacturer: Bus Pirate
[206813.300225] usb 3-3.4.1.4.3: SerialNumber: 264235D3012961E4
[206813.325249] cdc_acm 3-3.4.1.4.3:1.0: ttyACM0: USB ACM device
[206813.327114] cdc_acm 3-3.4.1.4.3:1.2: ttyACM1: USB ACM device
[206813.327835] usb-storage 3-3.4.1.4.3:1.4: USB Mass Storage device detected
[206813.328334] scsi host1: usb-storage 3-3.4.1.4.3:1.4
[206814.352551] scsi 1:0:0:0: Direct-Access BP5 Storage 1.0 PQ: 0 ANSI: 2
[206814.353764] sd 1:0:0:0: Attached scsi generic sg1 type 0
[206814.363294] sd 1:0:0:0: [sdb] 47824 2048-byte logical blocks: (97.9 MB/93.4 MiB)
[206814.364217] sd 1:0:0:0: [sdb] Write Protect is off
[206814.364234] sd 1:0:0:0: [sdb] Mode Sense: 03 00 00 00
[206814.365768] sd 1:0:0:0: [sdb] No Caching mode page found
[206814.365780] sd 1:0:0:0: [sdb] Assuming drive cache: write through
[206814.388385] sdb: sdb1
[206814.388786] sd 1:0:0:0: [sdb] Attached SCSI removable disk
All looked good; the BP volume mounted in read/write mode (as implied in the log). I was able to create a simple text file on the volume from the host.
Then I connected to the BP with minicom:
[206868.696145] sdb: detected capacity change from 191296 to 0
[206868.737574] sd 1:0:0:0: [sdb] tag#0 access beyond end of device
[206868.737610] I/O error, dev sdb, sector 252 op 0x1:(WRITE) flags 0x800 phys_seg 1 prio class 0
[206868.737624] Buffer I/O error on dev sdb1, logical block 0, lost sync page write
[206870.878523] sd 1:0:0:0: [sdb] 47824 2048-byte logical blocks: (97.9 MB/93.4 MiB)
[206870.880347] sd 1:0:0:0: [sdb] Write Protect is on
[206870.880365] sd 1:0:0:0: [sdb] Mode Sense: 03 00 80 00
[206870.883195] sdb: detected capacity change from 0 to 191296
[206870.893722] sdb: sdb1
[206959.648352] sd 1:0:0:0: [sdb] 47824 2048-byte logical blocks: (97.9 MB/93.4 MiB)
[206979.021349] usb 3-3.4.1.4.3: reset full-speed USB device number 36 using xhci_hcd
[206979.166060] cdc_acm 3-3.4.1.4.3:1.0: ttyACM0: USB ACM device
[206979.167045] cdc_acm 3-3.4.1.4.3:1.2: ttyACM1: USB ACM device
[206979.190234] sd 1:0:0:0: [sdb] 47824 2048-byte logical blocks: (97.9 MB/93.4 MiB)
[206979.190994] sd 1:0:0:0: [sdb] Write Protect is off
[206979.190996] sd 1:0:0:0: [sdb] Mode Sense: 03 00 00 00
[206979.917774] sdb: detected capacity change from 191296 to 0
[206980.209789] sd 1:0:0:0: [sdb] 47824 2048-byte logical blocks: (97.9 MB/93.4 MiB)
[206980.210549] sd 1:0:0:0: [sdb] Write Protect is on
[206980.210553] sd 1:0:0:0: [sdb] Mode Sense: 03 00 80 00
[206980.212214] sdb: detected capacity change from 0 to 191296
[206980.222518] sdb: sdb1
There was en error with access beyond end of device. I tried the process several times, but only saw those errors on the first try.
In minicom, I could do an ls and could configure SPI with no problem. In minicom, I did a flash read -f test.bin and the contents of the connected flash chip were stored on the BP’s internal storage.
Interestingly, the volume did not auto re-mount on the Linux host after connecting minicom. I could mount it manually with sudo mount /dev/sdb1 ./mnt and it mounted read-only:
┌──(matty💊s76)-[~/data/projects/cypherCon8.0/flash]
└─$ sudo mount /dev/sdb1 ./mnt
mount: /home/matty/data/projects/cypherCon8.0/flash/mnt: WARNING: source write-protected, mounted read-only.
From there I could copy files off of storage as expected.
There was an xhci_hcd reset along the way. Minicom was connected; it showed a temporary disconnect, then reconnected. Again, the storage didn’t automount on the host, but was mountable manually.
[207131.641121] usb 3-3.4.1.4.3: USB disconnect, device number 36
[207132.901039] usb 3-3.4.1.4.3: new full-speed USB device number 37 using xhci_hcd
[207133.045192] usb 3-3.4.1.4.3: New USB device found, idVendor=1209, idProduct=7332, bcdDevice= 1.01
[207133.045216] usb 3-3.4.1.4.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[207133.045227] usb 3-3.4.1.4.3: Product: Bus Pirate 5
[207133.045234] usb 3-3.4.1.4.3: Manufacturer: Bus Pirate
[207133.045240] usb 3-3.4.1.4.3: SerialNumber: 264235D3012961E4
[207133.070683] cdc_acm 3-3.4.1.4.3:1.0: ttyACM0: USB ACM device
[207133.072329] cdc_acm 3-3.4.1.4.3:1.2: ttyACM1: USB ACM device
[207133.073012] usb-storage 3-3.4.1.4.3:1.4: USB Mass Storage device detected
[207133.073512] scsi host1: usb-storage 3-3.4.1.4.3:1.4
[207134.101619] scsi 1:0:0:0: Direct-Access BP5 Storage 1.0 PQ: 0 ANSI: 2
[207134.102614] sd 1:0:0:0: Attached scsi generic sg1 type 0
[207134.104449] sd 1:0:0:0: [sdb] Media removed, stopped polling
[207134.105403] sd 1:0:0:0: [sdb] Attached SCSI removable disk
[207136.226572] sd 1:0:0:0: [sdb] 47824 2048-byte logical blocks: (97.9 MB/93.4 MiB)
[207136.228450] sd 1:0:0:0: [sdb] Write Protect is on
[207136.228475] sd 1:0:0:0: [sdb] Mode Sense: 03 00 80 00
[207136.231059] sdb: detected capacity change from 0 to 191296
[207136.241568] sdb: sdb1
One other thing of note: When I disconnected minicom (but left the BP USB cable connected), the storage volume remained mounted as read-only; it didn’t go back to read-write. This was also reflected by no output in the kernel log when disconnecting minicom (the logical serial connection to /dev/ttyACM0). If I manually unmount with sudo umount /dev/sdb1 and remount, it is still read-only.
The last thing I noted is that the first time I connected using minicom there was a slight delay after opening the USB serial port and it accepting input from the terminal; I’m guessing there’s some blocking process going on when the storage is changing from read-write on the host to read-only.
So, just the slight hiccups where the volume doesn’t always automount on the host. I didn’t see any instances where the “fake” 8K volume appeared; it was always the full 98MB.
From my point of view, this is a huge improvement! 
I don’t mind if I have to manually mount the volume on the host, as long as the storage remains uncorrupted. I know not everyone may feel that way… 
Thanks again for all of the work!