[PATCH 1/1] board: sifive: unmatched: move kernel load address to 0x80200000

[Tom Rini]

On Thu, Oct 26, 2023 at 03:22:52AM +0000, Yong-Xuan Wang wrote:

> U-boot initially loads the kernel image to the kernel_addr_r, and
> subsequently relocates it to memory address 0x80200000. Setting
> kernel_addr_r to 0x80200000 can eliminate one copy operation.
> 
> Signed-off-by: Yong-Xuan Wang <yongxuan.wang at sifive.com>
> ---
>  include/configs/sifive-unmatched.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/include/configs/sifive-unmatched.h b/include/configs/sifive-unmatched.h
> index 74150b7d4b..de8bfc1123 100644
> --- a/include/configs/sifive-unmatched.h
> +++ b/include/configs/sifive-unmatched.h
> @@ -36,7 +36,7 @@
>  	"name=system,size=-,bootable,type=${type_guid_gpt_system};"
>  
>  #define CFG_EXTRA_ENV_SETTINGS \
> -	"kernel_addr_r=0x84000000\0" \
> +	"kernel_addr_r=0x80200000\0" \
>  	"kernel_comp_addr_r=0x88000000\0" \
>  	"kernel_comp_size=0x4000000\0" \
>  	"fdt_addr_r=0x8c000000\0" \

This is I believe subtly wrong. If you want an execute in place kernel
image (and are using FIT images), this can be made to work. But if you
load your (Linux Kernel) Image to this address, the header will be at
0x80200000 and not the payload so you still end up moving it. Are you
sure this is (a) not still moving it and (b) it's OK to be executing the
header of the image like it's code (or is there some catch in the header
to lead to a jump over it, in that case) ?

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20231027/305f6d88/attachment.sig>