Hi, I maintain the Android Image Kitchen project, which has U-Boot uImage support for the handfull of Android devices that use uImage for their boot.img/recovery.img format. This support is achieved using cross-compiles of U-Boot's dumpimage and mkimage tools, to all the Android NDK architectures, as well as macOS, Linux and Cygwin.
My users have pointed out what appears to be a major flaw in dumpimage. Generally - on an Android device at least - a dump of a partition will be made with `dd if=/dev/block/*/*/by-name/boot of=boot.img` so this boot.img is the size of the entire partition, but dumpimage won't read/extract these, where freshly built images work fine. The reason for this appears to be that dumpimage can only handle images that are exactly the size they're supposed to be, and not a single byte more of even \x00 padding on the end; anything more and it seems to misinterpret the file as a GP image. Here's me demoing that: 10,485,760 uimage-untrimmed-gb-boot.img (dump from device boot partition) 5,110,936 uimage-trimmed-gb-boot.img (correct size) 5,110,937 uimage-extrabyte-gb-boot.img (single extra \x00 byte added to end) : dumpimage -l uimage-untrimmed-gb-boot.img GP Header: Size 27051956 LoadAddr 6116d3f2 : dumpimage -l uimage-trimmed-gb-boot.img Image Name: Linux-2.6.35 Created: Thu Apr 19 13:05:52 2012 Image Type: ARM Linux Multi-File Image (uncompressed) Data Size: 5110872 Bytes = 4991.09 KiB = 4.87 MiB Load Address: 80008000 Entry Point: 80008000 Contents: Image 0: 3367356 Bytes = 3288.43 KiB = 3.21 MiB Image 1: 1743504 Bytes = 1702.64 KiB = 1.66 MiB : dumpimage -l uimage-extrabyte-gb-boot.img GP Header: Size 27051956 LoadAddr 6116d3f2 I took a look at the dumpimage source and couldn't find where/why this could be happening so I'm hoping someone more familiar here could take a look and perhaps help with a fix. Thanks! Chris _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
