[U-Boot] [PATCH] x86/bootm: fix compressed image boot

[Hannes Schmelzer]

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.schmelzer at 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.schmelzer at 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.

>
> Regards,
> Bin
cheers,
Hannes