On 03/13/2013 10:51 AM, Stephen Warren wrote:
On 03/12/2013 08:58 PM, Sonic Zhang wrote:
Hi Stephen,
On Tue, Mar 12, 2013 at 11:09 AM, Stephen Warren swarren@wwwdotorg.org wrote:
On 03/11/2013 08:57 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@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 reuses function test_block_type() in function test_part_dos(). So, files on that partition can't be displayed when run command "fatls mmc 0".
The only difference in your change is to mark dos partition with flag DOS_PBR invalid.
I did test a raw FAT filesystem on an SD card without any partition table, and it worked fine. Admittedly I created the layout/filesystem with Linux rather than Windows, but I don't think the layout would be any difference. What if you "fatls mmc 0:0" rather than "fatls mmc 0"; does that make any difference?
"fatls mmc 0:0" makes no difference.
I have reproduced this. However, I believe it's not a simple "the code is wrong" issue, but rather some kind of issue with stale state sticking around.
Oh, actually perhaps I haven't. What is the exact error message that you see?
If I apply your patch, it doesn't solve the problem that I described; I suspect the problem you're seeing is something different.