Someone at work recently gave me a Raspberry Pi Pico. This is an ARM SoC. It's way too small to run NetBSD (less than a meg of RAM); I wanted to build my own bare-metal code for it. The reason I'm writing is that I'm having trouble accessing it as a USB device. This is on 5.2; I don't know whether the msdosfs support is different. If anyone can tell me what I might need to do differently, I can experiment.
I plug the thing in with the button pressed, which is supposed to make it appear as a mass-storage device. Which it does: umass0 at uhub1 port 1 configuration 1 interface 0 umass0: Raspberry Pi RP2 Boot, rev 1.10/1.00, addr 2 umass0: using SCSI over Bulk-Only scsibus0 at umass0: 2 targets, 1 lun per target sd0 at scsibus0 target 0 lun 0: <RPI, RP2, 2> disk removable sd0: fabricating a geometry sd0: 128 MB, 128 cyl, 64 head, 32 sec, 512 bytes/sect x 262144 sectors sd0: fabricating a geometry I can read it fine, with dd or moral equivalent. The problem is, it's supposed to have a FAT filesystem on it. Looking at the first few sectors makes that seem likely to be correct; hexdump -C shows me 00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 000001b0 00 00 00 00 00 00 00 00 9e 1c 0f 00 00 00 00 00 |...............| 000001c0 00 00 0e 00 00 00 01 00 00 00 ff ff 03 00 00 00 |..........ÿÿ....| 000001d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 000001f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 aa |..............Uª| 00000200 eb 3c 90 4d 53 57 49 4e 34 2e 31 00 02 08 01 00 |ë<MSWIN4.1.....| 00000210 02 00 02 00 00 f8 81 00 01 00 01 00 01 00 00 00 |.....ø.........| 00000220 ff ff 03 00 00 00 29 9e 1c 0f 00 52 50 49 2d 52 |ÿÿ....)...RPI-R| 00000230 50 32 20 20 20 20 46 41 54 31 36 20 20 20 eb fe |P2 FAT16 ëþ| 00000240 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 00000400 f8 ff ff ff ff ff ff ff 00 00 00 00 00 00 00 00 |øÿÿÿÿÿÿÿ........| 00000410 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * Trouble is, mount -t msdos rejects it. disklabel shows me # /dev/rsd0d: type: SCSI disk: RP2 label: fictitious flags: removable bytes/sector: 512 sectors/track: 32 tracks/cylinder: 64 sectors/cylinder: 2048 cylinders: 128 total sectors: 262144 rpm: 3600 interleave: 1 trackskew: 0 cylinderskew: 0 headswitch: 0 # microseconds track-to-track seek: 0 # microseconds drivedata: 5 partitions: # size offset fstype [fsize bsize cpg/sgs] d: 262144 0 unused 0 0 # (Cyl. 0 - 127) e: 262143 1 MSDOS # (Cyl. 0*- 127) But if I mount -r -t msdos /dev/sd0e /mnt, or with /dev/sd0d instead, I get "Invalid argument". Turning on MSDOSFS_DEBUG, sd0e gives me bootsig0 0 bootsig1 0 msdosfs_mountfs 22 and sd0d gives me bytespersec 0 secperclust 0 secpertrack 0 msdosfs_mountfs 22 Of course, it works fine on Linux. I'm so sick of "just use Linux and it all works" instead of actually bloody _documenting_ things. I don't have any easy way to tell whether Linux is doing more than treating it as Just Another mass-storage device, or perhaps its FAT16 support is doing things differetnly, but at least one of those must be true. Looking at the data, as I quoted above, both those are accurate: the putative filesystem beginning at block 1 does indeed have both signature bytes zero, and the one beginning at block 0 does indeed have zeros in the relevant fields. I'll be experimenting more, but if anyone has any thoughts I'd welcome them. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
