Re: msdosfs oddity?

Mouse <[email protected]>
Newsgroups gmane.os.netbsd.devel.kernel
Message-ID <[email protected]>
> I do a lot of hobby stuff with RPi Pico, so Iâ??m pretty familiar with its i$

I was hoping someone would be in that situation and willing to explain!

> The file system on the Pico (and all of the RP2040 devices) is completely vi$

I suspected as much when I found that overwriting the beginning of the
device didn't affect what I read from those same blocks.

>> 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.
> It works fine on macOS, too :-)

Yeah. :-/

> Anyway, figure out where itâ??s returning the EINVAL?

When I use the partition identified as MSDOS by fdisk and disklabel,
/dev/sd0e, it's the test for 0x55 0xaa in the last two blocsk:

> bootsig0 0 bootsig1 0
> msdosfs_mountfs 22

When I use the raw-disk partition, /dev/sd0d (the host was i386 for
these tests), it's the sanity tests

> bytespersec 0 secperclust 0 secpertrack 0
> msdosfs_mountfs 22

My next attempt was to dike out the 0x55 0xaa test.  When I did that,
msdosfs mounted it just fine.  But then, when I copied the file to the
device, it reset itself, making the umass disappear from USB.  When I
then tried to unmount the filesystem, the system crashed ungracefully.

I then guessed what you said above, that it wasn't actually caring
about the filesystem overhead writes, just the data content (since UF2
blocks are very self-descriptive) and tried lseeking to 1M into the
device (to avoid attempting to write over what NetBSD thinks is the
disklabel) and dropping the UF2 file there.  That worked fine; the last
write errored, but it worked without panicking the host.

So now I just need to try to dig up enough hardware documentation to
write my own code for it, probably including writing an ARM assembler.
(I think I have a DNARD somewhere, but I suspect I will find writing my
own assembler easier than bludgeoning the NetBSD/arm toolchain into
generating what the Pico wants.)

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		[email protected]
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.