On Thu, Jan 16, 2020 at 4:01 AM AKASHI Takahiro <takahiro.aka...@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.shevche...@gmail.com> wrote: > > > > On Tue, Jan 14, 2020 at 10:21 AM Andy Shevchenko > > > > <andy.shevche...@gmail.com> wrote: > > > > > On Tue, Jan 14, 2020 at 1:14 AM Heinrich Schuchardt > > > > > <xypron.g...@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