Hi Tom,
On Tue, Oct 31, 2023 at 7:54 PM Tom Rini <tr...@konsulko.com> wrote:
>
> On Tue, Oct 31, 2023 at 03:56:45PM +0800, Yong-Xuan Wang wrote:
>
> > 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.
>
> Thanks for confirming.
>
> Reviewed-by: Tom Rini <tr...@konsulko.com>
>
> As a follow-up, can you please work on migrating to plain text
> environment?
>
> >
> > 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
>
> --
> Tom
Sure. Could you please provide more details or examples of the plain text
environment? I want to ensure I fully understand your request before
proceeding.
Regards,
Yong-Xuan
