fat: handle Windows formatted partition (thru USB Mass Storage)

[AKASHI Takahiro]

On Wed, Jan 15, 2020 at 09:12:59AM +0900, AKASHI Takahiro wrote:
> On Tue, Jan 14, 2020 at 02:43:43PM +0200, Andy Shevchenko wrote:
> > On Tue, Jan 14, 2020 at 10:23 AM Andy Shevchenko
> > <andy.shevchenko at gmail.com> wrote:
> > > On Tue, Jan 14, 2020 at 10:21 AM Andy Shevchenko
> > > <andy.shevchenko at gmail.com> wrote:
> > > > On Tue, Jan 14, 2020 at 1:14 AM Heinrich Schuchardt <xypron.glpk at gmx.de> wrote:
> > > > > On 1/13/20 10:52 PM, Andy Shevchenko wrote:
> > >
> > > ...
> > >
> > > > > This image loads fine on current U-Boot, see below.
> > > >
> > > > Of course it does *in the test case you have done*.
> > > > I'm describing different one. The provided image must be a *partition*
> > > > on the real disk.
> > > >
> > > > So, before use it the preparatory steps must be made.
> > > >
> > > > Something like
> > > >
> > > > % dd if=/dev/zero of=image-file bs=1M count=1000
> > > > % fdisk image-file
> > > >  ...create a partition table, where one partition has a (similar) size
> > > > of the image I provided
> > > > % mount -o loop,offset=... image-file /mnt # use *partition* as a disk!
> > > > % dd --sparse if=mmc-fat-part of=/mnt
> > > > % umount /mnt
> > > >
> > > > And use image-file instead.
> > >
> > > Should I prepare it for you or you can do it yourself?
> > 
> > It's there under name image-file.gz
> 
> ===8<===
> $ hd image-file
> 00000000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
> *
> 000001b0  00 00 00 00 00 00 00 00  59 02 8c 89 00 00 00 20  |........Y...... |
> 000001c0  21 00 0c 08 27 62 00 08  00 00 01 00 18 00 00 00  |!...'b..........|
> 000001d0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
> *
> (snip)
> 00100000  eb 3c 90 6d 6b 64 6f 73  66 73 00 00 02 20 01 00  |.<.mkdosfs... ..|
> 00100010  02 00 02 00 00 f8 c0 00  10 00 04 00 00 00 00 00  |................|
> 00100020  00 00 18 00 80 00 29 ea  36 23 57 20 20 20 20 20  |......).6#W     |
> 00100030  20 20 20 20 20 20 46 41  54 31 36 20 20 20 0e 1f  |      FAT16   ..|
> (snip)
> 001001d0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
> *
> 001001f0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 55 aa  |..............U.|
> 00100200  f8 ff ff ff 00 00 00 00  00 00 00 00 00 00 00 00  |................|
> 00100210  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
> *
> 00110000  eb 58 90 4d 53 44 4f 53  35 2e 30 00 02 08 1a 14  |.X.MSDOS5.0.....|
> 00110010  02 00 00 00 00 f8 00 00  3f 00 ff 00 80 00 00 00  |........?.......|
> 00110020  00 e8 17 00 f3 05 00 00  00 00 00 00 02 00 00 00  |................|
> 00110030  01 00 06 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
> 00110040  80 00 29 f8 a9 74 d0 4e  4f 20 4e 41 4d 45 20 20  |..)..t.NO NAME  |
> 00110050  20 20 46 41 54 33 32 20  20 20 33 c9 8e d1 bc f4  |  FAT32   3.....|
> (snip)
> ===>8===
> 
> [0x100000-0x100200) looks to be PBR.
> [0x110000-0x110050) looks to be MBR.
> But I don't know what is [0x0-0x100000).

(Correction)
[0x0-0x200) is actually a partition table:

00000000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
000001b0  00 00 00 00 00 00 00 00  59 02 8c 89 00 00/00/20  |........Y...... |
                                                     ^^:boot_ind
			boot_ind: not ACTIVE
000001c0  21 00 0c 08 27 62/00 08  00 00/01 00 18 00/00 00  |!...'b..........|
                            p1's start   p1's size
                        start: 0x00000800 sector (= 0x100000)
                        size:  0x00180000 sectors
000001d0  00 00/00 00 00 00/00 00  00 00/00 00 00 00/00 00  |................|
*
000001f0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 55 aa  |..............U.|
                                                     ^^^^^:magic number

And [0x100000-0x100200) is a PBR, which then points to a next-level
partition:

00100000  eb 3c 90 6d 6b 64 6f 73  66 73 00 00 02 20 01 00  |.<.mkdosfs... ..|
(snip)
001001b0  00 00 00 00 00 00 00 00  8c 60 88 d5 00 00/00/02/ |.........`......|
001001c0  03 00 0c fe 3f 60/80 00  00 00/00 e8 17 00/00 00  |....?`..........|
                            start        size
                        start: 0x00000080
                        size:  0x0017e800

> Obviously U-Boot's fat code cannot handle it.

So precisely, U-Boot cannot handle nested partition( table)s?

-Takahiro Akashi

> 
> Thanks,
> -Takahiro Akashi
> 
> 
> > Commit messages have the commands I performed to get this image cooked.
> > 
> > -- 
> > With Best Regards,
> > Andy Shevchenko