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

[Andy Shevchenko]

On Thu, Jan 16, 2020 at 4:01 AM AKASHI Takahiro
<takahiro.akashi at linaro.org> wrote:
> 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

Thank you for detailed explanation.

> > Obviously U-Boot's fat code cannot handle it.
>
> So precisely, U-Boot cannot handle nested partition( table)s?

Seems so. We need to be able to supply the partition number we would
like to open, something like
  cmd <interface> [<dev>[:<partition>[:<nested partition>]]]
otherwise it will require some (error prone) heuristics to understand
which one user would like to use.

-- 
With Best Regards,
Andy Shevchenko