While building+installing the new firmware, I again had my Linux system go into a state where it refused to remount the BP file system.
When I installed the new firmware, (i.e. types $ and copied the firmware onto the file system), this error occurred - after the new firmware was installed and the RPi rebooted itself.
[ 9332.863386] usb 1-6: USB disconnect, device number 43
[ 9333.071303] FAT-fs (sda1): unable to read boot sector to mark fs as dirty
So it seems this is a RPi issue - not a BusPirate issue.
When it reconnected, the Linux log said
[ 9336.179356] sd 0:0:0:0: [sda] Attached SCSI removable disk
[ 9338.618719] FAT-fs (sda1): Volume was not properly unmounted. Some data may be corrupt. Please run fsck.
BTW I tried several things to be able to remount the file system:
Unplugging and replugging the BP
fsck /dev/sda1
mount /dev/sda1 /mnt; umount /mnt
sync; sync; sync
restarting udevadm
Eventually the automount started working again. I think it was a timeout. But for 10 minutes or so, the BP file system wasnāt mounting.
And hereās another thing I noticed. After it auto-remounted (and the system reported the file system was dirty), I umounted the file system, ran fsck, and fixed the file system. When I unplugged and replugged the BP, the system log said the file system was STILL uncleanly unmounted. But this time it did not auto-mount the file system.
I run into that once in a while after the ā$ā command. For me, I disconnect the USB cable and restart udev. That works 100% of the time for me. The key, for me anyway, is to have the USB cable disconnected when restarting udev.
Occasionally Windows doesnāt like the jump to bootloader either. The drive just wonāt mount automatically. It comes back immediately with a re-plug though. Wonder if this is similar. We could try to explicitly kill the USB connection and add a delay when jumping.
What happens is after the RPi gets new firmware, it disconnects the file system. The RPi developers said they added a delay, but this problem still happens. Apparently here is no standard way for an attached file system to indicate to the OS that itās disconnecting.
You are right. And there is no way to force an OS to send a command within a given period.
Taken together, there is no minimum time in which firmware can delay, and be sure that a host will āseeā a media change. It follows that media change notifications cannot be relied upon as occurring prior to a reboot of the firmware.
Instead, the correct thing for a device firmware is to ALWAYS initialize with a few errors pending:
BUS RESET
Possibly mode pages may have changed
and of course Media may have changed
Of course, none of those errors should occur for SCSIOP_INQUIRY ā¦ itās a special case command where errors should be avoided whenever possible (e.g., except for bus noise causes CRC errors or the like).
As someone who has a few too many boards from Adafruit, Iāve seen similar issues while updating firmware on various bits of hw.
Being a linux user, I generally try to make sure my external device filesystems are unmounted before disconnecting them. The same rule applies to microcontrollers - especially given that they disconnect themselves when they automatically reboot.
When you apply a firmware update to a self-rebooting device like this, the update wonāt actually be written until a sync is performed - either by the OS, manually, or on umount. To that end, Iāve generally found the best policy when updating one of these devices is to immediately umount after sending the firmware to minimize the possibility of fs corruption: cp -av firmware.uf2 /mnt ; umount /mnt (or whatever your mount point is). Obviously, this wonāt work if youāre dragging-and-dropping firmware to the target board in an X/VNC/Wayland session, so I generally recommend using the shell for this process.
The umount will force a sync, writing the copied data to the device, and then immediately unmount the fs as the device reboots. So far, Iāve had that work well for me, though I canāt say if thereās additional timing issues there or not.
