msdosfs oddity?

[Mouse <mouse%Rodents-Montreal.ORG@localhost>]

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		mouse%rodents-montreal.org@localhost
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B