-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 03/15/2013 01:10 AM, Stephen Warren wrote: > On 03/11/2013 08:59 PM, Sonic Zhang wrote: >> Hi Stephen, >> >> On Tue, Mar 12, 2013 at 1:28 AM, Stephen Warren >> <swar...@wwwdotorg.org> wrote: >>> On 03/11/2013 03:56 AM, sonic....@gmail.com wrote: >>>> From: Sonic Zhang <sonic.zh...@analog.com> >>>> >>>> - Should return 0 for both DOS_MBR and DOS_PBR block types >>>> in test_part_dos(). >>> >>> What problem does this solve? >>> >>> I don't believe this change is correct. The purpose of >>> test_part_dos() is to determine whether a block device >>> contains an MS-DOS partition table. >>> >>> Such a partition table is present in an MBR, but not a PBR. A >>> PBR contains a *FAT file-system, and does not include a >>> partition table. >> >> The SD card formated by windows 7 into one FAT partition can't be >> initialized correct in u-boot function init_part() after you >> reuse the function test_block_type() in function >> test_part_dos(). So, files on that partition can't be displayed >> when running command "fatls mmc 0". >> >> The only difference in your change is to mark dos partition with >> flag DOS_PBR invalid. > > Thanks for sending me the disk image. > > The image is a mess; it's been manipulated by a variety of tools at > different times that have left rather a lot of cruft there. > > The first sector does appear to be an actual MBR, containing a > single partition starting at LBA 0x10 (byte offset 0x2000), and > quite large in size. At LBA 0x10, I do see what may be the start > of a FAT16 file-system. So far, so good. > > However, the partition table contains the string "FAT32" at 0x52, > and also the string "mkdosfs" at 0x03. I believe that in the past, > mkdosfs was used on this card to create a raw FAT filesystem > without any partition table. Then later, some partitioning tool > was run to create the partition I mentioned above. Finally you > said that Windows was used to create the FAT filesystem within the > partition. However, the partitioning tool didn't wipe out the > region of the MBR that contains the boot code, and hence didn't > wipe out the "FAT32" filesystem signature. > > Finally, in LBA 3 (byte offset 0x600), I see another sector that > looks remarkably like the start of a (presumably long-gone) FAT > filesystem. Perhaps an old partition table on this device > contained a partition that started in this (non-cylinder-aligned) > sector. This sector contains the same "mkdosfs" and "FAT32" > signatures. > > If we take your patch, we end up with the following situation: > > With your strange partition table: > > ls mmc 0 ls mmc 0:auto -> Thinks there's a partition table, so > works, and picks partition 1. ls mmc 0:0 -> Explicit request for > "partition" 0 (whole-disk). This option doesn't make sense here, > since the whole-disk is not a file-system, but rather a > partitioned device. > > With a real raw FAT filesystem; no partitions: > > ls mmc 0 ls mmc 0:auto -> Thinks there's a partition table, so > tries to access a non- existent partition table entryrather than > the whole disk, so automatic mode fails. ls mmc 0:0 -> Explicit > request for "partition" 0 (whole-disk), so works. > > So the issue is that the automatic handling of raw FAT filesystems > (i.e. use of the entire disk rather than the first partition) > fails with your patch. Perhaps it's acceptable that people with raw > FAT filesystems must explicitly specify ":0" to access the whole > disk, and we accept that automatic mode won't work? I'll let Tom > or Wolfgang make the call.
Thanks for looking into all of this. What exactly fails with this image, without this patch applied? - -- Tom -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRQxgVAAoJENk4IS6UOR1WCtEQAIvLpSOD8ZgM2B0aKNUI92sr ZgULRoQ7bjBL12NPrHQEdQn09cS3RTGY7AijWECfH29m5RN6e23tri5/MSRrw9yw jxEPhIEWqNaJ0gEF9qteNm9QDlJyGq9AENMWIf33fqo+hF9jrAsFwzZKRmWnNm8U Euc+KGdIwqBkD2ke+YIwHhV7ohII4LWrUD7FTYTYT78By3YR0YNpqrrgNuJB5Bs6 1TDARj/qTYk5uGy+1Ep8EqTIMqWfWtmeUhE5k6wYONOYPaETnDTezoxvN4wAuIyP QF25XkJbNfU39UreGnXscWjeuS/3FHzEC6ArfT0n6uVv94fAbcH/w6gFUanNa3Ya 50/314K0ePiRH2rJP8/7tiCQixZtykvAfx5IfLr4HZsbDZtYMcLkKGvKiWkt+0Hp MKKm059GK4W1tPbc31sFToqrGNNo41bE8hcDBa8rjFsbKkdDbXnMdMyRm4J5qWBX MTGYsmw4veRVn8NAZVkCkyckZOIPu2I4CwLv4KyMBQZ/p/o70xzMMpOyBM6kXWWE +8uoFZEL0jjJh214TUjRNu6YfzKyTiIriO6zKRsU0Do1iGGQ9EhiJxWKeLsuxz2i C7o11B4ayFsrpJ+GfpV6JEl2UBRdBmiDmsp+9bwwH1eMBLkBMexH+KzNUTdW5eKI 7pumNMZepGQnQYXXHH0L =RjQu -----END PGP SIGNATURE----- _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot