Hi Hannes, On Thu, Oct 11, 2018 at 2:41 PM Hannes Schmelzer <han...@schmelzer.or.at> wrote: > > > On 11.10.2018 08:01, Bin Meng wrote: > > Hi Hannes, > Hi Bing, > thanks for very quick response on this. > > > > On Thu, Oct 11, 2018 at 1:45 PM Hannes Schmelzer > > <hannes.schmel...@br-automation.com> wrote: > >> If we're booting some u-boot module with compressed payload, we have to > >> use the pointer where the image really has been loaded (unzipped) to > >> instead the pointer to the payload of the u-boot module. > >> > >> Signed-off-by: Hannes Schmelzer <hannes.schmel...@br-automation.com> > >> --- > >> > >> arch/x86/lib/bootm.c | 4 ++-- > >> 1 file changed, 2 insertions(+), 2 deletions(-) > >> > > Can you describe with what reproduce steps current codes are failing? > > thanks! > The boot of a u-boot module with bootm walks like this: > > => bootm ${loadaddr} ${ramdisk} ${fdtcontroladdr} > this leads to call (coming through cmd/bootm.c) to "do_bootm_states". > The task of this "do_bootm_states" is to find out what todo with the > provided image (u-boot module), > is it compressed or not, which kind of os should be booted, ... > > So, for doing this work, "bootm_decomp_image" is called, > this function uses the image-header for finding out the compression > method and does decompress the real payload to some location. > > bootm_os_load moves on and finds out that some compressed linux payload > shall be booted. > So the "do_bootm_linux" and finally "boot_prep_linux" from lib/x86, > since wer'e actually running on a x86 machine, is called. > > This function makes the assumption that the bootable binary is directly > the payload of the u-boot module, > ignoring the work done by "bootm_decomp_image" during the step before > and tries to boot directly in my case a gzip binary. > > This is wrong. >
Thanks for the explanation. This patch looks good to me. However I was unable to proceed some testing to verify this. When I use 'bootm' to boot a uImage with uncompressed bzImage, I simply get: => bootm 2000000 3000000 ## Booting kernel from Legacy Image at 02000000 ... Image Name: linux Created: 2018-11-20 15:23:19 UTC Image Type: Intel x86 Linux Kernel Image (uncompressed) Data Size: 7716768 Bytes = 7.4 MiB Load Address: 01000000 Entry Point: 01000000 Verifying Checksum ... OK Could not find a valid setup.bin for x86 It looks the error message comes from boot_get_setup() which expects bootm payload is of FIT format. However this patch expects a uImage with legacy format (images->legacy_hdr_valid == true). Can you please post your complete instructions, including how to create uImage for U-Boot's bootm work for legacy booting? Regards, Bin _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot