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