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

[Tom Rini]

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 <trini at 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 <trini at 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.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

-- 
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/20231031/0d621aa4/attachment.sig>