All of lore.kernel.org
 help / color / mirror / Atom feed
* [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 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

* [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  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: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-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  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: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  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-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 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

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.