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.
Regards,
Bin
cheers,
Hannes
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
