[PATCH 1/1] board: sifive: unmatched: move kernel load address to 0x80200000
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" \
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) ?
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
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
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
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
participants (2)
-
Tom Rini -
Yong-Xuan Wang