* [PATCH 1/1] board: sifive: unmatched: move kernel load address to 0x80200000
@ 2023-10-26 3:22 Yong-Xuan Wang
2023-10-27 16:43 ` Tom Rini
0 siblings, 1 reply; 6+ messages in thread
From: Yong-Xuan Wang @ 2023-10-26 3:22 UTC (permalink / raw)
To: u-boot; +Cc: greentime.hu, vincent.chen, Yong-Xuan Wang, Paul Walmsley,
Green Wan
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@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" \
--
2.17.1
^ permalink raw reply related [flat|nested] 6+ messages in thread
* Re: [PATCH 1/1] board: sifive: unmatched: move kernel load address to 0x80200000
2023-10-26 3:22 [PATCH 1/1] board: sifive: unmatched: move kernel load address to 0x80200000 Yong-Xuan Wang
@ 2023-10-27 16:43 ` Tom Rini
2023-10-31 7:56 ` Yong-Xuan Wang
0 siblings, 1 reply; 6+ messages in thread
From: Tom Rini @ 2023-10-27 16:43 UTC (permalink / raw)
To: Yong-Xuan Wang
Cc: u-boot, greentime.hu, vincent.chen, Paul Walmsley, Green Wan
[-- Attachment #1: Type: text/plain, Size: 1458 bytes --]
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@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
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH 1/1] board: sifive: unmatched: move kernel load address to 0x80200000
2023-10-27 16:43 ` Tom Rini
@ 2023-10-31 7:56 ` Yong-Xuan Wang
2023-10-31 11:54 ` Tom Rini
0 siblings, 1 reply; 6+ messages in thread
From: Yong-Xuan Wang @ 2023-10-31 7:56 UTC (permalink / raw)
To: Tom Rini; +Cc: u-boot, greentime.hu, vincent.chen, Paul Walmsley, Green Wan
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 <trini@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@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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH 1/1] board: sifive: unmatched: move kernel load address to 0x80200000
2023-10-31 7:56 ` Yong-Xuan Wang
@ 2023-10-31 11:54 ` Tom Rini
2023-11-02 10:27 ` Yong-Xuan Wang
0 siblings, 1 reply; 6+ messages in thread
From: Tom Rini @ 2023-10-31 11:54 UTC (permalink / raw)
To: Yong-Xuan Wang
Cc: u-boot, greentime.hu, vincent.chen, Paul Walmsley, Green Wan
[-- Attachment #1: Type: text/plain, Size: 2300 bytes --]
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@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@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@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
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH 1/1] board: sifive: unmatched: move kernel load address to 0x80200000
2023-10-31 11:54 ` Tom Rini
@ 2023-11-02 10:27 ` Yong-Xuan Wang
2023-11-02 13:27 ` Tom Rini
0 siblings, 1 reply; 6+ messages in thread
From: Yong-Xuan Wang @ 2023-11-02 10:27 UTC (permalink / raw)
To: Tom Rini; +Cc: u-boot, greentime.hu, vincent.chen, Paul Walmsley, Green Wan
Hi Tom,
On Tue, Oct 31, 2023 at 7:54 PM Tom Rini <trini@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@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@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@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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH 1/1] board: sifive: unmatched: move kernel load address to 0x80200000
2023-11-02 10:27 ` Yong-Xuan Wang
@ 2023-11-02 13:27 ` Tom Rini
0 siblings, 0 replies; 6+ messages in thread
From: Tom Rini @ 2023-11-02 13:27 UTC (permalink / raw)
To: Yong-Xuan Wang
Cc: u-boot, greentime.hu, vincent.chen, Paul Walmsley, Green Wan
[-- Attachment #1: Type: text/plain, Size: 3228 bytes --]
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@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@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@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@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@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@chromium.org>
--
Tom
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2023-11-02 13:27 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2023-10-26 3:22 [PATCH 1/1] board: sifive: unmatched: move kernel load address to 0x80200000 Yong-Xuan Wang
2023-10-27 16:43 ` Tom Rini
2023-10-31 7:56 ` Yong-Xuan Wang
2023-10-31 11:54 ` Tom Rini
2023-11-02 10:27 ` Yong-Xuan Wang
2023-11-02 13:27 ` Tom Rini
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox