* [U-Boot] [PATCH v2 01/11] Kconfig: Separate AM33XX SOC config from target board config
2016-08-22 15:21 [U-Boot] [PATCH v2 00/11] Allow secure boot on AM33xx devices Andrew F. Davis
@ 2016-08-22 15:21 ` Andrew F. Davis
2016-08-26 20:12 ` Tom Rini
2016-08-22 15:21 ` [U-Boot] [PATCH v2 02/11] am33xx: config.mk: Add support for additional secure boot image types Andrew F. Davis
` (9 subsequent siblings)
10 siblings, 1 reply; 19+ messages in thread
From: Andrew F. Davis @ 2016-08-22 15:21 UTC (permalink / raw)
To: u-boot
The config option AM33XX is used in several boards and should be
defined as a stand-alone option for this SOC. We break this out
from TARGET_AM335X_* then enable AM33XX on in all the boards that
used TARGET_AM335X_* to eliminate any functional change with
this patch. Also conditionally define this in ti_am335x_common.h to prevent
redefinition. The definition can be removed completely when all platforms
that include this header have this definition added to their defconfig.
This is similar to what has already been done in
9de852642cae ("arm: Kconfig: Add support for AM43xx SoC specific Kconfig")
and is done for the same reasons.
Signed-off-by: Andrew F. Davis <afd@ti.com>
---
arch/arm/Kconfig | 51 +++++++-----------------------
arch/arm/cpu/armv7/am33xx/Kconfig | 49 ++++++++++++++++++++++++++++
configs/am335x_baltos_defconfig | 1 +
configs/am335x_boneblack_defconfig | 1 +
configs/am335x_boneblack_vboot_defconfig | 1 +
configs/am335x_evm_defconfig | 1 +
configs/am335x_evm_nor_defconfig | 1 +
configs/am335x_evm_norboot_defconfig | 1 +
configs/am335x_evm_spiboot_defconfig | 1 +
configs/am335x_evm_usbspl_defconfig | 1 +
configs/am335x_igep0033_defconfig | 1 +
configs/am335x_shc_defconfig | 1 +
configs/am335x_shc_ict_defconfig | 1 +
configs/am335x_shc_netboot_defconfig | 1 +
configs/am335x_shc_prompt_defconfig | 1 +
configs/am335x_shc_sdboot_defconfig | 1 +
configs/am335x_shc_sdboot_prompt_defconfig | 1 +
configs/am335x_sl50_defconfig | 1 +
include/configs/ti_am335x_common.h | 2 ++
19 files changed, 78 insertions(+), 40 deletions(-)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 5ac9401..b4bdf8a 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -331,14 +331,6 @@ config TARGET_PEPPER
select DM_SERIAL
select DM_GPIO
-config TARGET_AM335X_IGEP0033
- bool "Support am335x_igep0033"
- select CPU_V7
- select SUPPORT_SPL
- select DM
- select DM_SERIAL
- select DM_GPIO
-
config TARGET_PCM051
bool "Support pcm051"
select CPU_V7
@@ -403,38 +395,6 @@ config TARGET_PENGWYN
select DM_SERIAL
select DM_GPIO
-config TARGET_AM335X_BALTOS
- bool "Support am335x_baltos"
- select CPU_V7
- select SUPPORT_SPL
- select DM
- select DM_SERIAL
- select DM_GPIO
-
-config TARGET_AM335X_EVM
- bool "Support am335x_evm"
- select CPU_V7
- select SUPPORT_SPL
- select DM
- select DM_SERIAL
- select DM_GPIO
- select TI_I2C_BOARD_DETECT
-
-config TARGET_AM335X_SHC
- bool "Support am335x based shc board from bosch"
- select CPU_V7
- select SUPPORT_SPL
- select DM
- select DM_SERIAL
- select DM_GPIO
-
-config TARGET_AM335X_SL50
- bool "Support am335x_sl50"
- select CPU_V7
- select SUPPORT_SPL
- select DM
- select DM_SERIAL
-
config TARGET_BAV335X
bool "Support bav335x"
select CPU_V7
@@ -579,6 +539,17 @@ config AM43XX
protocols, dual camera support, optional 3D graphics
and an optional customer programmable secure boot.
+config AM33XX
+ bool "AM33XX SoC"
+ select CPU_V7
+ select SUPPORT_SPL
+ help
+ Support for AM335x SOC from Texas Instruments.
+ The AM335x high performance SOC features a Cortex-A8
+ ARM core, a dual core PRU-ICSS for industrial Ethernet
+ protocols, optional 3D graphics and an optional customer
+ programmable secure boot.
+
config RMOBILE
bool "Renesas ARM SoCs"
select CPU_V7
diff --git a/arch/arm/cpu/armv7/am33xx/Kconfig b/arch/arm/cpu/armv7/am33xx/Kconfig
index dc51e9b..d2fc31c 100644
--- a/arch/arm/cpu/armv7/am33xx/Kconfig
+++ b/arch/arm/cpu/armv7/am33xx/Kconfig
@@ -1,3 +1,50 @@
+if AM33XX
+
+choice
+ prompt "AM33xx board select"
+ optional
+
+config TARGET_AM335X_EVM
+ bool "Support am335x_evm"
+ select DM
+ select DM_SERIAL
+ select DM_GPIO
+ select TI_I2C_BOARD_DETECT
+ help
+ This option specifies support for the AM335x
+ GP and HS EVM development platforms. The AM335x
+ GP EVM is a standalone test, development, and
+ evaluation module system that enables developers
+ to write software and develop hardware around
+ an AM335x processor subsystem.
+
+config TARGET_AM335X_BALTOS
+ bool "Support am335x_baltos"
+ select DM
+ select DM_SERIAL
+ select DM_GPIO
+
+config TARGET_AM335X_IGEP0033
+ bool "Support am335x_igep0033"
+ select DM
+ select DM_SERIAL
+ select DM_GPIO
+
+config TARGET_AM335X_SHC
+ bool "Support am335x based shc board from bosch"
+ select DM
+ select DM_SERIAL
+ select DM_GPIO
+
+config TARGET_AM335X_SL50
+ bool "Support am335x_sl50"
+ select DM
+ select DM_SERIAL
+
+endchoice
+
+endif
+
if AM43XX
config TARGET_AM43XX_EVM
bool "Support am43xx_evm"
@@ -9,7 +56,9 @@ config TARGET_AM43XX_EVM
evaluation module system that enables developers
to write software and develop hardware around
an AM43xx processor subsystem.
+endif
+if AM43XX || AM33XX
config ISW_ENTRY_ADDR
hex "Address in memory or XIP flash of bootloader entry point"
help
diff --git a/configs/am335x_baltos_defconfig b/configs/am335x_baltos_defconfig
index 78f55cc..b6cfd07 100644
--- a/configs/am335x_baltos_defconfig
+++ b/configs/am335x_baltos_defconfig
@@ -1,4 +1,5 @@
CONFIG_ARM=y
+CONFIG_AM33XX=y
CONFIG_TARGET_AM335X_BALTOS=y
CONFIG_SPL_STACK_R_ADDR=0x82000000
CONFIG_SPL=y
diff --git a/configs/am335x_boneblack_defconfig b/configs/am335x_boneblack_defconfig
index d310e0b..5fabff6 100644
--- a/configs/am335x_boneblack_defconfig
+++ b/configs/am335x_boneblack_defconfig
@@ -1,4 +1,5 @@
CONFIG_ARM=y
+CONFIG_AM33XX=y
CONFIG_TARGET_AM335X_EVM=y
CONFIG_SPL_STACK_R_ADDR=0x82000000
CONFIG_SPL=y
diff --git a/configs/am335x_boneblack_vboot_defconfig b/configs/am335x_boneblack_vboot_defconfig
index c2f09cb..b47b51f 100644
--- a/configs/am335x_boneblack_vboot_defconfig
+++ b/configs/am335x_boneblack_vboot_defconfig
@@ -1,4 +1,5 @@
CONFIG_ARM=y
+CONFIG_AM33XX=y
CONFIG_TARGET_AM335X_EVM=y
CONFIG_SPL_STACK_R_ADDR=0x82000000
CONFIG_DEFAULT_DEVICE_TREE="am335x-boneblack"
diff --git a/configs/am335x_evm_defconfig b/configs/am335x_evm_defconfig
index 6885230..b344bb7 100644
--- a/configs/am335x_evm_defconfig
+++ b/configs/am335x_evm_defconfig
@@ -1,4 +1,5 @@
CONFIG_ARM=y
+CONFIG_AM33XX=y
CONFIG_TARGET_AM335X_EVM=y
CONFIG_SPL_STACK_R_ADDR=0x82000000
CONFIG_DEFAULT_DEVICE_TREE="am335x-evm"
diff --git a/configs/am335x_evm_nor_defconfig b/configs/am335x_evm_nor_defconfig
index 76a004e..e434dec 100644
--- a/configs/am335x_evm_nor_defconfig
+++ b/configs/am335x_evm_nor_defconfig
@@ -1,4 +1,5 @@
CONFIG_ARM=y
+CONFIG_AM33XX=y
CONFIG_TARGET_AM335X_EVM=y
CONFIG_SPL_STACK_R_ADDR=0x82000000
CONFIG_NOR=y
diff --git a/configs/am335x_evm_norboot_defconfig b/configs/am335x_evm_norboot_defconfig
index 99fc555..063eea7 100644
--- a/configs/am335x_evm_norboot_defconfig
+++ b/configs/am335x_evm_norboot_defconfig
@@ -1,4 +1,5 @@
CONFIG_ARM=y
+CONFIG_AM33XX=y
CONFIG_TARGET_AM335X_EVM=y
CONFIG_NOR=y
CONFIG_NOR_BOOT=y
diff --git a/configs/am335x_evm_spiboot_defconfig b/configs/am335x_evm_spiboot_defconfig
index 2fe1a25..89f472d 100644
--- a/configs/am335x_evm_spiboot_defconfig
+++ b/configs/am335x_evm_spiboot_defconfig
@@ -1,4 +1,5 @@
CONFIG_ARM=y
+CONFIG_AM33XX=y
CONFIG_TARGET_AM335X_EVM=y
CONFIG_SPL_STACK_R_ADDR=0x82000000
CONFIG_SPL=y
diff --git a/configs/am335x_evm_usbspl_defconfig b/configs/am335x_evm_usbspl_defconfig
index cba5e84..b689181 100644
--- a/configs/am335x_evm_usbspl_defconfig
+++ b/configs/am335x_evm_usbspl_defconfig
@@ -1,4 +1,5 @@
CONFIG_ARM=y
+CONFIG_AM33XX=y
CONFIG_TARGET_AM335X_EVM=y
CONFIG_SPL_STACK_R_ADDR=0x82000000
CONFIG_SPL=y
diff --git a/configs/am335x_igep0033_defconfig b/configs/am335x_igep0033_defconfig
index d6022a3..33e0637 100644
--- a/configs/am335x_igep0033_defconfig
+++ b/configs/am335x_igep0033_defconfig
@@ -1,4 +1,5 @@
CONFIG_ARM=y
+CONFIG_AM33XX=y
CONFIG_TARGET_AM335X_IGEP0033=y
CONFIG_SPL_STACK_R_ADDR=0x82000000
CONFIG_SPL=y
diff --git a/configs/am335x_shc_defconfig b/configs/am335x_shc_defconfig
index c83311f..04d1c91 100644
--- a/configs/am335x_shc_defconfig
+++ b/configs/am335x_shc_defconfig
@@ -1,4 +1,5 @@
CONFIG_ARM=y
+CONFIG_AM33XX=y
CONFIG_TARGET_AM335X_SHC=y
CONFIG_SERIES=y
CONFIG_SPL_STACK_R_ADDR=0x82000000
diff --git a/configs/am335x_shc_ict_defconfig b/configs/am335x_shc_ict_defconfig
index bfb56b2..999dc60 100644
--- a/configs/am335x_shc_ict_defconfig
+++ b/configs/am335x_shc_ict_defconfig
@@ -1,4 +1,5 @@
CONFIG_ARM=y
+CONFIG_AM33XX=y
CONFIG_TARGET_AM335X_SHC=y
CONFIG_SHC_ICT=y
CONFIG_SERIES=y
diff --git a/configs/am335x_shc_netboot_defconfig b/configs/am335x_shc_netboot_defconfig
index d16c5f0..a6eaf6b 100644
--- a/configs/am335x_shc_netboot_defconfig
+++ b/configs/am335x_shc_netboot_defconfig
@@ -1,4 +1,5 @@
CONFIG_ARM=y
+CONFIG_AM33XX=y
CONFIG_TARGET_AM335X_SHC=y
CONFIG_SHC_NETBOOT=y
CONFIG_SERIES=y
diff --git a/configs/am335x_shc_prompt_defconfig b/configs/am335x_shc_prompt_defconfig
index b9bc355..e174ba9 100644
--- a/configs/am335x_shc_prompt_defconfig
+++ b/configs/am335x_shc_prompt_defconfig
@@ -1,4 +1,5 @@
CONFIG_ARM=y
+CONFIG_AM33XX=y
CONFIG_TARGET_AM335X_SHC=y
CONFIG_SERIES=y
CONFIG_SPL_STACK_R_ADDR=0x82000000
diff --git a/configs/am335x_shc_sdboot_defconfig b/configs/am335x_shc_sdboot_defconfig
index b0e8eff..7b3974c 100644
--- a/configs/am335x_shc_sdboot_defconfig
+++ b/configs/am335x_shc_sdboot_defconfig
@@ -1,4 +1,5 @@
CONFIG_ARM=y
+CONFIG_AM33XX=y
CONFIG_TARGET_AM335X_SHC=y
CONFIG_SHC_SDBOOT=y
CONFIG_SERIES=y
diff --git a/configs/am335x_shc_sdboot_prompt_defconfig b/configs/am335x_shc_sdboot_prompt_defconfig
index b0e8eff..7b3974c 100644
--- a/configs/am335x_shc_sdboot_prompt_defconfig
+++ b/configs/am335x_shc_sdboot_prompt_defconfig
@@ -1,4 +1,5 @@
CONFIG_ARM=y
+CONFIG_AM33XX=y
CONFIG_TARGET_AM335X_SHC=y
CONFIG_SHC_SDBOOT=y
CONFIG_SERIES=y
diff --git a/configs/am335x_sl50_defconfig b/configs/am335x_sl50_defconfig
index 01c1eeb..87ea29e 100644
--- a/configs/am335x_sl50_defconfig
+++ b/configs/am335x_sl50_defconfig
@@ -1,4 +1,5 @@
CONFIG_ARM=y
+CONFIG_AM33XX=y
CONFIG_TARGET_AM335X_SL50=y
CONFIG_SPL_STACK_R_ADDR=0x82000000
CONFIG_SPL=y
diff --git a/include/configs/ti_am335x_common.h b/include/configs/ti_am335x_common.h
index bcd56fc..7a4c043 100644
--- a/include/configs/ti_am335x_common.h
+++ b/include/configs/ti_am335x_common.h
@@ -12,7 +12,9 @@
#ifndef __CONFIG_TI_AM335X_COMMON_H__
#define __CONFIG_TI_AM335X_COMMON_H__
+#ifndef CONFIG_AM33XX
#define CONFIG_AM33XX
+#endif
#define CONFIG_ARCH_CPU_INIT
#define CONFIG_SYS_CACHELINE_SIZE 64
#define CONFIG_MAX_RAM_BANK_SIZE (1024 << 20) /* 1GB */
--
2.9.3
^ permalink raw reply related [flat|nested] 19+ messages in thread* [U-Boot] [PATCH v2 01/11] Kconfig: Separate AM33XX SOC config from target board config
2016-08-22 15:21 ` [U-Boot] [PATCH v2 01/11] Kconfig: Separate AM33XX SOC config from target board config Andrew F. Davis
@ 2016-08-26 20:12 ` Tom Rini
0 siblings, 0 replies; 19+ messages in thread
From: Tom Rini @ 2016-08-26 20:12 UTC (permalink / raw)
To: u-boot
On Mon, Aug 22, 2016 at 10:21:21AM -0500, Andrew F. Davis wrote:
> The config option AM33XX is used in several boards and should be
> defined as a stand-alone option for this SOC. We break this out
> from TARGET_AM335X_* then enable AM33XX on in all the boards that
> used TARGET_AM335X_* to eliminate any functional change with
> this patch. Also conditionally define this in ti_am335x_common.h to prevent
> redefinition. The definition can be removed completely when all platforms
> that include this header have this definition added to their defconfig.
>
> This is similar to what has already been done in
> 9de852642cae ("arm: Kconfig: Add support for AM43xx SoC specific Kconfig")
> and is done for the same reasons.
>
> Signed-off-by: Andrew F. Davis <afd@ti.com>
[snip]
> diff --git a/include/configs/ti_am335x_common.h b/include/configs/ti_am335x_common.h
> index bcd56fc..7a4c043 100644
> --- a/include/configs/ti_am335x_common.h
> +++ b/include/configs/ti_am335x_common.h
> @@ -12,7 +12,9 @@
> #ifndef __CONFIG_TI_AM335X_COMMON_H__
> #define __CONFIG_TI_AM335X_COMMON_H__
>
> +#ifndef CONFIG_AM33XX
> #define CONFIG_AM33XX
> +#endif
> #define CONFIG_ARCH_CPU_INIT
> #define CONFIG_SYS_CACHELINE_SIZE 64
> #define CONFIG_MAX_RAM_BANK_SIZE (1024 << 20) /* 1GB */
We should do the fixup in this commit and drop the line from this
header.
--
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20160826/2cc0718d/attachment.sig>
^ permalink raw reply [flat|nested] 19+ messages in thread
* [U-Boot] [PATCH v2 02/11] am33xx: config.mk: Add support for additional secure boot image types
2016-08-22 15:21 [U-Boot] [PATCH v2 00/11] Allow secure boot on AM33xx devices Andrew F. Davis
2016-08-22 15:21 ` [U-Boot] [PATCH v2 01/11] Kconfig: Separate AM33XX SOC config from target board config Andrew F. Davis
@ 2016-08-22 15:21 ` Andrew F. Davis
2016-08-22 15:21 ` [U-Boot] [PATCH v2 03/11] am33xx: config.mk: Fix option used to enable SPI SPL image type Andrew F. Davis
` (8 subsequent siblings)
10 siblings, 0 replies; 19+ messages in thread
From: Andrew F. Davis @ 2016-08-22 15:21 UTC (permalink / raw)
To: u-boot
Depending on the boot media, different images are needed
for secure devices. The build generates u-boot*_HS_* files
as appropriate for the different boot modes.
For AM33xx devices additional image types are needed for
various SPL boot modes as the ROM checks for the name of
the boot mode in the file it loads.
Signed-off-by: Andrew F. Davis <afd@ti.com>
---
arch/arm/cpu/armv7/am33xx/config.mk | 27 +++++++++++++++++++++++++--
1 file changed, 25 insertions(+), 2 deletions(-)
diff --git a/arch/arm/cpu/armv7/am33xx/config.mk b/arch/arm/cpu/armv7/am33xx/config.mk
index d4eb21c..8e655d7 100644
--- a/arch/arm/cpu/armv7/am33xx/config.mk
+++ b/arch/arm/cpu/armv7/am33xx/config.mk
@@ -12,13 +12,36 @@ ifeq ($(CONFIG_TI_SECURE_DEVICE),y)
# For booting from SPI use
# u-boot-spl_HS_SPI_X-LOADER to program flash
#
-# For booting spl from all other media
-# use u-boot-spl_HS_ISSW
+# On AM43XX:
+#
+# For booting spl from all other media use
+# u-boot-spl_HS_ISSW
+#
+# On AM33XX:
+#
+# For booting spl from NOR flash or QSPI use
+# u-boot-spl_HS_XIP_X-LOADER
+#
+# For booting spl from NAND flash use
+# u-boot-spl_HS_X-LOADER
+#
+# For booting spl from SD/MMC/eMMC media use
+# u-boot-spl_HS_MLO
+#
+# For booting spl over UART, USB, or Ethernet use
+# u-boot-spl_HS_2ND
#
# Refer to README.ti-secure for more info
#
ALL-y += u-boot-spl_HS_ISSW
ALL-$(CONFIG_SPL_SPI_SUPPORT) += u-boot-spl_HS_SPI_X-LOADER
+ALL-$(CONFIG_SPL_QSPI_BOOT) += u-boot-spl_HS_XIP_X-LOADER
+ALL-$(CONFIG_SPL_NOR_BOOT) += u-boot-spl_HS_XIP_X-LOADER
+ALL-$(CONFIG_SPL_NAND_BOOT) += u-boot-spl_HS_X-LOADER
+ALL-$(CONFIG_SPL_SD_BOOT) += u-boot-spl_HS_MLO
+ALL-$(CONFIG_SPL_UART_BOOT) += u-boot-spl_HS_2ND
+ALL-$(CONFIG_SPL_USB_BOOT) += u-boot-spl_HS_2ND
+ALL-$(CONFIG_SPL_NET_BOOT) += u-boot-spl_HS_2ND
else
ALL-y += MLO
ALL-$(CONFIG_SPL_SPI_SUPPORT) += MLO.byteswap
--
2.9.3
^ permalink raw reply related [flat|nested] 19+ messages in thread* [U-Boot] [PATCH v2 03/11] am33xx: config.mk: Fix option used to enable SPI SPL image type
2016-08-22 15:21 [U-Boot] [PATCH v2 00/11] Allow secure boot on AM33xx devices Andrew F. Davis
2016-08-22 15:21 ` [U-Boot] [PATCH v2 01/11] Kconfig: Separate AM33XX SOC config from target board config Andrew F. Davis
2016-08-22 15:21 ` [U-Boot] [PATCH v2 02/11] am33xx: config.mk: Add support for additional secure boot image types Andrew F. Davis
@ 2016-08-22 15:21 ` Andrew F. Davis
2016-08-22 15:21 ` [U-Boot] [PATCH v2 04/11] doc: Update info on using AM33xx secure devices from TI Andrew F. Davis
` (7 subsequent siblings)
10 siblings, 0 replies; 19+ messages in thread
From: Andrew F. Davis @ 2016-08-22 15:21 UTC (permalink / raw)
To: u-boot
Before the addition of SPL boot media type Kconfig options there was no
way to determine what boot media the SPL would be booted from, so
it was assumed that if the SPL could load U-Boot proper via SPI then
the SPL itself would probably also be loaded from SPI.
Use the new SPL_SPI_BOOT option to enable the generation an SPL image
capable of being booted from SPI, and not have this depend on the SPL's
media loading capabilities.
Signed-off-by: Andrew F. Davis <afd@ti.com>
---
arch/arm/cpu/armv7/am33xx/config.mk | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/cpu/armv7/am33xx/config.mk b/arch/arm/cpu/armv7/am33xx/config.mk
index 8e655d7..2f53df8 100644
--- a/arch/arm/cpu/armv7/am33xx/config.mk
+++ b/arch/arm/cpu/armv7/am33xx/config.mk
@@ -34,7 +34,7 @@ ifeq ($(CONFIG_TI_SECURE_DEVICE),y)
# Refer to README.ti-secure for more info
#
ALL-y += u-boot-spl_HS_ISSW
-ALL-$(CONFIG_SPL_SPI_SUPPORT) += u-boot-spl_HS_SPI_X-LOADER
+ALL-$(CONFIG_SPL_SPI_BOOT) += u-boot-spl_HS_SPI_X-LOADER
ALL-$(CONFIG_SPL_QSPI_BOOT) += u-boot-spl_HS_XIP_X-LOADER
ALL-$(CONFIG_SPL_NOR_BOOT) += u-boot-spl_HS_XIP_X-LOADER
ALL-$(CONFIG_SPL_NAND_BOOT) += u-boot-spl_HS_X-LOADER
--
2.9.3
^ permalink raw reply related [flat|nested] 19+ messages in thread* [U-Boot] [PATCH v2 04/11] doc: Update info on using AM33xx secure devices from TI
2016-08-22 15:21 [U-Boot] [PATCH v2 00/11] Allow secure boot on AM33xx devices Andrew F. Davis
` (2 preceding siblings ...)
2016-08-22 15:21 ` [U-Boot] [PATCH v2 03/11] am33xx: config.mk: Fix option used to enable SPI SPL image type Andrew F. Davis
@ 2016-08-22 15:21 ` Andrew F. Davis
2016-08-22 15:21 ` [U-Boot] [PATCH v2 05/11] ti: omap-common: Allow AM33xx devices to be built securely Andrew F. Davis
` (6 subsequent siblings)
10 siblings, 0 replies; 19+ messages in thread
From: Andrew F. Davis @ 2016-08-22 15:21 UTC (permalink / raw)
To: u-boot
Add a section describing the additional boot types used on AM33xx
secure devices.
Signed-off-by: Andrew F. Davis <afd@ti.com>
---
doc/README.ti-secure | 32 ++++++++++++++++++++++++++++++++
1 file changed, 32 insertions(+)
diff --git a/doc/README.ti-secure b/doc/README.ti-secure
index 54c996d..9b0fbf9 100644
--- a/doc/README.ti-secure
+++ b/doc/README.ti-secure
@@ -43,6 +43,38 @@ Booting of U-Boot SPL
The script is basically the only required interface to the TI SECDEV
package for creating a bootable SPL image for secure TI devices.
+ Invoking the script for AM33xx Secure Devices
+ =============================================
+
+ create-boot-image.sh \
+ <IMAGE_FLAG> <INPUT_FILE> <OUTPUT_FILE> <SPL_LOAD_ADDR>
+
+ <IMAGE_FLAG> is a value that specifies the type of the image to
+ generate OR the action the image generation tool will take. Valid
+ values are:
+ SPI_X-LOADER - Generates an image for SPI flash (byte swapped)
+ X-LOADER - Generates an image for non-XIP flash
+ MLO - Generates an image for SD/MMC/eMMC media
+ 2ND - Generates an image for USB, UART and Ethernet
+ XIP_X-LOADER - Generates a single stage u-boot for NOR/QSPI XiP
+
+ <INPUT_FILE> is the full path and filename of the public world boot
+ loaderbinary file (depending on the boot media, this is usually
+ either u-boot-spl.bin or u-boot.bin).
+
+ <OUTPUT_FILE> is the full path and filename of the final secure
+ image. The output binary images should be used in place of the standard
+ non-secure binary images (see the platform-specific user's guides and
+ releases notes for how the non-secure images are typically used)
+ u-boot-spl_HS_SPI_X-LOADER - byte swapped boot image for SPI flash
+ u-boot-spl_HS_X-LOADER - boot image for NAND or SD/MMC/eMMC rawmode
+ u-boot-spl_HS_MLO - boot image for SD/MMC/eMMC media
+ u-boot-spl_HS_2ND - boot image for USB, UART and Ethernet
+ u-boot_HS_XIP_X-LOADER - boot image for NOR or QSPI Xip flash
+
+ <SPL_LOAD_ADDR> is the address at which SOC ROM should load the
+ <INPUT_FILE>
+
Invoking the script for AM43xx Secure Devices
=============================================
--
2.9.3
^ permalink raw reply related [flat|nested] 19+ messages in thread* [U-Boot] [PATCH v2 05/11] ti: omap-common: Allow AM33xx devices to be built securely
2016-08-22 15:21 [U-Boot] [PATCH v2 00/11] Allow secure boot on AM33xx devices Andrew F. Davis
` (3 preceding siblings ...)
2016-08-22 15:21 ` [U-Boot] [PATCH v2 04/11] doc: Update info on using AM33xx secure devices from TI Andrew F. Davis
@ 2016-08-22 15:21 ` Andrew F. Davis
2016-08-22 15:21 ` [U-Boot] [PATCH v2 06/11] board: am33xx-hs: spl: Allow post-processing of FIT image on AM33xx Andrew F. Davis
` (5 subsequent siblings)
10 siblings, 0 replies; 19+ messages in thread
From: Andrew F. Davis @ 2016-08-22 15:21 UTC (permalink / raw)
To: u-boot
Like OMAP54xx and AM43xx family SoCs, AM33xx based SoCs have high
security enabled models. Allow AM33xx devices to be built with
HS Device Type Support.
Signed-off-by: Andrew F. Davis <afd@ti.com>
---
arch/arm/cpu/armv7/omap-common/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/cpu/armv7/omap-common/Kconfig b/arch/arm/cpu/armv7/omap-common/Kconfig
index 7b39506..4daccd9 100644
--- a/arch/arm/cpu/armv7/omap-common/Kconfig
+++ b/arch/arm/cpu/armv7/omap-common/Kconfig
@@ -1,6 +1,6 @@
config TI_SECURE_DEVICE
bool "HS Device Type Support"
- depends on OMAP54XX || AM43XX
+ depends on OMAP54XX || AM43XX || AM33XX
help
If a high secure (HS) device type is being used, this config
must be set. This option impacts various aspects of the
--
2.9.3
^ permalink raw reply related [flat|nested] 19+ messages in thread* [U-Boot] [PATCH v2 06/11] board: am33xx-hs: spl: Allow post-processing of FIT image on AM33xx
2016-08-22 15:21 [U-Boot] [PATCH v2 00/11] Allow secure boot on AM33xx devices Andrew F. Davis
` (4 preceding siblings ...)
2016-08-22 15:21 ` [U-Boot] [PATCH v2 05/11] ti: omap-common: Allow AM33xx devices to be built securely Andrew F. Davis
@ 2016-08-22 15:21 ` Andrew F. Davis
2016-08-22 15:21 ` [U-Boot] [RFC PATCH v2 07/11] omap: Use SD_BOOT in place of EMMC_BOOT Andrew F. Davis
` (4 subsequent siblings)
10 siblings, 0 replies; 19+ messages in thread
From: Andrew F. Davis @ 2016-08-22 15:21 UTC (permalink / raw)
To: u-boot
When CONFIG_FIT_IMAGE_POST_PROCESS or CONFIG_SPL_FIT_IMAGE_POST_PROCESS
is enabled board_fit_image_post_process will be called, add this
function to am33xx boards when CONFIG_TI_SECURE_DEVICE is set to
verify the loaded image.
Signed-off-by: Andrew F. Davis <afd@ti.com>
---
board/ti/am335x/board.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/board/ti/am335x/board.c b/board/ti/am335x/board.c
index 56f4984..0ed16ca 100644
--- a/board/ti/am335x/board.c
+++ b/board/ti/am335x/board.c
@@ -25,6 +25,7 @@
#include <asm/io.h>
#include <asm/emif.h>
#include <asm/gpio.h>
+#include <asm/omap_sec_common.h>
#include <i2c.h>
#include <miiphy.h>
#include <cpsw.h>
@@ -775,3 +776,10 @@ int board_fit_config_name_match(const char *name)
return -1;
}
#endif
+
+#ifdef CONFIG_TI_SECURE_DEVICE
+void board_fit_image_post_process(void **p_image, size_t *p_size)
+{
+ secure_boot_verify_image(p_image, p_size);
+}
+#endif
--
2.9.3
^ permalink raw reply related [flat|nested] 19+ messages in thread* [U-Boot] [RFC PATCH v2 07/11] omap: Use SD_BOOT in place of EMMC_BOOT
2016-08-22 15:21 [U-Boot] [PATCH v2 00/11] Allow secure boot on AM33xx devices Andrew F. Davis
` (5 preceding siblings ...)
2016-08-22 15:21 ` [U-Boot] [PATCH v2 06/11] board: am33xx-hs: spl: Allow post-processing of FIT image on AM33xx Andrew F. Davis
@ 2016-08-22 15:21 ` Andrew F. Davis
2016-08-22 15:21 ` [U-Boot] [RFC PATCH v2 08/11] config: Remove usage of CONFIG_STORAGE_EMMC Andrew F. Davis
` (3 subsequent siblings)
10 siblings, 0 replies; 19+ messages in thread
From: Andrew F. Davis @ 2016-08-22 15:21 UTC (permalink / raw)
To: u-boot
The config option EMMC_BOOT is used in several OMAP based platforms with
the same meaning as the existing SD_BOOT. Convert all uses, no functional
changes.
Signed-off-by: Andrew F. Davis <afd@ti.com>
---
board/ti/am335x/mux.c | 4 ++--
configs/am335x_boneblack_defconfig | 2 +-
configs/am335x_boneblack_vboot_defconfig | 3 ++-
configs/am335x_sl50_defconfig | 2 +-
configs/brppt1_mmc_defconfig | 3 ++-
configs/brppt1_spi_defconfig | 3 ++-
include/configs/am335x_evm.h | 2 +-
include/configs/am335x_sl50.h | 2 +-
include/configs/bav335x.h | 2 +-
include/configs/brppt1.h | 6 +++---
10 files changed, 16 insertions(+), 13 deletions(-)
diff --git a/board/ti/am335x/mux.c b/board/ti/am335x/mux.c
index 8afa5f9..2d580d2 100644
--- a/board/ti/am335x/mux.c
+++ b/board/ti/am335x/mux.c
@@ -383,9 +383,9 @@ void enable_board_pin_mux(void)
/* Beaglebone LT pinmux */
configure_module_pin_mux(mii1_pin_mux);
configure_module_pin_mux(mmc0_pin_mux);
-#if defined(CONFIG_NAND) && defined(CONFIG_EMMC_BOOT)
+#if defined(CONFIG_NAND) && defined(CONFIG_SD_BOOT)
configure_module_pin_mux(nand_pin_mux);
-#elif defined(CONFIG_NOR) && defined(CONFIG_EMMC_BOOT)
+#elif defined(CONFIG_NOR) && defined(CONFIG_SD_BOOT)
configure_module_pin_mux(bone_norcape_pin_mux);
#else
configure_module_pin_mux(mmc1_pin_mux);
diff --git a/configs/am335x_boneblack_defconfig b/configs/am335x_boneblack_defconfig
index 5fabff6..93e6678 100644
--- a/configs/am335x_boneblack_defconfig
+++ b/configs/am335x_boneblack_defconfig
@@ -5,7 +5,6 @@ CONFIG_SPL_STACK_R_ADDR=0x82000000
CONFIG_SPL=y
CONFIG_SPL_STACK_R=y
CONFIG_FIT=y
-CONFIG_SYS_EXTRA_OPTIONS="EMMC_BOOT"
CONFIG_HUSH_PARSER=y
CONFIG_AUTOBOOT_KEYED=y
CONFIG_AUTOBOOT_PROMPT="Press SPACE to abort autoboot in %d seconds\n"
@@ -44,3 +43,4 @@ CONFIG_G_DNL_MANUFACTURER="Texas Instruments"
CONFIG_G_DNL_VENDOR_NUM=0x0451
CONFIG_G_DNL_PRODUCT_NUM=0xd022
CONFIG_OF_LIBFDT=y
+CONFIG_SD_BOOT=y
diff --git a/configs/am335x_boneblack_vboot_defconfig b/configs/am335x_boneblack_vboot_defconfig
index b47b51f..4dfe04e 100644
--- a/configs/am335x_boneblack_vboot_defconfig
+++ b/configs/am335x_boneblack_vboot_defconfig
@@ -8,7 +8,7 @@ CONFIG_SPL_STACK_R=y
CONFIG_FIT=y
CONFIG_FIT_VERBOSE=y
CONFIG_FIT_SIGNATURE=y
-CONFIG_SYS_EXTRA_OPTIONS="EMMC_BOOT,ENABLE_VBOOT"
+CONFIG_SYS_EXTRA_OPTIONS="ENABLE_VBOOT"
CONFIG_HUSH_PARSER=y
CONFIG_AUTOBOOT_KEYED=y
CONFIG_AUTOBOOT_PROMPT="Press SPACE to abort autoboot in %d seconds\n"
@@ -51,3 +51,4 @@ CONFIG_G_DNL_MANUFACTURER="Texas Instruments"
CONFIG_G_DNL_VENDOR_NUM=0x0451
CONFIG_G_DNL_PRODUCT_NUM=0xd022
CONFIG_DM_I2C=y
+CONFIG_SD_BOOT=y
diff --git a/configs/am335x_sl50_defconfig b/configs/am335x_sl50_defconfig
index 87ea29e..ff4c950 100644
--- a/configs/am335x_sl50_defconfig
+++ b/configs/am335x_sl50_defconfig
@@ -5,7 +5,6 @@ CONFIG_SPL_STACK_R_ADDR=0x82000000
CONFIG_SPL=y
CONFIG_SPL_STACK_R=y
CONFIG_FIT=y
-CONFIG_SYS_EXTRA_OPTIONS="EMMC_BOOT"
CONFIG_HUSH_PARSER=y
# CONFIG_AUTOBOOT is not set
CONFIG_CMD_BOOTZ=y
@@ -27,3 +26,4 @@ CONFIG_CMD_FAT=y
CONFIG_CMD_FS_GENERIC=y
CONFIG_SYS_NS16550=y
CONFIG_OF_LIBFDT=y
+CONFIG_SD_BOOT=y
diff --git a/configs/brppt1_mmc_defconfig b/configs/brppt1_mmc_defconfig
index cf2800b..9d36530 100644
--- a/configs/brppt1_mmc_defconfig
+++ b/configs/brppt1_mmc_defconfig
@@ -2,7 +2,7 @@ CONFIG_ARM=y
CONFIG_TARGET_BRPPT1=y
CONFIG_SPL=y
CONFIG_OF_BOARD_SETUP=y
-CONFIG_SYS_EXTRA_OPTIONS="SERIAL1,CONS_INDEX=1,EMMC_BOOT"
+CONFIG_SYS_EXTRA_OPTIONS="SERIAL1,CONS_INDEX=1"
CONFIG_BOOTDELAY=-2
CONFIG_HUSH_PARSER=y
CONFIG_CMD_BOOTZ=y
@@ -35,3 +35,4 @@ CONFIG_USB=y
CONFIG_USB_MUSB_HOST=y
CONFIG_USB_STORAGE=y
CONFIG_OF_LIBFDT=y
+CONFIG_SD_BOOT=y
diff --git a/configs/brppt1_spi_defconfig b/configs/brppt1_spi_defconfig
index fee9973..65a5666 100644
--- a/configs/brppt1_spi_defconfig
+++ b/configs/brppt1_spi_defconfig
@@ -2,7 +2,7 @@ CONFIG_ARM=y
CONFIG_TARGET_BRPPT1=y
CONFIG_SPL=y
CONFIG_OF_BOARD_SETUP=y
-CONFIG_SYS_EXTRA_OPTIONS="SERIAL1,CONS_INDEX=1,SPI_BOOT,EMMC_BOOT"
+CONFIG_SYS_EXTRA_OPTIONS="SERIAL1,CONS_INDEX=1,SPI_BOOT"
CONFIG_SPI_BOOT=y
CONFIG_BOOTDELAY=-2
CONFIG_HUSH_PARSER=y
@@ -41,3 +41,4 @@ CONFIG_USB=y
CONFIG_USB_MUSB_HOST=y
CONFIG_USB_STORAGE=y
CONFIG_OF_LIBFDT=y
+CONFIG_SD_BOOT=y
diff --git a/include/configs/am335x_evm.h b/include/configs/am335x_evm.h
index ba4c215..6be0e22 100644
--- a/include/configs/am335x_evm.h
+++ b/include/configs/am335x_evm.h
@@ -418,7 +418,7 @@
"512k(u-boot),128k(u-boot-env1)," \
"128k(u-boot-env2),3464k(kernel)," \
"-(rootfs)"
-#elif defined(CONFIG_EMMC_BOOT)
+#elif defined(CONFIG_SD_BOOT)
#define CONFIG_ENV_IS_IN_MMC
#define CONFIG_SPL_ENV_SUPPORT
#define CONFIG_SYS_MMC_ENV_DEV 1
diff --git a/include/configs/am335x_sl50.h b/include/configs/am335x_sl50.h
index 8454872..2854536 100644
--- a/include/configs/am335x_sl50.h
+++ b/include/configs/am335x_sl50.h
@@ -114,7 +114,7 @@
#define CONFIG_SPL_NET_VCI_STRING "AM335x U-Boot SPL"
#endif
-#if defined(CONFIG_EMMC_BOOT)
+#if defined(CONFIG_SD_BOOT)
#undef CONFIG_ENV_IS_NOWHERE
#define CONFIG_ENV_IS_IN_MMC
#define CONFIG_SPL_ENV_SUPPORT
diff --git a/include/configs/bav335x.h b/include/configs/bav335x.h
index e391c91..8743db4 100644
--- a/include/configs/bav335x.h
+++ b/include/configs/bav335x.h
@@ -548,7 +548,7 @@ DEFAULT_LINUX_BOOT_ENV \
"512k(u-boot),128k(u-boot-env1)," \
"128k(u-boot-env2),3464k(kernel)," \
"-(rootfs)"
-#elif defined(CONFIG_EMMC_BOOT)
+#elif defined(CONFIG_SD_BOOT)
#undef CONFIG_ENV_IS_NOWHERE
#define CONFIG_ENV_IS_IN_MMC
#define CONFIG_SPL_ENV_SUPPORT
diff --git a/include/configs/brppt1.h b/include/configs/brppt1.h
index 6a239b5..69a1adc 100644
--- a/include/configs/brppt1.h
+++ b/include/configs/brppt1.h
@@ -50,7 +50,7 @@
#define CONFIG_MACH_TYPE 0xFFFFFFFF /* TODO: check with kernel*/
/* MMC/SD IP block */
-#if defined(CONFIG_EMMC_BOOT)
+#if defined(CONFIG_SD_BOOT)
#define CONFIG_MMC
#define CONFIG_GENERIC_MMC
#define CONFIG_OMAP_HSMMC
@@ -59,7 +59,7 @@
#define CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR 0x300 /*addr. 0x60000 */
#define CONFIG_SYS_U_BOOT_MAX_SIZE_SECTORS 0x200 /* 256 KB */
#define CONFIG_SPL_MMC_SUPPORT
-#endif /* CONFIG_EMMC_BOOT */
+#endif /* CONFIG_SD_BOOT */
/*
* When we have SPI or NAND flash we expect to be making use of mtdparts,
@@ -269,7 +269,7 @@ MMCARGS
#define CONFIG_ENV_OFFSET (768 << 10) /* 768 KiB in */
#define CONFIG_ENV_OFFSET_REDUND (896 << 10) /* 896 KiB in */
-#elif defined(CONFIG_EMMC_BOOT)
+#elif defined(CONFIG_SD_BOOT)
#undef CONFIG_ENV_IS_NOWHERE
#define CONFIG_ENV_IS_IN_MMC
#define CONFIG_SYS_MMC_ENV_DEV 0
--
2.9.3
^ permalink raw reply related [flat|nested] 19+ messages in thread* [U-Boot] [RFC PATCH v2 08/11] config: Remove usage of CONFIG_STORAGE_EMMC
2016-08-22 15:21 [U-Boot] [PATCH v2 00/11] Allow secure boot on AM33xx devices Andrew F. Davis
` (6 preceding siblings ...)
2016-08-22 15:21 ` [U-Boot] [RFC PATCH v2 07/11] omap: Use SD_BOOT in place of EMMC_BOOT Andrew F. Davis
@ 2016-08-22 15:21 ` Andrew F. Davis
2016-08-22 15:21 ` [U-Boot] [RFC PATCH v2 09/11] spl: Kconfig: Add SPL_<media>_SUPPORT as Kconfig option Andrew F. Davis
` (2 subsequent siblings)
10 siblings, 0 replies; 19+ messages in thread
From: Andrew F. Davis @ 2016-08-22 15:21 UTC (permalink / raw)
To: u-boot
This config option seems to be unused and is probably vestigial.
Remove it.
Signed-off-by: Andrew F. Davis <afd@ti.com>
---
include/configs/am335x_evm.h | 2 --
include/configs/am335x_shc.h | 2 --
include/configs/am335x_sl50.h | 2 --
include/configs/bav335x.h | 2 --
4 files changed, 8 deletions(-)
diff --git a/include/configs/am335x_evm.h b/include/configs/am335x_evm.h
index 6be0e22..100471d 100644
--- a/include/configs/am335x_evm.h
+++ b/include/configs/am335x_evm.h
@@ -301,8 +301,6 @@
#define CONFIG_FASTBOOT_BUF_ADDR CONFIG_SYS_LOAD_ADDR
#define CONFIG_FASTBOOT_BUF_SIZE 0x07000000
-/* To support eMMC booting */
-#define CONFIG_STORAGE_EMMC
#define CONFIG_FASTBOOT_FLASH_MMC_DEV 1
#endif
diff --git a/include/configs/am335x_shc.h b/include/configs/am335x_shc.h
index f2484cb..8708c91 100644
--- a/include/configs/am335x_shc.h
+++ b/include/configs/am335x_shc.h
@@ -287,8 +287,6 @@
#define CONFIG_SPL_LDSCRIPT "$(CPUDIR)/am33xx/u-boot-spl.lds"
#ifndef CONFIG_SPL_USBETH_SUPPORT
-/* To support eMMC booting */
-#define CONFIG_STORAGE_EMMC
#define CONFIG_FASTBOOT_FLASH_MMC_DEV 1
#endif
diff --git a/include/configs/am335x_sl50.h b/include/configs/am335x_sl50.h
index 2854536..bad0317 100644
--- a/include/configs/am335x_sl50.h
+++ b/include/configs/am335x_sl50.h
@@ -91,8 +91,6 @@
#define CONFIG_SPL_LDSCRIPT "$(CPUDIR)/am33xx/u-boot-spl.lds"
#ifndef CONFIG_SPL_USBETH_SUPPORT
-/* To support eMMC booting */
-#define CONFIG_STORAGE_EMMC
#define CONFIG_FASTBOOT_FLASH_MMC_DEV 1
#endif
diff --git a/include/configs/bav335x.h b/include/configs/bav335x.h
index 8743db4..b0f9cc4 100644
--- a/include/configs/bav335x.h
+++ b/include/configs/bav335x.h
@@ -451,8 +451,6 @@ DEFAULT_LINUX_BOOT_ENV \
#define CONFIG_FASTBOOT_BUF_ADDR CONFIG_SYS_LOAD_ADDR
#define CONFIG_FASTBOOT_BUF_SIZE 0x07000000
-/* To support eMMC booting */
-#define CONFIG_STORAGE_EMMC
#define CONFIG_FASTBOOT_FLASH_MMC_DEV 1
#endif
--
2.9.3
^ permalink raw reply related [flat|nested] 19+ messages in thread* [U-Boot] [RFC PATCH v2 09/11] spl: Kconfig: Add SPL_<media>_SUPPORT as Kconfig option
2016-08-22 15:21 [U-Boot] [PATCH v2 00/11] Allow secure boot on AM33xx devices Andrew F. Davis
` (7 preceding siblings ...)
2016-08-22 15:21 ` [U-Boot] [RFC PATCH v2 08/11] config: Remove usage of CONFIG_STORAGE_EMMC Andrew F. Davis
@ 2016-08-22 15:21 ` Andrew F. Davis
2016-08-23 6:08 ` Masahiro Yamada
2016-08-22 15:21 ` [U-Boot] [RFC PATCH v2 10/11] spl: Kconfig: Add SPL_<media>_BOOT " Andrew F. Davis
2016-08-22 15:21 ` [U-Boot] [RFC PATCH v2 11/11] spl: Kconfig: Add CONFIG_SPL_TEXT_BASE " Andrew F. Davis
10 siblings, 1 reply; 19+ messages in thread
From: Andrew F. Davis @ 2016-08-22 15:21 UTC (permalink / raw)
To: u-boot
Create a new Kconfig file to contain SPL boot media loading support
options as we begin moving these to the Kconfig system and out of header
files. Initially add new configs for all the existing boot media types,
giving them the same definition name as before to allow compatibility
with systems not yet using Kconfig.
Signed-off-by: Andrew F. Davis <afd@ti.com>
---
common/Kconfig | 7 +++++++
common/spl/Kconfig | 54 ++++++++++++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 61 insertions(+)
create mode 100644 common/spl/Kconfig
diff --git a/common/Kconfig b/common/Kconfig
index 46e7173..f594db5 100644
--- a/common/Kconfig
+++ b/common/Kconfig
@@ -156,6 +156,13 @@ config SPI_BOOT
booted via SPI flash. This is not a must, some SoCs need this,
somes not.
+menu "SPL Media Loading Support"
+ depends on SPL
+
+source "common/spl/Kconfig"
+
+endmenu
+
endmenu
config BOOTDELAY
diff --git a/common/spl/Kconfig b/common/spl/Kconfig
new file mode 100644
index 0000000..788ca14
--- /dev/null
+++ b/common/spl/Kconfig
@@ -0,0 +1,54 @@
+config SPL_YMODEM_SUPPORT
+ depends on SPL
+ bool "SPL Support for loading next stage from UART"
+ help
+ This option enables SPL to load the next stage bootloader
+ over a UART line using the x/y/z/modem protocol.
+
+config SPL_MMC_SUPPORT
+ bool "SPL Support for loading next stage from SD/MMC/eMMC"
+ help
+ This option enables SPL to load the next stage bootloader
+ from an SD/MMC/eMMC device.
+
+config SPL_SPI_SUPPORT
+ bool "SPL Support for loading next stage from SPI flash"
+ help
+ This option enables SPL to load the next stage bootloader
+ from SPI flash.
+
+config SPL_USB_SUPPORT
+ bool "SPL Support for loading next stage from USB"
+ help
+ This option enables SPL to load the next stage bootloader
+ from a USB device.
+
+config SPL_SATA_SUPPORT
+ bool "SPL Support for loading next stage from SATA"
+ help
+ This option enables SPL to load the next stage bootloader
+ from a SATA device.
+
+config SPL_NOR_SUPPORT
+ bool "SPL Support for loading next stage from NOR flash"
+ help
+ This option enables SPL to load the next stage bootloader
+ from NOR flash.
+
+config SPL_NAND_SUPPORT
+ bool "SPL Support for loading next stage from NAND flash"
+ help
+ This option enables SPL to load the next stage bootloader
+ from NAND flash.
+
+config SPL_ONENAND_SUPPORT
+ bool "SPL Support for loading next stage from ONENAND"
+ help
+ This option enables SPL to load the next stage bootloader
+ from ONENAND.
+
+config SPL_NET_SUPPORT
+ bool "SPL Support for loading next stage from NET"
+ help
+ This option enables SPL to load the next stage bootloader
+ from NET.
--
2.9.3
^ permalink raw reply related [flat|nested] 19+ messages in thread* [U-Boot] [RFC PATCH v2 09/11] spl: Kconfig: Add SPL_<media>_SUPPORT as Kconfig option
2016-08-22 15:21 ` [U-Boot] [RFC PATCH v2 09/11] spl: Kconfig: Add SPL_<media>_SUPPORT as Kconfig option Andrew F. Davis
@ 2016-08-23 6:08 ` Masahiro Yamada
2016-08-23 15:02 ` Andrew F. Davis
2016-08-26 20:06 ` Tom Rini
0 siblings, 2 replies; 19+ messages in thread
From: Masahiro Yamada @ 2016-08-23 6:08 UTC (permalink / raw)
To: u-boot
2016-08-23 0:21 GMT+09:00 Andrew F. Davis <afd@ti.com>:
> Create a new Kconfig file to contain SPL boot media loading support
> options as we begin moving these to the Kconfig system and out of header
> files. Initially add new configs for all the existing boot media types,
> giving them the same definition name as before to allow compatibility
> with systems not yet using Kconfig.
>
> Signed-off-by: Andrew F. Davis <afd@ti.com>
> ---
> common/Kconfig | 7 +++++++
> common/spl/Kconfig | 54 ++++++++++++++++++++++++++++++++++++++++++++++++++++++
> 2 files changed, 61 insertions(+)
> create mode 100644 common/spl/Kconfig
>
> diff --git a/common/Kconfig b/common/Kconfig
> index 46e7173..f594db5 100644
> --- a/common/Kconfig
> +++ b/common/Kconfig
> @@ -156,6 +156,13 @@ config SPI_BOOT
> booted via SPI flash. This is not a must, some SoCs need this,
> somes not.
>
> +menu "SPL Media Loading Support"
> + depends on SPL
> +
> +source "common/spl/Kconfig"
> +
> +endmenu
> +
> endmenu
>
> config BOOTDELAY
> diff --git a/common/spl/Kconfig b/common/spl/Kconfig
> new file mode 100644
> index 0000000..788ca14
> --- /dev/null
> +++ b/common/spl/Kconfig
> @@ -0,0 +1,54 @@
> +config SPL_YMODEM_SUPPORT
> + depends on SPL
> + bool "SPL Support for loading next stage from UART"
> + help
> + This option enables SPL to load the next stage bootloader
> + over a UART line using the x/y/z/modem protocol.
> +
> +config SPL_MMC_SUPPORT
> + bool "SPL Support for loading next stage from SD/MMC/eMMC"
> + help
> + This option enables SPL to load the next stage bootloader
> + from an SD/MMC/eMMC device.
> +
> +config SPL_SPI_SUPPORT
> + bool "SPL Support for loading next stage from SPI flash"
> + help
> + This option enables SPL to load the next stage bootloader
> + from SPI flash.
> +
> +config SPL_USB_SUPPORT
> + bool "SPL Support for loading next stage from USB"
> + help
> + This option enables SPL to load the next stage bootloader
> + from a USB device.
> +
> +config SPL_SATA_SUPPORT
> + bool "SPL Support for loading next stage from SATA"
> + help
> + This option enables SPL to load the next stage bootloader
> + from a SATA device.
> +
> +config SPL_NOR_SUPPORT
> + bool "SPL Support for loading next stage from NOR flash"
> + help
> + This option enables SPL to load the next stage bootloader
> + from NOR flash.
> +
> +config SPL_NAND_SUPPORT
> + bool "SPL Support for loading next stage from NAND flash"
> + help
> + This option enables SPL to load the next stage bootloader
> + from NAND flash.
> +
> +config SPL_ONENAND_SUPPORT
> + bool "SPL Support for loading next stage from ONENAND"
> + help
> + This option enables SPL to load the next stage bootloader
> + from ONENAND.
> +
> +config SPL_NET_SUPPORT
> + bool "SPL Support for loading next stage from NET"
> + help
> + This option enables SPL to load the next stage bootloader
> + from NET.
Historically, config options for SPL build were named
in the format of CONFIG_SPL_*_SUPPORT,
but the suffix "_SUPPORT" was not adding anything
except making the macro name longer, in my opinion.
New options such as CONFIG_SPL_CLK, CONFIG_SPL_PINCTRL,
only use SPL_ prefix because this naming scheme
can exploit CONFIG_IS_ENABLED() macro.
Then, I was hit by this question:
Given that SPL exists for loading the next stage image,
"SPL Support for loading next stage from SD/MMC/eMMC"
(from the Kconfig prompt of this patch) is nearly equal to
"Enable MMC driver support for SPL".
SPL_MMC_SUPPORT in common/spl/Kconfig (for loading image from MMC)
SPL_MMC in drivers/mmc/Kconfig (for enabling MMC driver for SPL)
it would make it tedious to use if we added both of them.
Theoretically, we can control them independently if we want, but
common/spl/spl_*.c are almost small entry stubs.
Tom,
Which do you think a better place for those options?
(SPL_YMODEM has no good directory, though)
--
Best Regards
Masahiro Yamada
^ permalink raw reply [flat|nested] 19+ messages in thread
* [U-Boot] [RFC PATCH v2 09/11] spl: Kconfig: Add SPL_<media>_SUPPORT as Kconfig option
2016-08-23 6:08 ` Masahiro Yamada
@ 2016-08-23 15:02 ` Andrew F. Davis
2016-08-26 20:06 ` Tom Rini
1 sibling, 0 replies; 19+ messages in thread
From: Andrew F. Davis @ 2016-08-23 15:02 UTC (permalink / raw)
To: u-boot
On 08/23/2016 01:08 AM, Masahiro Yamada wrote:
> 2016-08-23 0:21 GMT+09:00 Andrew F. Davis <afd@ti.com>:
>> Create a new Kconfig file to contain SPL boot media loading support
>> options as we begin moving these to the Kconfig system and out of header
>> files. Initially add new configs for all the existing boot media types,
>> giving them the same definition name as before to allow compatibility
>> with systems not yet using Kconfig.
>>
>> Signed-off-by: Andrew F. Davis <afd@ti.com>
>> ---
>> common/Kconfig | 7 +++++++
>> common/spl/Kconfig | 54 ++++++++++++++++++++++++++++++++++++++++++++++++++++++
>> 2 files changed, 61 insertions(+)
>> create mode 100644 common/spl/Kconfig
>>
>> diff --git a/common/Kconfig b/common/Kconfig
>> index 46e7173..f594db5 100644
>> --- a/common/Kconfig
>> +++ b/common/Kconfig
>> @@ -156,6 +156,13 @@ config SPI_BOOT
>> booted via SPI flash. This is not a must, some SoCs need this,
>> somes not.
>>
>> +menu "SPL Media Loading Support"
>> + depends on SPL
>> +
>> +source "common/spl/Kconfig"
>> +
>> +endmenu
>> +
>> endmenu
>>
>> config BOOTDELAY
>> diff --git a/common/spl/Kconfig b/common/spl/Kconfig
>> new file mode 100644
>> index 0000000..788ca14
>> --- /dev/null
>> +++ b/common/spl/Kconfig
>> @@ -0,0 +1,54 @@
>> +config SPL_YMODEM_SUPPORT
>> + depends on SPL
>> + bool "SPL Support for loading next stage from UART"
>> + help
>> + This option enables SPL to load the next stage bootloader
>> + over a UART line using the x/y/z/modem protocol.
>> +
>> +config SPL_MMC_SUPPORT
>> + bool "SPL Support for loading next stage from SD/MMC/eMMC"
>> + help
>> + This option enables SPL to load the next stage bootloader
>> + from an SD/MMC/eMMC device.
>> +
>> +config SPL_SPI_SUPPORT
>> + bool "SPL Support for loading next stage from SPI flash"
>> + help
>> + This option enables SPL to load the next stage bootloader
>> + from SPI flash.
>> +
>> +config SPL_USB_SUPPORT
>> + bool "SPL Support for loading next stage from USB"
>> + help
>> + This option enables SPL to load the next stage bootloader
>> + from a USB device.
>> +
>> +config SPL_SATA_SUPPORT
>> + bool "SPL Support for loading next stage from SATA"
>> + help
>> + This option enables SPL to load the next stage bootloader
>> + from a SATA device.
>> +
>> +config SPL_NOR_SUPPORT
>> + bool "SPL Support for loading next stage from NOR flash"
>> + help
>> + This option enables SPL to load the next stage bootloader
>> + from NOR flash.
>> +
>> +config SPL_NAND_SUPPORT
>> + bool "SPL Support for loading next stage from NAND flash"
>> + help
>> + This option enables SPL to load the next stage bootloader
>> + from NAND flash.
>> +
>> +config SPL_ONENAND_SUPPORT
>> + bool "SPL Support for loading next stage from ONENAND"
>> + help
>> + This option enables SPL to load the next stage bootloader
>> + from ONENAND.
>> +
>> +config SPL_NET_SUPPORT
>> + bool "SPL Support for loading next stage from NET"
>> + help
>> + This option enables SPL to load the next stage bootloader
>> + from NET.
>
>
>
> Historically, config options for SPL build were named
> in the format of CONFIG_SPL_*_SUPPORT,
> but the suffix "_SUPPORT" was not adding anything
> except making the macro name longer, in my opinion.
>
> New options such as CONFIG_SPL_CLK, CONFIG_SPL_PINCTRL,
> only use SPL_ prefix because this naming scheme
> can exploit CONFIG_IS_ENABLED() macro.
>
>
> Then, I was hit by this question:
>
> Given that SPL exists for loading the next stage image,
> "SPL Support for loading next stage from SD/MMC/eMMC"
> (from the Kconfig prompt of this patch) is nearly equal to
> "Enable MMC driver support for SPL".
>
>
>
> SPL_MMC_SUPPORT in common/spl/Kconfig (for loading image from MMC)
> SPL_MMC in drivers/mmc/Kconfig (for enabling MMC driver for SPL)
> it would make it tedious to use if we added both of them.
> Theoretically, we can control them independently if we want, but
> common/spl/spl_*.c are almost small entry stubs.
>
We could have the *_SUPPORT option select the appropriate driver config
options. This way the stubs and the drivers would be enabled with one
option, all in one place. Right now you can build the driver into SPL
but not enable the SPL stub that uses it is, making for a rather useless
situation.
Andrew
>
> Tom,
> Which do you think a better place for those options?
> (SPL_YMODEM has no good directory, though)
>
>
>
>
>
^ permalink raw reply [flat|nested] 19+ messages in thread
* [U-Boot] [RFC PATCH v2 09/11] spl: Kconfig: Add SPL_<media>_SUPPORT as Kconfig option
2016-08-23 6:08 ` Masahiro Yamada
2016-08-23 15:02 ` Andrew F. Davis
@ 2016-08-26 20:06 ` Tom Rini
1 sibling, 0 replies; 19+ messages in thread
From: Tom Rini @ 2016-08-26 20:06 UTC (permalink / raw)
To: u-boot
On Tue, Aug 23, 2016 at 03:08:02PM +0900, Masahiro Yamada wrote:
> 2016-08-23 0:21 GMT+09:00 Andrew F. Davis <afd@ti.com>:
> > Create a new Kconfig file to contain SPL boot media loading support
> > options as we begin moving these to the Kconfig system and out of header
> > files. Initially add new configs for all the existing boot media types,
> > giving them the same definition name as before to allow compatibility
> > with systems not yet using Kconfig.
> >
> > Signed-off-by: Andrew F. Davis <afd@ti.com>
> > ---
> > common/Kconfig | 7 +++++++
> > common/spl/Kconfig | 54 ++++++++++++++++++++++++++++++++++++++++++++++++++++++
> > 2 files changed, 61 insertions(+)
> > create mode 100644 common/spl/Kconfig
> >
> > diff --git a/common/Kconfig b/common/Kconfig
> > index 46e7173..f594db5 100644
> > --- a/common/Kconfig
> > +++ b/common/Kconfig
> > @@ -156,6 +156,13 @@ config SPI_BOOT
> > booted via SPI flash. This is not a must, some SoCs need this,
> > somes not.
> >
> > +menu "SPL Media Loading Support"
> > + depends on SPL
> > +
> > +source "common/spl/Kconfig"
> > +
> > +endmenu
> > +
> > endmenu
> >
> > config BOOTDELAY
> > diff --git a/common/spl/Kconfig b/common/spl/Kconfig
> > new file mode 100644
> > index 0000000..788ca14
> > --- /dev/null
> > +++ b/common/spl/Kconfig
> > @@ -0,0 +1,54 @@
> > +config SPL_YMODEM_SUPPORT
> > + depends on SPL
> > + bool "SPL Support for loading next stage from UART"
> > + help
> > + This option enables SPL to load the next stage bootloader
> > + over a UART line using the x/y/z/modem protocol.
> > +
> > +config SPL_MMC_SUPPORT
> > + bool "SPL Support for loading next stage from SD/MMC/eMMC"
> > + help
> > + This option enables SPL to load the next stage bootloader
> > + from an SD/MMC/eMMC device.
> > +
> > +config SPL_SPI_SUPPORT
> > + bool "SPL Support for loading next stage from SPI flash"
> > + help
> > + This option enables SPL to load the next stage bootloader
> > + from SPI flash.
> > +
> > +config SPL_USB_SUPPORT
> > + bool "SPL Support for loading next stage from USB"
> > + help
> > + This option enables SPL to load the next stage bootloader
> > + from a USB device.
> > +
> > +config SPL_SATA_SUPPORT
> > + bool "SPL Support for loading next stage from SATA"
> > + help
> > + This option enables SPL to load the next stage bootloader
> > + from a SATA device.
> > +
> > +config SPL_NOR_SUPPORT
> > + bool "SPL Support for loading next stage from NOR flash"
> > + help
> > + This option enables SPL to load the next stage bootloader
> > + from NOR flash.
> > +
> > +config SPL_NAND_SUPPORT
> > + bool "SPL Support for loading next stage from NAND flash"
> > + help
> > + This option enables SPL to load the next stage bootloader
> > + from NAND flash.
> > +
> > +config SPL_ONENAND_SUPPORT
> > + bool "SPL Support for loading next stage from ONENAND"
> > + help
> > + This option enables SPL to load the next stage bootloader
> > + from ONENAND.
> > +
> > +config SPL_NET_SUPPORT
> > + bool "SPL Support for loading next stage from NET"
> > + help
> > + This option enables SPL to load the next stage bootloader
> > + from NET.
>
>
>
> Historically, config options for SPL build were named
> in the format of CONFIG_SPL_*_SUPPORT,
> but the suffix "_SUPPORT" was not adding anything
> except making the macro name longer, in my opinion.
>
> New options such as CONFIG_SPL_CLK, CONFIG_SPL_PINCTRL,
> only use SPL_ prefix because this naming scheme
> can exploit CONFIG_IS_ENABLED() macro.
>
>
> Then, I was hit by this question:
>
> Given that SPL exists for loading the next stage image,
> "SPL Support for loading next stage from SD/MMC/eMMC"
> (from the Kconfig prompt of this patch) is nearly equal to
> "Enable MMC driver support for SPL".
>
>
>
> SPL_MMC_SUPPORT in common/spl/Kconfig (for loading image from MMC)
> SPL_MMC in drivers/mmc/Kconfig (for enabling MMC driver for SPL)
> it would make it tedious to use if we added both of them.
> Theoretically, we can control them independently if we want, but
> common/spl/spl_*.c are almost small entry stubs.
>
>
> Tom,
> Which do you think a better place for those options?
> (SPL_YMODEM has no good directory, though)
My preference is to have SPL stuff in common/spl/Kconfig to start with.
And yes, we may have some redundant options that could be removed if
after investigation A && B are always enabled.
--
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20160826/9a71c38a/attachment.sig>
^ permalink raw reply [flat|nested] 19+ messages in thread
* [U-Boot] [RFC PATCH v2 10/11] spl: Kconfig: Add SPL_<media>_BOOT as Kconfig option
2016-08-22 15:21 [U-Boot] [PATCH v2 00/11] Allow secure boot on AM33xx devices Andrew F. Davis
` (8 preceding siblings ...)
2016-08-22 15:21 ` [U-Boot] [RFC PATCH v2 09/11] spl: Kconfig: Add SPL_<media>_SUPPORT as Kconfig option Andrew F. Davis
@ 2016-08-22 15:21 ` Andrew F. Davis
2016-08-22 15:21 ` [U-Boot] [RFC PATCH v2 11/11] spl: Kconfig: Add CONFIG_SPL_TEXT_BASE " Andrew F. Davis
10 siblings, 0 replies; 19+ messages in thread
From: Andrew F. Davis @ 2016-08-22 15:21 UTC (permalink / raw)
To: u-boot
Currently U-Boot proper has Kconfig options that enable the generation
of U-Boot binaries that are capable of being booted from the selected
boot media type. The same set of generation targets for SPL are assumed
with various methods and config header hackery. On some platforms the
options for SPL, such as load address, are dependent on boot type
and cannot depend on boot image type selected for U-Boot proper.
Add a Kconfig menu to select SPL boot image types, and populate it
with the same media types as are already available for U-Boot proper.
Signed-off-by: Andrew F. Davis <afd@ti.com>
---
common/Kconfig | 69 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 69 insertions(+)
diff --git a/common/Kconfig b/common/Kconfig
index f594db5..90ba5b2 100644
--- a/common/Kconfig
+++ b/common/Kconfig
@@ -156,6 +156,75 @@ config SPI_BOOT
booted via SPI flash. This is not a must, some SoCs need this,
somes not.
+menu "SPL Boot media"
+ depends on SPL
+
+config SPL_NOR_BOOT
+ bool "Support for booting SPL from NOR flash"
+ default n
+ help
+ Enabling this will make an SPL binary that is capable of being
+ booted via NOR flash. This is not a must, some SoCs need this,
+ some do not.
+
+config SPL_NAND_BOOT
+ bool "Support for booting SPL from NAND flash"
+ default n
+ help
+ Enabling this will make an SPL binary that is capable of being
+ booted via NAND flash. This is not a must, some SoCs need this,
+ some do not.
+
+config SPL_ONENAND_BOOT
+ bool "Support for booting SPL from ONENAND"
+ default n
+ help
+ Enabling this will make an SPL binary that is capable of being
+ booted via ONENAND. This is not a must, some SoCs need this,
+ some do not.
+
+config SPL_QSPI_BOOT
+ bool "Support for booting SPL from QSPI flash"
+ default n
+ help
+ Enabling this will make an SPL binary that is capable of being
+ booted via QSPI flash. This is not a must, some SoCs need this,
+ some do not.
+
+config SPL_SATA_BOOT
+ bool "Support for booting SPL from SATA"
+ default n
+ help
+ Enabling this will make an SPL binary that is capable of being
+ booted via SATA. This is not a must, some SoCs need this,
+ some do not.
+
+config SPL_SD_BOOT
+ bool "Support for booting SPL from SD/MMC/eMMC"
+ default n
+ help
+ Enabling this will make an SPL binary that is capable of being
+ booted via SD/MMC/eMMC. This is not a must, some SoCs need this,
+ some do not.
+
+config SPL_SPI_BOOT
+ bool "Support for booting SPL from SPI flash"
+ default n
+ help
+ Enabling this will make an SPL binary that is capable of being
+ booted via SPI flash. This is not a must, some SoCs need this,
+ some do not.
+
+config SPL_UART_BOOT
+ bool "Support for booting SPL from UART"
+ default n
+ help
+ Enabling this will make an SPL binary that is capable of being
+ booted via UART. This is not a must, some SoCs need this,
+ some do not.
+
+endmenu
+
menu "SPL Media Loading Support"
depends on SPL
--
2.9.3
^ permalink raw reply related [flat|nested] 19+ messages in thread* [U-Boot] [RFC PATCH v2 11/11] spl: Kconfig: Add CONFIG_SPL_TEXT_BASE as Kconfig option
2016-08-22 15:21 [U-Boot] [PATCH v2 00/11] Allow secure boot on AM33xx devices Andrew F. Davis
` (9 preceding siblings ...)
2016-08-22 15:21 ` [U-Boot] [RFC PATCH v2 10/11] spl: Kconfig: Add SPL_<media>_BOOT " Andrew F. Davis
@ 2016-08-22 15:21 ` Andrew F. Davis
2016-08-23 5:45 ` Masahiro Yamada
10 siblings, 1 reply; 19+ messages in thread
From: Andrew F. Davis @ 2016-08-22 15:21 UTC (permalink / raw)
To: u-boot
Add a new Kconfig CONFIG_SPL_TEXT_BASE. Set its default value to 0x0.
Signed-off-by: Andrew F. Davis <afd@ti.com>
---
Kconfig | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/Kconfig b/Kconfig
index cb5af5b..2935c41 100644
--- a/Kconfig
+++ b/Kconfig
@@ -319,6 +319,14 @@ config SYS_TEXT_BASE
help
TODO: Move CONFIG_SYS_TEXT_BASE for all the architecture
+config SPL_TEXT_BASE
+ hex "SPL Text Base"
+ depends on SPL
+ default 0x0
+ help
+ When SPL is enabled the image is linked with this as the
+ starting address in memeory for which the SPL will be loaded.
+
config SPL_LOAD_FIT
bool "Enable SPL loading U-Boot as a FIT"
depends on FIT
--
2.9.3
^ permalink raw reply related [flat|nested] 19+ messages in thread* [U-Boot] [RFC PATCH v2 11/11] spl: Kconfig: Add CONFIG_SPL_TEXT_BASE as Kconfig option
2016-08-22 15:21 ` [U-Boot] [RFC PATCH v2 11/11] spl: Kconfig: Add CONFIG_SPL_TEXT_BASE " Andrew F. Davis
@ 2016-08-23 5:45 ` Masahiro Yamada
2016-08-23 14:57 ` Andrew F. Davis
0 siblings, 1 reply; 19+ messages in thread
From: Masahiro Yamada @ 2016-08-23 5:45 UTC (permalink / raw)
To: u-boot
2016-08-23 0:21 GMT+09:00 Andrew F. Davis <afd@ti.com>:
> Add a new Kconfig CONFIG_SPL_TEXT_BASE. Set its default value to 0x0.
>
> Signed-off-by: Andrew F. Davis <afd@ti.com>
> ---
> Kconfig | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
> diff --git a/Kconfig b/Kconfig
> index cb5af5b..2935c41 100644
> --- a/Kconfig
> +++ b/Kconfig
> @@ -319,6 +319,14 @@ config SYS_TEXT_BASE
> help
> TODO: Move CONFIG_SYS_TEXT_BASE for all the architecture
>
> +config SPL_TEXT_BASE
> + hex "SPL Text Base"
> + depends on SPL
> + default 0x0
> + help
> + When SPL is enabled the image is linked with this as the
> + starting address in memeory for which the SPL will be loaded.
> +
> config SPL_LOAD_FIT
> bool "Enable SPL loading U-Boot as a FIT"
> depends on FIT
For example, my SoC, configs/uniphier_ld20_defconfig,
needs to set CONFIG_SPL_TEXT_BASE to 0x100000
because its Boot ROM loads SPL onto 0x100000.
It is not user-configurable at all, so I do not see much sense for the prompt.
I am not quite sure for other SoCs, but I guess similar situation.
(If we support relocation for SPL, we can make SPL_TEXT_BASE
a configurable parameter, but we do not have it at this point of time.)
Is it better to hide the prompt unless EXPERT is defined?
config SPL_TEXT_BASE
hex "SPL Text Base" if EXPERT
--
Best Regards
Masahiro Yamada
^ permalink raw reply [flat|nested] 19+ messages in thread* [U-Boot] [RFC PATCH v2 11/11] spl: Kconfig: Add CONFIG_SPL_TEXT_BASE as Kconfig option
2016-08-23 5:45 ` Masahiro Yamada
@ 2016-08-23 14:57 ` Andrew F. Davis
2016-08-26 17:59 ` Tom Rini
0 siblings, 1 reply; 19+ messages in thread
From: Andrew F. Davis @ 2016-08-23 14:57 UTC (permalink / raw)
To: u-boot
On 08/23/2016 12:45 AM, Masahiro Yamada wrote:
> 2016-08-23 0:21 GMT+09:00 Andrew F. Davis <afd@ti.com>:
>> Add a new Kconfig CONFIG_SPL_TEXT_BASE. Set its default value to 0x0.
>>
>> Signed-off-by: Andrew F. Davis <afd@ti.com>
>> ---
>> Kconfig | 8 ++++++++
>> 1 file changed, 8 insertions(+)
>>
>> diff --git a/Kconfig b/Kconfig
>> index cb5af5b..2935c41 100644
>> --- a/Kconfig
>> +++ b/Kconfig
>> @@ -319,6 +319,14 @@ config SYS_TEXT_BASE
>> help
>> TODO: Move CONFIG_SYS_TEXT_BASE for all the architecture
>>
>> +config SPL_TEXT_BASE
>> + hex "SPL Text Base"
>> + depends on SPL
>> + default 0x0
>> + help
>> + When SPL is enabled the image is linked with this as the
>> + starting address in memeory for which the SPL will be loaded.
>> +
>> config SPL_LOAD_FIT
>> bool "Enable SPL loading U-Boot as a FIT"
>> depends on FIT
>
>
>
> For example, my SoC, configs/uniphier_ld20_defconfig,
> needs to set CONFIG_SPL_TEXT_BASE to 0x100000
> because its Boot ROM loads SPL onto 0x100000.
>
> It is not user-configurable at all, so I do not see much sense for the prompt.
> I am not quite sure for other SoCs, but I guess similar situation.
>
> (If we support relocation for SPL, we can make SPL_TEXT_BASE
> a configurable parameter, but we do not have it at this point of time.)
>
>
> Is it better to hide the prompt unless EXPERT is defined?
>
> config SPL_TEXT_BASE
> hex "SPL Text Base" if EXPERT
>
>
I would be okay with this, I only really need this as a Kconfig option
so I can easily set it on a per defconfig basis
(am335x_evm_{boot_type}_defconfig), as you stated this isn't really for
users to change and so should be hidden by default.
Andrew
^ permalink raw reply [flat|nested] 19+ messages in thread* [U-Boot] [RFC PATCH v2 11/11] spl: Kconfig: Add CONFIG_SPL_TEXT_BASE as Kconfig option
2016-08-23 14:57 ` Andrew F. Davis
@ 2016-08-26 17:59 ` Tom Rini
0 siblings, 0 replies; 19+ messages in thread
From: Tom Rini @ 2016-08-26 17:59 UTC (permalink / raw)
To: u-boot
On Tue, Aug 23, 2016 at 09:57:34AM -0500, Andrew F. Davis wrote:
> On 08/23/2016 12:45 AM, Masahiro Yamada wrote:
> > 2016-08-23 0:21 GMT+09:00 Andrew F. Davis <afd@ti.com>:
> >> Add a new Kconfig CONFIG_SPL_TEXT_BASE. Set its default value to 0x0.
> >>
> >> Signed-off-by: Andrew F. Davis <afd@ti.com>
> >> ---
> >> Kconfig | 8 ++++++++
> >> 1 file changed, 8 insertions(+)
> >>
> >> diff --git a/Kconfig b/Kconfig
> >> index cb5af5b..2935c41 100644
> >> --- a/Kconfig
> >> +++ b/Kconfig
> >> @@ -319,6 +319,14 @@ config SYS_TEXT_BASE
> >> help
> >> TODO: Move CONFIG_SYS_TEXT_BASE for all the architecture
> >>
> >> +config SPL_TEXT_BASE
> >> + hex "SPL Text Base"
> >> + depends on SPL
> >> + default 0x0
> >> + help
> >> + When SPL is enabled the image is linked with this as the
> >> + starting address in memeory for which the SPL will be loaded.
> >> +
> >> config SPL_LOAD_FIT
> >> bool "Enable SPL loading U-Boot as a FIT"
> >> depends on FIT
> >
> >
> >
> > For example, my SoC, configs/uniphier_ld20_defconfig,
> > needs to set CONFIG_SPL_TEXT_BASE to 0x100000
> > because its Boot ROM loads SPL onto 0x100000.
> >
> > It is not user-configurable at all, so I do not see much sense for the prompt.
> > I am not quite sure for other SoCs, but I guess similar situation.
But note that it also sets CONFIG_SYS_TEXT_BASE=0x84000000 which isn't
really something that should be changed by users.
> > (If we support relocation for SPL, we can make SPL_TEXT_BASE
> > a configurable parameter, but we do not have it at this point of time.)
> >
> >
> > Is it better to hide the prompt unless EXPERT is defined?
> >
> > config SPL_TEXT_BASE
> > hex "SPL Text Base" if EXPERT
> >
> >
>
> I would be okay with this, I only really need this as a Kconfig option
> so I can easily set it on a per defconfig basis
> (am335x_evm_{boot_type}_defconfig), as you stated this isn't really for
> users to change and so should be hidden by default.
I think this shows that we need to think about how to migrate CONFIG_xxx
values that do not belong in CONFIG space. What's really true here
(yes?) is that for HS devices we must be loaded in a different, but
still not really configurable, area. And we don't want to do like we
have in the past of using a compatible with all types address[1] as this
reduces the available image space and SPL is larger than we would like
it to be these days.
I'm not sure if it's better to push this up to the architecture Kconfig
file so that in turn we can do a list of default 0x... if SOC so that
it's correct by default at least, or just be as good/bad as
CONFIG_SYS_TEXT_BASE is for today and follow up with better ideas after
the conversion is done for everything.
--
Tom
[1]: By which I mean, iirc, ROM starts looking at offset 0x0 and
executes the NOP instructions (ie 0x0) until we get into actual SPL
code.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20160826/fd75d3dc/attachment.sig>
^ permalink raw reply [flat|nested] 19+ messages in thread