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

[Hannes Schmelzer]

On 20.11.2018 16:34, Bin Meng wrote:
> Hi Hannes,
Hi Bin,
thanks for having a look into and sorry for my late response.

>
> On Thu, Oct 11, 2018 at 2:41 PM Hannes Schmelzer <hannes at 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.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.
>>
> 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?
Yes, i create the u-boot module by hand for testing with:

gzip -9 bzImage (which doesn't much because the bzImage already contains 
compressed stuff)
mkimage -A x86 -O linux -e 100000 -a 100000 -d bzImage.gz -c gzip ulinux

afterwards i load the created 'ulinux' to my target and boot:

=> tftp ${loadaddr} ulinux
Using e1000#0 device
TFTP from server 192.168.21.254; our IP address is 192.168.21.70
Filename 'ulinux'.
Load address: 0x121a1000
Loading: #################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
###############################################################
          8.9 MiB/s
done
Bytes transferred = 7597600 (73ee20 hex)
=> bootm ${loadaddr} - ${fdtcontroladdr}
## Booting kernel from Legacy Image at 121a1000 ...
    Image Name:
    Created:      2018-11-21   8:23:30 UTC
    Image Type:   Intel x86 Linux Kernel Image (gzip compressed)
    Data Size:    7597536 Bytes = 7.2 MiB
    Load Address: 00100000
    Entry Point:  00100000
    Verifying Checksum ... OK
## Flattened Device Tree blob at 7f2fe240
    Booting using the fdt blob at 0x7f2fe240
    Uncompressing Kernel Image ... OK
    Loading Device Tree to 0007a000, end 0007f166 ... OK
Valid Boot Flag
Setup Size = 0x00003e00
Magic signature found
Using boot protocol version 2.0e
Linux kernel version 4.20.0-rc3+ (schmelzerh at ategge3722) #1 SMP Wed Nov 
21 09:03:31 CET 2018
Building boot_params at 0x00090000
Loading bzImage at address 100000 (7703104 bytes)
Setup at 0x090000
Magic signature found
Kernel command line: "gei(0,0)host:vxWorks h=192.168.60.254 
e=192.168.60.1:255.255.255.0 g=192.168.60.254 u=vxWorksFTP pw=vxWorks"
Magic signature found

Starting kernel ...

--
this was just for testing this with a linux kernel. In real life on my 
target a vxWorks kernel is running.
My vxWorks 6.9 kernel also has the zero-page in front of the image and 
is booted in the same manner.
>
> Regards,
> Bin
cheers,
Hannes