* [U-Boot] [PATCH v2 0/3] Enable spl relocation on arm
@ 2019-05-16 12:19 Andy Yan
2019-05-16 12:21 ` [U-Boot] [PATCH v2 1/3] powerpc: Convert CONFIG_SPL_RELOC_TEXT_BASE to Kconfig Andy Yan
` (2 more replies)
0 siblings, 3 replies; 25+ messages in thread
From: Andy Yan @ 2019-05-16 12:19 UTC (permalink / raw)
To: u-boot
Some times we want to relocate spl code to dram after dram
initialization or relocate spl code to a high memory to avoid
code overid.
For example on Rockchip armv8 platform, we run with boot flow
TPL->SPL->ATF->U-Boot.
TPL run in sram and is responsible for dram initialization.
SPL run from the start address of dram and is responsible for
loading ATF and U-Boot.
The case here is that the ATF load address is from 64KB of dram,
which overlaps with spl code itself.
So we want to relocate spl itself to high memory to aovid this.
When look the code, I found powerpc use the spl relocation. So
I dicide share the config with powerpc.
Changes in v2:
- Move Kconfig modification to PATCH 1/3
- Add more detial commit message
Andy Yan (3):
powerpc: Convert CONFIG_SPL_RELOC_TEXT_BASE to Kconfig
spl: add relocation support
arm: add spl relocation support for arm
arch/arm/config.mk | 6 +++
arch/arm/cpu/armv8/start.S | 4 ++
arch/arm/cpu/armv8/u-boot-spl.lds | 17 ++++++
arch/arm/lib/Makefile | 2 +-
arch/arm/lib/crt0_64.S | 3 +-
common/spl/Kconfig | 13 +++++
common/spl/spl.c | 55 ++++++++++++++++++++
configs/BSC9131RDB_NAND_SYSCLK100_defconfig | 2 +
configs/BSC9131RDB_NAND_defconfig | 2 +
configs/BSC9132QDS_NAND_DDRCLK100_defconfig | 2 +
configs/BSC9132QDS_NAND_DDRCLK133_defconfig | 2 +
configs/C29XPCIE_NAND_defconfig | 2 +
configs/P1010RDB-PA_36BIT_NAND_defconfig | 2 +
configs/P1010RDB-PA_36BIT_SDCARD_defconfig | 2 +
configs/P1010RDB-PA_36BIT_SPIFLASH_defconfig | 2 +
configs/P1010RDB-PA_NAND_defconfig | 2 +
configs/P1010RDB-PA_SDCARD_defconfig | 2 +
configs/P1010RDB-PA_SPIFLASH_defconfig | 2 +
configs/P1010RDB-PB_36BIT_NAND_defconfig | 2 +
configs/P1010RDB-PB_36BIT_SDCARD_defconfig | 2 +
configs/P1010RDB-PB_36BIT_SPIFLASH_defconfig | 2 +
configs/P1010RDB-PB_NAND_defconfig | 2 +
configs/P1010RDB-PB_SDCARD_defconfig | 2 +
configs/P1010RDB-PB_SPIFLASH_defconfig | 2 +
configs/P1020MBG-PC_36BIT_SDCARD_defconfig | 2 +
configs/P1020MBG-PC_SDCARD_defconfig | 2 +
configs/P1020RDB-PC_36BIT_NAND_defconfig | 2 +
configs/P1020RDB-PC_36BIT_SDCARD_defconfig | 2 +
configs/P1020RDB-PC_36BIT_SPIFLASH_defconfig | 2 +
configs/P1020RDB-PC_NAND_defconfig | 2 +
configs/P1020RDB-PC_SDCARD_defconfig | 2 +
configs/P1020RDB-PC_SPIFLASH_defconfig | 2 +
configs/P1020RDB-PD_NAND_defconfig | 2 +
configs/P1020RDB-PD_SDCARD_defconfig | 2 +
configs/P1020RDB-PD_SPIFLASH_defconfig | 2 +
configs/P1020UTM-PC_36BIT_SDCARD_defconfig | 2 +
configs/P1020UTM-PC_SDCARD_defconfig | 2 +
configs/P1021RDB-PC_36BIT_NAND_defconfig | 2 +
configs/P1021RDB-PC_36BIT_SDCARD_defconfig | 2 +
configs/P1021RDB-PC_36BIT_SPIFLASH_defconfig | 2 +
configs/P1021RDB-PC_NAND_defconfig | 2 +
configs/P1021RDB-PC_SDCARD_defconfig | 2 +
configs/P1021RDB-PC_SPIFLASH_defconfig | 2 +
configs/P1022DS_36BIT_NAND_defconfig | 2 +
configs/P1022DS_36BIT_SDCARD_defconfig | 2 +
configs/P1022DS_36BIT_SPIFLASH_defconfig | 2 +
configs/P1022DS_NAND_defconfig | 2 +
configs/P1022DS_SDCARD_defconfig | 2 +
configs/P1022DS_SPIFLASH_defconfig | 2 +
configs/P1024RDB_NAND_defconfig | 2 +
configs/P1024RDB_SDCARD_defconfig | 2 +
configs/P1024RDB_SPIFLASH_defconfig | 2 +
configs/P1025RDB_NAND_defconfig | 2 +
configs/P1025RDB_SDCARD_defconfig | 2 +
configs/P1025RDB_SPIFLASH_defconfig | 2 +
configs/P2020RDB-PC_36BIT_NAND_defconfig | 2 +
configs/P2020RDB-PC_36BIT_SDCARD_defconfig | 2 +
configs/P2020RDB-PC_36BIT_SPIFLASH_defconfig | 2 +
configs/P2020RDB-PC_NAND_defconfig | 2 +
configs/P2020RDB-PC_SDCARD_defconfig | 2 +
configs/P2020RDB-PC_SPIFLASH_defconfig | 2 +
include/configs/BSC9131RDB.h | 1 -
include/configs/BSC9132QDS.h | 1 -
include/configs/C29XPCIE.h | 3 --
include/configs/P1010RDB.h | 4 --
include/configs/P1022DS.h | 3 --
include/configs/p1_p2_rdb_pc.h | 3 --
67 files changed, 206 insertions(+), 17 deletions(-)
--
2.17.1
^ permalink raw reply [flat|nested] 25+ messages in thread* [U-Boot] [PATCH v2 1/3] powerpc: Convert CONFIG_SPL_RELOC_TEXT_BASE to Kconfig 2019-05-16 12:19 [U-Boot] [PATCH v2 0/3] Enable spl relocation on arm Andy Yan @ 2019-05-16 12:21 ` Andy Yan 2019-05-16 12:21 ` [U-Boot] [PATCH v2 2/3] spl: add relocation support Andy Yan 2019-05-16 12:22 ` [U-Boot] [PATCH v2 3/3] arm: add spl relocation support for arm Andy Yan 2 siblings, 0 replies; 25+ messages in thread From: Andy Yan @ 2019-05-16 12:21 UTC (permalink / raw) To: u-boot Move CONFIG_SPL_RELOC_TEXT_BASE and CONFIG_SPL_SKIP_RELOCATE to Kconfig, so we can reuse it for cross other platform. Signed-off-by: Andy Yan <andy.yan@rock-chips.com> --- Changes in v2: None common/spl/Kconfig | 13 +++++++++++++ configs/BSC9131RDB_NAND_SYSCLK100_defconfig | 2 ++ configs/BSC9131RDB_NAND_defconfig | 2 ++ configs/BSC9132QDS_NAND_DDRCLK100_defconfig | 2 ++ configs/BSC9132QDS_NAND_DDRCLK133_defconfig | 2 ++ configs/C29XPCIE_NAND_defconfig | 2 ++ configs/P1010RDB-PA_36BIT_NAND_defconfig | 2 ++ configs/P1010RDB-PA_36BIT_SDCARD_defconfig | 2 ++ configs/P1010RDB-PA_36BIT_SPIFLASH_defconfig | 2 ++ configs/P1010RDB-PA_NAND_defconfig | 2 ++ configs/P1010RDB-PA_SDCARD_defconfig | 2 ++ configs/P1010RDB-PA_SPIFLASH_defconfig | 2 ++ configs/P1010RDB-PB_36BIT_NAND_defconfig | 2 ++ configs/P1010RDB-PB_36BIT_SDCARD_defconfig | 2 ++ configs/P1010RDB-PB_36BIT_SPIFLASH_defconfig | 2 ++ configs/P1010RDB-PB_NAND_defconfig | 2 ++ configs/P1010RDB-PB_SDCARD_defconfig | 2 ++ configs/P1010RDB-PB_SPIFLASH_defconfig | 2 ++ configs/P1020MBG-PC_36BIT_SDCARD_defconfig | 2 ++ configs/P1020MBG-PC_SDCARD_defconfig | 2 ++ configs/P1020RDB-PC_36BIT_NAND_defconfig | 2 ++ configs/P1020RDB-PC_36BIT_SDCARD_defconfig | 2 ++ configs/P1020RDB-PC_36BIT_SPIFLASH_defconfig | 2 ++ configs/P1020RDB-PC_NAND_defconfig | 2 ++ configs/P1020RDB-PC_SDCARD_defconfig | 2 ++ configs/P1020RDB-PC_SPIFLASH_defconfig | 2 ++ configs/P1020RDB-PD_NAND_defconfig | 2 ++ configs/P1020RDB-PD_SDCARD_defconfig | 2 ++ configs/P1020RDB-PD_SPIFLASH_defconfig | 2 ++ configs/P1020UTM-PC_36BIT_SDCARD_defconfig | 2 ++ configs/P1020UTM-PC_SDCARD_defconfig | 2 ++ configs/P1021RDB-PC_36BIT_NAND_defconfig | 2 ++ configs/P1021RDB-PC_36BIT_SDCARD_defconfig | 2 ++ configs/P1021RDB-PC_36BIT_SPIFLASH_defconfig | 2 ++ configs/P1021RDB-PC_NAND_defconfig | 2 ++ configs/P1021RDB-PC_SDCARD_defconfig | 2 ++ configs/P1021RDB-PC_SPIFLASH_defconfig | 2 ++ configs/P1022DS_36BIT_NAND_defconfig | 2 ++ configs/P1022DS_36BIT_SDCARD_defconfig | 2 ++ configs/P1022DS_36BIT_SPIFLASH_defconfig | 2 ++ configs/P1022DS_NAND_defconfig | 2 ++ configs/P1022DS_SDCARD_defconfig | 2 ++ configs/P1022DS_SPIFLASH_defconfig | 2 ++ configs/P1024RDB_NAND_defconfig | 2 ++ configs/P1024RDB_SDCARD_defconfig | 2 ++ configs/P1024RDB_SPIFLASH_defconfig | 2 ++ configs/P1025RDB_NAND_defconfig | 2 ++ configs/P1025RDB_SDCARD_defconfig | 2 ++ configs/P1025RDB_SPIFLASH_defconfig | 2 ++ configs/P2020RDB-PC_36BIT_NAND_defconfig | 2 ++ configs/P2020RDB-PC_36BIT_SDCARD_defconfig | 2 ++ configs/P2020RDB-PC_36BIT_SPIFLASH_defconfig | 2 ++ configs/P2020RDB-PC_NAND_defconfig | 2 ++ configs/P2020RDB-PC_SDCARD_defconfig | 2 ++ configs/P2020RDB-PC_SPIFLASH_defconfig | 2 ++ include/configs/BSC9131RDB.h | 1 - include/configs/BSC9132QDS.h | 1 - include/configs/C29XPCIE.h | 3 --- include/configs/P1010RDB.h | 4 ---- include/configs/P1022DS.h | 3 --- include/configs/p1_p2_rdb_pc.h | 3 --- 61 files changed, 121 insertions(+), 15 deletions(-) diff --git a/common/spl/Kconfig b/common/spl/Kconfig index 206c24076d..52669ce1f8 100644 --- a/common/spl/Kconfig +++ b/common/spl/Kconfig @@ -189,6 +189,19 @@ config SPL_DISPLAY_PRINT banner ("U-Boot SPL ..."). This function should be provided by the board. +config SPL_SKIP_RELOCATE + bool "Skip code relocation in SPL" + default y + help + The SPL code will be relocated to a high memory if you say no here. + Only ARM64 and PowerPC SPL support relocate now. + +config SPL_RELOC_TEXT_BASE + hex "Address the SPL relocate to" + depends on !SPL_SKIP_RELOCATE + help + The address on the ram where the SPL relocate to. + config SYS_MMCSD_RAW_MODE_U_BOOT_USE_SECTOR bool "MMC raw mode: by sector" default y if ARCH_SUNXI || ARCH_DAVINCI || ARCH_UNIPHIER || \ diff --git a/configs/BSC9131RDB_NAND_SYSCLK100_defconfig b/configs/BSC9131RDB_NAND_SYSCLK100_defconfig index 55906fa0ff..81aaff4585 100644 --- a/configs/BSC9131RDB_NAND_SYSCLK100_defconfig +++ b/configs/BSC9131RDB_NAND_SYSCLK100_defconfig @@ -13,6 +13,8 @@ CONFIG_BOOTDELAY=10 CONFIG_SYS_CONSOLE_IS_IN_ENV=y # CONFIG_MISC_INIT_R is not set # CONFIG_SPL_FRAMEWORK is not set +# CONFIG_SPL_SKIP_RELOCATE is not set +CONFIG_SPL_RELOC_TEXT_BASE=0x100000 CONFIG_SPL_NAND_SUPPORT=y CONFIG_HUSH_PARSER=y # CONFIG_CMD_FLASH is not set diff --git a/configs/BSC9131RDB_NAND_defconfig b/configs/BSC9131RDB_NAND_defconfig index e26ad536a8..fbe2665bd1 100644 --- a/configs/BSC9131RDB_NAND_defconfig +++ b/configs/BSC9131RDB_NAND_defconfig @@ -12,6 +12,8 @@ CONFIG_BOOTDELAY=10 CONFIG_SYS_CONSOLE_IS_IN_ENV=y # CONFIG_MISC_INIT_R is not set # CONFIG_SPL_FRAMEWORK is not set +# CONFIG_SPL_SKIP_RELOCATE is not set +CONFIG_SPL_RELOC_TEXT_BASE=0x100000 CONFIG_SPL_NAND_SUPPORT=y CONFIG_HUSH_PARSER=y # CONFIG_CMD_FLASH is not set diff --git a/configs/BSC9132QDS_NAND_DDRCLK100_defconfig b/configs/BSC9132QDS_NAND_DDRCLK100_defconfig index a0c697a786..c05e6d5edc 100644 --- a/configs/BSC9132QDS_NAND_DDRCLK100_defconfig +++ b/configs/BSC9132QDS_NAND_DDRCLK100_defconfig @@ -13,6 +13,8 @@ CONFIG_BOOTDELAY=10 CONFIG_SYS_CONSOLE_IS_IN_ENV=y CONFIG_BOARD_EARLY_INIT_R=y # CONFIG_SPL_FRAMEWORK is not set +# CONFIG_SPL_SKIP_RELOCATE is not set +CONFIG_SPL_RELOC_TEXT_BASE=0x100000 CONFIG_SPL_NAND_SUPPORT=y CONFIG_HUSH_PARSER=y CONFIG_CMD_IMLS=y diff --git a/configs/BSC9132QDS_NAND_DDRCLK133_defconfig b/configs/BSC9132QDS_NAND_DDRCLK133_defconfig index d688029f7b..fa8abbe0db 100644 --- a/configs/BSC9132QDS_NAND_DDRCLK133_defconfig +++ b/configs/BSC9132QDS_NAND_DDRCLK133_defconfig @@ -13,6 +13,8 @@ CONFIG_BOOTDELAY=10 CONFIG_SYS_CONSOLE_IS_IN_ENV=y CONFIG_BOARD_EARLY_INIT_R=y # CONFIG_SPL_FRAMEWORK is not set +# CONFIG_SPL_SKIP_RELOCATE is not set +CONFIG_SPL_RELOC_TEXT_BASE=0x100000 CONFIG_SPL_NAND_SUPPORT=y CONFIG_HUSH_PARSER=y CONFIG_CMD_IMLS=y diff --git a/configs/C29XPCIE_NAND_defconfig b/configs/C29XPCIE_NAND_defconfig index 94f04d74b7..1501f88502 100644 --- a/configs/C29XPCIE_NAND_defconfig +++ b/configs/C29XPCIE_NAND_defconfig @@ -16,6 +16,8 @@ CONFIG_SYS_CONSOLE_IS_IN_ENV=y # CONFIG_MISC_INIT_R is not set CONFIG_BOARD_EARLY_INIT_R=y # CONFIG_SPL_FRAMEWORK is not set +# CONFIG_SPL_SKIP_RELOCATE is not set +CONFIG_SPL_RELOC_TEXT_BASE=0xf8fbd000 CONFIG_SPL_NAND_SUPPORT=y CONFIG_TPL=y CONFIG_TPL_ENV_SUPPORT=y diff --git a/configs/P1010RDB-PA_36BIT_NAND_defconfig b/configs/P1010RDB-PA_36BIT_NAND_defconfig index 9e938b2f99..3196f61c4d 100644 --- a/configs/P1010RDB-PA_36BIT_NAND_defconfig +++ b/configs/P1010RDB-PA_36BIT_NAND_defconfig @@ -17,6 +17,8 @@ CONFIG_SYS_CONSOLE_IS_IN_ENV=y CONFIG_BOARD_EARLY_INIT_F=y CONFIG_BOARD_EARLY_INIT_R=y # CONFIG_SPL_FRAMEWORK is not set +# CONFIG_SPL_SKIP_RELOCATE is not set +CONFIG_SPL_RELOC_TEXT_BASE=0xd003d000 CONFIG_SPL_NAND_SUPPORT=y CONFIG_TPL=y CONFIG_TPL_DRIVERS_MISC_SUPPORT=y diff --git a/configs/P1010RDB-PA_36BIT_SDCARD_defconfig b/configs/P1010RDB-PA_36BIT_SDCARD_defconfig index 2e38575cc2..74af930332 100644 --- a/configs/P1010RDB-PA_36BIT_SDCARD_defconfig +++ b/configs/P1010RDB-PA_36BIT_SDCARD_defconfig @@ -19,6 +19,8 @@ CONFIG_SYS_CONSOLE_IS_IN_ENV=y CONFIG_BOARD_EARLY_INIT_F=y CONFIG_BOARD_EARLY_INIT_R=y # CONFIG_SPL_FRAMEWORK is not set +# CONFIG_SPL_SKIP_RELOCATE is not set +CONFIG_SPL_RELOC_TEXT_BASE=0xd0001000 CONFIG_SPL_ENV_SUPPORT=y CONFIG_SPL_I2C_SUPPORT=y CONFIG_SPL_MPC8XXX_INIT_DDR_SUPPORT=y diff --git a/configs/P1010RDB-PA_36BIT_SPIFLASH_defconfig b/configs/P1010RDB-PA_36BIT_SPIFLASH_defconfig index 9bdbac008c..553ae794c2 100644 --- a/configs/P1010RDB-PA_36BIT_SPIFLASH_defconfig +++ b/configs/P1010RDB-PA_36BIT_SPIFLASH_defconfig @@ -20,6 +20,8 @@ CONFIG_SYS_CONSOLE_IS_IN_ENV=y CONFIG_BOARD_EARLY_INIT_F=y CONFIG_BOARD_EARLY_INIT_R=y # CONFIG_SPL_FRAMEWORK is not set +# CONFIG_SPL_SKIP_RELOCATE is not set +CONFIG_SPL_RELOC_TEXT_BASE=0xd0001000 CONFIG_SPL_ENV_SUPPORT=y CONFIG_SPL_I2C_SUPPORT=y CONFIG_SPL_MPC8XXX_INIT_DDR_SUPPORT=y diff --git a/configs/P1010RDB-PA_NAND_defconfig b/configs/P1010RDB-PA_NAND_defconfig index aea45293c1..99b7171bdb 100644 --- a/configs/P1010RDB-PA_NAND_defconfig +++ b/configs/P1010RDB-PA_NAND_defconfig @@ -16,6 +16,8 @@ CONFIG_SYS_CONSOLE_IS_IN_ENV=y CONFIG_BOARD_EARLY_INIT_F=y CONFIG_BOARD_EARLY_INIT_R=y # CONFIG_SPL_FRAMEWORK is not set +# CONFIG_SPL_SKIP_RELOCATE is not set +CONFIG_SPL_RELOC_TEXT_BASE=0xd003d000 CONFIG_SPL_NAND_SUPPORT=y CONFIG_TPL=y CONFIG_TPL_DRIVERS_MISC_SUPPORT=y diff --git a/configs/P1010RDB-PA_SDCARD_defconfig b/configs/P1010RDB-PA_SDCARD_defconfig index 1455291e25..0e9c2f3db2 100644 --- a/configs/P1010RDB-PA_SDCARD_defconfig +++ b/configs/P1010RDB-PA_SDCARD_defconfig @@ -18,6 +18,8 @@ CONFIG_SYS_CONSOLE_IS_IN_ENV=y CONFIG_BOARD_EARLY_INIT_F=y CONFIG_BOARD_EARLY_INIT_R=y # CONFIG_SPL_FRAMEWORK is not set +# CONFIG_SPL_SKIP_RELOCATE is not set +CONFIG_SPL_RELOC_TEXT_BASE=0xd0001000 CONFIG_SPL_ENV_SUPPORT=y CONFIG_SPL_I2C_SUPPORT=y CONFIG_SPL_MPC8XXX_INIT_DDR_SUPPORT=y diff --git a/configs/P1010RDB-PA_SPIFLASH_defconfig b/configs/P1010RDB-PA_SPIFLASH_defconfig index bb38e716b2..e67aff9eaa 100644 --- a/configs/P1010RDB-PA_SPIFLASH_defconfig +++ b/configs/P1010RDB-PA_SPIFLASH_defconfig @@ -19,6 +19,8 @@ CONFIG_SYS_CONSOLE_IS_IN_ENV=y CONFIG_BOARD_EARLY_INIT_F=y CONFIG_BOARD_EARLY_INIT_R=y # CONFIG_SPL_FRAMEWORK is not set +# CONFIG_SPL_SKIP_RELOCATE is not set +CONFIG_SPL_RELOC_TEXT_BASE=0xd0001000 CONFIG_SPL_ENV_SUPPORT=y CONFIG_SPL_I2C_SUPPORT=y CONFIG_SPL_MPC8XXX_INIT_DDR_SUPPORT=y diff --git a/configs/P1010RDB-PB_36BIT_NAND_defconfig b/configs/P1010RDB-PB_36BIT_NAND_defconfig index ce80bade60..5a9823f83a 100644 --- a/configs/P1010RDB-PB_36BIT_NAND_defconfig +++ b/configs/P1010RDB-PB_36BIT_NAND_defconfig @@ -17,6 +17,8 @@ CONFIG_SYS_CONSOLE_IS_IN_ENV=y CONFIG_BOARD_EARLY_INIT_F=y CONFIG_BOARD_EARLY_INIT_R=y # CONFIG_SPL_FRAMEWORK is not set +# CONFIG_SPL_SKIP_RELOCATE is not set +CONFIG_SPL_RELOC_TEXT_BASE=0xd003d000 CONFIG_SPL_NAND_SUPPORT=y CONFIG_TPL=y CONFIG_TPL_DRIVERS_MISC_SUPPORT=y diff --git a/configs/P1010RDB-PB_36BIT_SDCARD_defconfig b/configs/P1010RDB-PB_36BIT_SDCARD_defconfig index 69a933cdf8..6b1b1e2fac 100644 --- a/configs/P1010RDB-PB_36BIT_SDCARD_defconfig +++ b/configs/P1010RDB-PB_36BIT_SDCARD_defconfig @@ -19,6 +19,8 @@ CONFIG_SYS_CONSOLE_IS_IN_ENV=y CONFIG_BOARD_EARLY_INIT_F=y CONFIG_BOARD_EARLY_INIT_R=y # CONFIG_SPL_FRAMEWORK is not set +# CONFIG_SPL_SKIP_RELOCATE is not set +CONFIG_SPL_RELOC_TEXT_BASE=0xd0001000 CONFIG_SPL_ENV_SUPPORT=y CONFIG_SPL_I2C_SUPPORT=y CONFIG_SPL_MPC8XXX_INIT_DDR_SUPPORT=y diff --git a/configs/P1010RDB-PB_36BIT_SPIFLASH_defconfig b/configs/P1010RDB-PB_36BIT_SPIFLASH_defconfig index 4ec77b8656..ea707ff1f9 100644 --- a/configs/P1010RDB-PB_36BIT_SPIFLASH_defconfig +++ b/configs/P1010RDB-PB_36BIT_SPIFLASH_defconfig @@ -20,6 +20,8 @@ CONFIG_SYS_CONSOLE_IS_IN_ENV=y CONFIG_BOARD_EARLY_INIT_F=y CONFIG_BOARD_EARLY_INIT_R=y # CONFIG_SPL_FRAMEWORK is not set +# CONFIG_SPL_SKIP_RELOCATE is not set +CONFIG_SPL_RELOC_TEXT_BASE=0xd0001000 CONFIG_SPL_ENV_SUPPORT=y CONFIG_SPL_I2C_SUPPORT=y CONFIG_SPL_MPC8XXX_INIT_DDR_SUPPORT=y diff --git a/configs/P1010RDB-PB_NAND_defconfig b/configs/P1010RDB-PB_NAND_defconfig index 1873c13191..2b96d93b3f 100644 --- a/configs/P1010RDB-PB_NAND_defconfig +++ b/configs/P1010RDB-PB_NAND_defconfig @@ -16,6 +16,8 @@ CONFIG_SYS_CONSOLE_IS_IN_ENV=y CONFIG_BOARD_EARLY_INIT_F=y CONFIG_BOARD_EARLY_INIT_R=y # CONFIG_SPL_FRAMEWORK is not set +# CONFIG_SPL_SKIP_RELOCATE is not set +CONFIG_SPL_RELOC_TEXT_BASE=0xd003d000 CONFIG_SPL_NAND_SUPPORT=y CONFIG_TPL=y CONFIG_TPL_DRIVERS_MISC_SUPPORT=y diff --git a/configs/P1010RDB-PB_SDCARD_defconfig b/configs/P1010RDB-PB_SDCARD_defconfig index be6ca00196..eeb9715122 100644 --- a/configs/P1010RDB-PB_SDCARD_defconfig +++ b/configs/P1010RDB-PB_SDCARD_defconfig @@ -18,6 +18,8 @@ CONFIG_SYS_CONSOLE_IS_IN_ENV=y CONFIG_BOARD_EARLY_INIT_F=y CONFIG_BOARD_EARLY_INIT_R=y # CONFIG_SPL_FRAMEWORK is not set +# CONFIG_SPL_SKIP_RELOCATE is not set +CONFIG_SPL_RELOC_TEXT_BASE=0xd0001000 CONFIG_SPL_ENV_SUPPORT=y CONFIG_SPL_I2C_SUPPORT=y CONFIG_SPL_MPC8XXX_INIT_DDR_SUPPORT=y diff --git a/configs/P1010RDB-PB_SPIFLASH_defconfig b/configs/P1010RDB-PB_SPIFLASH_defconfig index 6efe1aaca0..207b0f1b7c 100644 --- a/configs/P1010RDB-PB_SPIFLASH_defconfig +++ b/configs/P1010RDB-PB_SPIFLASH_defconfig @@ -19,6 +19,8 @@ CONFIG_SYS_CONSOLE_IS_IN_ENV=y CONFIG_BOARD_EARLY_INIT_F=y CONFIG_BOARD_EARLY_INIT_R=y # CONFIG_SPL_FRAMEWORK is not set +# CONFIG_SPL_SKIP_RELOCATE is not set +CONFIG_SPL_RELOC_TEXT_BASE=0xd0001000 CONFIG_SPL_ENV_SUPPORT=y CONFIG_SPL_I2C_SUPPORT=y CONFIG_SPL_MPC8XXX_INIT_DDR_SUPPORT=y diff --git a/configs/P1020MBG-PC_36BIT_SDCARD_defconfig b/configs/P1020MBG-PC_36BIT_SDCARD_defconfig index cd1c8fc965..0c3f80af73 100644 --- a/configs/P1020MBG-PC_36BIT_SDCARD_defconfig +++ b/configs/P1020MBG-PC_36BIT_SDCARD_defconfig @@ -19,6 +19,8 @@ CONFIG_BOOTDELAY=10 CONFIG_BOARD_EARLY_INIT_F=y CONFIG_BOARD_EARLY_INIT_R=y # CONFIG_SPL_FRAMEWORK is not set +# CONFIG_SPL_SKIP_RELOCATE is not set +CONFIG_SPL_RELOC_TEXT_BASE=0xf8f81000 CONFIG_SPL_ENV_SUPPORT=y CONFIG_SPL_I2C_SUPPORT=y CONFIG_SPL_MPC8XXX_INIT_DDR_SUPPORT=y diff --git a/configs/P1020MBG-PC_SDCARD_defconfig b/configs/P1020MBG-PC_SDCARD_defconfig index 21c10af164..a91ad088ca 100644 --- a/configs/P1020MBG-PC_SDCARD_defconfig +++ b/configs/P1020MBG-PC_SDCARD_defconfig @@ -18,6 +18,8 @@ CONFIG_BOOTDELAY=10 CONFIG_BOARD_EARLY_INIT_F=y CONFIG_BOARD_EARLY_INIT_R=y # CONFIG_SPL_FRAMEWORK is not set +# CONFIG_SPL_SKIP_RELOCATE is not set +CONFIG_SPL_RELOC_TEXT_BASE=0xf8f81000 CONFIG_SPL_ENV_SUPPORT=y CONFIG_SPL_I2C_SUPPORT=y CONFIG_SPL_MPC8XXX_INIT_DDR_SUPPORT=y diff --git a/configs/P1020RDB-PC_36BIT_NAND_defconfig b/configs/P1020RDB-PC_36BIT_NAND_defconfig index 13a47f8176..4ed4d31b3c 100644 --- a/configs/P1020RDB-PC_36BIT_NAND_defconfig +++ b/configs/P1020RDB-PC_36BIT_NAND_defconfig @@ -17,6 +17,8 @@ CONFIG_BOOTDELAY=10 CONFIG_BOARD_EARLY_INIT_F=y CONFIG_BOARD_EARLY_INIT_R=y # CONFIG_SPL_FRAMEWORK is not set +# CONFIG_SPL_SKIP_RELOCATE is not set +CONFIG_SPL_RELOC_TEXT_BASE=0xf8fbe000 CONFIG_SPL_NAND_SUPPORT=y CONFIG_TPL=y CONFIG_TPL_ENV_SUPPORT=y diff --git a/configs/P1020RDB-PC_36BIT_SDCARD_defconfig b/configs/P1020RDB-PC_36BIT_SDCARD_defconfig index 96c9f3c8f1..2d2b3e55cc 100644 --- a/configs/P1020RDB-PC_36BIT_SDCARD_defconfig +++ b/configs/P1020RDB-PC_36BIT_SDCARD_defconfig @@ -19,6 +19,8 @@ CONFIG_BOOTDELAY=10 CONFIG_BOARD_EARLY_INIT_F=y CONFIG_BOARD_EARLY_INIT_R=y # CONFIG_SPL_FRAMEWORK is not set +# CONFIG_SPL_SKIP_RELOCATE is not set +CONFIG_SPL_RELOC_TEXT_BASE=0xf8f81000 CONFIG_SPL_ENV_SUPPORT=y CONFIG_SPL_I2C_SUPPORT=y CONFIG_SPL_MPC8XXX_INIT_DDR_SUPPORT=y diff --git a/configs/P1020RDB-PC_36BIT_SPIFLASH_defconfig b/configs/P1020RDB-PC_36BIT_SPIFLASH_defconfig index a28913ef7a..32eb72deb5 100644 --- a/configs/P1020RDB-PC_36BIT_SPIFLASH_defconfig +++ b/configs/P1020RDB-PC_36BIT_SPIFLASH_defconfig @@ -20,6 +20,8 @@ CONFIG_BOOTDELAY=10 CONFIG_BOARD_EARLY_INIT_F=y CONFIG_BOARD_EARLY_INIT_R=y # CONFIG_SPL_FRAMEWORK is not set +# CONFIG_SPL_SKIP_RELOCATE is not set +CONFIG_SPL_RELOC_TEXT_BASE=0xf8f81000 CONFIG_SPL_ENV_SUPPORT=y CONFIG_SPL_I2C_SUPPORT=y CONFIG_SPL_MPC8XXX_INIT_DDR_SUPPORT=y diff --git a/configs/P1020RDB-PC_NAND_defconfig b/configs/P1020RDB-PC_NAND_defconfig index 6b5c7a5110..0bede77352 100644 --- a/configs/P1020RDB-PC_NAND_defconfig +++ b/configs/P1020RDB-PC_NAND_defconfig @@ -16,6 +16,8 @@ CONFIG_BOOTDELAY=10 CONFIG_BOARD_EARLY_INIT_F=y CONFIG_BOARD_EARLY_INIT_R=y # CONFIG_SPL_FRAMEWORK is not set +# CONFIG_SPL_SKIP_RELOCATE is not set +CONFIG_SPL_RELOC_TEXT_BASE=0xf8fbe000 CONFIG_SPL_NAND_SUPPORT=y CONFIG_TPL=y CONFIG_TPL_ENV_SUPPORT=y diff --git a/configs/P1020RDB-PC_SDCARD_defconfig b/configs/P1020RDB-PC_SDCARD_defconfig index 6ab5929e78..18293c7b12 100644 --- a/configs/P1020RDB-PC_SDCARD_defconfig +++ b/configs/P1020RDB-PC_SDCARD_defconfig @@ -18,6 +18,8 @@ CONFIG_BOOTDELAY=10 CONFIG_BOARD_EARLY_INIT_F=y CONFIG_BOARD_EARLY_INIT_R=y # CONFIG_SPL_FRAMEWORK is not set +# CONFIG_SPL_SKIP_RELOCATE is not set +CONFIG_SPL_RELOC_TEXT_BASE=0xf8f81000 CONFIG_SPL_ENV_SUPPORT=y CONFIG_SPL_I2C_SUPPORT=y CONFIG_SPL_MPC8XXX_INIT_DDR_SUPPORT=y diff --git a/configs/P1020RDB-PC_SPIFLASH_defconfig b/configs/P1020RDB-PC_SPIFLASH_defconfig index afc789b603..c652c2c8eb 100644 --- a/configs/P1020RDB-PC_SPIFLASH_defconfig +++ b/configs/P1020RDB-PC_SPIFLASH_defconfig @@ -19,6 +19,8 @@ CONFIG_BOOTDELAY=10 CONFIG_BOARD_EARLY_INIT_F=y CONFIG_BOARD_EARLY_INIT_R=y # CONFIG_SPL_FRAMEWORK is not set +# CONFIG_SPL_SKIP_RELOCATE is not set +CONFIG_SPL_RELOC_TEXT_BASE=0xf8f81000 CONFIG_SPL_ENV_SUPPORT=y CONFIG_SPL_I2C_SUPPORT=y CONFIG_SPL_MPC8XXX_INIT_DDR_SUPPORT=y diff --git a/configs/P1020RDB-PD_NAND_defconfig b/configs/P1020RDB-PD_NAND_defconfig index 324881d5f0..ea06155a71 100644 --- a/configs/P1020RDB-PD_NAND_defconfig +++ b/configs/P1020RDB-PD_NAND_defconfig @@ -16,6 +16,8 @@ CONFIG_BOOTDELAY=10 CONFIG_BOARD_EARLY_INIT_F=y CONFIG_BOARD_EARLY_INIT_R=y # CONFIG_SPL_FRAMEWORK is not set +# CONFIG_SPL_SKIP_RELOCATE is not set +CONFIG_SPL_RELOC_TEXT_BASE=0xf8fbe000 CONFIG_SPL_NAND_SUPPORT=y CONFIG_TPL=y CONFIG_TPL_ENV_SUPPORT=y diff --git a/configs/P1020RDB-PD_SDCARD_defconfig b/configs/P1020RDB-PD_SDCARD_defconfig index 4c7212068c..06a8c03c1b 100644 --- a/configs/P1020RDB-PD_SDCARD_defconfig +++ b/configs/P1020RDB-PD_SDCARD_defconfig @@ -18,6 +18,8 @@ CONFIG_BOOTDELAY=10 CONFIG_BOARD_EARLY_INIT_F=y CONFIG_BOARD_EARLY_INIT_R=y # CONFIG_SPL_FRAMEWORK is not set +# CONFIG_SPL_SKIP_RELOCATE is not set +CONFIG_SPL_RELOC_TEXT_BASE=0xf8f81000 CONFIG_SPL_ENV_SUPPORT=y CONFIG_SPL_I2C_SUPPORT=y CONFIG_SPL_MPC8XXX_INIT_DDR_SUPPORT=y diff --git a/configs/P1020RDB-PD_SPIFLASH_defconfig b/configs/P1020RDB-PD_SPIFLASH_defconfig index 243456c8a3..48e6619465 100644 --- a/configs/P1020RDB-PD_SPIFLASH_defconfig +++ b/configs/P1020RDB-PD_SPIFLASH_defconfig @@ -19,6 +19,8 @@ CONFIG_BOOTDELAY=10 CONFIG_BOARD_EARLY_INIT_F=y CONFIG_BOARD_EARLY_INIT_R=y # CONFIG_SPL_FRAMEWORK is not set +# CONFIG_SPL_SKIP_RELOCATE is not set +CONFIG_SPL_RELOC_TEXT_BASE=0xf8f81000 CONFIG_SPL_ENV_SUPPORT=y CONFIG_SPL_I2C_SUPPORT=y CONFIG_SPL_MPC8XXX_INIT_DDR_SUPPORT=y diff --git a/configs/P1020UTM-PC_36BIT_SDCARD_defconfig b/configs/P1020UTM-PC_36BIT_SDCARD_defconfig index 0c15789c44..3da0e4f5c2 100644 --- a/configs/P1020UTM-PC_36BIT_SDCARD_defconfig +++ b/configs/P1020UTM-PC_36BIT_SDCARD_defconfig @@ -19,6 +19,8 @@ CONFIG_BOOTDELAY=10 CONFIG_BOARD_EARLY_INIT_F=y CONFIG_BOARD_EARLY_INIT_R=y # CONFIG_SPL_FRAMEWORK is not set +# CONFIG_SPL_SKIP_RELOCATE is not set +CONFIG_SPL_RELOC_TEXT_BASE=0xf8f81000 CONFIG_SPL_ENV_SUPPORT=y CONFIG_SPL_I2C_SUPPORT=y CONFIG_SPL_MPC8XXX_INIT_DDR_SUPPORT=y diff --git a/configs/P1020UTM-PC_SDCARD_defconfig b/configs/P1020UTM-PC_SDCARD_defconfig index 3285aabfc2..7033744ced 100644 --- a/configs/P1020UTM-PC_SDCARD_defconfig +++ b/configs/P1020UTM-PC_SDCARD_defconfig @@ -18,6 +18,8 @@ CONFIG_BOOTDELAY=10 CONFIG_BOARD_EARLY_INIT_F=y CONFIG_BOARD_EARLY_INIT_R=y # CONFIG_SPL_FRAMEWORK is not set +# CONFIG_SPL_SKIP_RELOCATE is not set +CONFIG_SPL_RELOC_TEXT_BASE=0xf8f81000 CONFIG_SPL_ENV_SUPPORT=y CONFIG_SPL_I2C_SUPPORT=y CONFIG_SPL_MPC8XXX_INIT_DDR_SUPPORT=y diff --git a/configs/P1021RDB-PC_36BIT_NAND_defconfig b/configs/P1021RDB-PC_36BIT_NAND_defconfig index c0524e75f1..163494ecff 100644 --- a/configs/P1021RDB-PC_36BIT_NAND_defconfig +++ b/configs/P1021RDB-PC_36BIT_NAND_defconfig @@ -17,6 +17,8 @@ CONFIG_BOOTDELAY=10 CONFIG_BOARD_EARLY_INIT_F=y CONFIG_BOARD_EARLY_INIT_R=y # CONFIG_SPL_FRAMEWORK is not set +# CONFIG_SPL_SKIP_RELOCATE is not set +CONFIG_SPL_RELOC_TEXT_BASE=0xf8fbe000 CONFIG_SPL_NAND_SUPPORT=y CONFIG_TPL=y CONFIG_TPL_ENV_SUPPORT=y diff --git a/configs/P1021RDB-PC_36BIT_SDCARD_defconfig b/configs/P1021RDB-PC_36BIT_SDCARD_defconfig index a5bcf76301..0554a042b8 100644 --- a/configs/P1021RDB-PC_36BIT_SDCARD_defconfig +++ b/configs/P1021RDB-PC_36BIT_SDCARD_defconfig @@ -19,6 +19,8 @@ CONFIG_BOOTDELAY=10 CONFIG_BOARD_EARLY_INIT_F=y CONFIG_BOARD_EARLY_INIT_R=y # CONFIG_SPL_FRAMEWORK is not set +# CONFIG_SPL_SKIP_RELOCATE is not set +CONFIG_SPL_RELOC_TEXT_BASE=0xf8f81000 CONFIG_SPL_ENV_SUPPORT=y CONFIG_SPL_I2C_SUPPORT=y CONFIG_SPL_MPC8XXX_INIT_DDR_SUPPORT=y diff --git a/configs/P1021RDB-PC_36BIT_SPIFLASH_defconfig b/configs/P1021RDB-PC_36BIT_SPIFLASH_defconfig index c4160b4066..add996c87d 100644 --- a/configs/P1021RDB-PC_36BIT_SPIFLASH_defconfig +++ b/configs/P1021RDB-PC_36BIT_SPIFLASH_defconfig @@ -20,6 +20,8 @@ CONFIG_BOOTDELAY=10 CONFIG_BOARD_EARLY_INIT_F=y CONFIG_BOARD_EARLY_INIT_R=y # CONFIG_SPL_FRAMEWORK is not set +# CONFIG_SPL_SKIP_RELOCATE is not set +CONFIG_SPL_RELOC_TEXT_BASE=0xf8f81000 CONFIG_SPL_ENV_SUPPORT=y CONFIG_SPL_I2C_SUPPORT=y CONFIG_SPL_MPC8XXX_INIT_DDR_SUPPORT=y diff --git a/configs/P1021RDB-PC_NAND_defconfig b/configs/P1021RDB-PC_NAND_defconfig index 4221812e27..7a63d346f0 100644 --- a/configs/P1021RDB-PC_NAND_defconfig +++ b/configs/P1021RDB-PC_NAND_defconfig @@ -16,6 +16,8 @@ CONFIG_BOOTDELAY=10 CONFIG_BOARD_EARLY_INIT_F=y CONFIG_BOARD_EARLY_INIT_R=y # CONFIG_SPL_FRAMEWORK is not set +# CONFIG_SPL_SKIP_RELOCATE is not set +CONFIG_SPL_RELOC_TEXT_BASE=0xf8fbe000 CONFIG_SPL_NAND_SUPPORT=y CONFIG_TPL=y CONFIG_TPL_ENV_SUPPORT=y diff --git a/configs/P1021RDB-PC_SDCARD_defconfig b/configs/P1021RDB-PC_SDCARD_defconfig index ebd6b4c13d..dea5713b20 100644 --- a/configs/P1021RDB-PC_SDCARD_defconfig +++ b/configs/P1021RDB-PC_SDCARD_defconfig @@ -18,6 +18,8 @@ CONFIG_BOOTDELAY=10 CONFIG_BOARD_EARLY_INIT_F=y CONFIG_BOARD_EARLY_INIT_R=y # CONFIG_SPL_FRAMEWORK is not set +# CONFIG_SPL_SKIP_RELOCATE is not set +CONFIG_SPL_RELOC_TEXT_BASE=0xf8f81000 CONFIG_SPL_ENV_SUPPORT=y CONFIG_SPL_I2C_SUPPORT=y CONFIG_SPL_MPC8XXX_INIT_DDR_SUPPORT=y diff --git a/configs/P1021RDB-PC_SPIFLASH_defconfig b/configs/P1021RDB-PC_SPIFLASH_defconfig index 5ce43841c5..ef6d281a3d 100644 --- a/configs/P1021RDB-PC_SPIFLASH_defconfig +++ b/configs/P1021RDB-PC_SPIFLASH_defconfig @@ -19,6 +19,8 @@ CONFIG_BOOTDELAY=10 CONFIG_BOARD_EARLY_INIT_F=y CONFIG_BOARD_EARLY_INIT_R=y # CONFIG_SPL_FRAMEWORK is not set +# CONFIG_SPL_SKIP_RELOCATE is not set +CONFIG_SPL_RELOC_TEXT_BASE=0xf8f81000 CONFIG_SPL_ENV_SUPPORT=y CONFIG_SPL_I2C_SUPPORT=y CONFIG_SPL_MPC8XXX_INIT_DDR_SUPPORT=y diff --git a/configs/P1022DS_36BIT_NAND_defconfig b/configs/P1022DS_36BIT_NAND_defconfig index e73c54a362..f4d39fc9e2 100644 --- a/configs/P1022DS_36BIT_NAND_defconfig +++ b/configs/P1022DS_36BIT_NAND_defconfig @@ -15,6 +15,8 @@ CONFIG_BOOTDELAY=10 CONFIG_BOARD_EARLY_INIT_F=y CONFIG_BOARD_EARLY_INIT_R=y # CONFIG_SPL_FRAMEWORK is not set +# CONFIG_SPL_SKIP_RELOCATE is not set +CONFIG_SPL_RELOC_TEXT_BASE=0xf8fbe000 CONFIG_SPL_NAND_SUPPORT=y CONFIG_TPL=y CONFIG_TPL_ENV_SUPPORT=y diff --git a/configs/P1022DS_36BIT_SDCARD_defconfig b/configs/P1022DS_36BIT_SDCARD_defconfig index 6a03645373..e7efeb082e 100644 --- a/configs/P1022DS_36BIT_SDCARD_defconfig +++ b/configs/P1022DS_36BIT_SDCARD_defconfig @@ -17,6 +17,8 @@ CONFIG_BOOTDELAY=10 CONFIG_BOARD_EARLY_INIT_F=y CONFIG_BOARD_EARLY_INIT_R=y # CONFIG_SPL_FRAMEWORK is not set +# CONFIG_SPL_SKIP_RELOCATE is not set +CONFIG_SPL_RELOC_TEXT_BASE=0xf8f81000 CONFIG_SPL_ENV_SUPPORT=y CONFIG_SPL_I2C_SUPPORT=y CONFIG_SPL_MPC8XXX_INIT_DDR_SUPPORT=y diff --git a/configs/P1022DS_36BIT_SPIFLASH_defconfig b/configs/P1022DS_36BIT_SPIFLASH_defconfig index aa6640c6ca..2f32190946 100644 --- a/configs/P1022DS_36BIT_SPIFLASH_defconfig +++ b/configs/P1022DS_36BIT_SPIFLASH_defconfig @@ -18,6 +18,8 @@ CONFIG_BOOTDELAY=10 CONFIG_BOARD_EARLY_INIT_F=y CONFIG_BOARD_EARLY_INIT_R=y # CONFIG_SPL_FRAMEWORK is not set +# CONFIG_SPL_SKIP_RELOCATE is not set +CONFIG_SPL_RELOC_TEXT_BASE=0xf8f81000 CONFIG_SPL_ENV_SUPPORT=y CONFIG_SPL_I2C_SUPPORT=y CONFIG_SPL_MPC8XXX_INIT_DDR_SUPPORT=y diff --git a/configs/P1022DS_NAND_defconfig b/configs/P1022DS_NAND_defconfig index 7d25d55986..a6ad17b5d7 100644 --- a/configs/P1022DS_NAND_defconfig +++ b/configs/P1022DS_NAND_defconfig @@ -14,6 +14,8 @@ CONFIG_BOOTDELAY=10 CONFIG_BOARD_EARLY_INIT_F=y CONFIG_BOARD_EARLY_INIT_R=y # CONFIG_SPL_FRAMEWORK is not set +# CONFIG_SPL_SKIP_RELOCATE is not set +CONFIG_SPL_RELOC_TEXT_BASE=0xf8fbe000 CONFIG_SPL_NAND_SUPPORT=y CONFIG_TPL=y CONFIG_TPL_ENV_SUPPORT=y diff --git a/configs/P1022DS_SDCARD_defconfig b/configs/P1022DS_SDCARD_defconfig index cf90121f9d..465153e26a 100644 --- a/configs/P1022DS_SDCARD_defconfig +++ b/configs/P1022DS_SDCARD_defconfig @@ -16,6 +16,8 @@ CONFIG_BOOTDELAY=10 CONFIG_BOARD_EARLY_INIT_F=y CONFIG_BOARD_EARLY_INIT_R=y # CONFIG_SPL_FRAMEWORK is not set +# CONFIG_SPL_SKIP_RELOCATE is not set +CONFIG_SPL_RELOC_TEXT_BASE=0xf8f81000 CONFIG_SPL_ENV_SUPPORT=y CONFIG_SPL_I2C_SUPPORT=y CONFIG_SPL_MPC8XXX_INIT_DDR_SUPPORT=y diff --git a/configs/P1022DS_SPIFLASH_defconfig b/configs/P1022DS_SPIFLASH_defconfig index 81421c93bf..cb6ea46680 100644 --- a/configs/P1022DS_SPIFLASH_defconfig +++ b/configs/P1022DS_SPIFLASH_defconfig @@ -17,6 +17,8 @@ CONFIG_BOOTDELAY=10 CONFIG_BOARD_EARLY_INIT_F=y CONFIG_BOARD_EARLY_INIT_R=y # CONFIG_SPL_FRAMEWORK is not set +# CONFIG_SPL_SKIP_RELOCATE is not set +CONFIG_SPL_RELOC_TEXT_BASE=0xf8f81000 CONFIG_SPL_ENV_SUPPORT=y CONFIG_SPL_I2C_SUPPORT=y CONFIG_SPL_MPC8XXX_INIT_DDR_SUPPORT=y diff --git a/configs/P1024RDB_NAND_defconfig b/configs/P1024RDB_NAND_defconfig index 4eabadf8ac..0b40c1996c 100644 --- a/configs/P1024RDB_NAND_defconfig +++ b/configs/P1024RDB_NAND_defconfig @@ -16,6 +16,8 @@ CONFIG_BOOTDELAY=10 CONFIG_BOARD_EARLY_INIT_F=y CONFIG_BOARD_EARLY_INIT_R=y # CONFIG_SPL_FRAMEWORK is not set +# CONFIG_SPL_SKIP_RELOCATE is not set +CONFIG_SPL_RELOC_TEXT_BASE=0xf8fbe000 CONFIG_SPL_NAND_SUPPORT=y CONFIG_TPL=y CONFIG_TPL_ENV_SUPPORT=y diff --git a/configs/P1024RDB_SDCARD_defconfig b/configs/P1024RDB_SDCARD_defconfig index 3e35df07fc..0313d7a7a6 100644 --- a/configs/P1024RDB_SDCARD_defconfig +++ b/configs/P1024RDB_SDCARD_defconfig @@ -18,6 +18,8 @@ CONFIG_BOOTDELAY=10 CONFIG_BOARD_EARLY_INIT_F=y CONFIG_BOARD_EARLY_INIT_R=y # CONFIG_SPL_FRAMEWORK is not set +# CONFIG_SPL_SKIP_RELOCATE is not set +CONFIG_SPL_RELOC_TEXT_BASE=0xf8f81000 CONFIG_SPL_ENV_SUPPORT=y CONFIG_SPL_I2C_SUPPORT=y CONFIG_SPL_MPC8XXX_INIT_DDR_SUPPORT=y diff --git a/configs/P1024RDB_SPIFLASH_defconfig b/configs/P1024RDB_SPIFLASH_defconfig index 5e92ce1227..9a747db3d0 100644 --- a/configs/P1024RDB_SPIFLASH_defconfig +++ b/configs/P1024RDB_SPIFLASH_defconfig @@ -19,6 +19,8 @@ CONFIG_BOOTDELAY=10 CONFIG_BOARD_EARLY_INIT_F=y CONFIG_BOARD_EARLY_INIT_R=y # CONFIG_SPL_FRAMEWORK is not set +# CONFIG_SPL_SKIP_RELOCATE is not set +CONFIG_SPL_RELOC_TEXT_BASE=0xf8f81000 CONFIG_SPL_ENV_SUPPORT=y CONFIG_SPL_I2C_SUPPORT=y CONFIG_SPL_MPC8XXX_INIT_DDR_SUPPORT=y diff --git a/configs/P1025RDB_NAND_defconfig b/configs/P1025RDB_NAND_defconfig index 2670cf1e7b..b75a187103 100644 --- a/configs/P1025RDB_NAND_defconfig +++ b/configs/P1025RDB_NAND_defconfig @@ -16,6 +16,8 @@ CONFIG_BOOTDELAY=10 CONFIG_BOARD_EARLY_INIT_F=y CONFIG_BOARD_EARLY_INIT_R=y # CONFIG_SPL_FRAMEWORK is not set +# CONFIG_SPL_SKIP_RELOCATE is not set +CONFIG_SPL_RELOC_TEXT_BASE=0xf8fbe000 CONFIG_SPL_NAND_SUPPORT=y CONFIG_TPL=y CONFIG_TPL_ENV_SUPPORT=y diff --git a/configs/P1025RDB_SDCARD_defconfig b/configs/P1025RDB_SDCARD_defconfig index fec3ac8c15..076c0f3ae8 100644 --- a/configs/P1025RDB_SDCARD_defconfig +++ b/configs/P1025RDB_SDCARD_defconfig @@ -18,6 +18,8 @@ CONFIG_BOOTDELAY=10 CONFIG_BOARD_EARLY_INIT_F=y CONFIG_BOARD_EARLY_INIT_R=y # CONFIG_SPL_FRAMEWORK is not set +# CONFIG_SPL_SKIP_RELOCATE is not set +CONFIG_SPL_RELOC_TEXT_BASE=0xf8f81000 CONFIG_SPL_ENV_SUPPORT=y CONFIG_SPL_I2C_SUPPORT=y CONFIG_SPL_MPC8XXX_INIT_DDR_SUPPORT=y diff --git a/configs/P1025RDB_SPIFLASH_defconfig b/configs/P1025RDB_SPIFLASH_defconfig index f8c6486b52..52221e0b61 100644 --- a/configs/P1025RDB_SPIFLASH_defconfig +++ b/configs/P1025RDB_SPIFLASH_defconfig @@ -19,6 +19,8 @@ CONFIG_BOOTDELAY=10 CONFIG_BOARD_EARLY_INIT_F=y CONFIG_BOARD_EARLY_INIT_R=y # CONFIG_SPL_FRAMEWORK is not set +# CONFIG_SPL_SKIP_RELOCATE is not set +CONFIG_SPL_RELOC_TEXT_BASE=0xf8f81000 CONFIG_SPL_ENV_SUPPORT=y CONFIG_SPL_I2C_SUPPORT=y CONFIG_SPL_MPC8XXX_INIT_DDR_SUPPORT=y diff --git a/configs/P2020RDB-PC_36BIT_NAND_defconfig b/configs/P2020RDB-PC_36BIT_NAND_defconfig index ea80231de0..b4c15d76d5 100644 --- a/configs/P2020RDB-PC_36BIT_NAND_defconfig +++ b/configs/P2020RDB-PC_36BIT_NAND_defconfig @@ -17,6 +17,8 @@ CONFIG_BOOTDELAY=10 CONFIG_BOARD_EARLY_INIT_F=y CONFIG_BOARD_EARLY_INIT_R=y # CONFIG_SPL_FRAMEWORK is not set +# CONFIG_SPL_SKIP_RELOCATE is not set +CONFIG_SPL_RELOC_TEXT_BASE=0xf8ffe000 CONFIG_SPL_NAND_SUPPORT=y CONFIG_TPL=y CONFIG_TPL_ENV_SUPPORT=y diff --git a/configs/P2020RDB-PC_36BIT_SDCARD_defconfig b/configs/P2020RDB-PC_36BIT_SDCARD_defconfig index 7f0d3f80cf..7c6ddbc929 100644 --- a/configs/P2020RDB-PC_36BIT_SDCARD_defconfig +++ b/configs/P2020RDB-PC_36BIT_SDCARD_defconfig @@ -19,6 +19,8 @@ CONFIG_BOOTDELAY=10 CONFIG_BOARD_EARLY_INIT_F=y CONFIG_BOARD_EARLY_INIT_R=y # CONFIG_SPL_FRAMEWORK is not set +# CONFIG_SPL_SKIP_RELOCATE is not set +CONFIG_SPL_RELOC_TEXT_BASE=0xf8f81000 CONFIG_SPL_ENV_SUPPORT=y CONFIG_SPL_I2C_SUPPORT=y CONFIG_SPL_MPC8XXX_INIT_DDR_SUPPORT=y diff --git a/configs/P2020RDB-PC_36BIT_SPIFLASH_defconfig b/configs/P2020RDB-PC_36BIT_SPIFLASH_defconfig index ad0c7cc750..b18e96c050 100644 --- a/configs/P2020RDB-PC_36BIT_SPIFLASH_defconfig +++ b/configs/P2020RDB-PC_36BIT_SPIFLASH_defconfig @@ -20,6 +20,8 @@ CONFIG_BOOTDELAY=10 CONFIG_BOARD_EARLY_INIT_F=y CONFIG_BOARD_EARLY_INIT_R=y # CONFIG_SPL_FRAMEWORK is not set +# CONFIG_SPL_SKIP_RELOCATE is not set +CONFIG_SPL_RELOC_TEXT_BASE=0xf8f81000 CONFIG_SPL_ENV_SUPPORT=y CONFIG_SPL_I2C_SUPPORT=y CONFIG_SPL_MPC8XXX_INIT_DDR_SUPPORT=y diff --git a/configs/P2020RDB-PC_NAND_defconfig b/configs/P2020RDB-PC_NAND_defconfig index aeb14c81d9..871d18ede0 100644 --- a/configs/P2020RDB-PC_NAND_defconfig +++ b/configs/P2020RDB-PC_NAND_defconfig @@ -16,6 +16,8 @@ CONFIG_BOOTDELAY=10 CONFIG_BOARD_EARLY_INIT_F=y CONFIG_BOARD_EARLY_INIT_R=y # CONFIG_SPL_FRAMEWORK is not set +# CONFIG_SPL_SKIP_RELOCATE is not set +CONFIG_SPL_RELOC_TEXT_BASE=0xf8ffe000 CONFIG_SPL_NAND_SUPPORT=y CONFIG_TPL=y CONFIG_TPL_ENV_SUPPORT=y diff --git a/configs/P2020RDB-PC_SDCARD_defconfig b/configs/P2020RDB-PC_SDCARD_defconfig index a2bdcc22bb..b96281716b 100644 --- a/configs/P2020RDB-PC_SDCARD_defconfig +++ b/configs/P2020RDB-PC_SDCARD_defconfig @@ -18,6 +18,8 @@ CONFIG_BOOTDELAY=10 CONFIG_BOARD_EARLY_INIT_F=y CONFIG_BOARD_EARLY_INIT_R=y # CONFIG_SPL_FRAMEWORK is not set +# CONFIG_SPL_SKIP_RELOCATE is not set +CONFIG_SPL_RELOC_TEXT_BASE=0xf8f81000 CONFIG_SPL_ENV_SUPPORT=y CONFIG_SPL_I2C_SUPPORT=y CONFIG_SPL_MPC8XXX_INIT_DDR_SUPPORT=y diff --git a/configs/P2020RDB-PC_SPIFLASH_defconfig b/configs/P2020RDB-PC_SPIFLASH_defconfig index df72a7d49c..0d27892393 100644 --- a/configs/P2020RDB-PC_SPIFLASH_defconfig +++ b/configs/P2020RDB-PC_SPIFLASH_defconfig @@ -19,6 +19,8 @@ CONFIG_BOOTDELAY=10 CONFIG_BOARD_EARLY_INIT_F=y CONFIG_BOARD_EARLY_INIT_R=y # CONFIG_SPL_FRAMEWORK is not set +# CONFIG_SPL_SKIP_RELOCATE is not set +CONFIG_SPL_RELOC_TEXT_BASE=0xf8f81000 CONFIG_SPL_ENV_SUPPORT=y CONFIG_SPL_I2C_SUPPORT=y CONFIG_SPL_MPC8XXX_INIT_DDR_SUPPORT=y diff --git a/include/configs/BSC9131RDB.h b/include/configs/BSC9131RDB.h index c01071e60d..f76120ad7d 100644 --- a/include/configs/BSC9131RDB.h +++ b/include/configs/BSC9131RDB.h @@ -26,7 +26,6 @@ #define CONFIG_SPL_TEXT_BASE 0xFFFFE000 #define CONFIG_SPL_MAX_SIZE 8192 -#define CONFIG_SPL_RELOC_TEXT_BASE 0x00100000 #define CONFIG_SPL_RELOC_STACK 0x00100000 #define CONFIG_SYS_NAND_U_BOOT_SIZE ((768 << 10) - 0x2000) #define CONFIG_SYS_NAND_U_BOOT_DST (0x00200000 - CONFIG_SPL_MAX_SIZE) diff --git a/include/configs/BSC9132QDS.h b/include/configs/BSC9132QDS.h index 68100f1d52..a6ee178157 100644 --- a/include/configs/BSC9132QDS.h +++ b/include/configs/BSC9132QDS.h @@ -34,7 +34,6 @@ #define CONFIG_SPL_TEXT_BASE 0xFFFFE000 #define CONFIG_SPL_MAX_SIZE 8192 -#define CONFIG_SPL_RELOC_TEXT_BASE 0x00100000 #define CONFIG_SPL_RELOC_STACK 0x00100000 #define CONFIG_SYS_NAND_U_BOOT_SIZE ((768 << 10) - 0x2000) #define CONFIG_SYS_NAND_U_BOOT_DST (0x00200000 - CONFIG_SPL_MAX_SIZE) diff --git a/include/configs/C29XPCIE.h b/include/configs/C29XPCIE.h index 9b83a50fdf..84afb00925 100644 --- a/include/configs/C29XPCIE.h +++ b/include/configs/C29XPCIE.h @@ -299,7 +299,6 @@ #define CONFIG_SYS_INIT_L2_ADDR_PHYS CONFIG_SYS_INIT_L2_ADDR #define CONFIG_SYS_L2_SIZE (256 << 10) #define CONFIG_SYS_INIT_L2_END (CONFIG_SYS_INIT_L2_ADDR + CONFIG_SYS_L2_SIZE) -#define CONFIG_SPL_RELOC_TEXT_BASE 0xf8f81000 #define CONFIG_SPL_RELOC_STACK (CONFIG_SYS_INIT_L2_ADDR + 128 * 1024) #define CONFIG_SPL_RELOC_MALLOC_ADDR (CONFIG_SYS_INIT_L2_ADDR + 160 * 1024) #define CONFIG_SPL_RELOC_MALLOC_SIZE (96 << 10) @@ -310,7 +309,6 @@ #define CONFIG_SYS_INIT_L2_ADDR_PHYS CONFIG_SYS_INIT_L2_ADDR #define CONFIG_SYS_L2_SIZE (256 << 10) #define CONFIG_SYS_INIT_L2_END (CONFIG_SYS_INIT_L2_ADDR + CONFIG_SYS_L2_SIZE) -#define CONFIG_SPL_RELOC_TEXT_BASE 0xf8f81000 #define CONFIG_SPL_RELOC_STACK (CONFIG_SYS_INIT_L2_ADDR + 192 * 1024) #define CONFIG_SPL_RELOC_MALLOC_ADDR (CONFIG_SYS_INIT_L2_ADDR + 208 * 1024) #define CONFIG_SPL_RELOC_MALLOC_SIZE (48 << 10) @@ -320,7 +318,6 @@ #define CONFIG_SYS_INIT_L2_ADDR_PHYS CONFIG_SYS_INIT_L2_ADDR #define CONFIG_SYS_L2_SIZE (256 << 10) #define CONFIG_SYS_INIT_L2_END (CONFIG_SYS_INIT_L2_ADDR + CONFIG_SYS_L2_SIZE) -#define CONFIG_SPL_RELOC_TEXT_BASE (CONFIG_SYS_INIT_L2_END - 0x3000) #define CONFIG_SPL_RELOC_STACK ((CONFIG_SYS_INIT_L2_END - 1) & ~0xF) #endif #endif diff --git a/include/configs/P1010RDB.h b/include/configs/P1010RDB.h index 4be40d0d02..47eb945ad9 100644 --- a/include/configs/P1010RDB.h +++ b/include/configs/P1010RDB.h @@ -64,7 +64,6 @@ #define CONFIG_SPL_TEXT_BASE 0xFFFFE000 #define CONFIG_SPL_MAX_SIZE 8192 -#define CONFIG_SPL_RELOC_TEXT_BASE 0x00100000 #define CONFIG_SPL_RELOC_STACK 0x00100000 #define CONFIG_SYS_NAND_U_BOOT_SIZE ((768 << 10) - 0x2000) #define CONFIG_SYS_NAND_U_BOOT_DST (0x00200000 - CONFIG_SPL_MAX_SIZE) @@ -492,7 +491,6 @@ extern unsigned long get_sdram_size(void); #define CONFIG_SYS_INIT_L2_ADDR_PHYS CONFIG_SYS_INIT_L2_ADDR #define CONFIG_SYS_L2_SIZE (256 << 10) #define CONFIG_SYS_INIT_L2_END (CONFIG_SYS_INIT_L2_ADDR + CONFIG_SYS_L2_SIZE) -#define CONFIG_SPL_RELOC_TEXT_BASE 0xD0001000 #define CONFIG_SPL_RELOC_STACK (CONFIG_SYS_INIT_L2_ADDR + 112 * 1024) #define CONFIG_SPL_RELOC_MALLOC_ADDR (CONFIG_SYS_INIT_L2_ADDR + 128 * 1024) #define CONFIG_SPL_RELOC_MALLOC_SIZE (128 << 10) @@ -503,7 +501,6 @@ extern unsigned long get_sdram_size(void); #define CONFIG_SYS_INIT_L2_ADDR_PHYS CONFIG_SYS_INIT_L2_ADDR #define CONFIG_SYS_L2_SIZE (256 << 10) #define CONFIG_SYS_INIT_L2_END (CONFIG_SYS_INIT_L2_ADDR + CONFIG_SYS_L2_SIZE) -#define CONFIG_SPL_RELOC_TEXT_BASE 0xD0001000 #define CONFIG_SPL_RELOC_STACK (CONFIG_SYS_INIT_L2_ADDR + 192 * 1024) #define CONFIG_SPL_RELOC_MALLOC_ADDR (CONFIG_SYS_INIT_L2_ADDR + 208 * 1024) #define CONFIG_SPL_RELOC_MALLOC_SIZE (48 << 10) @@ -513,7 +510,6 @@ extern unsigned long get_sdram_size(void); #define CONFIG_SYS_INIT_L2_ADDR_PHYS CONFIG_SYS_INIT_L2_ADDR #define CONFIG_SYS_L2_SIZE (256 << 10) #define CONFIG_SYS_INIT_L2_END (CONFIG_SYS_INIT_L2_ADDR + CONFIG_SYS_L2_SIZE) -#define CONFIG_SPL_RELOC_TEXT_BASE (CONFIG_SYS_INIT_L2_END - 0x3000) #define CONFIG_SPL_RELOC_STACK ((CONFIG_SYS_INIT_L2_END - 1) & ~0xF) #endif #endif diff --git a/include/configs/P1022DS.h b/include/configs/P1022DS.h index bdbf119c32..d903cc3834 100644 --- a/include/configs/P1022DS.h +++ b/include/configs/P1022DS.h @@ -303,7 +303,6 @@ #define CONFIG_SYS_INIT_L2_ADDR_PHYS CONFIG_SYS_INIT_L2_ADDR #define CONFIG_SYS_L2_SIZE (256 << 10) #define CONFIG_SYS_INIT_L2_END (CONFIG_SYS_INIT_L2_ADDR + CONFIG_SYS_L2_SIZE) -#define CONFIG_SPL_RELOC_TEXT_BASE 0xf8f81000 #define CONFIG_SPL_RELOC_STACK (CONFIG_SYS_INIT_L2_ADDR + 116 * 1024) #define CONFIG_SPL_RELOC_MALLOC_ADDR (CONFIG_SYS_INIT_L2_ADDR + 148 * 1024) #define CONFIG_SPL_RELOC_MALLOC_SIZE (108 << 10) @@ -314,7 +313,6 @@ #define CONFIG_SYS_INIT_L2_ADDR_PHYS CONFIG_SYS_INIT_L2_ADDR #define CONFIG_SYS_L2_SIZE (256 << 10) #define CONFIG_SYS_INIT_L2_END (CONFIG_SYS_INIT_L2_ADDR + CONFIG_SYS_L2_SIZE) -#define CONFIG_SPL_RELOC_TEXT_BASE 0xf8f81000 #define CONFIG_SPL_RELOC_STACK (CONFIG_SYS_INIT_L2_ADDR + 192 * 1024) #define CONFIG_SPL_RELOC_MALLOC_ADDR (CONFIG_SYS_INIT_L2_ADDR + 208 * 1024) #define CONFIG_SPL_RELOC_MALLOC_SIZE (48 << 10) @@ -324,7 +322,6 @@ #define CONFIG_SYS_INIT_L2_ADDR_PHYS CONFIG_SYS_INIT_L2_ADDR #define CONFIG_SYS_L2_SIZE (256 << 10) #define CONFIG_SYS_INIT_L2_END (CONFIG_SYS_INIT_L2_ADDR + CONFIG_SYS_L2_SIZE) -#define CONFIG_SPL_RELOC_TEXT_BASE (CONFIG_SYS_INIT_L2_END - 0x2000) #define CONFIG_SPL_RELOC_STACK ((CONFIG_SYS_INIT_L2_END - 1) & ~0xF) #endif #endif diff --git a/include/configs/p1_p2_rdb_pc.h b/include/configs/p1_p2_rdb_pc.h index 8fa91fb81d..f9572af121 100644 --- a/include/configs/p1_p2_rdb_pc.h +++ b/include/configs/p1_p2_rdb_pc.h @@ -503,7 +503,6 @@ #define CONFIG_SYS_INIT_L2_ADDR 0xf8f80000 #define CONFIG_SYS_INIT_L2_ADDR_PHYS CONFIG_SYS_INIT_L2_ADDR #define CONFIG_SYS_INIT_L2_END (CONFIG_SYS_INIT_L2_ADDR + CONFIG_SYS_L2_SIZE) -#define CONFIG_SPL_RELOC_TEXT_BASE 0xf8f81000 #define CONFIG_SPL_GD_ADDR (CONFIG_SYS_INIT_L2_ADDR + 112 * 1024) #define CONFIG_SPL_RELOC_STACK (CONFIG_SYS_INIT_L2_ADDR + 116 * 1024) #define CONFIG_SPL_RELOC_MALLOC_ADDR (CONFIG_SYS_INIT_L2_ADDR + 148 * 1024) @@ -517,7 +516,6 @@ #define CONFIG_SYS_INIT_L2_ADDR 0xf8f80000 #define CONFIG_SYS_INIT_L2_ADDR_PHYS CONFIG_SYS_INIT_L2_ADDR #define CONFIG_SYS_INIT_L2_END (CONFIG_SYS_INIT_L2_ADDR + CONFIG_SYS_L2_SIZE) -#define CONFIG_SPL_RELOC_TEXT_BASE 0xf8f81000 #define CONFIG_SPL_RELOC_STACK (CONFIG_SYS_INIT_L2_ADDR + 192 * 1024) #define CONFIG_SPL_RELOC_MALLOC_ADDR (CONFIG_SYS_INIT_L2_ADDR + 208 * 1024) #define CONFIG_SPL_RELOC_MALLOC_SIZE (48 << 10) @@ -526,7 +524,6 @@ #define CONFIG_SYS_INIT_L2_ADDR 0xf8f80000 #define CONFIG_SYS_INIT_L2_ADDR_PHYS CONFIG_SYS_INIT_L2_ADDR #define CONFIG_SYS_INIT_L2_END (CONFIG_SYS_INIT_L2_ADDR + CONFIG_SYS_L2_SIZE) -#define CONFIG_SPL_RELOC_TEXT_BASE (CONFIG_SYS_INIT_L2_END - 0x2000) #define CONFIG_SPL_RELOC_STACK ((CONFIG_SYS_INIT_L2_END - 1) & ~0xF) #endif /* CONFIG_TPL_BUILD */ #endif -- 2.17.1 ^ permalink raw reply related [flat|nested] 25+ messages in thread
* [U-Boot] [PATCH v2 2/3] spl: add relocation support 2019-05-16 12:19 [U-Boot] [PATCH v2 0/3] Enable spl relocation on arm Andy Yan 2019-05-16 12:21 ` [U-Boot] [PATCH v2 1/3] powerpc: Convert CONFIG_SPL_RELOC_TEXT_BASE to Kconfig Andy Yan @ 2019-05-16 12:21 ` Andy Yan 2019-05-17 8:34 ` Lukasz Majewski 2019-05-18 16:26 ` Simon Glass 2019-05-16 12:22 ` [U-Boot] [PATCH v2 3/3] arm: add spl relocation support for arm Andy Yan 2 siblings, 2 replies; 25+ messages in thread From: Andy Yan @ 2019-05-16 12:21 UTC (permalink / raw) To: u-boot Some times we want to relocate spl code to dram after dram initialization or relocate spl code to a high memory to avoid code overid. For example on Rockchip armv8 platform, we run with boot flow TPL->SPL->ATF->U-Boot. TPL run in sram and is responsible for dram initialization. SPL run from the start address of dram and is responsible for loading ATF and U-Boot. The case here is that the ATF load address is from 64KB of dram, which overlaps with spl code itself. So we want to relocate spl itself to high memory to aovid this. Signed-off-by: Andy Yan <andy.yan@rock-chips.com> --- Changes in v2: - Move Kconfig modification to PATCH 1/3 common/spl/spl.c | 55 ++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 55 insertions(+) diff --git a/common/spl/spl.c b/common/spl/spl.c index 88d4b8a9bf..affb65ccbd 100644 --- a/common/spl/spl.c +++ b/common/spl/spl.c @@ -12,6 +12,7 @@ #include <dm.h> #include <handoff.h> #include <spl.h> +#include <asm/sections.h> #include <asm/u-boot.h> #include <nand.h> #include <fat.h> @@ -439,6 +440,28 @@ static int spl_common_init(bool setup_malloc) return 0; } +#if !defined(CONFIG_SPL_SKIP_RELOCATE) && !defined(CONFIG_TPL_BUILD) +static void spl_setup_relocate(void) +{ + gd->relocaddr = CONFIG_SPL_RELOC_TEXT_BASE; + gd->new_gd = (gd_t *)gd; + gd->start_addr_sp = gd->relocaddr; + gd->fdt_size = ALIGN(fdt_totalsize(gd->fdt_blob) + 0x1000, 32); + + gd->start_addr_sp -= gd->fdt_size; + gd->new_fdt = (void *)gd->start_addr_sp; + memcpy(gd->new_fdt, gd->fdt_blob, gd->fdt_size); + gd->fdt_blob = gd->new_fdt; + + gd->reloc_off = gd->relocaddr - (unsigned long)__image_copy_start; +} +#else +static void spl_setup_relocate(void) +{ + +} +#endif + void spl_set_bd(void) { /* @@ -460,6 +483,8 @@ int spl_early_init(void) return ret; gd->flags |= GD_FLG_SPL_EARLY_INIT; + spl_setup_relocate(); + return 0; } @@ -563,6 +588,34 @@ static int boot_from_devices(struct spl_image_info *spl_image, return -ENODEV; } +#if defined(CONFIG_DM) && !defined(CONFIG_SPL_SKIP_RELOCATE) && !defined(CONFIG_TPL_BUILD) +static int spl_initr_dm(void) +{ + int ret; + + /* Save the pre-reloc driver model and start a new one */ + gd->dm_root_f = gd->dm_root; + gd->dm_root = NULL; + bootstage_start(BOOTSTATE_ID_ACCUM_DM_R, "dm_r"); + ret = dm_init_and_scan(false); + bootstage_accum(BOOTSTATE_ID_ACCUM_DM_R); + if (ret) + return ret; + +#if defined(CONFIG_TIMER) + gd->timer = NULL; +#endif + serial_init(); + + return 0; +} +#else +static int spl_initr_dm(void) +{ + return 0; +} +#endif + void board_init_r(gd_t *dummy1, ulong dummy2) { u32 spl_boot_list[] = { @@ -577,6 +630,8 @@ void board_init_r(gd_t *dummy1, ulong dummy2) debug(">>" SPL_TPL_PROMPT "board_init_r()\n"); + spl_initr_dm(); + spl_set_bd(); #if defined(CONFIG_SYS_SPL_MALLOC_START) -- 2.17.1 ^ permalink raw reply related [flat|nested] 25+ messages in thread
* [U-Boot] [PATCH v2 2/3] spl: add relocation support 2019-05-16 12:21 ` [U-Boot] [PATCH v2 2/3] spl: add relocation support Andy Yan @ 2019-05-17 8:34 ` Lukasz Majewski 2019-05-17 9:03 ` Andy Yan 2019-05-18 16:26 ` Simon Glass 1 sibling, 1 reply; 25+ messages in thread From: Lukasz Majewski @ 2019-05-17 8:34 UTC (permalink / raw) To: u-boot On Thu, 16 May 2019 20:21:50 +0800 Andy Yan <andy.yan@rock-chips.com> wrote: > Some times we want to relocate spl code to dram after dram > initialization or relocate spl code to a high memory to avoid > code overid. > > For example on Rockchip armv8 platform, we run with boot flow > TPL->SPL->ATF->U-Boot. > TPL run in sram and is responsible for dram initialization. > SPL run from the start address of dram and is responsible for > loading ATF and U-Boot. > > The case here is that the ATF load address is from 64KB of dram, > which overlaps with spl code itself. > > So we want to relocate spl itself to high memory to aovid this. > > Signed-off-by: Andy Yan <andy.yan@rock-chips.com> > --- > > Changes in v2: > - Move Kconfig modification to PATCH 1/3 > > common/spl/spl.c | 55 > ++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 55 > insertions(+) > > diff --git a/common/spl/spl.c b/common/spl/spl.c > index 88d4b8a9bf..affb65ccbd 100644 > --- a/common/spl/spl.c > +++ b/common/spl/spl.c > @@ -12,6 +12,7 @@ > #include <dm.h> > #include <handoff.h> > #include <spl.h> > +#include <asm/sections.h> > #include <asm/u-boot.h> > #include <nand.h> > #include <fat.h> > @@ -439,6 +440,28 @@ static int spl_common_init(bool setup_malloc) > return 0; > } > > +#if !defined(CONFIG_SPL_SKIP_RELOCATE) && !defined(CONFIG_TPL_BUILD) > +static void spl_setup_relocate(void) > +{ > + gd->relocaddr = CONFIG_SPL_RELOC_TEXT_BASE; > + gd->new_gd = (gd_t *)gd; > + gd->start_addr_sp = gd->relocaddr; > + gd->fdt_size = ALIGN(fdt_totalsize(gd->fdt_blob) + 0x1000, > 32); + What is the purpose of 0x1000 magic number? Could it be described in some way (in-code comment, #define, etc) ? > + gd->start_addr_sp -= gd->fdt_size; > + gd->new_fdt = (void *)gd->start_addr_sp; > + memcpy(gd->new_fdt, gd->fdt_blob, gd->fdt_size); > + gd->fdt_blob = gd->new_fdt; > + > + gd->reloc_off = gd->relocaddr - (unsigned > long)__image_copy_start; +} > +#else > +static void spl_setup_relocate(void) > +{ > + > +} > +#endif > + > void spl_set_bd(void) > { > /* > @@ -460,6 +483,8 @@ int spl_early_init(void) > return ret; > gd->flags |= GD_FLG_SPL_EARLY_INIT; > > + spl_setup_relocate(); > + > return 0; > } > > @@ -563,6 +588,34 @@ static int boot_from_devices(struct > spl_image_info *spl_image, return -ENODEV; > } > > +#if defined(CONFIG_DM) && !defined(CONFIG_SPL_SKIP_RELOCATE) > && !defined(CONFIG_TPL_BUILD) +static int spl_initr_dm(void) > +{ > + int ret; > + > + /* Save the pre-reloc driver model and start a new one */ > + gd->dm_root_f = gd->dm_root; > + gd->dm_root = NULL; > + bootstage_start(BOOTSTATE_ID_ACCUM_DM_R, "dm_r"); > + ret = dm_init_and_scan(false); > + bootstage_accum(BOOTSTATE_ID_ACCUM_DM_R); > + if (ret) > + return ret; > + > +#if defined(CONFIG_TIMER) > + gd->timer = NULL; > +#endif > + serial_init(); > + > + return 0; > +} > +#else > +static int spl_initr_dm(void) > +{ > + return 0; > +} > +#endif > + > void board_init_r(gd_t *dummy1, ulong dummy2) > { > u32 spl_boot_list[] = { > @@ -577,6 +630,8 @@ void board_init_r(gd_t *dummy1, ulong dummy2) > > debug(">>" SPL_TPL_PROMPT "board_init_r()\n"); > > + spl_initr_dm(); > + > spl_set_bd(); > > #if defined(CONFIG_SYS_SPL_MALLOC_START) Best regards, Lukasz Majewski -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lukma at denx.de -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: <http://lists.denx.de/pipermail/u-boot/attachments/20190517/d51d5c9e/attachment.sig> ^ permalink raw reply [flat|nested] 25+ messages in thread
* [U-Boot] [PATCH v2 2/3] spl: add relocation support 2019-05-17 8:34 ` Lukasz Majewski @ 2019-05-17 9:03 ` Andy Yan 0 siblings, 0 replies; 25+ messages in thread From: Andy Yan @ 2019-05-17 9:03 UTC (permalink / raw) To: u-boot Hi Lukasz: On 2019/5/17 下午4:34, Lukasz Majewski wrote: > On Thu, 16 May 2019 20:21:50 +0800 > Andy Yan <andy.yan@rock-chips.com> wrote: > >> Some times we want to relocate spl code to dram after dram >> initialization or relocate spl code to a high memory to avoid >> code overid. >> >> For example on Rockchip armv8 platform, we run with boot flow >> TPL->SPL->ATF->U-Boot. >> TPL run in sram and is responsible for dram initialization. >> SPL run from the start address of dram and is responsible for >> loading ATF and U-Boot. >> >> The case here is that the ATF load address is from 64KB of dram, >> which overlaps with spl code itself. >> >> So we want to relocate spl itself to high memory to aovid this. >> >> Signed-off-by: Andy Yan <andy.yan@rock-chips.com> >> --- >> >> Changes in v2: >> - Move Kconfig modification to PATCH 1/3 >> >> common/spl/spl.c | 55 >> ++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 55 >> insertions(+) >> >> diff --git a/common/spl/spl.c b/common/spl/spl.c >> index 88d4b8a9bf..affb65ccbd 100644 >> --- a/common/spl/spl.c >> +++ b/common/spl/spl.c >> @@ -12,6 +12,7 @@ >> #include <dm.h> >> #include <handoff.h> >> #include <spl.h> >> +#include <asm/sections.h> >> #include <asm/u-boot.h> >> #include <nand.h> >> #include <fat.h> >> @@ -439,6 +440,28 @@ static int spl_common_init(bool setup_malloc) >> return 0; >> } >> >> +#if !defined(CONFIG_SPL_SKIP_RELOCATE) && !defined(CONFIG_TPL_BUILD) >> +static void spl_setup_relocate(void) >> +{ >> + gd->relocaddr = CONFIG_SPL_RELOC_TEXT_BASE; >> + gd->new_gd = (gd_t *)gd; >> + gd->start_addr_sp = gd->relocaddr; >> + gd->fdt_size = ALIGN(fdt_totalsize(gd->fdt_blob) + 0x1000, >> 32); + > What is the purpose of 0x1000 magic number? Could it be described in > some way (in-code comment, #define, etc) ? > This code is copied from board_f.c, I think is to aligned to 4KB here. >> + gd->start_addr_sp -= gd->fdt_size; >> + gd->new_fdt = (void *)gd->start_addr_sp; >> + memcpy(gd->new_fdt, gd->fdt_blob, gd->fdt_size); >> + gd->fdt_blob = gd->new_fdt; >> + >> + gd->reloc_off = gd->relocaddr - (unsigned >> long)__image_copy_start; +} >> +#else >> +static void spl_setup_relocate(void) >> +{ >> + >> +} >> +#endif >> + >> void spl_set_bd(void) >> { >> /* >> @@ -460,6 +483,8 @@ int spl_early_init(void) >> return ret; >> gd->flags |= GD_FLG_SPL_EARLY_INIT; >> >> + spl_setup_relocate(); >> + >> return 0; >> } >> >> @@ -563,6 +588,34 @@ static int boot_from_devices(struct >> spl_image_info *spl_image, return -ENODEV; >> } >> >> +#if defined(CONFIG_DM) && !defined(CONFIG_SPL_SKIP_RELOCATE) >> && !defined(CONFIG_TPL_BUILD) +static int spl_initr_dm(void) >> +{ >> + int ret; >> + >> + /* Save the pre-reloc driver model and start a new one */ >> + gd->dm_root_f = gd->dm_root; >> + gd->dm_root = NULL; >> + bootstage_start(BOOTSTATE_ID_ACCUM_DM_R, "dm_r"); >> + ret = dm_init_and_scan(false); >> + bootstage_accum(BOOTSTATE_ID_ACCUM_DM_R); >> + if (ret) >> + return ret; >> + >> +#if defined(CONFIG_TIMER) >> + gd->timer = NULL; >> +#endif >> + serial_init(); >> + >> + return 0; >> +} >> +#else >> +static int spl_initr_dm(void) >> +{ >> + return 0; >> +} >> +#endif >> + >> void board_init_r(gd_t *dummy1, ulong dummy2) >> { >> u32 spl_boot_list[] = { >> @@ -577,6 +630,8 @@ void board_init_r(gd_t *dummy1, ulong dummy2) >> >> debug(">>" SPL_TPL_PROMPT "board_init_r()\n"); >> >> + spl_initr_dm(); >> + >> spl_set_bd(); >> >> #if defined(CONFIG_SYS_SPL_MALLOC_START) > > > > Best regards, > > Lukasz Majewski > > -- > > DENX Software Engineering GmbH, Managing Director: Wolfgang Denk > HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany > Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lukma at denx.de ^ permalink raw reply [flat|nested] 25+ messages in thread
* [U-Boot] [PATCH v2 2/3] spl: add relocation support 2019-05-16 12:21 ` [U-Boot] [PATCH v2 2/3] spl: add relocation support Andy Yan 2019-05-17 8:34 ` Lukasz Majewski @ 2019-05-18 16:26 ` Simon Glass 2019-05-20 6:34 ` [U-Boot] [PATCH v2 2/3] spl: add relocation support【请注意，邮件由sjg@google.com代发】 Andy Yan 1 sibling, 1 reply; 25+ messages in thread From: Simon Glass @ 2019-05-18 16:26 UTC (permalink / raw) To: u-boot Hi Andy, Instead of this could you: - move ATF? - change the SPL load address so it is not in the way (since TPL can load to any address) - (in extremis) create a function which does a memmove() and a jump, copy it somewhere and run it (I think x86 does this) Regards, Simon On Thu, 16 May 2019 at 06:22, Andy Yan <andy.yan@rock-chips.com> wrote: > > Some times we want to relocate spl code to dram after dram > initialization or relocate spl code to a high memory to avoid > code overid. > > For example on Rockchip armv8 platform, we run with boot flow > TPL->SPL->ATF->U-Boot. > TPL run in sram and is responsible for dram initialization. > SPL run from the start address of dram and is responsible for > loading ATF and U-Boot. > > The case here is that the ATF load address is from 64KB of dram, > which overlaps with spl code itself. > > So we want to relocate spl itself to high memory to aovid this. > > Signed-off-by: Andy Yan <andy.yan@rock-chips.com> > --- > > Changes in v2: > - Move Kconfig modification to PATCH 1/3 > > common/spl/spl.c | 55 ++++++++++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 55 insertions(+) > > diff --git a/common/spl/spl.c b/common/spl/spl.c > index 88d4b8a9bf..affb65ccbd 100644 > --- a/common/spl/spl.c > +++ b/common/spl/spl.c > @@ -12,6 +12,7 @@ > #include <dm.h> > #include <handoff.h> > #include <spl.h> > +#include <asm/sections.h> > #include <asm/u-boot.h> > #include <nand.h> > #include <fat.h> > @@ -439,6 +440,28 @@ static int spl_common_init(bool setup_malloc) > return 0; > } > > +#if !defined(CONFIG_SPL_SKIP_RELOCATE) && !defined(CONFIG_TPL_BUILD) > +static void spl_setup_relocate(void) > +{ > + gd->relocaddr = CONFIG_SPL_RELOC_TEXT_BASE; > + gd->new_gd = (gd_t *)gd; > + gd->start_addr_sp = gd->relocaddr; > + gd->fdt_size = ALIGN(fdt_totalsize(gd->fdt_blob) + 0x1000, 32); > + > + gd->start_addr_sp -= gd->fdt_size; > + gd->new_fdt = (void *)gd->start_addr_sp; > + memcpy(gd->new_fdt, gd->fdt_blob, gd->fdt_size); > + gd->fdt_blob = gd->new_fdt; > + > + gd->reloc_off = gd->relocaddr - (unsigned long)__image_copy_start; > +} > +#else > +static void spl_setup_relocate(void) > +{ > + > +} > +#endif > + > void spl_set_bd(void) > { > /* > @@ -460,6 +483,8 @@ int spl_early_init(void) > return ret; > gd->flags |= GD_FLG_SPL_EARLY_INIT; > > + spl_setup_relocate(); > + > return 0; > } > > @@ -563,6 +588,34 @@ static int boot_from_devices(struct spl_image_info *spl_image, > return -ENODEV; > } > > +#if defined(CONFIG_DM) && !defined(CONFIG_SPL_SKIP_RELOCATE) && !defined(CONFIG_TPL_BUILD) > +static int spl_initr_dm(void) > +{ > + int ret; > + > + /* Save the pre-reloc driver model and start a new one */ > + gd->dm_root_f = gd->dm_root; > + gd->dm_root = NULL; > + bootstage_start(BOOTSTATE_ID_ACCUM_DM_R, "dm_r"); > + ret = dm_init_and_scan(false); > + bootstage_accum(BOOTSTATE_ID_ACCUM_DM_R); > + if (ret) > + return ret; > + > +#if defined(CONFIG_TIMER) > + gd->timer = NULL; > +#endif > + serial_init(); > + > + return 0; > +} > +#else > +static int spl_initr_dm(void) > +{ > + return 0; > +} > +#endif > + > void board_init_r(gd_t *dummy1, ulong dummy2) > { > u32 spl_boot_list[] = { > @@ -577,6 +630,8 @@ void board_init_r(gd_t *dummy1, ulong dummy2) > > debug(">>" SPL_TPL_PROMPT "board_init_r()\n"); > > + spl_initr_dm(); > + > spl_set_bd(); > > #if defined(CONFIG_SYS_SPL_MALLOC_START) > -- > 2.17.1 > > > ^ permalink raw reply [flat|nested] 25+ messages in thread
* [U-Boot] [PATCH v2 2/3] spl: add relocation support【请注意，邮件由sjg@google.com代发】 2019-05-18 16:26 ` Simon Glass @ 2019-05-20 6:34 ` Andy Yan 2019-05-20 15:35 ` Simon Glass 2019-05-20 15:58 ` Andre Przywara 0 siblings, 2 replies; 25+ messages in thread From: Andy Yan @ 2019-05-20 6:34 UTC (permalink / raw) To: u-boot Hi Simon: On 2019/5/19 上午12:26, Simon Glass wrote: > Hi Andy, > > Instead of this could you: > > - move ATF? All rockchip based arm64 ATF run from the start 64KB of dram as this will give convenient for kernel manage the memory. On the other hand, change the ATF load address will break the compatibility of the exiting firmware. > - change the SPL load address so it is not in the way (since TPL can > load to any address) The SPL is loaded by bootrom after TPL back to bootrom, so the load address if fixed by bootrom code. I know we can build mmc or other storage driver into TPL so we can use tpl load spl on some platform that sram is big enough, but there are also many rockchip soc has very small sram, so we tend to only do dram initialization in tpl, and let bootrom load next stage . > - (in extremis) create a function which does a memmove() and a jump, > copy it somewhere and run it (I think x86 does this) > > Regards, > Simon > > On Thu, 16 May 2019 at 06:22, Andy Yan <andy.yan@rock-chips.com> wrote: >> Some times we want to relocate spl code to dram after dram >> initialization or relocate spl code to a high memory to avoid >> code overid. >> >> For example on Rockchip armv8 platform, we run with boot flow >> TPL->SPL->ATF->U-Boot. >> TPL run in sram and is responsible for dram initialization. >> SPL run from the start address of dram and is responsible for >> loading ATF and U-Boot. >> >> The case here is that the ATF load address is from 64KB of dram, >> which overlaps with spl code itself. >> >> So we want to relocate spl itself to high memory to aovid this. >> >> Signed-off-by: Andy Yan <andy.yan@rock-chips.com> >> --- >> >> Changes in v2: >> - Move Kconfig modification to PATCH 1/3 >> >> common/spl/spl.c | 55 ++++++++++++++++++++++++++++++++++++++++++++++++ >> 1 file changed, 55 insertions(+) >> >> diff --git a/common/spl/spl.c b/common/spl/spl.c >> index 88d4b8a9bf..affb65ccbd 100644 >> --- a/common/spl/spl.c >> +++ b/common/spl/spl.c >> @@ -12,6 +12,7 @@ >> #include <dm.h> >> #include <handoff.h> >> #include <spl.h> >> +#include <asm/sections.h> >> #include <asm/u-boot.h> >> #include <nand.h> >> #include <fat.h> >> @@ -439,6 +440,28 @@ static int spl_common_init(bool setup_malloc) >> return 0; >> } >> >> +#if !defined(CONFIG_SPL_SKIP_RELOCATE) && !defined(CONFIG_TPL_BUILD) >> +static void spl_setup_relocate(void) >> +{ >> + gd->relocaddr = CONFIG_SPL_RELOC_TEXT_BASE; >> + gd->new_gd = (gd_t *)gd; >> + gd->start_addr_sp = gd->relocaddr; >> + gd->fdt_size = ALIGN(fdt_totalsize(gd->fdt_blob) + 0x1000, 32); >> + >> + gd->start_addr_sp -= gd->fdt_size; >> + gd->new_fdt = (void *)gd->start_addr_sp; >> + memcpy(gd->new_fdt, gd->fdt_blob, gd->fdt_size); >> + gd->fdt_blob = gd->new_fdt; >> + >> + gd->reloc_off = gd->relocaddr - (unsigned long)__image_copy_start; >> +} >> +#else >> +static void spl_setup_relocate(void) >> +{ >> + >> +} >> +#endif >> + >> void spl_set_bd(void) >> { >> /* >> @@ -460,6 +483,8 @@ int spl_early_init(void) >> return ret; >> gd->flags |= GD_FLG_SPL_EARLY_INIT; >> >> + spl_setup_relocate(); >> + >> return 0; >> } >> >> @@ -563,6 +588,34 @@ static int boot_from_devices(struct spl_image_info *spl_image, >> return -ENODEV; >> } >> >> +#if defined(CONFIG_DM) && !defined(CONFIG_SPL_SKIP_RELOCATE) && !defined(CONFIG_TPL_BUILD) >> +static int spl_initr_dm(void) >> +{ >> + int ret; >> + >> + /* Save the pre-reloc driver model and start a new one */ >> + gd->dm_root_f = gd->dm_root; >> + gd->dm_root = NULL; >> + bootstage_start(BOOTSTATE_ID_ACCUM_DM_R, "dm_r"); >> + ret = dm_init_and_scan(false); >> + bootstage_accum(BOOTSTATE_ID_ACCUM_DM_R); >> + if (ret) >> + return ret; >> + >> +#if defined(CONFIG_TIMER) >> + gd->timer = NULL; >> +#endif >> + serial_init(); >> + >> + return 0; >> +} >> +#else >> +static int spl_initr_dm(void) >> +{ >> + return 0; >> +} >> +#endif >> + >> void board_init_r(gd_t *dummy1, ulong dummy2) >> { >> u32 spl_boot_list[] = { >> @@ -577,6 +630,8 @@ void board_init_r(gd_t *dummy1, ulong dummy2) >> >> debug(">>" SPL_TPL_PROMPT "board_init_r()\n"); >> >> + spl_initr_dm(); >> + >> spl_set_bd(); >> >> #if defined(CONFIG_SYS_SPL_MALLOC_START) >> -- >> 2.17.1 >> >> >> > > ^ permalink raw reply [flat|nested] 25+ messages in thread
* [U-Boot] [PATCH v2 2/3] spl: add relocation support【请注意，邮件由sjg@google.com代发】 2019-05-20 6:34 ` [U-Boot] [PATCH v2 2/3] spl: add relocation support【请注意，邮件由sjg@google.com代发】 Andy Yan @ 2019-05-20 15:35 ` Simon Glass 2019-05-21 6:50 ` Andy Yan 2019-05-20 15:58 ` Andre Przywara 1 sibling, 1 reply; 25+ messages in thread From: Simon Glass @ 2019-05-20 15:35 UTC (permalink / raw) To: u-boot Hi Andy, On Mon, 20 May 2019 at 00:34, Andy Yan <andy.yan@rock-chips.com> wrote: > > Hi Simon: > > On 2019/5/19 上午12:26, Simon Glass wrote: > > Hi Andy, > > > > Instead of this could you: > > > > - move ATF? > > All rockchip based arm64 ATF run from the start 64KB of dram as this > will give convenient for kernel manage the memory. > > On the other hand, change the ATF load address will break the > compatibility of the exiting firmware. > > > - change the SPL load address so it is not in the way (since TPL can > > load to any address) > > The SPL is loaded by bootrom after TPL back to bootrom, so the load > address if fixed by bootrom code. I think you are creating a nightmare here. If you have to do things like this for older and smaller SoCs, OK. But it should not be used for newer ones that can do things properly. The bootrom has so many limitations that it just creates pain. > > I know we can build mmc or other storage driver into TPL so we can use > tpl load spl on some platform that sram is big enough, but there are > also many rockchip soc has very small sram, so we tend to only do dram > initialization in tpl, and let bootrom load next stage . See above > > > - (in extremis) create a function which does a memmove() and a jump, > > copy it somewhere and run it (I think x86 does this) ? - Simon > > > > Regards, > > Simon > > > > On Thu, 16 May 2019 at 06:22, Andy Yan <andy.yan@rock-chips.com> wrote: > >> Some times we want to relocate spl code to dram after dram > >> initialization or relocate spl code to a high memory to avoid > >> code overid. > >> > >> For example on Rockchip armv8 platform, we run with boot flow > >> TPL->SPL->ATF->U-Boot. > >> TPL run in sram and is responsible for dram initialization. > >> SPL run from the start address of dram and is responsible for > >> loading ATF and U-Boot. > >> > >> The case here is that the ATF load address is from 64KB of dram, > >> which overlaps with spl code itself. > >> > >> So we want to relocate spl itself to high memory to aovid this. > >> > >> Signed-off-by: Andy Yan <andy.yan@rock-chips.com> > >> --- > >> > >> Changes in v2: > >> - Move Kconfig modification to PATCH 1/3 > >> > >> common/spl/spl.c | 55 ++++++++++++++++++++++++++++++++++++++++++++++++ > >> 1 file changed, 55 insertions(+) > >> > >> diff --git a/common/spl/spl.c b/common/spl/spl.c > >> index 88d4b8a9bf..affb65ccbd 100644 > >> --- a/common/spl/spl.c > >> +++ b/common/spl/spl.c > >> @@ -12,6 +12,7 @@ > >> #include <dm.h> > >> #include <handoff.h> > >> #include <spl.h> > >> +#include <asm/sections.h> > >> #include <asm/u-boot.h> > >> #include <nand.h> > >> #include <fat.h> > >> @@ -439,6 +440,28 @@ static int spl_common_init(bool setup_malloc) > >> return 0; > >> } > >> > >> +#if !defined(CONFIG_SPL_SKIP_RELOCATE) && !defined(CONFIG_TPL_BUILD) > >> +static void spl_setup_relocate(void) > >> +{ > >> + gd->relocaddr = CONFIG_SPL_RELOC_TEXT_BASE; > >> + gd->new_gd = (gd_t *)gd; > >> + gd->start_addr_sp = gd->relocaddr; > >> + gd->fdt_size = ALIGN(fdt_totalsize(gd->fdt_blob) + 0x1000, 32); > >> + > >> + gd->start_addr_sp -= gd->fdt_size; > >> + gd->new_fdt = (void *)gd->start_addr_sp; > >> + memcpy(gd->new_fdt, gd->fdt_blob, gd->fdt_size); > >> + gd->fdt_blob = gd->new_fdt; > >> + > >> + gd->reloc_off = gd->relocaddr - (unsigned long)__image_copy_start; > >> +} > >> +#else > >> +static void spl_setup_relocate(void) > >> +{ > >> + > >> +} > >> +#endif > >> + > >> void spl_set_bd(void) > >> { > >> /* > >> @@ -460,6 +483,8 @@ int spl_early_init(void) > >> return ret; > >> gd->flags |= GD_FLG_SPL_EARLY_INIT; > >> > >> + spl_setup_relocate(); > >> + > >> return 0; > >> } > >> > >> @@ -563,6 +588,34 @@ static int boot_from_devices(struct spl_image_info *spl_image, > >> return -ENODEV; > >> } > >> > >> +#if defined(CONFIG_DM) && !defined(CONFIG_SPL_SKIP_RELOCATE) && !defined(CONFIG_TPL_BUILD) > >> +static int spl_initr_dm(void) > >> +{ > >> + int ret; > >> + > >> + /* Save the pre-reloc driver model and start a new one */ > >> + gd->dm_root_f = gd->dm_root; > >> + gd->dm_root = NULL; > >> + bootstage_start(BOOTSTATE_ID_ACCUM_DM_R, "dm_r"); > >> + ret = dm_init_and_scan(false); > >> + bootstage_accum(BOOTSTATE_ID_ACCUM_DM_R); > >> + if (ret) > >> + return ret; > >> + > >> +#if defined(CONFIG_TIMER) > >> + gd->timer = NULL; > >> +#endif > >> + serial_init(); > >> + > >> + return 0; > >> +} > >> +#else > >> +static int spl_initr_dm(void) > >> +{ > >> + return 0; > >> +} > >> +#endif > >> + > >> void board_init_r(gd_t *dummy1, ulong dummy2) > >> { > >> u32 spl_boot_list[] = { > >> @@ -577,6 +630,8 @@ void board_init_r(gd_t *dummy1, ulong dummy2) > >> > >> debug(">>" SPL_TPL_PROMPT "board_init_r()\n"); > >> > >> + spl_initr_dm(); > >> + > >> spl_set_bd(); > >> > >> #if defined(CONFIG_SYS_SPL_MALLOC_START) > >> -- > >> 2.17.1 > >> > >> > >> > > > > > > ^ permalink raw reply [flat|nested] 25+ messages in thread
* [U-Boot] [PATCH v2 2/3] spl: add relocation support【请注意，邮件由sjg@google.com代发】 2019-05-20 15:35 ` Simon Glass @ 2019-05-21 6:50 ` Andy Yan 2019-05-22 0:28 ` Simon Glass 0 siblings, 1 reply; 25+ messages in thread From: Andy Yan @ 2019-05-21 6:50 UTC (permalink / raw) To: u-boot Hi Simon: On 2019/5/20 下午11:35, Simon Glass wrote: > Hi Andy, > > On Mon, 20 May 2019 at 00:34, Andy Yan <andy.yan@rock-chips.com> wrote: >> Hi Simon: >> >> On 2019/5/19 上午12:26, Simon Glass wrote: >>> Hi Andy, >>> >>> Instead of this could you: >>> >>> - move ATF? >> All rockchip based arm64 ATF run from the start 64KB of dram as this >> will give convenient for kernel manage the memory. >> >> On the other hand, change the ATF load address will break the >> compatibility of the exiting firmware. >> >>> - change the SPL load address so it is not in the way (since TPL can >>> load to any address) >> The SPL is loaded by bootrom after TPL back to bootrom, so the load >> address if fixed by bootrom code. > I think you are creating a nightmare here. If you have to do things > like this for older and smaller SoCs, OK. But it should not be used > for newer ones that can do things properly. Most rockchip based SOC sram is small, even in the future soc roadmap, this situation will still exist, larger sram means more cost. As for the current spl for rockchip soc in mainline, we use a workaround by reserve large space at the head of spl(see CONFIG_ROCKCHIP_SPL_RESERVE_IRAM ), this generate a very large spl binary. As for my patch, the spl relocation is disabled default, we only enable it on necessary platform, so it won't hurt others . > The bootrom has so many limitations that it just creates pain. > >> I know we can build mmc or other storage driver into TPL so we can use >> tpl load spl on some platform that sram is big enough, but there are >> also many rockchip soc has very small sram, so we tend to only do dram >> initialization in tpl, and let bootrom load next stage . > See above > For the consideration of software development, we also want to keep TPL clean, only do dram initialization(as it current status), this make our internal dram team work more simple, they don't need to care about other modules like mmc. >>> - (in extremis) create a function which does a memmove() and a jump, >>> copy it somewhere and run it (I think x86 does this) > ? I am not very understand about this, just a memmove may not work, we need to link the code by pie, and fix the rela.dyn sections after copy. see arm/relocate_64.S > > - Simon > >>> Regards, >>> Simon >>> >>> On Thu, 16 May 2019 at 06:22, Andy Yan <andy.yan@rock-chips.com> wrote: >>>> Some times we want to relocate spl code to dram after dram >>>> initialization or relocate spl code to a high memory to avoid >>>> code overid. >>>> >>>> For example on Rockchip armv8 platform, we run with boot flow >>>> TPL->SPL->ATF->U-Boot. >>>> TPL run in sram and is responsible for dram initialization. >>>> SPL run from the start address of dram and is responsible for >>>> loading ATF and U-Boot. >>>> >>>> The case here is that the ATF load address is from 64KB of dram, >>>> which overlaps with spl code itself. >>>> >>>> So we want to relocate spl itself to high memory to aovid this. >>>> >>>> Signed-off-by: Andy Yan <andy.yan@rock-chips.com> >>>> --- >>>> >>>> Changes in v2: >>>> - Move Kconfig modification to PATCH 1/3 >>>> >>>> common/spl/spl.c | 55 ++++++++++++++++++++++++++++++++++++++++++++++++ >>>> 1 file changed, 55 insertions(+) >>>> >>>> diff --git a/common/spl/spl.c b/common/spl/spl.c >>>> index 88d4b8a9bf..affb65ccbd 100644 >>>> --- a/common/spl/spl.c >>>> +++ b/common/spl/spl.c >>>> @@ -12,6 +12,7 @@ >>>> #include <dm.h> >>>> #include <handoff.h> >>>> #include <spl.h> >>>> +#include <asm/sections.h> >>>> #include <asm/u-boot.h> >>>> #include <nand.h> >>>> #include <fat.h> >>>> @@ -439,6 +440,28 @@ static int spl_common_init(bool setup_malloc) >>>> return 0; >>>> } >>>> >>>> +#if !defined(CONFIG_SPL_SKIP_RELOCATE) && !defined(CONFIG_TPL_BUILD) >>>> +static void spl_setup_relocate(void) >>>> +{ >>>> + gd->relocaddr = CONFIG_SPL_RELOC_TEXT_BASE; >>>> + gd->new_gd = (gd_t *)gd; >>>> + gd->start_addr_sp = gd->relocaddr; >>>> + gd->fdt_size = ALIGN(fdt_totalsize(gd->fdt_blob) + 0x1000, 32); >>>> + >>>> + gd->start_addr_sp -= gd->fdt_size; >>>> + gd->new_fdt = (void *)gd->start_addr_sp; >>>> + memcpy(gd->new_fdt, gd->fdt_blob, gd->fdt_size); >>>> + gd->fdt_blob = gd->new_fdt; >>>> + >>>> + gd->reloc_off = gd->relocaddr - (unsigned long)__image_copy_start; >>>> +} >>>> +#else >>>> +static void spl_setup_relocate(void) >>>> +{ >>>> + >>>> +} >>>> +#endif >>>> + >>>> void spl_set_bd(void) >>>> { >>>> /* >>>> @@ -460,6 +483,8 @@ int spl_early_init(void) >>>> return ret; >>>> gd->flags |= GD_FLG_SPL_EARLY_INIT; >>>> >>>> + spl_setup_relocate(); >>>> + >>>> return 0; >>>> } >>>> >>>> @@ -563,6 +588,34 @@ static int boot_from_devices(struct spl_image_info *spl_image, >>>> return -ENODEV; >>>> } >>>> >>>> +#if defined(CONFIG_DM) && !defined(CONFIG_SPL_SKIP_RELOCATE) && !defined(CONFIG_TPL_BUILD) >>>> +static int spl_initr_dm(void) >>>> +{ >>>> + int ret; >>>> + >>>> + /* Save the pre-reloc driver model and start a new one */ >>>> + gd->dm_root_f = gd->dm_root; >>>> + gd->dm_root = NULL; >>>> + bootstage_start(BOOTSTATE_ID_ACCUM_DM_R, "dm_r"); >>>> + ret = dm_init_and_scan(false); >>>> + bootstage_accum(BOOTSTATE_ID_ACCUM_DM_R); >>>> + if (ret) >>>> + return ret; >>>> + >>>> +#if defined(CONFIG_TIMER) >>>> + gd->timer = NULL; >>>> +#endif >>>> + serial_init(); >>>> + >>>> + return 0; >>>> +} >>>> +#else >>>> +static int spl_initr_dm(void) >>>> +{ >>>> + return 0; >>>> +} >>>> +#endif >>>> + >>>> void board_init_r(gd_t *dummy1, ulong dummy2) >>>> { >>>> u32 spl_boot_list[] = { >>>> @@ -577,6 +630,8 @@ void board_init_r(gd_t *dummy1, ulong dummy2) >>>> >>>> debug(">>" SPL_TPL_PROMPT "board_init_r()\n"); >>>> >>>> + spl_initr_dm(); >>>> + >>>> spl_set_bd(); >>>> >>>> #if defined(CONFIG_SYS_SPL_MALLOC_START) >>>> -- >>>> 2.17.1 >>>> >>>> >>>> >>> >> > > ^ permalink raw reply [flat|nested] 25+ messages in thread
* [U-Boot] [PATCH v2 2/3] spl: add relocation support【请注意，邮件由sjg@google.com代发】 2019-05-21 6:50 ` Andy Yan @ 2019-05-22 0:28 ` Simon Glass 2019-05-22 1:56 ` Andy Yan 0 siblings, 1 reply; 25+ messages in thread From: Simon Glass @ 2019-05-22 0:28 UTC (permalink / raw) To: u-boot Hi Andy, On Tue, 21 May 2019 at 00:51, Andy Yan <andy.yan@rock-chips.com> wrote: > > Hi Simon: > > On 2019/5/20 下午11:35, Simon Glass wrote: > > Hi Andy, > > > > On Mon, 20 May 2019 at 00:34, Andy Yan <andy.yan@rock-chips.com> wrote: > >> Hi Simon: > >> > >> On 2019/5/19 上午12:26, Simon Glass wrote: > >>> Hi Andy, > >>> > >>> Instead of this could you: > >>> > >>> - move ATF? > >> All rockchip based arm64 ATF run from the start 64KB of dram as this > >> will give convenient for kernel manage the memory. > >> > >> On the other hand, change the ATF load address will break the > >> compatibility of the exiting firmware. > >> > >>> - change the SPL load address so it is not in the way (since TPL can > >>> load to any address) > >> The SPL is loaded by bootrom after TPL back to bootrom, so the load > >> address if fixed by bootrom code. > > I think you are creating a nightmare here. If you have to do things > > like this for older and smaller SoCs, OK. But it should not be used > > for newer ones that can do things properly. > > > Most rockchip based SOC sram is small, even in the future soc roadmap, > this situation will still exist, larger sram means more cost. I believe the RK3399 has 192KB. What is the minimum size in new chips? > > As for the current spl for rockchip soc in mainline, we use a workaround > by reserve large space at the head of spl(see > CONFIG_ROCKCHIP_SPL_RESERVE_IRAM ), this generate a very large spl binary. Yes. > > As for my patch, the spl relocation is disabled default, we only enable > it on necessary platform, so it won't hurt others . Well it adds more code and complexity. Perhaps it makes sense to add this, but I want to understand the need. > > > The bootrom has so many limitations that it just creates pain. > > > >> I know we can build mmc or other storage driver into TPL so we can use > >> tpl load spl on some platform that sram is big enough, but there are > >> also many rockchip soc has very small sram, so we tend to only do dram > >> initialization in tpl, and let bootrom load next stage . > > See above > > > For the consideration of software development, we also want to keep TPL > clean, only do dram initialization(as it current status), this make our > internal dram team work more simple, they don't need to care about other > modules like mmc. Yes I understand this, but the boot ROM should be provided as a library to call into: int mmc_read(void *addr, int start_block, int end_block) int spi_read(void *addr, int start_block, int end_block) Then SPL or TPL can use it without all the strange limitations we have now. Since you probably already have these functions somewhere in the boot ROM, you could implement this using a function table somewhere in the ROM with a magic number before it, so that SPL can find it. > > > >>> - (in extremis) create a function which does a memmove() and a jump, > >>> copy it somewhere and run it (I think x86 does this) > > ? > I am not very understand about this, just a memmove may not work, we > need to link the code by pie, and fix the rela.dyn sections after copy. > see arm/relocate_64.S Well if you don't access absolute addresses (which you generally don't in ARM) your memmove() and jump code should be relocatable. Also I wonder what you think of Andre's solution? [..] Regards Simon ^ permalink raw reply [flat|nested] 25+ messages in thread
* [U-Boot] [PATCH v2 2/3] spl: add relocation support【请注意，邮件由sjg@google.com代发】 2019-05-22 0:28 ` Simon Glass @ 2019-05-22 1:56 ` Andy Yan 2019-05-22 19:39 ` Simon Glass 0 siblings, 1 reply; 25+ messages in thread From: Andy Yan @ 2019-05-22 1:56 UTC (permalink / raw) To: u-boot Hi Simon: Simon Glass <sjg@chromium.org> 于2019年5月22日周三 上午8:28写道： > Hi Andy, > > On Tue, 21 May 2019 at 00:51, Andy Yan <andy.yan@rock-chips.com> wrote: > > > > Hi Simon: > > > > On 2019/5/20 下午11:35, Simon Glass wrote: > > > Hi Andy, > > > > > > On Mon, 20 May 2019 at 00:34, Andy Yan <andy.yan@rock-chips.com> > wrote: > > >> Hi Simon: > > >> > > >> On 2019/5/19 上午12:26, Simon Glass wrote: > > >>> Hi Andy, > > >>> > > >>> Instead of this could you: > > >>> > > >>> - move ATF? > > >> All rockchip based arm64 ATF run from the start 64KB of dram as this > > >> will give convenient for kernel manage the memory. > > >> > > >> On the other hand, change the ATF load address will break the > > >> compatibility of the exiting firmware. > > >> > > >>> - change the SPL load address so it is not in the way (since TPL can > > >>> load to any address) > > >> The SPL is loaded by bootrom after TPL back to bootrom, so the load > > >> address if fixed by bootrom code. > > > I think you are creating a nightmare here. If you have to do things > > > like this for older and smaller SoCs, OK. But it should not be used > > > for newer ones that can do things properly. > > > > > > Most rockchip based SOC sram is small, even in the future soc roadmap, > > this situation will still exist, larger sram means more cost. > > I believe the RK3399 has 192KB. What is the minimum size in new chips? > The sram size of RK3328 is 32KB, and now the u-boot-tpl.bin of rk3328 without storage drive is 28KB. The available sram size for TPL on RK3326 is 10KB, our another A35 based IOT SOC has the same limitation. > > > > > As for the current spl for rockchip soc in mainline, we use a workaround > > by reserve large space at the head of spl(see > > CONFIG_ROCKCHIP_SPL_RESERVE_IRAM ), this generate a very large spl > binary. > > Yes. > > > > > As for my patch, the spl relocation is disabled default, we only enable > > it on necessary platform, so it won't hurt others . > > Well it adds more code and complexity. Perhaps it makes sense to add > this, but I want to understand the need. > > > > > > The bootrom has so many limitations that it just creates pain. > > > > > >> I know we can build mmc or other storage driver into TPL so we can use > > >> tpl load spl on some platform that sram is big enough, but there are > > >> also many rockchip soc has very small sram, so we tend to only do dram > > >> initialization in tpl, and let bootrom load next stage . > > > See above > > > > > For the consideration of software development, we also want to keep TPL > > clean, only do dram initialization(as it current status), this make our > > internal dram team work more simple, they don't need to care about other > > modules like mmc. > > Yes I understand this, but the boot ROM should be provided as a > library to call into: > > int mmc_read(void *addr, int start_block, int end_block) > int spi_read(void *addr, int start_block, int end_block) > > Then SPL or TPL can use it without all the strange limitations we have now. > > Since you probably already have these functions somewhere in the boot > ROM, you could implement this using a function table somewhere in the > ROM with a magic number before it, so that SPL can find it. > The Bootrom do much more work than directly load the spl binary. It will do somthing like checksum, look for the backup when the current image is invalid, also including security check when secure boot is enabled. This is why we did much work to add back_too_bootrom mechanism in mainline in 2017. > > > > > > > >>> - (in extremis) create a function which does a memmove() and a jump, > > >>> copy it somewhere and run it (I think x86 does this) > > > ? > > I am not very understand about this, just a memmove may not work, we > > need to link the code by pie, and fix the rela.dyn sections after copy. > > see arm/relocate_64.S > > Well if you don't access absolute addresses (which you generally don't > in ARM) your memmove() and jump code should be relocatable. > > Also I wonder what you think of Andre's solution? > > See my reply . > [..] > > Regards > Simon > _______________________________________________ > U-Boot mailing list > U-Boot at lists.denx.de > https://lists.denx.de/listinfo/u-boot > ^ permalink raw reply [flat|nested] 25+ messages in thread
* [U-Boot] [PATCH v2 2/3] spl: add relocation support【请注意，邮件由sjg@google.com代发】 2019-05-22 1:56 ` Andy Yan @ 2019-05-22 19:39 ` Simon Glass 2019-05-28 8:33 ` Andy Yan 0 siblings, 1 reply; 25+ messages in thread From: Simon Glass @ 2019-05-22 19:39 UTC (permalink / raw) To: u-boot Hi Andy, On Tue, 21 May 2019 at 19:56, Andy Yan <andyshrk@gmail.com> wrote: > > Hi Simon: > > Simon Glass <sjg@chromium.org> 于2019年5月22日周三 上午8:28写道： >> >> Hi Andy, >> >> On Tue, 21 May 2019 at 00:51, Andy Yan <andy.yan@rock-chips.com> wrote: >> > >> > Hi Simon: >> > >> > On 2019/5/20 下午11:35, Simon Glass wrote: >> > > Hi Andy, >> > > >> > > On Mon, 20 May 2019 at 00:34, Andy Yan <andy.yan@rock-chips.com> wrote: >> > >> Hi Simon: >> > >> >> > >> On 2019/5/19 上午12:26, Simon Glass wrote: >> > >>> Hi Andy, >> > >>> >> > >>> Instead of this could you: >> > >>> >> > >>> - move ATF? >> > >> All rockchip based arm64 ATF run from the start 64KB of dram as this >> > >> will give convenient for kernel manage the memory. >> > >> >> > >> On the other hand, change the ATF load address will break the >> > >> compatibility of the exiting firmware. >> > >> >> > >>> - change the SPL load address so it is not in the way (since TPL can >> > >>> load to any address) >> > >> The SPL is loaded by bootrom after TPL back to bootrom, so the load >> > >> address if fixed by bootrom code. >> > > I think you are creating a nightmare here. If you have to do things >> > > like this for older and smaller SoCs, OK. But it should not be used >> > > for newer ones that can do things properly. >> > >> > >> > Most rockchip based SOC sram is small, even in the future soc roadmap, >> > this situation will still exist, larger sram means more cost. >> >> I believe the RK3399 has 192KB. What is the minimum size in new chips? > > > The sram size of RK3328 is 32KB, and now the u-boot-tpl.bin of rk3328 without storage drive is 28KB. > The available sram size for TPL on RK3326 is 10KB, our another A35 based IOT SOC has the same limitation. OK, I see. > >> >> >> > >> > As for the current spl for rockchip soc in mainline, we use a workaround >> > by reserve large space at the head of spl(see >> > CONFIG_ROCKCHIP_SPL_RESERVE_IRAM ), this generate a very large spl binary. >> >> Yes. >> >> > >> > As for my patch, the spl relocation is disabled default, we only enable >> > it on necessary platform, so it won't hurt others . >> >> Well it adds more code and complexity. Perhaps it makes sense to add >> this, but I want to understand the need. >> >> > >> > > The bootrom has so many limitations that it just creates pain. >> > > >> > >> I know we can build mmc or other storage driver into TPL so we can use >> > >> tpl load spl on some platform that sram is big enough, but there are >> > >> also many rockchip soc has very small sram, so we tend to only do dram >> > >> initialization in tpl, and let bootrom load next stage . >> > > See above >> > > >> > For the consideration of software development, we also want to keep TPL >> > clean, only do dram initialization(as it current status), this make our >> > internal dram team work more simple, they don't need to care about other >> > modules like mmc. >> >> Yes I understand this, but the boot ROM should be provided as a >> library to call into: >> >> int mmc_read(void *addr, int start_block, int end_block) >> int spi_read(void *addr, int start_block, int end_block) >> >> Then SPL or TPL can use it without all the strange limitations we have now. >> >> Since you probably already have these functions somewhere in the boot >> ROM, you could implement this using a function table somewhere in the >> ROM with a magic number before it, so that SPL can find it. > > > The Bootrom do much more work than directly load the spl binary. It will do somthing like checksum, look for the backup when the current image is invalid, also including security check when secure boot is enabled. This is why we did much work to add back_too_bootrom mechanism in mainline in 2017. Yes I understand that, but it is also quite inflexible, and creates enormous problems with bootloaders. I am not suggesting that you remove functionality. I am suggesting that you allow bootloaders to call into some of it, to reduce the problems caused by the inflexible bootrom. Regards, Simon >> >> >> > >> > >> > >>> - (in extremis) create a function which does a memmove() and a jump, >> > >>> copy it somewhere and run it (I think x86 does this) >> > > ? >> > I am not very understand about this, just a memmove may not work, we >> > need to link the code by pie, and fix the rela.dyn sections after copy. >> > see arm/relocate_64.S >> >> Well if you don't access absolute addresses (which you generally don't >> in ARM) your memmove() and jump code should be relocatable. >> >> Also I wonder what you think of Andre's solution? >> > > See my reply . Regards, Simon ^ permalink raw reply [flat|nested] 25+ messages in thread
* [U-Boot] [PATCH v2 2/3] spl: add relocation support【请注意，邮件由sjg@google.com代发】 2019-05-22 19:39 ` Simon Glass @ 2019-05-28 8:33 ` Andy Yan 2019-06-22 19:10 ` Simon Glass 0 siblings, 1 reply; 25+ messages in thread From: Andy Yan @ 2019-05-28 8:33 UTC (permalink / raw) To: u-boot Hi Simon: On 2019/5/23 上午3:39, Simon Glass wrote: > Hi Andy, > > On Tue, 21 May 2019 at 19:56, Andy Yan <andyshrk@gmail.com> wrote: >> Hi Simon: >> >> Simon Glass <sjg@chromium.org> 于2019年5月22日周三 上午8:28写道： >>> Hi Andy, >>> >>> On Tue, 21 May 2019 at 00:51, Andy Yan <andy.yan@rock-chips.com> wrote: >>>> Hi Simon: >>>> >>>> On 2019/5/20 下午11:35, Simon Glass wrote: >>>>> Hi Andy, >>>>> >>>>> On Mon, 20 May 2019 at 00:34, Andy Yan <andy.yan@rock-chips.com> wrote: >>>>>> Hi Simon: >>>>>> >>>>>> On 2019/5/19 上午12:26, Simon Glass wrote: >>>>>>> Hi Andy, >>>>>>> >>>>>>> Instead of this could you: >>>>>>> >>>>>>> - move ATF? >>>>>> All rockchip based arm64 ATF run from the start 64KB of dram as this >>>>>> will give convenient for kernel manage the memory. >>>>>> >>>>>> On the other hand, change the ATF load address will break the >>>>>> compatibility of the exiting firmware. >>>>>> >>>>>>> - change the SPL load address so it is not in the way (since TPL can >>>>>>> load to any address) >>>>>> The SPL is loaded by bootrom after TPL back to bootrom, so the load >>>>>> address if fixed by bootrom code. >>>>> I think you are creating a nightmare here. If you have to do things >>>>> like this for older and smaller SoCs, OK. But it should not be used >>>>> for newer ones that can do things properly. >>>> >>>> Most rockchip based SOC sram is small, even in the future soc roadmap, >>>> this situation will still exist, larger sram means more cost. >>> I believe the RK3399 has 192KB. What is the minimum size in new chips? >> >> The sram size of RK3328 is 32KB, and now the u-boot-tpl.bin of rk3328 without storage drive is 28KB. >> The available sram size for TPL on RK3326 is 10KB, our another A35 based IOT SOC has the same limitation. > OK, I see. > >>> >>>> As for the current spl for rockchip soc in mainline, we use a workaround >>>> by reserve large space at the head of spl(see >>>> CONFIG_ROCKCHIP_SPL_RESERVE_IRAM ), this generate a very large spl binary. >>> Yes. >>> >>>> As for my patch, the spl relocation is disabled default, we only enable >>>> it on necessary platform, so it won't hurt others . >>> Well it adds more code and complexity. Perhaps it makes sense to add >>> this, but I want to understand the need. >>> >>>>> The bootrom has so many limitations that it just creates pain. >>>>> >>>>>> I know we can build mmc or other storage driver into TPL so we can use >>>>>> tpl load spl on some platform that sram is big enough, but there are >>>>>> also many rockchip soc has very small sram, so we tend to only do dram >>>>>> initialization in tpl, and let bootrom load next stage . >>>>> See above >>>>> >>>> For the consideration of software development, we also want to keep TPL >>>> clean, only do dram initialization(as it current status), this make our >>>> internal dram team work more simple, they don't need to care about other >>>> modules like mmc. >>> Yes I understand this, but the boot ROM should be provided as a >>> library to call into: >>> >>> int mmc_read(void *addr, int start_block, int end_block) >>> int spi_read(void *addr, int start_block, int end_block) >>> >>> Then SPL or TPL can use it without all the strange limitations we have now. >>> >>> Since you probably already have these functions somewhere in the boot >>> ROM, you could implement this using a function table somewhere in the >>> ROM with a magic number before it, so that SPL can find it. >> >> The Bootrom do much more work than directly load the spl binary. It will do somthing like checksum, look for the backup when the current image is invalid, also including security check when secure boot is enabled. This is why we did much work to add back_too_bootrom mechanism in mainline in 2017. > Yes I understand that, but it is also quite inflexible, and creates > enormous problems with bootloaders. > > I am not suggesting that you remove functionality. I am suggesting > that you allow bootloaders to call into some of it, to reduce the > problems caused by the inflexible bootrom. I checked with people who write bootrom code these days, as different chip written by different people from different team, it took a bit long time to figure out this. Yes , bootrom have storage access api like mmc_read/read_sfc_nand/read_sfc_nor/nandc_read, but bootrom does not provide a fixed table for these api, and the address for these api are different on different chip, this means we have to list the api address chip by chip in SPL code. There is another thing, as the bootrom code are written by different person, the api interface don't keep constant: sfc_nor_read on one chip is sfc_nor_read(void *addr, int start, int len), but on another chip is sfc_nor_read(int start, void *addr, int len), this make things complicated. Also as what I mentioned before, the Bootrom do much more work than directly load the spl binary, especially in secure boot mode, but the bootrom don't want to export secure related api for security concern . So this seems not a good choice to reuse bootrom api in spl. > Regards, > Simon > > >>> >>>> >>>>>>> - (in extremis) create a function which does a memmove() and a jump, >>>>>>> copy it somewhere and run it (I think x86 does this) >>>>> ? >>>> I am not very understand about this, just a memmove may not work, we >>>> need to link the code by pie, and fix the rela.dyn sections after copy. >>>> see arm/relocate_64.S >>> Well if you don't access absolute addresses (which you generally don't >>> in ARM) your memmove() and jump code should be relocatable. >>> >>> Also I wonder what you think of Andre's solution? >>> >> See my reply . > Regards, > Simon > > > ^ permalink raw reply [flat|nested] 25+ messages in thread
* [U-Boot] [PATCH v2 2/3] spl: add relocation support【请注意，邮件由sjg@google.com代发】 2019-05-28 8:33 ` Andy Yan @ 2019-06-22 19:10 ` Simon Glass 2019-06-24 10:36 ` Andy Yan 0 siblings, 1 reply; 25+ messages in thread From: Simon Glass @ 2019-06-22 19:10 UTC (permalink / raw) To: u-boot Hi Andy, On Tue, 28 May 2019 at 09:34, Andy Yan <andy.yan@rock-chips.com> wrote: > > Hi Simon: > > On 2019/5/23 上午3:39, Simon Glass wrote: > > Hi Andy, > > On Tue, 21 May 2019 at 19:56, Andy Yan <andyshrk@gmail.com> wrote: > > Hi Simon: > > Simon Glass <sjg@chromium.org> 于2019年5月22日周三 上午8:28写道： > > Hi Andy, > > On Tue, 21 May 2019 at 00:51, Andy Yan <andy.yan@rock-chips.com> wrote: > > Hi Simon: > > On 2019/5/20 下午11:35, Simon Glass wrote: > > Hi Andy, > > On Mon, 20 May 2019 at 00:34, Andy Yan <andy.yan@rock-chips.com> wrote: > > Hi Simon: > > On 2019/5/19 上午12:26, Simon Glass wrote: > > Hi Andy, > > Instead of this could you: > > - move ATF? > > All rockchip based arm64 ATF run from the start 64KB of dram as this > will give convenient for kernel manage the memory. > > On the other hand, change the ATF load address will break the > compatibility of the exiting firmware. > > - change the SPL load address so it is not in the way (since TPL can > load to any address) > > The SPL is loaded by bootrom after TPL back to bootrom, so the load > address if fixed by bootrom code. > > I think you are creating a nightmare here. If you have to do things > like this for older and smaller SoCs, OK. But it should not be used > for newer ones that can do things properly. > > Most rockchip based SOC sram is small, even in the future soc roadmap, > this situation will still exist, larger sram means more cost. > > I believe the RK3399 has 192KB. What is the minimum size in new chips? > > The sram size of RK3328 is 32KB, and now the u-boot-tpl.bin of rk3328 without storage drive is 28KB. > The available sram size for TPL on RK3326 is 10KB, our another A35 based IOT SOC has the same limitation. > > OK, I see. > > > As for the current spl for rockchip soc in mainline, we use a workaround > by reserve large space at the head of spl(see > CONFIG_ROCKCHIP_SPL_RESERVE_IRAM ), this generate a very large spl binary. > > Yes. > > As for my patch, the spl relocation is disabled default, we only enable > it on necessary platform, so it won't hurt others . > > Well it adds more code and complexity. Perhaps it makes sense to add > this, but I want to understand the need. > > The bootrom has so many limitations that it just creates pain. > > I know we can build mmc or other storage driver into TPL so we can use > tpl load spl on some platform that sram is big enough, but there are > also many rockchip soc has very small sram, so we tend to only do dram > initialization in tpl, and let bootrom load next stage . > > See above > > For the consideration of software development, we also want to keep TPL > clean, only do dram initialization(as it current status), this make our > internal dram team work more simple, they don't need to care about other > modules like mmc. > > Yes I understand this, but the boot ROM should be provided as a > library to call into: > > int mmc_read(void *addr, int start_block, int end_block) > int spi_read(void *addr, int start_block, int end_block) > > Then SPL or TPL can use it without all the strange limitations we have now. > > Since you probably already have these functions somewhere in the boot > ROM, you could implement this using a function table somewhere in the > ROM with a magic number before it, so that SPL can find it. > > The Bootrom do much more work than directly load the spl binary. It will do somthing like checksum, look for the backup when the current image is invalid, also including security check when secure boot is enabled. This is why we did much work to add back_too_bootrom mechanism in mainline in 2017. > > Yes I understand that, but it is also quite inflexible, and creates > enormous problems with bootloaders. > > I am not suggesting that you remove functionality. I am suggesting > that you allow bootloaders to call into some of it, to reduce the > problems caused by the inflexible bootrom. > > > I checked with people who write bootrom code these days, as different chip written by different people from different team, it took a bit long time to figure out this. > > Yes , bootrom have storage access api like mmc_read/read_sfc_nand/read_sfc_nor/nandc_read, but bootrom does not provide a fixed table for these api, and the address for these api are different on different chip, this means we have to list the api address chip by chip in SPL code. There is another thing, as the bootrom code are written by different person, the api interface don't keep constant: sfc_nor_read on one chip is sfc_nor_read(void *addr, int start, int len), but on another chip is sfc_nor_read(int start, void *addr, int len), this make things complicated. > > Also as what I mentioned before, the Bootrom do much more work than directly load the spl binary, especially in secure boot mode, but the bootrom don't want to export secure related api for security concern . > > So this seems not a good choice to reuse bootrom api in spl. While I understand what you are saying, I don't think it would be hard to add a little interface layer for each SoC which supports reading from each type of device, and knows the SoC ROM address to call, and deals with changing args, etc. Really, it should be a very small amount of code. And the benefit is a large reduction in TPL/SPL code size and a lot less of the insane hacks we ahve now! > > Regards, > Simon > > > > > - (in extremis) create a function which does a memmove() and a jump, > copy it somewhere and run it (I think x86 does this) > > ? > > I am not very understand about this, just a memmove may not work, we > need to link the code by pie, and fix the rela.dyn sections after copy. > see arm/relocate_64.S > > Well if you don't access absolute addresses (which you generally don't > in ARM) your memmove() and jump code should be relocatable. > > Also I wonder what you think of Andre's solution? > > See my reply . > > Regards, > Simon > > > ^ permalink raw reply [flat|nested] 25+ messages in thread
* [U-Boot] [PATCH v2 2/3] spl: add relocation support【请注意，邮件由sjg@google.com代发】 2019-06-22 19:10 ` Simon Glass @ 2019-06-24 10:36 ` Andy Yan 2019-06-30 13:03 ` [U-Boot] [PATCH v2 2/3] spl: add relocation support Kever Yang 2019-07-06 17:16 ` [U-Boot] [PATCH v2 2/3] spl: add relocation support【请注意，邮件由sjg@google.com代发】 Simon Glass 0 siblings, 2 replies; 25+ messages in thread From: Andy Yan @ 2019-06-24 10:36 UTC (permalink / raw) To: u-boot Hi Simon: Glad to see you online again. On 2019/6/23 上午3:10, Simon Glass wrote: > Hi Andy, > > On Tue, 28 May 2019 at 09:34, Andy Yan <andy.yan@rock-chips.com> wrote: >> Hi Simon: >> >> On 2019/5/23 上午3:39, Simon Glass wrote: >> >> Hi Andy, >> >> On Tue, 21 May 2019 at 19:56, Andy Yan <andyshrk@gmail.com> wrote: >> >> Hi Simon: >> >> Simon Glass <sjg@chromium.org> 于2019年5月22日周三 上午8:28写道： >> >> Hi Andy, >> >> On Tue, 21 May 2019 at 00:51, Andy Yan <andy.yan@rock-chips.com> wrote: >> >> Hi Simon: >> >> On 2019/5/20 下午11:35, Simon Glass wrote: >> >> Hi Andy, >> >> On Mon, 20 May 2019 at 00:34, Andy Yan <andy.yan@rock-chips.com> wrote: >> >> Hi Simon: >> >> On 2019/5/19 上午12:26, Simon Glass wrote: >> >> Hi Andy, >> >> Instead of this could you: >> >> - move ATF? >> >> All rockchip based arm64 ATF run from the start 64KB of dram as this >> will give convenient for kernel manage the memory. >> >> On the other hand, change the ATF load address will break the >> compatibility of the exiting firmware. >> >> - change the SPL load address so it is not in the way (since TPL can >> load to any address) >> >> The SPL is loaded by bootrom after TPL back to bootrom, so the load >> address if fixed by bootrom code. >> >> I think you are creating a nightmare here. If you have to do things >> like this for older and smaller SoCs, OK. But it should not be used >> for newer ones that can do things properly. >> >> Most rockchip based SOC sram is small, even in the future soc roadmap, >> this situation will still exist, larger sram means more cost. >> >> I believe the RK3399 has 192KB. What is the minimum size in new chips? >> >> The sram size of RK3328 is 32KB, and now the u-boot-tpl.bin of rk3328 without storage drive is 28KB. >> The available sram size for TPL on RK3326 is 10KB, our another A35 based IOT SOC has the same limitation. >> >> OK, I see. >> >> >> As for the current spl for rockchip soc in mainline, we use a workaround >> by reserve large space at the head of spl(see >> CONFIG_ROCKCHIP_SPL_RESERVE_IRAM ), this generate a very large spl binary. >> >> Yes. >> >> As for my patch, the spl relocation is disabled default, we only enable >> it on necessary platform, so it won't hurt others . >> >> Well it adds more code and complexity. Perhaps it makes sense to add >> this, but I want to understand the need. >> >> The bootrom has so many limitations that it just creates pain. >> >> I know we can build mmc or other storage driver into TPL so we can use >> tpl load spl on some platform that sram is big enough, but there are >> also many rockchip soc has very small sram, so we tend to only do dram >> initialization in tpl, and let bootrom load next stage . >> >> See above >> >> For the consideration of software development, we also want to keep TPL >> clean, only do dram initialization(as it current status), this make our >> internal dram team work more simple, they don't need to care about other >> modules like mmc. >> >> Yes I understand this, but the boot ROM should be provided as a >> library to call into: >> >> int mmc_read(void *addr, int start_block, int end_block) >> int spi_read(void *addr, int start_block, int end_block) >> >> Then SPL or TPL can use it without all the strange limitations we have now. >> >> Since you probably already have these functions somewhere in the boot >> ROM, you could implement this using a function table somewhere in the >> ROM with a magic number before it, so that SPL can find it. >> >> The Bootrom do much more work than directly load the spl binary. It will do somthing like checksum, look for the backup when the current image is invalid, also including security check when secure boot is enabled. This is why we did much work to add back_too_bootrom mechanism in mainline in 2017. >> >> Yes I understand that, but it is also quite inflexible, and creates >> enormous problems with bootloaders. >> >> I am not suggesting that you remove functionality. I am suggesting >> that you allow bootloaders to call into some of it, to reduce the >> problems caused by the inflexible bootrom. >> >> >> I checked with people who write bootrom code these days, as different chip written by different people from different team, it took a bit long time to figure out this. >> >> Yes , bootrom have storage access api like mmc_read/read_sfc_nand/read_sfc_nor/nandc_read, but bootrom does not provide a fixed table for these api, and the address for these api are different on different chip, this means we have to list the api address chip by chip in SPL code. There is another thing, as the bootrom code are written by different person, the api interface don't keep constant: sfc_nor_read on one chip is sfc_nor_read(void *addr, int start, int len), but on another chip is sfc_nor_read(int start, void *addr, int len), this make things complicated. >> >> Also as what I mentioned before, the Bootrom do much more work than directly load the spl binary, especially in secure boot mode, but the bootrom don't want to export secure related api for security concern . >> >> So this seems not a good choice to reuse bootrom api in spl. > While I understand what you are saying, I don't think it would be hard > to add a little interface layer for each SoC which supports reading > from each type of device, and knows the SoC ROM address to call, and > deals with changing args, etc. > > Really, it should be a very small amount of code. And the benefit is a > large reduction in TPL/SPL code size and a lot less of the insane > hacks we ahve now! > Yes, it's not hard to add a wrapper for every soc from technical side, but it make things complicated. When we get a new soc, we need to check with the bootrom person for the storage api type by type, the we get a long header file nested with ''if chipA, else if chipB, esle if chipC", this looks not nice . What's more , there is one more issue, bootrom will not export the secure related api, so we can't do secure boot with this method. I still prefer to reuse the existing relocation mechanism. >> Regards, >> Simon >> >> >> >> >> - (in extremis) create a function which does a memmove() and a jump, >> copy it somewhere and run it (I think x86 does this) >> >> ? >> >> I am not very understand about this, just a memmove may not work, we >> need to link the code by pie, and fix the rela.dyn sections after copy. >> see arm/relocate_64.S >> >> Well if you don't access absolute addresses (which you generally don't >> in ARM) your memmove() and jump code should be relocatable. >> >> Also I wonder what you think of Andre's solution? >> >> See my reply . >> >> Regards, >> Simon >> >> >> > > ^ permalink raw reply [flat|nested] 25+ messages in thread
* [U-Boot] [PATCH v2 2/3] spl: add relocation support 2019-06-24 10:36 ` Andy Yan @ 2019-06-30 13:03 ` Kever Yang 2019-07-06 17:16 ` [U-Boot] [PATCH v2 2/3] spl: add relocation support【请注意，邮件由sjg@google.com代发】 Simon Glass 1 sibling, 0 replies; 25+ messages in thread From: Kever Yang @ 2019-06-30 13:03 UTC (permalink / raw) To: u-boot Hi Simon, Andy, I think you are mixing up two different topic, they should be separate: 1. re-use API in BootRom in SPL to make SPL have a small enough size; 2. Enable relocation feature so that we can use the space in low address freely; The 1st topic about re-use API in BootRom is depends on vendor's design, and in Rockchip's case, the BootRom is totally close source, and provide a BACK_TO_BOOTROM feature for the very first blob of code, this program can be very small and without any storage driver, which is usually used for DDR init. We are suffer from SPL(with DRAM init) size expands while SPL have the SRAM size limit, so I think it's time for Rockchip platform to split the DRAM init part into TPL and then SPL running in DRAM which would not have size limit. The 2nd topic about SPL relocation, which is a exist feature of U-Boot SPL, I think it's reasonable to make this feature can fully relocate(instead of stack/gd/bss now) on ARM platform as an option feature, just like we may need to make the no relocate as an option for some boards need it. Thanks, - Kever On 06/24/2019 06:36 PM, Andy Yan wrote: > Hi Simon: > > Glad to see you online again. > > On 2019/6/23 上午3:10, Simon Glass wrote: >> Hi Andy, >> >> On Tue, 28 May 2019 at 09:34, Andy Yan <andy.yan@rock-chips.com> wrote: >>> Hi Simon: >>> >>> On 2019/5/23 上午3:39, Simon Glass wrote: >>> >>> Hi Andy, >>> >>> On Tue, 21 May 2019 at 19:56, Andy Yan <andyshrk@gmail.com> wrote: >>> >>> Hi Simon: >>> >>> Simon Glass <sjg@chromium.org> 于2019年5月22日周三 上午8:28写道： >>> >>> Hi Andy, >>> >>> On Tue, 21 May 2019 at 00:51, Andy Yan <andy.yan@rock-chips.com> wrote: >>> >>> Hi Simon: >>> >>> On 2019/5/20 下午11:35, Simon Glass wrote: >>> >>> Hi Andy, >>> >>> On Mon, 20 May 2019 at 00:34, Andy Yan <andy.yan@rock-chips.com> wrote: >>> >>> Hi Simon: >>> >>> On 2019/5/19 上午12:26, Simon Glass wrote: >>> >>> Hi Andy, >>> >>> Instead of this could you: >>> >>> - move ATF? >>> >>> All rockchip based arm64 ATF run from the start 64KB of dram as this >>> will give convenient for kernel manage the memory. >>> >>> On the other hand, change the ATF load address will break the >>> compatibility of the exiting firmware. >>> >>> - change the SPL load address so it is not in the way (since TPL can >>> load to any address) >>> >>> The SPL is loaded by bootrom after TPL back to bootrom, so the load >>> address if fixed by bootrom code. >>> >>> I think you are creating a nightmare here. If you have to do things >>> like this for older and smaller SoCs, OK. But it should not be used >>> for newer ones that can do things properly. >>> >>> Most rockchip based SOC sram is small, even in the future soc roadmap, >>> this situation will still exist, larger sram means more cost. >>> >>> I believe the RK3399 has 192KB. What is the minimum size in new chips? >>> >>> The sram size of RK3328 is 32KB, and now the u-boot-tpl.bin of >>> rk3328 without storage drive is 28KB. >>> The available sram size for TPL on RK3326 is 10KB, our another A35 >>> based IOT SOC has the same limitation. >>> >>> OK, I see. >>> >>> >>> As for the current spl for rockchip soc in mainline, we use a >>> workaround >>> by reserve large space at the head of spl(see >>> CONFIG_ROCKCHIP_SPL_RESERVE_IRAM ), this generate a very large spl >>> binary. >>> >>> Yes. >>> >>> As for my patch, the spl relocation is disabled default, we only enable >>> it on necessary platform, so it won't hurt others . >>> >>> Well it adds more code and complexity. Perhaps it makes sense to add >>> this, but I want to understand the need. >>> >>> The bootrom has so many limitations that it just creates pain. >>> >>> I know we can build mmc or other storage driver into TPL so we can use >>> tpl load spl on some platform that sram is big enough, but there are >>> also many rockchip soc has very small sram, so we tend to only do dram >>> initialization in tpl, and let bootrom load next stage . >>> >>> See above >>> >>> For the consideration of software development, we also want to keep TPL >>> clean, only do dram initialization(as it current status), this make >>> our >>> internal dram team work more simple, they don't need to care about >>> other >>> modules like mmc. >>> >>> Yes I understand this, but the boot ROM should be provided as a >>> library to call into: >>> >>> int mmc_read(void *addr, int start_block, int end_block) >>> int spi_read(void *addr, int start_block, int end_block) >>> >>> Then SPL or TPL can use it without all the strange limitations we >>> have now. >>> >>> Since you probably already have these functions somewhere in the boot >>> ROM, you could implement this using a function table somewhere in the >>> ROM with a magic number before it, so that SPL can find it. >>> >>> The Bootrom do much more work than directly load the spl binary. It >>> will do somthing like checksum, look for the backup when the current >>> image is invalid, also including security check when secure boot is >>> enabled. This is why we did much work to add back_too_bootrom >>> mechanism in mainline in 2017. >>> >>> Yes I understand that, but it is also quite inflexible, and creates >>> enormous problems with bootloaders. >>> >>> I am not suggesting that you remove functionality. I am suggesting >>> that you allow bootloaders to call into some of it, to reduce the >>> problems caused by the inflexible bootrom. >>> >>> >>> I checked with people who write bootrom code these days, as >>> different chip written by different people from different team, it >>> took a bit long time to figure out this. >>> >>> Yes , bootrom have storage access api like >>> mmc_read/read_sfc_nand/read_sfc_nor/nandc_read, but bootrom does >>> not provide a fixed table for these api, and the address for these >>> api are different on different chip, this means we have to list the >>> api address chip by chip in SPL code. There is another thing, as the >>> bootrom code are written by different person, the api interface >>> don't keep constant: sfc_nor_read on one chip is sfc_nor_read(void >>> *addr, int start, int len), but on another chip is sfc_nor_read(int >>> start, void *addr, int len), this make things complicated. >>> >>> Also as what I mentioned before, the Bootrom do much more work than >>> directly load the spl binary, especially in secure boot mode, but >>> the bootrom don't want to export secure related api for security >>> concern . >>> >>> So this seems not a good choice to reuse bootrom api in spl. >> While I understand what you are saying, I don't think it would be hard >> to add a little interface layer for each SoC which supports reading >> from each type of device, and knows the SoC ROM address to call, and >> deals with changing args, etc. >> >> Really, it should be a very small amount of code. And the benefit is a >> large reduction in TPL/SPL code size and a lot less of the insane >> hacks we ahve now! >> > > Yes, it's not hard to add a wrapper for every soc from technical side, > but it make things complicated. When we get a new soc, we need to > check with the bootrom person for the storage api type by type, the we > get a long header file nested with ''if chipA, else if chipB, esle if > chipC", this looks not nice . > > What's more , there is one more issue, bootrom will not export the > secure related api, so we can't do secure boot with this method. > > I still prefer to reuse the existing relocation mechanism. > > >>> Regards, >>> Simon >>> >>> >>> >>> >>> - (in extremis) create a function which does a memmove() and a jump, >>> copy it somewhere and run it (I think x86 does this) >>> >>> ? >>> >>> I am not very understand about this, just a memmove may not work, we >>> need to link the code by pie, and fix the rela.dyn sections after copy. >>> see arm/relocate_64.S >>> >>> Well if you don't access absolute addresses (which you generally don't >>> in ARM) your memmove() and jump code should be relocatable. >>> >>> Also I wonder what you think of Andre's solution? >>> >>> See my reply . >>> >>> Regards, >>> Simon >>> >>> >>> >> >> > > ^ permalink raw reply [flat|nested] 25+ messages in thread
* [U-Boot] [PATCH v2 2/3] spl: add relocation support【请注意，邮件由sjg@google.com代发】 2019-06-24 10:36 ` Andy Yan 2019-06-30 13:03 ` [U-Boot] [PATCH v2 2/3] spl: add relocation support Kever Yang @ 2019-07-06 17:16 ` Simon Glass 2019-07-07 0:36 ` Andy Yan 1 sibling, 1 reply; 25+ messages in thread From: Simon Glass @ 2019-07-06 17:16 UTC (permalink / raw) To: u-boot Hi Andy, On Mon, 24 Jun 2019 at 04:37, Andy Yan <andy.yan@rock-chips.com> wrote: > > Hi Simon: > > Glad to see you online again. > > On 2019/6/23 上午3:10, Simon Glass wrote: > > Hi Andy, > > > > On Tue, 28 May 2019 at 09:34, Andy Yan <andy.yan@rock-chips.com> wrote: > >> Hi Simon: > >> > >> On 2019/5/23 上午3:39, Simon Glass wrote: > >> > >> Hi Andy, > >> > >> On Tue, 21 May 2019 at 19:56, Andy Yan <andyshrk@gmail.com> wrote: > >> > >> Hi Simon: > >> > >> Simon Glass <sjg@chromium.org> 于2019年5月22日周三 上午8:28写道： > >> > >> Hi Andy, > >> > >> On Tue, 21 May 2019 at 00:51, Andy Yan <andy.yan@rock-chips.com> wrote: > >> > >> Hi Simon: > >> > >> On 2019/5/20 下午11:35, Simon Glass wrote: > >> > >> Hi Andy, > >> > >> On Mon, 20 May 2019 at 00:34, Andy Yan <andy.yan@rock-chips.com> wrote: > >> > >> Hi Simon: > >> > >> On 2019/5/19 上午12:26, Simon Glass wrote: > >> > >> Hi Andy, > >> > >> Instead of this could you: > >> > >> - move ATF? > >> > >> All rockchip based arm64 ATF run from the start 64KB of dram as this > >> will give convenient for kernel manage the memory. > >> > >> On the other hand, change the ATF load address will break the > >> compatibility of the exiting firmware. > >> > >> - change the SPL load address so it is not in the way (since TPL can > >> load to any address) > >> > >> The SPL is loaded by bootrom after TPL back to bootrom, so the load > >> address if fixed by bootrom code. > >> > >> I think you are creating a nightmare here. If you have to do things > >> like this for older and smaller SoCs, OK. But it should not be used > >> for newer ones that can do things properly. > >> > >> Most rockchip based SOC sram is small, even in the future soc roadmap, > >> this situation will still exist, larger sram means more cost. > >> > >> I believe the RK3399 has 192KB. What is the minimum size in new chips? > >> > >> The sram size of RK3328 is 32KB, and now the u-boot-tpl.bin of rk3328 without storage drive is 28KB. > >> The available sram size for TPL on RK3326 is 10KB, our another A35 based IOT SOC has the same limitation. > >> > >> OK, I see. > >> > >> > >> As for the current spl for rockchip soc in mainline, we use a workaround > >> by reserve large space at the head of spl(see > >> CONFIG_ROCKCHIP_SPL_RESERVE_IRAM ), this generate a very large spl binary. > >> > >> Yes. > >> > >> As for my patch, the spl relocation is disabled default, we only enable > >> it on necessary platform, so it won't hurt others . > >> > >> Well it adds more code and complexity. Perhaps it makes sense to add > >> this, but I want to understand the need. > >> > >> The bootrom has so many limitations that it just creates pain. > >> > >> I know we can build mmc or other storage driver into TPL so we can use > >> tpl load spl on some platform that sram is big enough, but there are > >> also many rockchip soc has very small sram, so we tend to only do dram > >> initialization in tpl, and let bootrom load next stage . > >> > >> See above > >> > >> For the consideration of software development, we also want to keep TPL > >> clean, only do dram initialization(as it current status), this make our > >> internal dram team work more simple, they don't need to care about other > >> modules like mmc. > >> > >> Yes I understand this, but the boot ROM should be provided as a > >> library to call into: > >> > >> int mmc_read(void *addr, int start_block, int end_block) > >> int spi_read(void *addr, int start_block, int end_block) > >> > >> Then SPL or TPL can use it without all the strange limitations we have now. > >> > >> Since you probably already have these functions somewhere in the boot > >> ROM, you could implement this using a function table somewhere in the > >> ROM with a magic number before it, so that SPL can find it. > >> > >> The Bootrom do much more work than directly load the spl binary. It will do somthing like checksum, look for the backup when the current image is invalid, also including security check when secure boot is enabled. This is why we did much work to add back_too_bootrom mechanism in mainline in 2017. > >> > >> Yes I understand that, but it is also quite inflexible, and creates > >> enormous problems with bootloaders. > >> > >> I am not suggesting that you remove functionality. I am suggesting > >> that you allow bootloaders to call into some of it, to reduce the > >> problems caused by the inflexible bootrom. > >> > >> > >> I checked with people who write bootrom code these days, as different chip written by different people from different team, it took a bit long time to figure out this. > >> > >> Yes , bootrom have storage access api like mmc_read/read_sfc_nand/read_sfc_nor/nandc_read, but bootrom does not provide a fixed table for these api, and the address for these api are different on different chip, this means we have to list the api address chip by chip in SPL code. There is another thing, as the bootrom code are written by different person, the api interface don't keep constant: sfc_nor_read on one chip is sfc_nor_read(void *addr, int start, int len), but on another chip is sfc_nor_read(int start, void *addr, int len), this make things complicated. > >> > >> Also as what I mentioned before, the Bootrom do much more work than directly load the spl binary, especially in secure boot mode, but the bootrom don't want to export secure related api for security concern . > >> > >> So this seems not a good choice to reuse bootrom api in spl. > > While I understand what you are saying, I don't think it would be hard > > to add a little interface layer for each SoC which supports reading > > from each type of device, and knows the SoC ROM address to call, and > > deals with changing args, etc. > > > > Really, it should be a very small amount of code. And the benefit is a > > large reduction in TPL/SPL code size and a lot less of the insane > > hacks we ahve now! > > > > Yes, it's not hard to add a wrapper for every soc from technical side, > but it make things complicated. When we get a new soc, we need to check > with the bootrom person for the storage api type by type, the we get a > long header file nested with ''if chipA, else if chipB, esle if chipC", > this looks not nice . I suggest having one header per SoC. Also, if you do talk to your chip people, ask them to use a consistent API from now on, and put the table of function pointers (and perhaps an API version) in the ROM itself. > > What's more , there is one more issue, bootrom will not export the > secure related api, so we can't do secure boot with this method. Why not? Making an API hidden does not help security. I honestly worry that no one at Rockchip is thinking about how to actually implement a bootloader that covers all the chips that you ship. Consistency takes effort. > > I still prefer to reuse the existing relocation mechanism. To keep compatibility with the old closed-source binary? I feel that you should show some willingness to make things better in the future. No other SoC needs relocation in SPL as far as I know. What has happened with Rockchip SoCs to cause this? If you must add relocation please use CONFIG_SPL_RELOCATE since not relocating should be the default. And try to put the code hidden away in spl_reloc.c or something. Regards, Simon ^ permalink raw reply [flat|nested] 25+ messages in thread
* [U-Boot] [PATCH v2 2/3] spl: add relocation support【请注意，邮件由sjg@google.com代发】 2019-07-06 17:16 ` [U-Boot] [PATCH v2 2/3] spl: add relocation support【请注意，邮件由sjg@google.com代发】 Simon Glass @ 2019-07-07 0:36 ` Andy Yan 2019-08-13 9:35 ` Simon Glass 0 siblings, 1 reply; 25+ messages in thread From: Andy Yan @ 2019-07-07 0:36 UTC (permalink / raw) To: u-boot Hi Simon： Simon Glass <sjg@chromium.org> 于2019年7月7日周日 上午1:16写道： > Hi Andy, > > On Mon, 24 Jun 2019 at 04:37, Andy Yan <andy.yan@rock-chips.com> wrote: > > > > Hi Simon: > > > > Glad to see you online again. > > > > On 2019/6/23 上午3:10, Simon Glass wrote: > > > Hi Andy, > > > > > > On Tue, 28 May 2019 at 09:34, Andy Yan <andy.yan@rock-chips.com> > wrote: > > >> Hi Simon: > > >> > > >> On 2019/5/23 上午3:39, Simon Glass wrote: > > >> > > >> Hi Andy, > > >> > > >> On Tue, 21 May 2019 at 19:56, Andy Yan <andyshrk@gmail.com> wrote: > > >> > > >> Hi Simon: > > >> > > >> Simon Glass <sjg@chromium.org> 于2019年5月22日周三 上午8:28写道： > > >> > > >> Hi Andy, > > >> > > >> On Tue, 21 May 2019 at 00:51, Andy Yan <andy.yan@rock-chips.com> > wrote: > > >> > > >> Hi Simon: > > >> > > >> On 2019/5/20 下午11:35, Simon Glass wrote: > > >> > > >> Hi Andy, > > >> > > >> On Mon, 20 May 2019 at 00:34, Andy Yan <andy.yan@rock-chips.com> > wrote: > > >> > > >> Hi Simon: > > >> > > >> On 2019/5/19 上午12:26, Simon Glass wrote: > > >> > > >> Hi Andy, > > >> > > >> Instead of this could you: > > >> > > >> - move ATF? > > >> > > >> All rockchip based arm64 ATF run from the start 64KB of dram as this > > >> will give convenient for kernel manage the memory. > > >> > > >> On the other hand, change the ATF load address will break the > > >> compatibility of the exiting firmware. > > >> > > >> - change the SPL load address so it is not in the way (since TPL can > > >> load to any address) > > >> > > >> The SPL is loaded by bootrom after TPL back to bootrom, so the load > > >> address if fixed by bootrom code. > > >> > > >> I think you are creating a nightmare here. If you have to do things > > >> like this for older and smaller SoCs, OK. But it should not be used > > >> for newer ones that can do things properly. > > >> > > >> Most rockchip based SOC sram is small, even in the future soc > roadmap, > > >> this situation will still exist, larger sram means more cost. > > >> > > >> I believe the RK3399 has 192KB. What is the minimum size in new chips? > > >> > > >> The sram size of RK3328 is 32KB, and now the u-boot-tpl.bin of rk3328 > without storage drive is 28KB. > > >> The available sram size for TPL on RK3326 is 10KB, our another A35 > based IOT SOC has the same limitation. > > >> > > >> OK, I see. > > >> > > >> > > >> As for the current spl for rockchip soc in mainline, we use a > workaround > > >> by reserve large space at the head of spl(see > > >> CONFIG_ROCKCHIP_SPL_RESERVE_IRAM ), this generate a very large spl > binary. > > >> > > >> Yes. > > >> > > >> As for my patch, the spl relocation is disabled default, we only > enable > > >> it on necessary platform, so it won't hurt others . > > >> > > >> Well it adds more code and complexity. Perhaps it makes sense to add > > >> this, but I want to understand the need. > > >> > > >> The bootrom has so many limitations that it just creates pain. > > >> > > >> I know we can build mmc or other storage driver into TPL so we can use > > >> tpl load spl on some platform that sram is big enough, but there are > > >> also many rockchip soc has very small sram, so we tend to only do dram > > >> initialization in tpl, and let bootrom load next stage . > > >> > > >> See above > > >> > > >> For the consideration of software development, we also want to keep > TPL > > >> clean, only do dram initialization(as it current status), this make > our > > >> internal dram team work more simple, they don't need to care about > other > > >> modules like mmc. > > >> > > >> Yes I understand this, but the boot ROM should be provided as a > > >> library to call into: > > >> > > >> int mmc_read(void *addr, int start_block, int end_block) > > >> int spi_read(void *addr, int start_block, int end_block) > > >> > > >> Then SPL or TPL can use it without all the strange limitations we > have now. > > >> > > >> Since you probably already have these functions somewhere in the boot > > >> ROM, you could implement this using a function table somewhere in the > > >> ROM with a magic number before it, so that SPL can find it. > > >> > > >> The Bootrom do much more work than directly load the spl binary. It > will do somthing like checksum, look for the backup when the current image > is invalid, also including security check when secure boot is enabled. This > is why we did much work to add back_too_bootrom mechanism in mainline in > 2017. > > >> > > >> Yes I understand that, but it is also quite inflexible, and creates > > >> enormous problems with bootloaders. > > >> > > >> I am not suggesting that you remove functionality. I am suggesting > > >> that you allow bootloaders to call into some of it, to reduce the > > >> problems caused by the inflexible bootrom. > > >> > > >> > > >> I checked with people who write bootrom code these days, as > different chip written by different people from different team, it took a > bit long time to figure out this. > > >> > > >> Yes , bootrom have storage access api like > mmc_read/read_sfc_nand/read_sfc_nor/nandc_read, but bootrom does not > provide a fixed table for these api, and the address for these api are > different on different chip, this means we have to list the api address > chip by chip in SPL code. There is another thing, as the bootrom code are > written by different person, the api interface don't keep constant: > sfc_nor_read on one chip is sfc_nor_read(void *addr, int start, int len), > but on another chip is sfc_nor_read(int start, void *addr, int len), this > make things complicated. > > >> > > >> Also as what I mentioned before, the Bootrom do much more work than > directly load the spl binary, especially in secure boot mode, but the > bootrom don't want to export secure related api for security concern . > > >> > > >> So this seems not a good choice to reuse bootrom api in spl. > > > While I understand what you are saying, I don't think it would be hard > > > to add a little interface layer for each SoC which supports reading > > > from each type of device, and knows the SoC ROM address to call, and > > > deals with changing args, etc. > > > > > > Really, it should be a very small amount of code. And the benefit is a > > > large reduction in TPL/SPL code size and a lot less of the insane > > > hacks we ahve now! > > > > > > > Yes, it's not hard to add a wrapper for every soc from technical side, > > but it make things complicated. When we get a new soc, we need to check > > with the bootrom person for the storage api type by type, the we get a > > long header file nested with ''if chipA, else if chipB, esle if chipC", > > this looks not nice . > > I suggest having one header per SoC. > > Also, if you do talk to your chip people, ask them to use a consistent > API from now on, and put the table of function pointers (and perhaps > an API version) in the ROM itself. > > > > > What's more , there is one more issue, bootrom will not export the > > secure related api, so we can't do secure boot with this method. > > Why not? Making an API hidden does not help security. > > I honestly worry that no one at Rockchip is thinking about how to > actually implement a bootloader that covers all the chips that you > ship. Consistency takes effort. > > > > > I still prefer to reuse the existing relocation mechanism. > > To keep compatibility with the old closed-source binary? > > I feel that you should show some willingness to make things better in > the future. No other SoC needs relocation in SPL as far as I know. > Actually： There are ！ （1）Just do a grep about relocate_code function, you will see powerpc handle spl relocate themselves. (2) function spl_relocate_stack_gd written by yourself. What has happened with Rockchip SoCs to cause this? > > If you must add relocation please use CONFIG_SPL_RELOCATE since not > relocating should be the default. And try to put the code hidden away > in spl_reloc.c or something. > I have already reuse the existing CONFIG_SPL_SKIP_RELOCATE config in my patch. > Regards, > Simon > ^ permalink raw reply [flat|nested] 25+ messages in thread
* [U-Boot] [PATCH v2 2/3] spl: add relocation support【请注意，邮件由sjg@google.com代发】 2019-07-07 0:36 ` Andy Yan @ 2019-08-13 9:35 ` Simon Glass 0 siblings, 0 replies; 25+ messages in thread From: Simon Glass @ 2019-08-13 9:35 UTC (permalink / raw) To: u-boot Hi Andy, On Sat, 6 Jul 2019 at 18:36, Andy Yan <andyshrk@gmail.com> wrote: > > Hi Simon： > > Simon Glass <sjg@chromium.org> 于2019年7月7日周日 上午1:16写道： >> >> Hi Andy, >> >> On Mon, 24 Jun 2019 at 04:37, Andy Yan <andy.yan@rock-chips.com> wrote: >> > >> > Hi Simon: >> > >> > Glad to see you online again. >> > >> > On 2019/6/23 上午3:10, Simon Glass wrote: >> > > Hi Andy, >> > > >> > > On Tue, 28 May 2019 at 09:34, Andy Yan <andy.yan@rock-chips.com> wrote: >> > >> Hi Simon: >> > >> >> > >> On 2019/5/23 上午3:39, Simon Glass wrote: >> > >> >> > >> Hi Andy, >> > >> >> > >> On Tue, 21 May 2019 at 19:56, Andy Yan <andyshrk@gmail.com> wrote: >> > >> >> > >> Hi Simon: >> > >> >> > >> Simon Glass <sjg@chromium.org> 于2019年5月22日周三 上午8:28写道： >> > >> >> > >> Hi Andy, >> > >> >> > >> On Tue, 21 May 2019 at 00:51, Andy Yan <andy.yan@rock-chips.com> wrote: >> > >> >> > >> Hi Simon: >> > >> >> > >> On 2019/5/20 下午11:35, Simon Glass wrote: >> > >> >> > >> Hi Andy, >> > >> >> > >> On Mon, 20 May 2019 at 00:34, Andy Yan <andy.yan@rock-chips.com> wrote: >> > >> >> > >> Hi Simon: >> > >> >> > >> On 2019/5/19 上午12:26, Simon Glass wrote: >> > >> >> > >> Hi Andy, >> > >> >> > >> Instead of this could you: >> > >> >> > >> - move ATF? >> > >> >> > >> All rockchip based arm64 ATF run from the start 64KB of dram as this >> > >> will give convenient for kernel manage the memory. >> > >> >> > >> On the other hand, change the ATF load address will break the >> > >> compatibility of the exiting firmware. >> > >> >> > >> - change the SPL load address so it is not in the way (since TPL can >> > >> load to any address) >> > >> >> > >> The SPL is loaded by bootrom after TPL back to bootrom, so the load >> > >> address if fixed by bootrom code. >> > >> >> > >> I think you are creating a nightmare here. If you have to do things >> > >> like this for older and smaller SoCs, OK. But it should not be used >> > >> for newer ones that can do things properly. >> > >> >> > >> Most rockchip based SOC sram is small, even in the future soc roadmap, >> > >> this situation will still exist, larger sram means more cost. >> > >> >> > >> I believe the RK3399 has 192KB. What is the minimum size in new chips? >> > >> >> > >> The sram size of RK3328 is 32KB, and now the u-boot-tpl.bin of rk3328 without storage drive is 28KB. >> > >> The available sram size for TPL on RK3326 is 10KB, our another A35 based IOT SOC has the same limitation. >> > >> >> > >> OK, I see. >> > >> >> > >> >> > >> As for the current spl for rockchip soc in mainline, we use a workaround >> > >> by reserve large space at the head of spl(see >> > >> CONFIG_ROCKCHIP_SPL_RESERVE_IRAM ), this generate a very large spl binary. >> > >> >> > >> Yes. >> > >> >> > >> As for my patch, the spl relocation is disabled default, we only enable >> > >> it on necessary platform, so it won't hurt others . >> > >> >> > >> Well it adds more code and complexity. Perhaps it makes sense to add >> > >> this, but I want to understand the need. >> > >> >> > >> The bootrom has so many limitations that it just creates pain. >> > >> >> > >> I know we can build mmc or other storage driver into TPL so we can use >> > >> tpl load spl on some platform that sram is big enough, but there are >> > >> also many rockchip soc has very small sram, so we tend to only do dram >> > >> initialization in tpl, and let bootrom load next stage . >> > >> >> > >> See above >> > >> >> > >> For the consideration of software development, we also want to keep TPL >> > >> clean, only do dram initialization(as it current status), this make our >> > >> internal dram team work more simple, they don't need to care about other >> > >> modules like mmc. >> > >> >> > >> Yes I understand this, but the boot ROM should be provided as a >> > >> library to call into: >> > >> >> > >> int mmc_read(void *addr, int start_block, int end_block) >> > >> int spi_read(void *addr, int start_block, int end_block) >> > >> >> > >> Then SPL or TPL can use it without all the strange limitations we have now. >> > >> >> > >> Since you probably already have these functions somewhere in the boot >> > >> ROM, you could implement this using a function table somewhere in the >> > >> ROM with a magic number before it, so that SPL can find it. >> > >> >> > >> The Bootrom do much more work than directly load the spl binary. It will do somthing like checksum, look for the backup when the current image is invalid, also including security check when secure boot is enabled. This is why we did much work to add back_too_bootrom mechanism in mainline in 2017. >> > >> >> > >> Yes I understand that, but it is also quite inflexible, and creates >> > >> enormous problems with bootloaders. >> > >> >> > >> I am not suggesting that you remove functionality. I am suggesting >> > >> that you allow bootloaders to call into some of it, to reduce the >> > >> problems caused by the inflexible bootrom. >> > >> >> > >> >> > >> I checked with people who write bootrom code these days, as different chip written by different people from different team, it took a bit long time to figure out this. >> > >> >> > >> Yes , bootrom have storage access api like mmc_read/read_sfc_nand/read_sfc_nor/nandc_read, but bootrom does not provide a fixed table for these api, and the address for these api are different on different chip, this means we have to list the api address chip by chip in SPL code. There is another thing, as the bootrom code are written by different person, the api interface don't keep constant: sfc_nor_read on one chip is sfc_nor_read(void *addr, int start, int len), but on another chip is sfc_nor_read(int start, void *addr, int len), this make things complicated. >> > >> >> > >> Also as what I mentioned before, the Bootrom do much more work than directly load the spl binary, especially in secure boot mode, but the bootrom don't want to export secure related api for security concern . >> > >> >> > >> So this seems not a good choice to reuse bootrom api in spl. >> > > While I understand what you are saying, I don't think it would be hard >> > > to add a little interface layer for each SoC which supports reading >> > > from each type of device, and knows the SoC ROM address to call, and >> > > deals with changing args, etc. >> > > >> > > Really, it should be a very small amount of code. And the benefit is a >> > > large reduction in TPL/SPL code size and a lot less of the insane >> > > hacks we ahve now! >> > > >> > >> > Yes, it's not hard to add a wrapper for every soc from technical side, >> > but it make things complicated. When we get a new soc, we need to check >> > with the bootrom person for the storage api type by type, the we get a >> > long header file nested with ''if chipA, else if chipB, esle if chipC", >> > this looks not nice . >> >> I suggest having one header per SoC. >> >> Also, if you do talk to your chip people, ask them to use a consistent >> API from now on, and put the table of function pointers (and perhaps >> an API version) in the ROM itself. >> >> > >> > What's more , there is one more issue, bootrom will not export the >> > secure related api, so we can't do secure boot with this method. >> >> Why not? Making an API hidden does not help security. >> >> I honestly worry that no one at Rockchip is thinking about how to >> actually implement a bootloader that covers all the chips that you >> ship. Consistency takes effort. >> >> > >> > I still prefer to reuse the existing relocation mechanism. >> >> To keep compatibility with the old closed-source binary? >> >> I feel that you should show some willingness to make things better in >> the future. No other SoC needs relocation in SPL as far as I know. > > > Actually： There are ！ > （1）Just do a grep about relocate_code function, you will see powerpc handle spl relocate themselves. > (2) function spl_relocate_stack_gd written by yourself. > >> What has happened with Rockchip SoCs to cause this? > > >> >> If you must add relocation please use CONFIG_SPL_RELOCATE since not >> relocating should be the default. And try to put the code hidden away >> in spl_reloc.c or something. > > > > I have already reuse the existing CONFIG_SPL_SKIP_RELOCATE config in my patch. Right, but the default should be to not relocate, so please use the name above. Regards, Simon ^ permalink raw reply [flat|nested] 25+ messages in thread
* [U-Boot] [PATCH v2 2/3] spl: add relocation support【请注意，邮件由sjg@google.com代发】 2019-05-20 6:34 ` [U-Boot] [PATCH v2 2/3] spl: add relocation support【请注意，邮件由sjg@google.com代发】 Andy Yan 2019-05-20 15:35 ` Simon Glass @ 2019-05-20 15:58 ` Andre Przywara 2019-05-22 1:42 ` Andy Yan 1 sibling, 1 reply; 25+ messages in thread From: Andre Przywara @ 2019-05-20 15:58 UTC (permalink / raw) To: u-boot On Mon, 20 May 2019 14:34:01 +0800 Andy Yan <andy.yan@rock-chips.com> wrote: Hi, > On 2019/5/19 上午12:26, Simon Glass wrote: > > Hi Andy, > > > > Instead of this could you: > > > > - move ATF? > > All rockchip based arm64 ATF run from the start 64KB of dram as this > will give convenient for kernel manage the memory. This is just BL31 of ATF, right? ATF recently gained PIE support for BL31 [1], so by just enabling this in platform.mk you will get a relocatable BL31 image, with a very minimal runtime linker. Worked out of the box on Allwinner for me, but YMMV. So you could load newer ATF builds everywhere. Does that help you? > On the other hand, change the ATF load address will break the > compatibility of the exiting firmware. I am not sure what you mean with "compatibility of existing firmware"? Surely you combine all the firmware components (SPL/TPL/ATF/U-Boot proper) into one image? And there would be no real mix and match, with older pre-compiled builds? So by changing the ATF base address and the load address in TPL at the same time you won't have issues? Cheers, Andre. [1] https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/commit/?id=fc922ca87cc6af8277dc0eb710fc63a2957f0194 > > - change the SPL load address so it is not in the way (since TPL can > > load to any address) > > The SPL is loaded by bootrom after TPL back to bootrom, so the load > address if fixed by bootrom code. > > I know we can build mmc or other storage driver into TPL so we can use > tpl load spl on some platform that sram is big enough, but there are > also many rockchip soc has very small sram, so we tend to only do dram > initialization in tpl, and let bootrom load next stage . > > > - (in extremis) create a function which does a memmove() and a jump, > > copy it somewhere and run it (I think x86 does this) > > > > Regards, > > Simon > > > > On Thu, 16 May 2019 at 06:22, Andy Yan <andy.yan@rock-chips.com> wrote: > >> Some times we want to relocate spl code to dram after dram > >> initialization or relocate spl code to a high memory to avoid > >> code overid. > >> > >> For example on Rockchip armv8 platform, we run with boot flow > >> TPL->SPL->ATF->U-Boot. > >> TPL run in sram and is responsible for dram initialization. > >> SPL run from the start address of dram and is responsible for > >> loading ATF and U-Boot. > >> > >> The case here is that the ATF load address is from 64KB of dram, > >> which overlaps with spl code itself. > >> > >> So we want to relocate spl itself to high memory to aovid this. > >> > >> Signed-off-by: Andy Yan <andy.yan@rock-chips.com> > >> --- > >> > >> Changes in v2: > >> - Move Kconfig modification to PATCH 1/3 > >> > >> common/spl/spl.c | 55 ++++++++++++++++++++++++++++++++++++++++++++++++ > >> 1 file changed, 55 insertions(+) > >> > >> diff --git a/common/spl/spl.c b/common/spl/spl.c > >> index 88d4b8a9bf..affb65ccbd 100644 > >> --- a/common/spl/spl.c > >> +++ b/common/spl/spl.c > >> @@ -12,6 +12,7 @@ > >> #include <dm.h> > >> #include <handoff.h> > >> #include <spl.h> > >> +#include <asm/sections.h> > >> #include <asm/u-boot.h> > >> #include <nand.h> > >> #include <fat.h> > >> @@ -439,6 +440,28 @@ static int spl_common_init(bool setup_malloc) > >> return 0; > >> } > >> > >> +#if !defined(CONFIG_SPL_SKIP_RELOCATE) && !defined(CONFIG_TPL_BUILD) > >> +static void spl_setup_relocate(void) > >> +{ > >> + gd->relocaddr = CONFIG_SPL_RELOC_TEXT_BASE; > >> + gd->new_gd = (gd_t *)gd; > >> + gd->start_addr_sp = gd->relocaddr; > >> + gd->fdt_size = ALIGN(fdt_totalsize(gd->fdt_blob) + 0x1000, 32); > >> + > >> + gd->start_addr_sp -= gd->fdt_size; > >> + gd->new_fdt = (void *)gd->start_addr_sp; > >> + memcpy(gd->new_fdt, gd->fdt_blob, gd->fdt_size); > >> + gd->fdt_blob = gd->new_fdt; > >> + > >> + gd->reloc_off = gd->relocaddr - (unsigned long)__image_copy_start; > >> +} > >> +#else > >> +static void spl_setup_relocate(void) > >> +{ > >> + > >> +} > >> +#endif > >> + > >> void spl_set_bd(void) > >> { > >> /* > >> @@ -460,6 +483,8 @@ int spl_early_init(void) > >> return ret; > >> gd->flags |= GD_FLG_SPL_EARLY_INIT; > >> > >> + spl_setup_relocate(); > >> + > >> return 0; > >> } > >> > >> @@ -563,6 +588,34 @@ static int boot_from_devices(struct spl_image_info *spl_image, > >> return -ENODEV; > >> } > >> > >> +#if defined(CONFIG_DM) && !defined(CONFIG_SPL_SKIP_RELOCATE) && !defined(CONFIG_TPL_BUILD) > >> +static int spl_initr_dm(void) > >> +{ > >> + int ret; > >> + > >> + /* Save the pre-reloc driver model and start a new one */ > >> + gd->dm_root_f = gd->dm_root; > >> + gd->dm_root = NULL; > >> + bootstage_start(BOOTSTATE_ID_ACCUM_DM_R, "dm_r"); > >> + ret = dm_init_and_scan(false); > >> + bootstage_accum(BOOTSTATE_ID_ACCUM_DM_R); > >> + if (ret) > >> + return ret; > >> + > >> +#if defined(CONFIG_TIMER) > >> + gd->timer = NULL; > >> +#endif > >> + serial_init(); > >> + > >> + return 0; > >> +} > >> +#else > >> +static int spl_initr_dm(void) > >> +{ > >> + return 0; > >> +} > >> +#endif > >> + > >> void board_init_r(gd_t *dummy1, ulong dummy2) > >> { > >> u32 spl_boot_list[] = { > >> @@ -577,6 +630,8 @@ void board_init_r(gd_t *dummy1, ulong dummy2) > >> > >> debug(">>" SPL_TPL_PROMPT "board_init_r()\n"); > >> > >> + spl_initr_dm(); > >> + > >> spl_set_bd(); > >> > >> #if defined(CONFIG_SYS_SPL_MALLOC_START) > >> -- > >> 2.17.1 > >> > >> > >> > > > > > > ^ permalink raw reply [flat|nested] 25+ messages in thread
* [U-Boot] [PATCH v2 2/3] spl: add relocation support【请注意，邮件由sjg@google.com代发】 2019-05-20 15:58 ` Andre Przywara @ 2019-05-22 1:42 ` Andy Yan 2019-05-22 19:39 ` Simon Glass 0 siblings, 1 reply; 25+ messages in thread From: Andy Yan @ 2019-05-22 1:42 UTC (permalink / raw) To: u-boot Hi Andre: Andre Przywara <andre.przywara@arm.com> 于2019年5月20日周一 下午11:59写道： > On Mon, 20 May 2019 14:34:01 +0800 > Andy Yan <andy.yan@rock-chips.com> wrote: > > Hi, > > > On 2019/5/19 上午12:26, Simon Glass wrote: > > > Hi Andy, > > > > > > Instead of this could you: > > > > > > - move ATF? > > > > All rockchip based arm64 ATF run from the start 64KB of dram as this > > will give convenient for kernel manage the memory. > > This is just BL31 of ATF, right? > ATF recently gained PIE support for BL31 [1], so by just enabling this in > platform.mk you will get a relocatable BL31 image, with a very minimal > runtime linker. Worked out of the box on Allwinner for me, but YMMV. > So you could load newer ATF builds everywhere. > > This is not the root case, actually we want put ATF as close as possible to the start of dram, this give linux kernel convenient to manage the memory. > Does that help you? > > > On the other hand, change the ATF load address will break the > > compatibility of the exiting firmware. > > I am not sure what you mean with "compatibility of existing firmware"? > Surely you combine all the firmware components (SPL/TPL/ATF/U-Boot proper) > into one image? And there would be no real mix and match, with older > pre-compiled builds? So by changing the ATF base address and the load > address in TPL at the same time you won't have issues? > I mean older pre-compiled builds published by rockchip rkbin [1], many projects and popular boards directly use this , for example Armbian. How to change the base address of the pre-build binary? [1] https://github.com/rockchip-linux/rkbin > Cheers, > Andre. > > [1] > https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/commit/?id=fc922ca87cc6af8277dc0eb710fc63a2957f0194 > > > > - change the SPL load address so it is not in the way (since TPL can > > > load to any address) > > > > The SPL is loaded by bootrom after TPL back to bootrom, so the load > > address if fixed by bootrom code. > > > > I know we can build mmc or other storage driver into TPL so we can use > > tpl load spl on some platform that sram is big enough, but there are > > also many rockchip soc has very small sram, so we tend to only do dram > > initialization in tpl, and let bootrom load next stage . > > > > > - (in extremis) create a function which does a memmove() and a jump, > > > copy it somewhere and run it (I think x86 does this) > > > > > > Regards, > > > Simon > > > > > > On Thu, 16 May 2019 at 06:22, Andy Yan <andy.yan@rock-chips.com> > wrote: > > >> Some times we want to relocate spl code to dram after dram > > >> initialization or relocate spl code to a high memory to avoid > > >> code overid. > > >> > > >> For example on Rockchip armv8 platform, we run with boot flow > > >> TPL->SPL->ATF->U-Boot. > > >> TPL run in sram and is responsible for dram initialization. > > >> SPL run from the start address of dram and is responsible for > > >> loading ATF and U-Boot. > > >> > > >> The case here is that the ATF load address is from 64KB of dram, > > >> which overlaps with spl code itself. > > >> > > >> So we want to relocate spl itself to high memory to aovid this. > > >> > > >> Signed-off-by: Andy Yan <andy.yan@rock-chips.com> > > >> --- > > >> > > >> Changes in v2: > > >> - Move Kconfig modification to PATCH 1/3 > > >> > > >> common/spl/spl.c | 55 > ++++++++++++++++++++++++++++++++++++++++++++++++ > > >> 1 file changed, 55 insertions(+) > > >> > > >> diff --git a/common/spl/spl.c b/common/spl/spl.c > > >> index 88d4b8a9bf..affb65ccbd 100644 > > >> --- a/common/spl/spl.c > > >> +++ b/common/spl/spl.c > > >> @@ -12,6 +12,7 @@ > > >> #include <dm.h> > > >> #include <handoff.h> > > >> #include <spl.h> > > >> +#include <asm/sections.h> > > >> #include <asm/u-boot.h> > > >> #include <nand.h> > > >> #include <fat.h> > > >> @@ -439,6 +440,28 @@ static int spl_common_init(bool setup_malloc) > > >> return 0; > > >> } > > >> > > >> +#if !defined(CONFIG_SPL_SKIP_RELOCATE) && !defined(CONFIG_TPL_BUILD) > > >> +static void spl_setup_relocate(void) > > >> +{ > > >> + gd->relocaddr = CONFIG_SPL_RELOC_TEXT_BASE; > > >> + gd->new_gd = (gd_t *)gd; > > >> + gd->start_addr_sp = gd->relocaddr; > > >> + gd->fdt_size = ALIGN(fdt_totalsize(gd->fdt_blob) + 0x1000, > 32); > > >> + > > >> + gd->start_addr_sp -= gd->fdt_size; > > >> + gd->new_fdt = (void *)gd->start_addr_sp; > > >> + memcpy(gd->new_fdt, gd->fdt_blob, gd->fdt_size); > > >> + gd->fdt_blob = gd->new_fdt; > > >> + > > >> + gd->reloc_off = gd->relocaddr - (unsigned > long)__image_copy_start; > > >> +} > > >> +#else > > >> +static void spl_setup_relocate(void) > > >> +{ > > >> + > > >> +} > > >> +#endif > > >> + > > >> void spl_set_bd(void) > > >> { > > >> /* > > >> @@ -460,6 +483,8 @@ int spl_early_init(void) > > >> return ret; > > >> gd->flags |= GD_FLG_SPL_EARLY_INIT; > > >> > > >> + spl_setup_relocate(); > > >> + > > >> return 0; > > >> } > > >> > > >> @@ -563,6 +588,34 @@ static int boot_from_devices(struct > spl_image_info *spl_image, > > >> return -ENODEV; > > >> } > > >> > > >> +#if defined(CONFIG_DM) && !defined(CONFIG_SPL_SKIP_RELOCATE) && > !defined(CONFIG_TPL_BUILD) > > >> +static int spl_initr_dm(void) > > >> +{ > > >> + int ret; > > >> + > > >> + /* Save the pre-reloc driver model and start a new one */ > > >> + gd->dm_root_f = gd->dm_root; > > >> + gd->dm_root = NULL; > > >> + bootstage_start(BOOTSTATE_ID_ACCUM_DM_R, "dm_r"); > > >> + ret = dm_init_and_scan(false); > > >> + bootstage_accum(BOOTSTATE_ID_ACCUM_DM_R); > > >> + if (ret) > > >> + return ret; > > >> + > > >> +#if defined(CONFIG_TIMER) > > >> + gd->timer = NULL; > > >> +#endif > > >> + serial_init(); > > >> + > > >> + return 0; > > >> +} > > >> +#else > > >> +static int spl_initr_dm(void) > > >> +{ > > >> + return 0; > > >> +} > > >> +#endif > > >> + > > >> void board_init_r(gd_t *dummy1, ulong dummy2) > > >> { > > >> u32 spl_boot_list[] = { > > >> @@ -577,6 +630,8 @@ void board_init_r(gd_t *dummy1, ulong dummy2) > > >> > > >> debug(">>" SPL_TPL_PROMPT "board_init_r()\n"); > > >> > > >> + spl_initr_dm(); > > >> + > > >> spl_set_bd(); > > >> > > >> #if defined(CONFIG_SYS_SPL_MALLOC_START) > > >> -- > > >> 2.17.1 > > >> > > >> > > >> > > > > > > > > > > > > _______________________________________________ > U-Boot mailing list > U-Boot at lists.denx.de > https://lists.denx.de/listinfo/u-boot > ^ permalink raw reply [flat|nested] 25+ messages in thread
* [U-Boot] [PATCH v2 2/3] spl: add relocation support【请注意，邮件由sjg@google.com代发】 2019-05-22 1:42 ` Andy Yan @ 2019-05-22 19:39 ` Simon Glass 2019-05-28 8:47 ` Andy Yan 0 siblings, 1 reply; 25+ messages in thread From: Simon Glass @ 2019-05-22 19:39 UTC (permalink / raw) To: u-boot Hi Andy, On Tue, 21 May 2019 at 19:43, Andy Yan <andyshrk@gmail.com> wrote: > > Hi Andre: > > Andre Przywara <andre.przywara@arm.com> 于2019年5月20日周一 下午11:59写道： > > > On Mon, 20 May 2019 14:34:01 +0800 > > Andy Yan <andy.yan@rock-chips.com> wrote: > > > > Hi, > > > > > On 2019/5/19 上午12:26, Simon Glass wrote: > > > > Hi Andy, > > > > > > > > Instead of this could you: > > > > > > > > - move ATF? > > > > > > All rockchip based arm64 ATF run from the start 64KB of dram as this > > > will give convenient for kernel manage the memory. > > > > This is just BL31 of ATF, right? > > ATF recently gained PIE support for BL31 [1], so by just enabling this in > > platform.mk you will get a relocatable BL31 image, with a very minimal > > runtime linker. Worked out of the box on Allwinner for me, but YMMV. > > So you could load newer ATF builds everywhere. > > > > > This is not the root case, actually we want put ATF as close as possible to > the start of dram, this give linux kernel convenient to manage the memory. But instead of 64KB you could put it at 32KB or 128KB. It's still in the first 1MB. Linux won't care, right? > > > > > Does that help you? > > > > > On the other hand, change the ATF load address will break the > > > compatibility of the exiting firmware. > > > > I am not sure what you mean with "compatibility of existing firmware"? > > Surely you combine all the firmware components (SPL/TPL/ATF/U-Boot proper) > > into one image? And there would be no real mix and match, with older > > pre-compiled builds? So by changing the ATF base address and the load > > address in TPL at the same time you won't have issues? > > > > I mean older pre-compiled builds published by rockchip rkbin [1], many > projects and popular boards directly use this , for example Armbian. How to > change the base address of the pre-build binary? > [1] https://github.com/rockchip-linux/rkbin Perhaps I am misunderstanding your intent here, but mainline U-Boot should not be bound to the design decisions of old closed-source binaries. [...] Regards, Simon ^ permalink raw reply [flat|nested] 25+ messages in thread
* [U-Boot] [PATCH v2 2/3] spl: add relocation support【请注意，邮件由sjg@google.com代发】 2019-05-22 19:39 ` Simon Glass @ 2019-05-28 8:47 ` Andy Yan 2019-06-22 19:10 ` Simon Glass 0 siblings, 1 reply; 25+ messages in thread From: Andy Yan @ 2019-05-28 8:47 UTC (permalink / raw) To: u-boot Hi Simon: On 2019/5/23 上午3:39, Simon Glass wrote: > Hi Andy, > > On Tue, 21 May 2019 at 19:43, Andy Yan <andyshrk@gmail.com> wrote: >> Hi Andre: >> >> Andre Przywara <andre.przywara@arm.com> 于2019年5月20日周一 下午11:59写道： >> >>> On Mon, 20 May 2019 14:34:01 +0800 >>> Andy Yan <andy.yan@rock-chips.com> wrote: >>> >>> Hi, >>> >>>> On 2019/5/19 上午12:26, Simon Glass wrote: >>>>> Hi Andy, >>>>> >>>>> Instead of this could you: >>>>> >>>>> - move ATF? >>>> All rockchip based arm64 ATF run from the start 64KB of dram as this >>>> will give convenient for kernel manage the memory. >>> This is just BL31 of ATF, right? >>> ATF recently gained PIE support for BL31 [1], so by just enabling this in >>> platform.mk you will get a relocatable BL31 image, with a very minimal >>> runtime linker. Worked out of the box on Allwinner for me, but YMMV. >>> So you could load newer ATF builds everywhere. >>> >>> >> This is not the root case, actually we want put ATF as close as possible to >> the start of dram, this give linux kernel convenient to manage the memory. > But instead of 64KB you could put it at 32KB or 128KB. It's still in > the first 1MB. Linux won't care, right? > >> >> >>> Does that help you? >>> >>>> On the other hand, change the ATF load address will break the >>>> compatibility of the exiting firmware. >>> I am not sure what you mean with "compatibility of existing firmware"? >>> Surely you combine all the firmware components (SPL/TPL/ATF/U-Boot proper) >>> into one image? And there would be no real mix and match, with older >>> pre-compiled builds? So by changing the ATF base address and the load >>> address in TPL at the same time you won't have issues? >>> >> I mean older pre-compiled builds published by rockchip rkbin [1], many >> projects and popular boards directly use this , for example Armbian. How to >> change the base address of the pre-build binary? >> [1] https://github.com/rockchip-linux/rkbin > Perhaps I am misunderstanding your intent here, but mainline U-Boot > should not be bound to the design decisions of old closed-source > binaries. Indeed rockchip have submit the ATF support for rockchip platforms to ATF mainline. But the situation is: we see many people like directly use the pre-build binary from rkbin, they are used on many popular boards and projects. Armbian is one of the example for this[0] , it use mainline u-boot, but use atf from rkbin for some boards. So we are really care about the compatibility. [0]https://github.com/armbian/build/blob/master/config/sources/rockchip64.conf <https://github.com/armbian/build/blob/master/config/sources/rockchip64.conf> > [...] > > Regards, > Simon > > > ^ permalink raw reply [flat|nested] 25+ messages in thread
* [U-Boot] [PATCH v2 2/3] spl: add relocation support【请注意，邮件由sjg@google.com代发】 2019-05-28 8:47 ` Andy Yan @ 2019-06-22 19:10 ` Simon Glass 0 siblings, 0 replies; 25+ messages in thread From: Simon Glass @ 2019-06-22 19:10 UTC (permalink / raw) To: u-boot Hi, On Tue, 28 May 2019 at 09:47, Andy Yan <andy.yan@rock-chips.com> wrote: > > Hi Simon: > > On 2019/5/23 上午3:39, Simon Glass wrote: > > Hi Andy, > > On Tue, 21 May 2019 at 19:43, Andy Yan <andyshrk@gmail.com> wrote: > > Hi Andre: > > Andre Przywara <andre.przywara@arm.com> 于2019年5月20日周一 下午11:59写道： > > On Mon, 20 May 2019 14:34:01 +0800 > Andy Yan <andy.yan@rock-chips.com> wrote: > > Hi, > > On 2019/5/19 上午12:26, Simon Glass wrote: > > Hi Andy, > > Instead of this could you: > > - move ATF? > > All rockchip based arm64 ATF run from the start 64KB of dram as this > will give convenient for kernel manage the memory. > > This is just BL31 of ATF, right? > ATF recently gained PIE support for BL31 [1], so by just enabling this in > platform.mk you will get a relocatable BL31 image, with a very minimal > runtime linker. Worked out of the box on Allwinner for me, but YMMV. > So you could load newer ATF builds everywhere. > > > This is not the root case, actually we want put ATF as close as possible to > the start of dram, this give linux kernel convenient to manage the memory. > > But instead of 64KB you could put it at 32KB or 128KB. It's still in > the first 1MB. Linux won't care, right? > > > > Does that help you? > > On the other hand, change the ATF load address will break the > compatibility of the exiting firmware. > > I am not sure what you mean with "compatibility of existing firmware"? > Surely you combine all the firmware components (SPL/TPL/ATF/U-Boot proper) > into one image? And there would be no real mix and match, with older > pre-compiled builds? So by changing the ATF base address and the load > address in TPL at the same time you won't have issues? > > I mean older pre-compiled builds published by rockchip rkbin [1], many > projects and popular boards directly use this , for example Armbian. How to > change the base address of the pre-build binary? > [1] https://github.com/rockchip-linux/rkbin > > Perhaps I am misunderstanding your intent here, but mainline U-Boot > should not be bound to the design decisions of old closed-source > binaries. > > Indeed rockchip have submit the ATF support for rockchip platforms to ATF mainline. But the situation is: we see many people like directly use the pre-build binary from rkbin, they are used on many popular boards and projects. Armbian is one of the example for this[0] , it use mainline u-boot, but use atf from rkbin for some boards. > > So we are really care about the compatibility. OK I understand that. But perhaps for your newer chips you can start using U-Boot SPL instead of rkbin? Then, we can move away from the limitations. > > [0]https://github.com/armbian/build/blob/master/config/sources/rockchip64.conf > > [...] > Regards, Simon ^ permalink raw reply [flat|nested] 25+ messages in thread
* [U-Boot] [PATCH v2 3/3] arm: add spl relocation support for arm 2019-05-16 12:19 [U-Boot] [PATCH v2 0/3] Enable spl relocation on arm Andy Yan 2019-05-16 12:21 ` [U-Boot] [PATCH v2 1/3] powerpc: Convert CONFIG_SPL_RELOC_TEXT_BASE to Kconfig Andy Yan 2019-05-16 12:21 ` [U-Boot] [PATCH v2 2/3] spl: add relocation support Andy Yan @ 2019-05-16 12:22 ` Andy Yan 2 siblings, 0 replies; 25+ messages in thread From: Andy Yan @ 2019-05-16 12:22 UTC (permalink / raw) To: u-boot Some times we want to relocate spl code to dram after dram initialization or relocate spl code to a high memory to avoid code overid. For example on Rockchip armv8 platform, we run with boot flow TPL->SPL->ATF->U-Boot. TPL run in sram and is responsible for dram initialization. SPL run from the start address of dram and is responsible for loading ATF and U-Boot. The case here is that the ATF load address is from 64KB of dram, which overlaps with spl code itself. So we want to relocate spl itself to high memory to aovid this. Signed-off-by: Andy Yan <andy.yan@rock-chips.com> --- Changes in v2: - Add more detial commit message arch/arm/config.mk | 6 ++++++ arch/arm/cpu/armv8/start.S | 4 ++++ arch/arm/cpu/armv8/u-boot-spl.lds | 17 +++++++++++++++++ arch/arm/lib/Makefile | 2 +- arch/arm/lib/crt0_64.S | 3 ++- 5 files changed, 30 insertions(+), 2 deletions(-) diff --git a/arch/arm/config.mk b/arch/arm/config.mk index f25603109e..7f6ad89601 100644 --- a/arch/arm/config.mk +++ b/arch/arm/config.mk @@ -102,6 +102,12 @@ endif # needed for relocation LDFLAGS_u-boot += -pie +ifndef CONFIG_SPL_SKIP_RELOCATE +LDFLAGS_u-boot-spl = -pie +else +SPL_LDFLAGS_u-boot-spl = +endif + # # FIXME: binutils versions < 2.22 have a bug in the assembler where # branches to weak symbols can be incorrectly optimized in thumb mode diff --git a/arch/arm/cpu/armv8/start.S b/arch/arm/cpu/armv8/start.S index fe52166e28..a7dad3cd69 100644 --- a/arch/arm/cpu/armv8/start.S +++ b/arch/arm/cpu/armv8/start.S @@ -35,7 +35,11 @@ _start: .globl _TEXT_BASE _TEXT_BASE: +#if defined(CONFIG_SPL_BUILD) + .quad CONFIG_SPL_TEXT_BASE +#else .quad CONFIG_SYS_TEXT_BASE +#endif /* * These are defined in the linker script. diff --git a/arch/arm/cpu/armv8/u-boot-spl.lds b/arch/arm/cpu/armv8/u-boot-spl.lds index ccbf359bd1..64102afc8b 100644 --- a/arch/arm/cpu/armv8/u-boot-spl.lds +++ b/arch/arm/cpu/armv8/u-boot-spl.lds @@ -53,6 +53,23 @@ SECTIONS *(.__end) } >.sram +#ifndef CONFIG_SPL_SKIP_RELOCATE + . = ALIGN(8); + + .rel_dyn_start : + { + *(.__rel_dyn_start) + } >.sram + + .rela.dyn : { + *(.rela*) + } >.sram + + .rel_dyn_end : + { + *(.__rel_dyn_end) + } >.sram +#endif _image_binary_end = .; .bss_start (NOLOAD) : { diff --git a/arch/arm/lib/Makefile b/arch/arm/lib/Makefile index 48ee6c3c60..f27b3fb79f 100644 --- a/arch/arm/lib/Makefile +++ b/arch/arm/lib/Makefile @@ -21,7 +21,7 @@ else obj-y += setjmp.o endif -ifndef CONFIG_SPL_BUILD +ifndef CONFIG_TPL_BUILD ifdef CONFIG_ARM64 obj-y += relocate_64.o else diff --git a/arch/arm/lib/crt0_64.S b/arch/arm/lib/crt0_64.S index d6b632aa87..e5605fe325 100644 --- a/arch/arm/lib/crt0_64.S +++ b/arch/arm/lib/crt0_64.S @@ -89,7 +89,8 @@ ENTRY(_main) mov x0, #0 bl board_init_f -#if !defined(CONFIG_SPL_BUILD) +#if (defined(CONFIG_SPL_BUILD) && !defined(CONFIG_TPL_BUILD) && !defined(CONFIG_SPL_SKIP_RELOCATE)) || \ + !defined(CONFIG_SPL_BUILD) /* * Set up intermediate environment (new sp and gd) and call * relocate_code(addr_moni). Trick here is that we'll return -- 2.17.1 ^ permalink raw reply related [flat|nested] 25+ messages in thread
end of thread, other threads:[~2019-08-13 9:35 UTC | newest] Thread overview: 25+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2019-05-16 12:19 [U-Boot] [PATCH v2 0/3] Enable spl relocation on arm Andy Yan 2019-05-16 12:21 ` [U-Boot] [PATCH v2 1/3] powerpc: Convert CONFIG_SPL_RELOC_TEXT_BASE to Kconfig Andy Yan 2019-05-16 12:21 ` [U-Boot] [PATCH v2 2/3] spl: add relocation support Andy Yan 2019-05-17 8:34 ` Lukasz Majewski 2019-05-17 9:03 ` Andy Yan 2019-05-18 16:26 ` Simon Glass 2019-05-20 6:34 ` [U-Boot] [PATCH v2 2/3] spl: add relocation support【请注意，邮件由sjg@google.com代发】 Andy Yan 2019-05-20 15:35 ` Simon Glass 2019-05-21 6:50 ` Andy Yan 2019-05-22 0:28 ` Simon Glass 2019-05-22 1:56 ` Andy Yan 2019-05-22 19:39 ` Simon Glass 2019-05-28 8:33 ` Andy Yan 2019-06-22 19:10 ` Simon Glass 2019-06-24 10:36 ` Andy Yan 2019-06-30 13:03 ` [U-Boot] [PATCH v2 2/3] spl: add relocation support Kever Yang 2019-07-06 17:16 ` [U-Boot] [PATCH v2 2/3] spl: add relocation support【请注意，邮件由sjg@google.com代发】 Simon Glass 2019-07-07 0:36 ` Andy Yan 2019-08-13 9:35 ` Simon Glass 2019-05-20 15:58 ` Andre Przywara 2019-05-22 1:42 ` Andy Yan 2019-05-22 19:39 ` Simon Glass 2019-05-28 8:47 ` Andy Yan 2019-06-22 19:10 ` Simon Glass 2019-05-16 12:22 ` [U-Boot] [PATCH v2 3/3] arm: add spl relocation support for arm Andy Yan
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.