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

[Tom Rini]

On Thu, Nov 02, 2023 at 06:27:37PM +0800, Yong-Xuan Wang wrote:
> Hi Tom,
> 
> On Tue, Oct 31, 2023 at 7:54 PM Tom Rini <trini at 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 <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
> 
> 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.

Sure.  An example conversion is:
commit fc2af2d978b525e188b15d909e321caf9445bdb0
Author: Simon Glass <sjg at chromium.org>
Date:   Thu Jul 27 15:54:30 2023 -0600

    arm: rpi: Switch to a text environment
    
    Use the new environment format so we can drop most of the config.h file.
    
    Signed-off-by: Simon Glass <sjg at chromium.org>

-- 
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/20231102/af44c5b9/attachment.sig>