Hi Tom, 0x80200000 comes from the result of the relocated_addr in booti_setup() on HiFive Unmatched board. If we load the Kernel Image to this address, it will not be moved. Currently one of the first two 8-byte of RISC-V Kernel Image is j _start_kernel instruction, so it's OK to execute the header of the Image.
Regards, Yong-Xuan On Sat, Oct 28, 2023 at 12:43 AM Tom Rini <tr...@konsulko.com> wrote: > > 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.w...@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