Rockbox

I suspect the reason for this may be r30566 - Allow any partition type, not just known FAT types. If memory serves the partition type mechanism was introduced to allow for correct detection of super floppies. This would mean that the olympus 100 will also fail as is uses a superfloppy for its internal disk.

Confirmed, I reverted commit r30566 and 30567 and the sd card shows up again. I also noticed a considerable speed up starting with these removed, might be related.

Reverting the partition type change doesn't really fix this; it only happens to work if by coincidence none of the four "types" that you get when you interpret the FAT BPB as an MBR happen to be ones we know about, which is not guaranteed. I don't see how this can be broken in the first place, in fact - one of the misinterpreted partition table entries would have to actually point to something sufficiently like a filesystem to allow fat_mount() to succeed, otherwise it will fall back to mounting it as a superfloppy; possibly fat_mount is not being careful enough about mounting weird stuff?

It would still take longer, though, even if that worked (since it might have to fail to mount four hypothetical filesystems before mounting the real one), so we should do this better. The real fix would be to sanity-check that sector 0 is a plausible MBR before attempting to read any partitions in it. This is tricky, though, since the only guaranteed magic is also present in a BPB. We should probably look at what partition_msdos in linux does to determine whether an MBR is "real".

Well, actually it shouldn't take much longer. If fat_mount can't determine that the "partition" is not actually a FAT filesystem quickly then it's probably not being smart enough; it should really only have to read the BPB to figure that out and four sector reads shouldn't take long enough that anyone will notice :/

I can provide more details, just tell me what you need. If patches are available I can try them out.

As for the speed, I can put it on a video if you like.

I'm not saying it *doesn't* take longer, I believe you :)

I'm saying it *shouldn't* really, and since it does then fat_mount is probably not as quick to reject the invalid FS as it should be.

Due to a site hangup a day or two ago, I was unable to remind folks *why* r30566 was added--and why it needs to be UN-reverted after the underlying issue is resolved.

r30566 was added was to assure that first-gen SDXC (and in the near future microSDXC) cards, which have the same pinout as SD & SDHC and thus *should* be readable by Rockbox once reformatted to FAT32, can be read regardless of whether or not the FAT32 formatter changed the MBR partition type. (SDXC cards by default are formatted in exFAT; supporting anything other than FAT32 and its predecessors is a NoDo, not to mention there's currently *no* open-source implementation of exFAT.) It was reported by someone who used a 64GB SDXC card as a SSD that he had to correct the MBR partition type before Rockbox would read it, because his FAT32 formatter left the partition type unchanged (exFAT uses the same partition type as NTFS).

According to the committer of that patch, nearly all OSes now ignore the MBR partition type and interpret the filesystem directly, just as Torne says. Thus, such a card is readable in Windows, Mac, Linux, etc.--but not in Rockbox because it requires a FAT partition type in the MBR. Others in IRC when that patch was committed suggested that FAT32 formatters should *not* be expected to write to the MBR. Thus, the patch was committed to remove the MBR checking code which was deemed (and should be) unnecessary.

If there's a problem with Rockbox mounting certain FAT drives (i.e., superfloppies), the detection code needs to be corrected so that r30566 can be reapplied. Otherwise, once microSDXC cards come out, we'll hear user complaints that Rockbox won't read them even after being reformatted to FAT32. Those folks will probably want us to get rid of the NoDo, which IMO should be out of the question at least until (a) there are Rockboxed targets that support exFAT drives in OF, so that exFAT code can be confined to those targets to satisfy the intent of the NoDo, *and* (b) an open-source exFAT implementation exists (I understand it's being worked on). It'll be hard enough to direct users to the non-MS utilities that can format >32GB drives as FAT32; they'll just tune us out once we start talking about changing the MBR.

Sander, can you attach a copy of the first sector of your SD card?

Here you go.

dd if=/dev/sdi of=/home/sander/rb_sectors bs=512 count=2
2+0 records in
2+0 records out