Rockbox

Tasklist

FS#12294 - No SD card in current build

Attached to Project: Rockbox
Opened by Sander Sweers (infirit) - Monday, 26 September 2011, 18:10 GMT
Last edited by Torne Wuff (torne) - Sunday, 02 October 2011, 11:48 GMT
Task Type Bugs
Category Drivers
Status Unconfirmed   Reopened
Assigned To No-one
Operating System Sansa e200
Severity Low
Priority Normal
Reported Version Daily build (which?)
Due in Version Undecided
Due Date Undecided
Percent Complete 0%
Votes 0
Private No

Details

In the current build r30605 (but also previous current builds) my micro SD does not show up in Rockbox or the file manager when connected to USB. The micro SD card is a sandisk 16gb card from a few years ago.

I verified it working in the latest release 3.9. It might be because the SD card does not have a partition. It has been formatted fat32.
This task depends upon

Comment by Robert Kukla (roolku) - Friday, 30 September 2011, 08:03 GMT
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.
Comment by Sander Sweers (infirit) - Sunday, 02 October 2011, 10:23 GMT
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.
Comment by Torne Wuff (torne) - Sunday, 02 October 2011, 11:48 GMT
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".
Comment by Torne Wuff (torne) - Sunday, 02 October 2011, 11:54 GMT
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 :/
Comment by Sander Sweers (infirit) - Sunday, 02 October 2011, 12:09 GMT
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.
Comment by Torne Wuff (torne) - Sunday, 02 October 2011, 15:39 GMT
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.
Comment by Richard Brittain (rbbrittain) - Sunday, 02 October 2011, 21:35 GMT
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.
Comment by Torne Wuff (torne) - Monday, 03 October 2011, 10:22 GMT
Sander, can you attach a copy of the first sector of your SD card?
Comment by Sander Sweers (infirit) - Monday, 03 October 2011, 13:34 GMT
Here you go.

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

Loading...