[U-Boot-Users] FAT mbr on MMC or SD cards
Hi all,
I've been testing a wide variety of MMC/SD cards straight out of the package. Some cards have a MBR at sector 0 (like a hard drive) while others are unpartitioned with a volume boot sector at sector 0 (like a floppy). And it might change if you reformat the card.
I'm still on 1.1.5, but I didn't see any major changes in 1.1.6. Within fs/fat/fat.c one of the first functions file_fat_detectfs() calls read_bootsectandvi(). I think I need to make, and then submit patches for, a few changes:
1. This code assumes that sector 0 contains a VBR. Instead I think it should decide if 0 is an MBR or VBR, or even better utilize the dev:part command line. Can I make this determination that from the first three bytes, or is there a better way?
2. The decision of fat12, fat16, and fat32 is made upon fat_length and an ascii field. The Microsoft document claims that the determination shall be made only by the count of clusters. Any disputes on that fix?
3. Structure boot_sector may need a packed attribute. As far as I can tell there are no makefile flags so gcc is free to add padding to align members inside structures. This would be a problem for the memcpy from block to boot_sector within read_bootsectandvi(). What is the coding standard for specifying 1-byte packing where necessary? Just add the gcc attribute?
Thanks!
-joey
In message f4p407$8qj$1@sea.gmane.org you wrote:
I've been testing a wide variety of MMC/SD cards straight out of the package. Some cards have a MBR at sector 0 (like a hard drive) while others are unpartitioned with a volume boot sector at sector 0 (like a floppy). And it might change if you reformat the card.
I'm still on 1.1.5, but I didn't see any major changes in 1.1.6. Within
Comparing to ancient versions probably shows little difference in that area. indeed.
fs/fat/fat.c one of the first functions file_fat_detectfs() calls read_bootsectandvi(). I think I need to make, and then submit patches for, a few changes:
- This code assumes that sector 0 contains a VBR. Instead I think it should
decide if 0 is an MBR or VBR, or even better utilize the dev:part command line. Can I make this determination that from the first three bytes, or is there a better way?
We have a patch in the queue to fix this, but it did not pass our internal review and unfortunately the engineer is on vacation right now so he cannot clean it up. Please be patiend for a week or two.
- The decision of fat12, fat16, and fat32 is made upon fat_length and an
ascii field. The Microsoft document claims that the determination shall be made only by the count of clusters. Any disputes on that fix?
I have no idea...
- Structure boot_sector may need a packed attribute. As far as I can tell
there are no makefile flags so gcc is free to add padding to align members inside structures. This would be a problem for the memcpy from block to boot_sector within read_bootsectandvi(). What is the coding standard for specifying 1-byte packing where necessary? Just add the gcc attribute?
Just add "__attribute__ ((packed))".
Best regards,
Wolfgang Denk
"Wolfgang Denk" wd@denx.de wrote in message news:20070613184133.A9478352681@atlas.denx.de...
- This code assumes that sector 0 contains a VBR. Instead I think it
should decide if 0 is an MBR or VBR, or even better utilize the dev:part command line. Can I make this determination that from the first three bytes, or is there a better way?
We have a patch in the queue to fix this, but it did not pass our internal review and unfortunately the engineer is on vacation right now so he cannot clean it up. Please be patiend for a week or two.
I wanted to share that with the list in case anybody else gets stuck.
Since my original email, I noticed code in fat_register_device() which determines a part_offset for 1.1.5 and 1.1.6. For now I've hacked this code to check the first three bytes EB:xx:90 or E9:xx:xx to make the mbr/pbr decision instead of the ascii string. Also I have it reading the valid partition offset instead of assuming 32. And finally I added a packed attribute to all structs.
- The decision of fat12, fat16, and fat32 is made upon fat_length and an
ascii field. The Microsoft document claims that the determination shall be made only by the count of clusters. Any disputes on that fix?
I have no idea...
I was reading a document "FAT: General Overfiew of On-Disk Format" v1.02 May 5, 1999 by Microsoft Corporation. The correct way is to calculate CountofClusters. Less than 4085 is FAT12, less than 65525 is FAT16, anything else is FAT32. I'll watch, and after he gets back from vacation we can do something about it.
-joey
participants (2)
-
Joey Oravec -
Wolfgang Denk