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@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@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