[U-Boot] [PATCH v1] DOS_PBR block type is also valid dos block type.

[Tom Rini <trini@ti.com>]

-----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 
>> <swarren@wwwdotorg.org> wrote:
>>> On 03/11/2013 03:56 AM, sonic.adi at gmail.com wrote:
>>>> From: Sonic Zhang <sonic.zhang@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-----