[U-Boot] [PATCH 00/16] Support for boot image creation for TI secure devices

[U-Boot] [PATCH 00/16] Support for boot image creation for TI secure devices

[Daniel Allred]

Adds support for creating bootable images for AM43xx HS
and DRA7xx/AM57xx HS devices.

Daniel Allred (10):
  doc: Add info on using secure devices from TI
  ti: omap-common: Add commands for generating secure SPL images
  ti: AM43xx: config.mk: Add support for generating secure boot images
  ti_omap5_common: Update SPL start address on secure parts
  spl: build: ti: add support for secure boot images
  ARM: omap4/5: Add device type to CPU string
  ARM: omap5: add hooks for cpu/SoC fdt fixups
  ARM: omap5: add ft_board_setup for dra7xx/am57xx
  ARM: omap5: Add config for board/cpu fdt fixups
  defconfig: ti: Add configs for OMAP5-class secure parts

Madan Srinivas (6):
  arm: am33xx: Kconfig: Add secure device definitions
  arm: Kconfig: Add support for AM43xx SoC specific Kconfig
  ti: omap-common: Add Kconfig file for secure device support
  ti: AM43xx: Use CONFIG options from SOC Kconfig
  ti: AM43xx: board: Detect AM43xx HS EVM
  defconfig: Add configs for AM43xx secure parts

 arch/arm/Kconfig                                |  23 +--
 arch/arm/cpu/armv7/am33xx/Kconfig               |  40 ++++++
 arch/arm/cpu/armv7/am33xx/config.mk             |  20 +++
 arch/arm/cpu/armv7/omap-common/Kconfig          |  17 +++
 arch/arm/cpu/armv7/omap-common/config_secure.mk |  66 +++++++++
 arch/arm/cpu/armv7/omap-common/hwinit-common.c  |  22 ++-
 arch/arm/cpu/armv7/omap5/Makefile               |   1 +
 arch/arm/cpu/armv7/omap5/config.mk              |   6 +
 arch/arm/cpu/armv7/omap5/fdt.c                  | 183 ++++++++++++++++++++++++
 arch/arm/include/asm/arch-omap4/cpu.h           |   7 +
 arch/arm/include/asm/arch-omap5/cpu.h           |   7 +
 board/ti/am43xx/board.c                         |   4 +-
 board/ti/am43xx/board.h                         |  14 +-
 board/ti/am43xx/mux.c                           |   2 +-
 board/ti/am57xx/board.c                         |   9 ++
 board/ti/dra7xx/evm.c                           |   9 ++
 configs/am43xx_evm_defconfig                    |   1 +
 configs/am43xx_evm_ethboot_defconfig            |   1 +
 configs/am43xx_evm_qspiboot_defconfig           |   2 +
 configs/am43xx_evm_usbhost_boot_defconfig       |   2 +
 configs/am43xx_hs_evm_defconfig                 |  12 ++
 configs/am43xx_hs_evm_ethboot_defconfig         |  11 ++
 configs/am43xx_hs_evm_qspiboot_defconfig        |  10 ++
 configs/am43xx_hs_evm_rtconly_defconfig         |  12 ++
 configs/am43xx_hs_evm_usbhost_boot_defconfig    |  11 ++
 configs/am43xx_hs_evm_usbspl_defconfig          |  12 ++
 configs/am57xx_hs_evm_defconfig                 |  20 +++
 configs/dra72_hs_evm_defconfig                  |  28 ++++
 configs/dra74_hs_evm_defconfig                  |  27 ++++
 doc/README.ti-secure                            |  92 ++++++++++++
 include/configs/am43xx_evm.h                    |  23 ++-
 include/configs/am57xx_evm.h                    |   3 +
 include/configs/dra7xx_evm.h                    |   3 +
 include/configs/ti_omap5_common.h               |  32 ++++-
 34 files changed, 695 insertions(+), 37 deletions(-)
 create mode 100644 arch/arm/cpu/armv7/am33xx/Kconfig
 create mode 100644 arch/arm/cpu/armv7/omap-common/Kconfig
 create mode 100644 arch/arm/cpu/armv7/omap-common/config_secure.mk
 create mode 100644 arch/arm/cpu/armv7/omap5/fdt.c
 create mode 100644 configs/am43xx_hs_evm_defconfig
 create mode 100644 configs/am43xx_hs_evm_ethboot_defconfig
 create mode 100644 configs/am43xx_hs_evm_qspiboot_defconfig
 create mode 100644 configs/am43xx_hs_evm_rtconly_defconfig
 create mode 100644 configs/am43xx_hs_evm_usbhost_boot_defconfig
 create mode 100644 configs/am43xx_hs_evm_usbspl_defconfig
 create mode 100644 configs/am57xx_hs_evm_defconfig
 create mode 100644 configs/dra72_hs_evm_defconfig
 create mode 100644 configs/dra74_hs_evm_defconfig
 create mode 100644 doc/README.ti-secure

-- 
1.9.1

[U-Boot] [PATCH 01/16] doc: Add info on using secure devices from TI

[Daniel Allred]

Adds doc/README.ti-secure file to explain in generic terms
how boot images need to be created for secure devices from
Texas Instruments.

Specific details for creating secure boot images for the
AM43xx, DRA7xx and AM57xx secure devices from Texas
Instruments are also provided in the README file.

Secure devices require a security development package (SECDEV)
package that can be downloaded from:

	http://www.ti.com/mysecuresoftware

Login is required and access is granted under appropriate NDA
and export control restrictions.

Signed-off-by: Madan Srinivas <madans@ti.com>
Signed-off-by: Daniel Allred <d-allred@ti.com>
---
 doc/README.ti-secure | 92 ++++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 92 insertions(+)
 create mode 100644 doc/README.ti-secure

diff --git a/doc/README.ti-secure b/doc/README.ti-secure
new file mode 100644
index 0000000..fa818ae
--- /dev/null
+++ b/doc/README.ti-secure
@@ -0,0 +1,92 @@
+README on how boot images are created for secure TI devices
+
+CONFIG_TI_SECURE_DEVICE:
+Secure TI devices require a boot image that is authenticated by ROM
+code to function. Without this, even JTAG remains locked and the
+device is essentially useless. In order to create a valid boot image for
+a secure device from TI, the initial public software image must be signed
+and combined with various headers, certificates, and other binary images.
+
+Information on the details on the complete boot image format can be obtained
+from Texas Instruments. The tools used to generate boot images for secure
+devices are part of a secure development package (SECDEV) that can be
+downloaded from:
+
+	http://www.ti.com/mysecuresoftware (login required)
+
+The secure development package is access controlled due to NDA and export
+control restrictions. Access must be requested and granted by TI before the
+package is viewable and downloadable. Contact TI, either online or by way
+of a local TI representative, to request access.
+
+When CONFIG_TI_SECURE_DEVICE is set, the U-Boot SPL build process requires
+the presence and use of these tools in order to create a viable boot image.
+The build process will look for the environment variable TI_SECURE_DEV_PKG,
+which should be the path of the installed SECDEV package. If the
+TI_SECURE_DEV_PKG variable is not defined or if it is defined but doesn't
+point to a valid SECDEV package, a warning is issued during the build to
+indicate that a final secure bootable image was not created.
+
+Within the SECDEV package exists an image creation script:
+
+${TI_SECURE_DEV_PKG}/scripts/create-boot-image.sh
+
+This is called as part of the SPL/u-boot build process. As the secure boot
+image formats and requirements differ between secure SOC from TI, the
+purpose of this script is to abstract these details as much as possible.
+
+The script is basically the only required interface to the TI SECDEV package
+for secure TI devices.
+
+Invoking the script for AM43xx 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)
+	XIP_X-LOADER - Generates a single stage u-boot for NOR/QSPI XiP
+	ISSW - Generates an image for all other boot modes
+
+<INPUT_FILE> is the full path and filename of the public world boot loader
+binary 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_HS_XIP_X-LOADER - boot image for NOR or QSPI flash
+	u-boot-spl_HS_ISSW - boot image for all other boot media
+
+<SPL_LOAD_ADDR> is the address at which SOC ROM should load the <INPUT_FILE>
+
+Invoking the script for DRA7xx/AM57xx Secure Devices
+====================================================
+
+create-boot-image.sh <IMAGE_TYPE> <INPUT_FILE> <OUTPUT_FILE>
+
+<IMAGE_TYPE> is a value that specifies the type of the image to generate OR
+the action the image generation tool will take. Valid values are:
+	X-LOADER - Generates an image for NOR or QSPI boot modes
+	MLO - Generates an image for SD/MMC/eMMC boot modes
+	ULO - Generates an image for USB/UART peripheral boot modes
+	Note: ULO is not yet used by the u-boot build process
+
+<INPUT_FILE> is the full path and filename of the public world boot loader
+binary file (for this platform, this is always u-boot-spl.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_MLO - boot image for SD/MMC/eMMC.This image is
+		copied to a file named MLO, which is the name that
+		the device ROM bootloader requires for loading from
+		the FAT partition of an SD card (same as on
+		non-secure devices)
+	u-boot-spl_HS_X-LOADER - boot image for all other flash memories
+		including QSPI and NOR flash
-- 
1.9.1

[U-Boot] [PATCH 01/16] doc: Add info on using secure devices from TI

[Lokesh Vutla]

On Tuesday 12 April 2016 05:07 AM, Daniel Allred wrote:
> Adds doc/README.ti-secure file to explain in generic terms
> how boot images need to be created for secure devices from
> Texas Instruments.
> 
> Specific details for creating secure boot images for the
> AM43xx, DRA7xx and AM57xx secure devices from Texas
> Instruments are also provided in the README file.
> 
> Secure devices require a security development package (SECDEV)
> package that can be downloaded from:
> 
> 	http://www.ti.com/mysecuresoftware
> 
> Login is required and access is granted under appropriate NDA
> and export control restrictions.

Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>

Thanks and regards,
Lokesh

[U-Boot] [PATCH 01/16] doc: Add info on using secure devices from TI

[Andreas Dannenberg]

On Mon, Apr 11, 2016 at 06:37:03PM -0500, Daniel Allred wrote:
> Adds doc/README.ti-secure file to explain in generic terms
> how boot images need to be created for secure devices from
> Texas Instruments.
> 
> Specific details for creating secure boot images for the
> AM43xx, DRA7xx and AM57xx secure devices from Texas
> Instruments are also provided in the README file.
> 
> Secure devices require a security development package (SECDEV)
> package that can be downloaded from:
> 
> 	http://www.ti.com/mysecuresoftware
> 
> Login is required and access is granted under appropriate NDA
> and export control restrictions.
> 
> Signed-off-by: Madan Srinivas <madans@ti.com>
> Signed-off-by: Daniel Allred <d-allred@ti.com>
> ---
>  doc/README.ti-secure | 92 ++++++++++++++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 92 insertions(+)
>  create mode 100644 doc/README.ti-secure
> 
> diff --git a/doc/README.ti-secure b/doc/README.ti-secure
> new file mode 100644
> index 0000000..fa818ae
> --- /dev/null
> +++ b/doc/README.ti-secure
> @@ -0,0 +1,92 @@
> +README on how boot images are created for secure TI devices
> +
> +CONFIG_TI_SECURE_DEVICE:
> +Secure TI devices require a boot image that is authenticated by ROM
> +code to function. Without this, even JTAG remains locked and the
> +device is essentially useless. In order to create a valid boot image for
> +a secure device from TI, the initial public software image must be signed
> +and combined with various headers, certificates, and other binary images.
> +
> +Information on the details on the complete boot image format can be obtained
> +from Texas Instruments. The tools used to generate boot images for secure
> +devices are part of a secure development package (SECDEV) that can be
> +downloaded from:
> +
> +	http://www.ti.com/mysecuresoftware (login required)
> +
> +The secure development package is access controlled due to NDA and export
> +control restrictions. Access must be requested and granted by TI before the
> +package is viewable and downloadable. Contact TI, either online or by way
> +of a local TI representative, to request access.
> +
> +When CONFIG_TI_SECURE_DEVICE is set, the U-Boot SPL build process requires
> +the presence and use of these tools in order to create a viable boot image.
> +The build process will look for the environment variable TI_SECURE_DEV_PKG,
> +which should be the path of the installed SECDEV package. If the
> +TI_SECURE_DEV_PKG variable is not defined or if it is defined but doesn't
> +point to a valid SECDEV package, a warning is issued during the build to
> +indicate that a final secure bootable image was not created.
> +
> +Within the SECDEV package exists an image creation script:
> +
> +${TI_SECURE_DEV_PKG}/scripts/create-boot-image.sh
> +
> +This is called as part of the SPL/u-boot build process. As the secure boot
> +image formats and requirements differ between secure SOC from TI, the
> +purpose of this script is to abstract these details as much as possible.
> +
> +The script is basically the only required interface to the TI SECDEV package
> +for secure TI devices.
> +
> +Invoking the script for AM43xx 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)
> +	XIP_X-LOADER - Generates a single stage u-boot for NOR/QSPI XiP
> +	ISSW - Generates an image for all other boot modes
> +
> +<INPUT_FILE> is the full path and filename of the public world boot loader
> +binary 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_HS_XIP_X-LOADER - boot image for NOR or QSPI flash
> +	u-boot-spl_HS_ISSW - boot image for all other boot media
> +
> +<SPL_LOAD_ADDR> is the address at which SOC ROM should load the <INPUT_FILE>
> +
> +Invoking the script for DRA7xx/AM57xx Secure Devices
> +====================================================
> +
> +create-boot-image.sh <IMAGE_TYPE> <INPUT_FILE> <OUTPUT_FILE>
> +
> +<IMAGE_TYPE> is a value that specifies the type of the image to generate OR
> +the action the image generation tool will take. Valid values are:
> +	X-LOADER - Generates an image for NOR or QSPI boot modes
> +	MLO - Generates an image for SD/MMC/eMMC boot modes
> +	ULO - Generates an image for USB/UART peripheral boot modes
> +	Note: ULO is not yet used by the u-boot build process
> +
> +<INPUT_FILE> is the full path and filename of the public world boot loader
> +binary file (for this platform, this is always u-boot-spl.bin).
> +
> +

Minor nit-picks... Extra blank line.

> +<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_MLO - boot image for SD/MMC/eMMC.This image is

Missing space after punctuation mark.


Reviewed-by: Andreas Dannenberg <dannenberg@ti.com>

--
Andreas Dannenberg
Texas Instruments Inc

> +		copied to a file named MLO, which is the name that
> +		the device ROM bootloader requires for loading from
> +		the FAT partition of an SD card (same as on
> +		non-secure devices)
> +	u-boot-spl_HS_X-LOADER - boot image for all other flash memories
> +		including QSPI and NOR flash
> -- 
> 1.9.1
> 
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH 01/16] doc: Add info on using secure devices from TI

[Tom Rini]

On Mon, Apr 11, 2016 at 06:37:03PM -0500, Daniel Allred wrote:

> Adds doc/README.ti-secure file to explain in generic terms
> how boot images need to be created for secure devices from
> Texas Instruments.
> 
> Specific details for creating secure boot images for the
> AM43xx, DRA7xx and AM57xx secure devices from Texas
> Instruments are also provided in the README file.
> 
> Secure devices require a security development package (SECDEV)
> package that can be downloaded from:
> 
> 	http://www.ti.com/mysecuresoftware
> 
> Login is required and access is granted under appropriate NDA
> and export control restrictions.
> 
> Signed-off-by: Madan Srinivas <madans@ti.com>
> Signed-off-by: Daniel Allred <d-allred@ti.com>

Reviewed-by: Tom Rini <trini@konsulko.com>

-- 
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/20160421/ff010762/attachment.sig>

[U-Boot] [PATCH 02/16] arm: am33xx: Kconfig: Add secure device definitions

[Daniel Allred]

From: Madan Srinivas <madans@ti.com>

Adds a new Kconfig file for AM33xx class devices. We
need a common place to define CONFIG parameters
for these SOCs, especially for adding support
for secure devices.

a) Adds a definition for ISW_ENTRY_ADDR. This is the
address to which the ROM branches when the SOC
ROM hands off execution to the boot loader.
CONFIG_SYS_TEXT_BASE and CONFIG_SPL_TEXT_BASE are set
to this value for AM43xx devices.

b) Adds CONFIG_PUB_ROM_DATA_SIZE which is used to
calculate CONFIG_SPL_MAX_SIZE. This value indicates the
amount of memory needed by the ROM to store data during
the boot process.

Currently, these CONFIG options are used only by AM43xx,
but in future other AM33xx class SOCs will also use them.

Signed-off-by: Madan Srinivas <madans@ti.com>
Signed-off-by: Daniel Allred <d-allred@ti.com>
---
 arch/arm/cpu/armv7/am33xx/Kconfig | 27 +++++++++++++++++++++++++++
 1 file changed, 27 insertions(+)
 create mode 100644 arch/arm/cpu/armv7/am33xx/Kconfig

diff --git a/arch/arm/cpu/armv7/am33xx/Kconfig b/arch/arm/cpu/armv7/am33xx/Kconfig
new file mode 100644
index 0000000..39759cd
--- /dev/null
+++ b/arch/arm/cpu/armv7/am33xx/Kconfig
@@ -0,0 +1,27 @@
+config ISW_ENTRY_ADDR
+	hex "Address in memory or XIP flash of bootloader entry point"
+	help
+	  After any reset, the boot ROM on the AM43XX SOC
+	  searches the boot media for a valid boot image.
+	  For non-XIP devices, the ROM then copies the
+	  image into internal memory.
+	  For all boot modes, after the ROM processes the
+	  boot image it eventually computes the entry
+	  point address depending on the device type
+	  (secure/non-secure), boot media (xip/non-xip) and
+	  image headers.
+	default 0x402F4000
+
+config PUB_ROM_DATA_SIZE
+	hex "Size in bytes of the L3 SRAM reserved by ROM to store data"
+	help
+	  During the device boot, the public ROM uses the top of
+	  the public L3 OCMC RAM to store r/w data like stack,
+	  heap, globals etc. When the ROM is copying the boot
+	  image from the boot media into memory, the image must
+	  not spill over into this area. This value can be used
+	  during compile time to determine the maximum size of a
+	  boot image. Once the ROM transfers control to the boot
+	  image, this area is no longer used, and can be reclaimed
+	  for run time use by the boot image.
+	default 0x8400
-- 
1.9.1

[U-Boot] [PATCH 02/16] arm: am33xx: Kconfig: Add secure device definitions

[Lokesh Vutla]

On Tuesday 12 April 2016 05:07 AM, Daniel Allred wrote:
> From: Madan Srinivas <madans@ti.com>
> 
> Adds a new Kconfig file for AM33xx class devices. We
> need a common place to define CONFIG parameters
> for these SOCs, especially for adding support
> for secure devices.
> 
> a) Adds a definition for ISW_ENTRY_ADDR. This is the
> address to which the ROM branches when the SOC
> ROM hands off execution to the boot loader.
> CONFIG_SYS_TEXT_BASE and CONFIG_SPL_TEXT_BASE are set
> to this value for AM43xx devices.
> 
> b) Adds CONFIG_PUB_ROM_DATA_SIZE which is used to
> calculate CONFIG_SPL_MAX_SIZE. This value indicates the
> amount of memory needed by the ROM to store data during
> the boot process.
> 
> Currently, these CONFIG options are used only by AM43xx,
> but in future other AM33xx class SOCs will also use them.

Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>

Thanks and regards,
Lokesh

[U-Boot] [PATCH 02/16] arm: am33xx: Kconfig: Add secure device definitions

[Andreas Dannenberg]

On Mon, Apr 11, 2016 at 06:37:04PM -0500, Daniel Allred wrote:
> From: Madan Srinivas <madans@ti.com>
> 
> Adds a new Kconfig file for AM33xx class devices. We
> need a common place to define CONFIG parameters
> for these SOCs, especially for adding support
> for secure devices.
> 
> a) Adds a definition for ISW_ENTRY_ADDR. This is the
> address to which the ROM branches when the SOC
> ROM hands off execution to the boot loader.
> CONFIG_SYS_TEXT_BASE and CONFIG_SPL_TEXT_BASE are set
> to this value for AM43xx devices.
> 
> b) Adds CONFIG_PUB_ROM_DATA_SIZE which is used to
> calculate CONFIG_SPL_MAX_SIZE. This value indicates the
> amount of memory needed by the ROM to store data during
> the boot process.
> 
> Currently, these CONFIG options are used only by AM43xx,
> but in future other AM33xx class SOCs will also use them.
> 
> Signed-off-by: Madan Srinivas <madans@ti.com>
> Signed-off-by: Daniel Allred <d-allred@ti.com>

Tested-by: Andreas Dannenberg <dannenberg@ti.com>

--
Andreas Dannenberg
Texas Instruments Inc

[U-Boot] [PATCH 02/16] arm: am33xx: Kconfig: Add secure device definitions

[Tom Rini]

On Mon, Apr 11, 2016 at 06:37:04PM -0500, Daniel Allred wrote:

> From: Madan Srinivas <madans@ti.com>
> 
> Adds a new Kconfig file for AM33xx class devices. We
> need a common place to define CONFIG parameters
> for these SOCs, especially for adding support
> for secure devices.
> 
> a) Adds a definition for ISW_ENTRY_ADDR. This is the
> address to which the ROM branches when the SOC
> ROM hands off execution to the boot loader.
> CONFIG_SYS_TEXT_BASE and CONFIG_SPL_TEXT_BASE are set
> to this value for AM43xx devices.
> 
> b) Adds CONFIG_PUB_ROM_DATA_SIZE which is used to
> calculate CONFIG_SPL_MAX_SIZE. This value indicates the
> amount of memory needed by the ROM to store data during
> the boot process.
> 
> Currently, these CONFIG options are used only by AM43xx,
> but in future other AM33xx class SOCs will also use them.
> 
> Signed-off-by: Madan Srinivas <madans@ti.com>
> Signed-off-by: Daniel Allred <d-allred@ti.com>

Reviewed-by: Tom Rini <trini@konsulko.com>

-- 
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/20160421/d966663e/attachment.sig>

[U-Boot] [PATCH 03/16] arm: Kconfig: Add support for AM43xx SoC specific Kconfig

[Daniel Allred]

From: Madan Srinivas <madans@ti.com>

Adding support for AM43xx secure devices require the addition
of some SOC specific config options like the amount of memory
used by public ROM and the address of the entry point of u-boot
or SPL, as seen by the ROM code, for the image to be built
correctly.

This mandates the addition of am AM43xx CONFIG option and the
ARM Kconfig file has been modified to source this SOC Kconfig
file. Moving the TARGET_AM43XX_EVM config option to the SOC
KConfig and out of the arch/arm/Kconfig.

Updating defconfigs to add the CONFIG_AM43XX=y statement and
removing the #define CONFIG_AM43XX from the header file.

Signed-off-by: Madan Srinivas <madans@ti.com>
Signed-off-by: Daniel Allred <d-allred@ti.com>
---
 arch/arm/Kconfig                          | 19 +++++++++++++------
 arch/arm/cpu/armv7/am33xx/Kconfig         | 13 +++++++++++++
 configs/am43xx_evm_defconfig              |  1 +
 configs/am43xx_evm_ethboot_defconfig      |  1 +
 configs/am43xx_evm_qspiboot_defconfig     |  1 +
 configs/am43xx_evm_usbhost_boot_defconfig |  1 +
 include/configs/am43xx_evm.h              |  2 --
 7 files changed, 30 insertions(+), 8 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index f18dbe6..088d6e0 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -381,12 +381,6 @@ config TARGET_AM335X_SL50
 	select DM
 	select DM_SERIAL
 
-config TARGET_AM43XX_EVM
-	bool "Support am43xx_evm"
-	select CPU_V7
-	select SUPPORT_SPL
-	select TI_I2C_BOARD_DETECT
-
 config TARGET_BAV335X
 	bool "Support bav335x"
 	select CPU_V7
@@ -507,6 +501,17 @@ config OMAP54XX
 	select CPU_V7
 	select SUPPORT_SPL
 
+config AM43XX
+	bool "AM43XX SoC"
+	select CPU_V7
+	select SUPPORT_SPL
+	help
+	  Support for AM43xx SOC from Texas Instruments.
+	  The AM43xx high performance SOC features a Cortex-A9
+	  ARM core, a quad core PRU-ICSS for industrial Ethernet
+	  protocols, dual camera support, optional 3D graphics
+	  and an optional customer programmable secure boot.
+
 config RMOBILE
 	bool "Renesas ARM SoCs"
 	select CPU_V7
@@ -776,6 +781,8 @@ source "arch/arm/cpu/armv7/omap4/Kconfig"
 
 source "arch/arm/cpu/armv7/omap5/Kconfig"
 
+source "arch/arm/cpu/armv7/am33xx/Kconfig"
+
 source "arch/arm/mach-orion5x/Kconfig"
 
 source "arch/arm/cpu/armv7/rmobile/Kconfig"
diff --git a/arch/arm/cpu/armv7/am33xx/Kconfig b/arch/arm/cpu/armv7/am33xx/Kconfig
index 39759cd..68bcc64 100644
--- a/arch/arm/cpu/armv7/am33xx/Kconfig
+++ b/arch/arm/cpu/armv7/am33xx/Kconfig
@@ -1,3 +1,15 @@
+if AM43XX
+config TARGET_AM43XX_EVM
+	bool "Support am43xx_evm"
+	select CREATE_BOARD_SYMLINK
+	help
+	  This option specifies support for the AM43xx
+	  GP and HS EVM development platforms.The AM437x
+	  GP EVM is a standalone test, development, and
+	  evaluation module system that enables developers
+	  to write software and develop hardware around
+	  an AM43xx processor subsystem.
+
 config ISW_ENTRY_ADDR
 	hex "Address in memory or XIP flash of bootloader entry point"
 	help
@@ -25,3 +37,4 @@ config PUB_ROM_DATA_SIZE
 	  image, this area is no longer used, and can be reclaimed
 	  for run time use by the boot image.
 	default 0x8400
+endif
diff --git a/configs/am43xx_evm_defconfig b/configs/am43xx_evm_defconfig
index cc83006..4b0a188 100644
--- a/configs/am43xx_evm_defconfig
+++ b/configs/am43xx_evm_defconfig
@@ -1,4 +1,5 @@
 CONFIG_ARM=y
+CONFIG_AM43XX=y
 CONFIG_TARGET_AM43XX_EVM=y
 CONFIG_SPL=y
 CONFIG_SYS_EXTRA_OPTIONS="SERIAL1,CONS_INDEX=1,NAND"
diff --git a/configs/am43xx_evm_ethboot_defconfig b/configs/am43xx_evm_ethboot_defconfig
index a720c14..20001ca 100644
--- a/configs/am43xx_evm_ethboot_defconfig
+++ b/configs/am43xx_evm_ethboot_defconfig
@@ -1,4 +1,5 @@
 CONFIG_ARM=y
+CONFIG_AM43XX=y
 CONFIG_TARGET_AM43XX_EVM=y
 CONFIG_SPL=y
 CONFIG_SYS_EXTRA_OPTIONS="SERIAL1,CONS_INDEX=1,NAND,SPL_ETH_SUPPORT"
diff --git a/configs/am43xx_evm_qspiboot_defconfig b/configs/am43xx_evm_qspiboot_defconfig
index 6db389b..2170a68 100644
--- a/configs/am43xx_evm_qspiboot_defconfig
+++ b/configs/am43xx_evm_qspiboot_defconfig
@@ -1,4 +1,5 @@
 CONFIG_ARM=y
+CONFIG_AM43XX=y
 CONFIG_TARGET_AM43XX_EVM=y
 CONFIG_SYS_EXTRA_OPTIONS="SERIAL1,CONS_INDEX=1,QSPI,QSPI_BOOT"
 # CONFIG_CMD_IMLS is not set
diff --git a/configs/am43xx_evm_usbhost_boot_defconfig b/configs/am43xx_evm_usbhost_boot_defconfig
index cbaf5a5..14343a9 100644
--- a/configs/am43xx_evm_usbhost_boot_defconfig
+++ b/configs/am43xx_evm_usbhost_boot_defconfig
@@ -1,4 +1,5 @@
 CONFIG_ARM=y
+CONFIG_AM43XX=y
 CONFIG_TARGET_AM43XX_EVM=y
 CONFIG_SPL=y
 CONFIG_SYS_EXTRA_OPTIONS="SERIAL1,CONS_INDEX=1,NAND,SPL_USB_HOST_SUPPORT"
diff --git a/include/configs/am43xx_evm.h b/include/configs/am43xx_evm.h
index fd3f6a7..b98f7a1 100644
--- a/include/configs/am43xx_evm.h
+++ b/include/configs/am43xx_evm.h
@@ -9,8 +9,6 @@
 #ifndef __CONFIG_AM43XX_EVM_H
 #define __CONFIG_AM43XX_EVM_H
 
-#define CONFIG_AM43XX
-
 #define CONFIG_CMD_FAT
 
 #define CONFIG_BOARD_LATE_INIT
-- 
1.9.1

[U-Boot] [PATCH 03/16] arm: Kconfig: Add support for AM43xx SoC specific Kconfig

[Lokesh Vutla]

On Tuesday 12 April 2016 05:07 AM, Daniel Allred wrote:
> From: Madan Srinivas <madans@ti.com>
> 
> Adding support for AM43xx secure devices require the addition
> of some SOC specific config options like the amount of memory
> used by public ROM and the address of the entry point of u-boot
> or SPL, as seen by the ROM code, for the image to be built
> correctly.
> 
> This mandates the addition of am AM43xx CONFIG option and the
> ARM Kconfig file has been modified to source this SOC Kconfig
> file. Moving the TARGET_AM43XX_EVM config option to the SOC
> KConfig and out of the arch/arm/Kconfig.
> 
> Updating defconfigs to add the CONFIG_AM43XX=y statement and
> removing the #define CONFIG_AM43XX from the header file.

Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>

Thanks and regards,
Lokesh

[U-Boot] [PATCH 03/16] arm: Kconfig: Add support for AM43xx SoC specific Kconfig

[Lokesh Vutla]

On Tuesday 12 April 2016 05:07 AM, Daniel Allred wrote:
> From: Madan Srinivas <madans@ti.com>
> 
> Adding support for AM43xx secure devices require the addition
> of some SOC specific config options like the amount of memory
> used by public ROM and the address of the entry point of u-boot
> or SPL, as seen by the ROM code, for the image to be built
> correctly.
> 
> This mandates the addition of am AM43xx CONFIG option and the
> ARM Kconfig file has been modified to source this SOC Kconfig
> file. Moving the TARGET_AM43XX_EVM config option to the SOC
> KConfig and out of the arch/arm/Kconfig.
> 
> Updating defconfigs to add the CONFIG_AM43XX=y statement and
> removing the #define CONFIG_AM43XX from the header file.
> 
> Signed-off-by: Madan Srinivas <madans@ti.com>
> Signed-off-by: Daniel Allred <d-allred@ti.com>
> ---
>  arch/arm/Kconfig                          | 19 +++++++++++++------
>  arch/arm/cpu/armv7/am33xx/Kconfig         | 13 +++++++++++++
>  configs/am43xx_evm_defconfig              |  1 +
>  configs/am43xx_evm_ethboot_defconfig      |  1 +
>  configs/am43xx_evm_qspiboot_defconfig     |  1 +
>  configs/am43xx_evm_usbhost_boot_defconfig |  1 +
>  include/configs/am43xx_evm.h              |  2 --
>  7 files changed, 30 insertions(+), 8 deletions(-)
> 
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index f18dbe6..088d6e0 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -381,12 +381,6 @@ config TARGET_AM335X_SL50
>  	select DM
>  	select DM_SERIAL
>  
> -config TARGET_AM43XX_EVM
> -	bool "Support am43xx_evm"
> -	select CPU_V7
> -	select SUPPORT_SPL
> -	select TI_I2C_BOARD_DETECT
> -
>  config TARGET_BAV335X
>  	bool "Support bav335x"
>  	select CPU_V7
> @@ -507,6 +501,17 @@ config OMAP54XX
>  	select CPU_V7
>  	select SUPPORT_SPL
>  
> +config AM43XX
> +	bool "AM43XX SoC"
> +	select CPU_V7
> +	select SUPPORT_SPL
> +	help
> +	  Support for AM43xx SOC from Texas Instruments.
> +	  The AM43xx high performance SOC features a Cortex-A9
> +	  ARM core, a quad core PRU-ICSS for industrial Ethernet
> +	  protocols, dual camera support, optional 3D graphics
> +	  and an optional customer programmable secure boot.
> +
>  config RMOBILE
>  	bool "Renesas ARM SoCs"
>  	select CPU_V7
> @@ -776,6 +781,8 @@ source "arch/arm/cpu/armv7/omap4/Kconfig"
>  
>  source "arch/arm/cpu/armv7/omap5/Kconfig"
>  
> +source "arch/arm/cpu/armv7/am33xx/Kconfig"
> +
>  source "arch/arm/mach-orion5x/Kconfig"
>  
>  source "arch/arm/cpu/armv7/rmobile/Kconfig"
> diff --git a/arch/arm/cpu/armv7/am33xx/Kconfig b/arch/arm/cpu/armv7/am33xx/Kconfig
> index 39759cd..68bcc64 100644
> --- a/arch/arm/cpu/armv7/am33xx/Kconfig
> +++ b/arch/arm/cpu/armv7/am33xx/Kconfig
> @@ -1,3 +1,15 @@
> +if AM43XX
> +config TARGET_AM43XX_EVM
> +	bool "Support am43xx_evm"
> +	select CREATE_BOARD_SYMLINK

This should be TI_I2C_BOARD_DETECT or else you will get a build error.

Thanks and regards,
Lokesh

> +	help
> +	  This option specifies support for the AM43xx
> +	  GP and HS EVM development platforms.The AM437x
> +	  GP EVM is a standalone test, development, and
> +	  evaluation module system that enables developers
> +	  to write software and develop hardware around
> +	  an AM43xx processor subsystem.
> +
>  config ISW_ENTRY_ADDR
>  	hex "Address in memory or XIP flash of bootloader entry point"
>  	help
> @@ -25,3 +37,4 @@ config PUB_ROM_DATA_SIZE
>  	  image, this area is no longer used, and can be reclaimed
>  	  for run time use by the boot image.
>  	default 0x8400
> +endif
> diff --git a/configs/am43xx_evm_defconfig b/configs/am43xx_evm_defconfig
> index cc83006..4b0a188 100644
> --- a/configs/am43xx_evm_defconfig
> +++ b/configs/am43xx_evm_defconfig
> @@ -1,4 +1,5 @@
>  CONFIG_ARM=y
> +CONFIG_AM43XX=y
>  CONFIG_TARGET_AM43XX_EVM=y
>  CONFIG_SPL=y
>  CONFIG_SYS_EXTRA_OPTIONS="SERIAL1,CONS_INDEX=1,NAND"
> diff --git a/configs/am43xx_evm_ethboot_defconfig b/configs/am43xx_evm_ethboot_defconfig
> index a720c14..20001ca 100644
> --- a/configs/am43xx_evm_ethboot_defconfig
> +++ b/configs/am43xx_evm_ethboot_defconfig
> @@ -1,4 +1,5 @@
>  CONFIG_ARM=y
> +CONFIG_AM43XX=y
>  CONFIG_TARGET_AM43XX_EVM=y
>  CONFIG_SPL=y
>  CONFIG_SYS_EXTRA_OPTIONS="SERIAL1,CONS_INDEX=1,NAND,SPL_ETH_SUPPORT"
> diff --git a/configs/am43xx_evm_qspiboot_defconfig b/configs/am43xx_evm_qspiboot_defconfig
> index 6db389b..2170a68 100644
> --- a/configs/am43xx_evm_qspiboot_defconfig
> +++ b/configs/am43xx_evm_qspiboot_defconfig
> @@ -1,4 +1,5 @@
>  CONFIG_ARM=y
> +CONFIG_AM43XX=y
>  CONFIG_TARGET_AM43XX_EVM=y
>  CONFIG_SYS_EXTRA_OPTIONS="SERIAL1,CONS_INDEX=1,QSPI,QSPI_BOOT"
>  # CONFIG_CMD_IMLS is not set
> diff --git a/configs/am43xx_evm_usbhost_boot_defconfig b/configs/am43xx_evm_usbhost_boot_defconfig
> index cbaf5a5..14343a9 100644
> --- a/configs/am43xx_evm_usbhost_boot_defconfig
> +++ b/configs/am43xx_evm_usbhost_boot_defconfig
> @@ -1,4 +1,5 @@
>  CONFIG_ARM=y
> +CONFIG_AM43XX=y
>  CONFIG_TARGET_AM43XX_EVM=y
>  CONFIG_SPL=y
>  CONFIG_SYS_EXTRA_OPTIONS="SERIAL1,CONS_INDEX=1,NAND,SPL_USB_HOST_SUPPORT"
> diff --git a/include/configs/am43xx_evm.h b/include/configs/am43xx_evm.h
> index fd3f6a7..b98f7a1 100644
> --- a/include/configs/am43xx_evm.h
> +++ b/include/configs/am43xx_evm.h
> @@ -9,8 +9,6 @@
>  #ifndef __CONFIG_AM43XX_EVM_H
>  #define __CONFIG_AM43XX_EVM_H
>  
> -#define CONFIG_AM43XX
> -
>  #define CONFIG_CMD_FAT
>  
>  #define CONFIG_BOARD_LATE_INIT
> 

[U-Boot] [PATCH 03/16] arm: Kconfig: Add support for AM43xx SoC specific Kconfig

[Andreas Dannenberg]

On Fri, Apr 15, 2016 at 04:27:45PM +0530, Lokesh Vutla wrote:
> 
> 
> On Tuesday 12 April 2016 05:07 AM, Daniel Allred wrote:
> > From: Madan Srinivas <madans@ti.com>
> > 
> > Adding support for AM43xx secure devices require the addition
> > of some SOC specific config options like the amount of memory
> > used by public ROM and the address of the entry point of u-boot
> > or SPL, as seen by the ROM code, for the image to be built
> > correctly.
> > 
> > This mandates the addition of am AM43xx CONFIG option and the
> > ARM Kconfig file has been modified to source this SOC Kconfig
> > file. Moving the TARGET_AM43XX_EVM config option to the SOC
> > KConfig and out of the arch/arm/Kconfig.
> > 
> > Updating defconfigs to add the CONFIG_AM43XX=y statement and
> > removing the #define CONFIG_AM43XX from the header file.
> > 
> > Signed-off-by: Madan Srinivas <madans@ti.com>
> > Signed-off-by: Daniel Allred <d-allred@ti.com>
> > ---
> >  arch/arm/Kconfig                          | 19 +++++++++++++------
> >  arch/arm/cpu/armv7/am33xx/Kconfig         | 13 +++++++++++++
> >  configs/am43xx_evm_defconfig              |  1 +
> >  configs/am43xx_evm_ethboot_defconfig      |  1 +
> >  configs/am43xx_evm_qspiboot_defconfig     |  1 +
> >  configs/am43xx_evm_usbhost_boot_defconfig |  1 +
> >  include/configs/am43xx_evm.h              |  2 --
> >  7 files changed, 30 insertions(+), 8 deletions(-)
> > 
> > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> > index f18dbe6..088d6e0 100644
> > --- a/arch/arm/Kconfig
> > +++ b/arch/arm/Kconfig
> > @@ -381,12 +381,6 @@ config TARGET_AM335X_SL50
> >  	select DM
> >  	select DM_SERIAL
> >  
> > -config TARGET_AM43XX_EVM
> > -	bool "Support am43xx_evm"
> > -	select CPU_V7
> > -	select SUPPORT_SPL
> > -	select TI_I2C_BOARD_DETECT
> > -
> >  config TARGET_BAV335X
> >  	bool "Support bav335x"
> >  	select CPU_V7
> > @@ -507,6 +501,17 @@ config OMAP54XX
> >  	select CPU_V7
> >  	select SUPPORT_SPL
> >  
> > +config AM43XX
> > +	bool "AM43XX SoC"
> > +	select CPU_V7
> > +	select SUPPORT_SPL
> > +	help
> > +	  Support for AM43xx SOC from Texas Instruments.
> > +	  The AM43xx high performance SOC features a Cortex-A9
> > +	  ARM core, a quad core PRU-ICSS for industrial Ethernet
> > +	  protocols, dual camera support, optional 3D graphics
> > +	  and an optional customer programmable secure boot.
> > +
> >  config RMOBILE
> >  	bool "Renesas ARM SoCs"
> >  	select CPU_V7
> > @@ -776,6 +781,8 @@ source "arch/arm/cpu/armv7/omap4/Kconfig"
> >  
> >  source "arch/arm/cpu/armv7/omap5/Kconfig"
> >  
> > +source "arch/arm/cpu/armv7/am33xx/Kconfig"
> > +
> >  source "arch/arm/mach-orion5x/Kconfig"
> >  
> >  source "arch/arm/cpu/armv7/rmobile/Kconfig"
> > diff --git a/arch/arm/cpu/armv7/am33xx/Kconfig b/arch/arm/cpu/armv7/am33xx/Kconfig
> > index 39759cd..68bcc64 100644
> > --- a/arch/arm/cpu/armv7/am33xx/Kconfig
> > +++ b/arch/arm/cpu/armv7/am33xx/Kconfig
> > @@ -1,3 +1,15 @@
> > +if AM43XX
> > +config TARGET_AM43XX_EVM
> > +	bool "Support am43xx_evm"
> > +	select CREATE_BOARD_SYMLINK
> 
> This should be TI_I2C_BOARD_DETECT or else you will get a build error.

Yes this is definitely an issue, I just ran into this when trying to
build and test U-Boot for AM43xx HS which is when I saw your response.

However even after fixing this I get additional build errors from SPI,
USB Gadget, and UART related routines such as...

cmd/built-in.o: In function `do_spi_xfer':
/home/a0797059/git/u-boot/cmd/spi.c:61: undefined reference to `spi_setup_slave'
/home/a0797059/git/u-boot/cmd/spi.c:68: undefined reference to `spi_claim_bus'
/home/a0797059/git/u-boot/cmd/spi.c:71: undefined reference to `spi_xfer'
/home/a0797059/git/u-boot/cmd/spi.c:88: undefined reference to `spi_release_bus'
/home/a0797059/git/u-boot/cmd/spi.c:90: undefined reference to `spi_free_slave'

<cut>

I'll be digging into this a bit more to see where that comes from.

Regards,

--
Andreas Dannenberg
Texas Instruments Inc



> 
> Thanks and regards,
> Lokesh
> 
> > +	help
> > +	  This option specifies support for the AM43xx
> > +	  GP and HS EVM development platforms.The AM437x
> > +	  GP EVM is a standalone test, development, and
> > +	  evaluation module system that enables developers
> > +	  to write software and develop hardware around
> > +	  an AM43xx processor subsystem.
> > +
> >  config ISW_ENTRY_ADDR
> >  	hex "Address in memory or XIP flash of bootloader entry point"
> >  	help
> > @@ -25,3 +37,4 @@ config PUB_ROM_DATA_SIZE
> >  	  image, this area is no longer used, and can be reclaimed
> >  	  for run time use by the boot image.
> >  	default 0x8400
> > +endif
> > diff --git a/configs/am43xx_evm_defconfig b/configs/am43xx_evm_defconfig
> > index cc83006..4b0a188 100644
> > --- a/configs/am43xx_evm_defconfig
> > +++ b/configs/am43xx_evm_defconfig
> > @@ -1,4 +1,5 @@
> >  CONFIG_ARM=y
> > +CONFIG_AM43XX=y
> >  CONFIG_TARGET_AM43XX_EVM=y
> >  CONFIG_SPL=y
> >  CONFIG_SYS_EXTRA_OPTIONS="SERIAL1,CONS_INDEX=1,NAND"
> > diff --git a/configs/am43xx_evm_ethboot_defconfig b/configs/am43xx_evm_ethboot_defconfig
> > index a720c14..20001ca 100644
> > --- a/configs/am43xx_evm_ethboot_defconfig
> > +++ b/configs/am43xx_evm_ethboot_defconfig
> > @@ -1,4 +1,5 @@
> >  CONFIG_ARM=y
> > +CONFIG_AM43XX=y
> >  CONFIG_TARGET_AM43XX_EVM=y
> >  CONFIG_SPL=y
> >  CONFIG_SYS_EXTRA_OPTIONS="SERIAL1,CONS_INDEX=1,NAND,SPL_ETH_SUPPORT"
> > diff --git a/configs/am43xx_evm_qspiboot_defconfig b/configs/am43xx_evm_qspiboot_defconfig
> > index 6db389b..2170a68 100644
> > --- a/configs/am43xx_evm_qspiboot_defconfig
> > +++ b/configs/am43xx_evm_qspiboot_defconfig
> > @@ -1,4 +1,5 @@
> >  CONFIG_ARM=y
> > +CONFIG_AM43XX=y
> >  CONFIG_TARGET_AM43XX_EVM=y
> >  CONFIG_SYS_EXTRA_OPTIONS="SERIAL1,CONS_INDEX=1,QSPI,QSPI_BOOT"
> >  # CONFIG_CMD_IMLS is not set
> > diff --git a/configs/am43xx_evm_usbhost_boot_defconfig b/configs/am43xx_evm_usbhost_boot_defconfig
> > index cbaf5a5..14343a9 100644
> > --- a/configs/am43xx_evm_usbhost_boot_defconfig
> > +++ b/configs/am43xx_evm_usbhost_boot_defconfig
> > @@ -1,4 +1,5 @@
> >  CONFIG_ARM=y
> > +CONFIG_AM43XX=y
> >  CONFIG_TARGET_AM43XX_EVM=y
> >  CONFIG_SPL=y
> >  CONFIG_SYS_EXTRA_OPTIONS="SERIAL1,CONS_INDEX=1,NAND,SPL_USB_HOST_SUPPORT"
> > diff --git a/include/configs/am43xx_evm.h b/include/configs/am43xx_evm.h
> > index fd3f6a7..b98f7a1 100644
> > --- a/include/configs/am43xx_evm.h
> > +++ b/include/configs/am43xx_evm.h
> > @@ -9,8 +9,6 @@
> >  #ifndef __CONFIG_AM43XX_EVM_H
> >  #define __CONFIG_AM43XX_EVM_H
> >  
> > -#define CONFIG_AM43XX
> > -
> >  #define CONFIG_CMD_FAT
> >  
> >  #define CONFIG_BOARD_LATE_INIT
> > 
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH 03/16] arm: Kconfig: Add support for AM43xx SoC specific Kconfig

[Andreas Dannenberg]

On Mon, Apr 18, 2016 at 04:03:58PM -0500, Andreas Dannenberg wrote:
> On Fri, Apr 15, 2016 at 04:27:45PM +0530, Lokesh Vutla wrote:
> > On Tuesday 12 April 2016 05:07 AM, Daniel Allred wrote:
> > > From: Madan Srinivas <madans@ti.com>
> > > 
> > > Adding support for AM43xx secure devices require the addition
> > > of some SOC specific config options like the amount of memory
> > > used by public ROM and the address of the entry point of u-boot
> > > or SPL, as seen by the ROM code, for the image to be built
> > > correctly.
> > > 
> > > This mandates the addition of am AM43xx CONFIG option and the
> > > ARM Kconfig file has been modified to source this SOC Kconfig
> > > file. Moving the TARGET_AM43XX_EVM config option to the SOC
> > > KConfig and out of the arch/arm/Kconfig.
> > > 
> > > Updating defconfigs to add the CONFIG_AM43XX=y statement and
> > > removing the #define CONFIG_AM43XX from the header file.
> > > 
> > > Signed-off-by: Madan Srinivas <madans@ti.com>
> > > Signed-off-by: Daniel Allred <d-allred@ti.com>
> > > ---
> > >  arch/arm/Kconfig                          | 19 +++++++++++++------
> > >  arch/arm/cpu/armv7/am33xx/Kconfig         | 13 +++++++++++++
> > >  configs/am43xx_evm_defconfig              |  1 +
> > >  configs/am43xx_evm_ethboot_defconfig      |  1 +
> > >  configs/am43xx_evm_qspiboot_defconfig     |  1 +
> > >  configs/am43xx_evm_usbhost_boot_defconfig |  1 +
> > >  include/configs/am43xx_evm.h              |  2 --
> > >  7 files changed, 30 insertions(+), 8 deletions(-)
> > > 
> > > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> > > index f18dbe6..088d6e0 100644
> > > --- a/arch/arm/Kconfig
> > > +++ b/arch/arm/Kconfig
> > > @@ -381,12 +381,6 @@ config TARGET_AM335X_SL50
> > >  	select DM
> > >  	select DM_SERIAL
> > >  
> > > -config TARGET_AM43XX_EVM
> > > -	bool "Support am43xx_evm"
> > > -	select CPU_V7
> > > -	select SUPPORT_SPL
> > > -	select TI_I2C_BOARD_DETECT
> > > -
> > >  config TARGET_BAV335X
> > >  	bool "Support bav335x"
> > >  	select CPU_V7
> > > @@ -507,6 +501,17 @@ config OMAP54XX
> > >  	select CPU_V7
> > >  	select SUPPORT_SPL
> > >  
> > > +config AM43XX
> > > +	bool "AM43XX SoC"
> > > +	select CPU_V7
> > > +	select SUPPORT_SPL
> > > +	help
> > > +	  Support for AM43xx SOC from Texas Instruments.
> > > +	  The AM43xx high performance SOC features a Cortex-A9
> > > +	  ARM core, a quad core PRU-ICSS for industrial Ethernet
> > > +	  protocols, dual camera support, optional 3D graphics
> > > +	  and an optional customer programmable secure boot.
> > > +
> > >  config RMOBILE
> > >  	bool "Renesas ARM SoCs"
> > >  	select CPU_V7
> > > @@ -776,6 +781,8 @@ source "arch/arm/cpu/armv7/omap4/Kconfig"
> > >  
> > >  source "arch/arm/cpu/armv7/omap5/Kconfig"
> > >  
> > > +source "arch/arm/cpu/armv7/am33xx/Kconfig"
> > > +
> > >  source "arch/arm/mach-orion5x/Kconfig"
> > >  
> > >  source "arch/arm/cpu/armv7/rmobile/Kconfig"
> > > diff --git a/arch/arm/cpu/armv7/am33xx/Kconfig b/arch/arm/cpu/armv7/am33xx/Kconfig
> > > index 39759cd..68bcc64 100644
> > > --- a/arch/arm/cpu/armv7/am33xx/Kconfig
> > > +++ b/arch/arm/cpu/armv7/am33xx/Kconfig
> > > @@ -1,3 +1,15 @@
> > > +if AM43XX
> > > +config TARGET_AM43XX_EVM
> > > +	bool "Support am43xx_evm"
> > > +	select CREATE_BOARD_SYMLINK
> > 
> > This should be TI_I2C_BOARD_DETECT or else you will get a build error.
> 
> Yes this is definitely an issue, I just ran into this when trying to
> build and test U-Boot for AM43xx HS which is when I saw your response.
> 
> However even after fixing this I get additional build errors from SPI,
> USB Gadget, and UART related routines such as...
> 
> cmd/built-in.o: In function `do_spi_xfer':
> /home/a0797059/git/u-boot/cmd/spi.c:61: undefined reference to `spi_setup_slave'
> /home/a0797059/git/u-boot/cmd/spi.c:68: undefined reference to `spi_claim_bus'
> /home/a0797059/git/u-boot/cmd/spi.c:71: undefined reference to `spi_xfer'
> /home/a0797059/git/u-boot/cmd/spi.c:88: undefined reference to `spi_release_bus'
> /home/a0797059/git/u-boot/cmd/spi.c:90: undefined reference to `spi_free_slave'
> 
> <cut>
> 
> I'll be digging into this a bit more to see where that comes from.

It turns out that the defconfig file(s) part of this patch series are
missing the enables for device drivers for the devices accessed by
U-Boot. After migrating the respective config settings from the
am43xx_evm_defconfig file that's already part of U-Boot over to
am43xx_hs_evm_defconfig the AM43xx HS device support can be build
successfully and allows booting up the secure device.

Under the condition the change regarding TI_I2C_BOARD_DETECT highlighted
gets addressed this patch gets my...

Tested-by: Andreas Dannenberg <dannenberg@ti.com>

[U-Boot] [PATCH 04/16] ti: omap-common: Add Kconfig file for secure device support

[Daniel Allred]

From: Madan Srinivas <madans@ti.com>

Defines CONFIG_TI_SECURE_DEVICE which needs to be turned on
when building images for secure devices. This flag is used
to invoke the secure image creation tools for creating a
boot image that can be used on secure devices. This flag
may also be used to conditionally compile code specific
to secure devices.

This terminology will be used by all OMAP architecture devices,
hence introducing to a common location.

With the creation of Kconfig for omap-common, moved the
sourcing of the Kconfig files for the omap3/4/5 and am33xx
devices from arch/arm/KConfig to the omap-common one.

Signed-off-by: Madan Srinivas <madans@ti.com>
Signed-off-by: Daniel Allred <d-allred@ti.com>
---
 arch/arm/Kconfig                       |  8 +-------
 arch/arm/cpu/armv7/omap-common/Kconfig | 17 +++++++++++++++++
 2 files changed, 18 insertions(+), 7 deletions(-)
 create mode 100644 arch/arm/cpu/armv7/omap-common/Kconfig

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 088d6e0..6d3fb80 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -775,13 +775,7 @@ source "arch/arm/cpu/armv7/mx6/Kconfig"
 
 source "arch/arm/cpu/armv7/mx5/Kconfig"
 
-source "arch/arm/cpu/armv7/omap3/Kconfig"
-
-source "arch/arm/cpu/armv7/omap4/Kconfig"
-
-source "arch/arm/cpu/armv7/omap5/Kconfig"
-
-source "arch/arm/cpu/armv7/am33xx/Kconfig"
+source "arch/arm/cpu/armv7/omap-common/Kconfig"
 
 source "arch/arm/mach-orion5x/Kconfig"
 
diff --git a/arch/arm/cpu/armv7/omap-common/Kconfig b/arch/arm/cpu/armv7/omap-common/Kconfig
new file mode 100644
index 0000000..7b39506
--- /dev/null
+++ b/arch/arm/cpu/armv7/omap-common/Kconfig
@@ -0,0 +1,17 @@
+config TI_SECURE_DEVICE
+	bool "HS Device Type Support"
+	depends on OMAP54XX || AM43XX
+	help
+	  If a high secure (HS) device type is being used, this config
+	  must be set. This option impacts various aspects of the
+	  build system (to create signed boot images that can be
+	  authenticated) and the code. See the doc/README.ti-secure
+	  file for further details.
+
+source "arch/arm/cpu/armv7/omap3/Kconfig"
+
+source "arch/arm/cpu/armv7/omap4/Kconfig"
+
+source "arch/arm/cpu/armv7/omap5/Kconfig"
+
+source "arch/arm/cpu/armv7/am33xx/Kconfig"
-- 
1.9.1

[U-Boot] [PATCH 04/16] ti: omap-common: Add Kconfig file for secure device support

[Lokesh Vutla]

On Tuesday 12 April 2016 05:07 AM, Daniel Allred wrote:
> From: Madan Srinivas <madans@ti.com>
> 
> Defines CONFIG_TI_SECURE_DEVICE which needs to be turned on
> when building images for secure devices. This flag is used
> to invoke the secure image creation tools for creating a
> boot image that can be used on secure devices. This flag
> may also be used to conditionally compile code specific
> to secure devices.
> 
> This terminology will be used by all OMAP architecture devices,
> hence introducing to a common location.
> 
> With the creation of Kconfig for omap-common, moved the
> sourcing of the Kconfig files for the omap3/4/5 and am33xx
> devices from arch/arm/KConfig to the omap-common one.
> 
> Signed-off-by: Madan Srinivas <madans@ti.com>
> Signed-off-by: Daniel Allred <d-allred@ti.com>
> ---

Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>

Thanks and regards,
Lokesh

[U-Boot] [PATCH 04/16] ti: omap-common: Add Kconfig file for secure device support

[Andreas Dannenberg]

On Mon, Apr 11, 2016 at 06:37:06PM -0500, Daniel Allred wrote:
> From: Madan Srinivas <madans@ti.com>
> 
> Defines CONFIG_TI_SECURE_DEVICE which needs to be turned on
> when building images for secure devices. This flag is used
> to invoke the secure image creation tools for creating a
> boot image that can be used on secure devices. This flag
> may also be used to conditionally compile code specific
> to secure devices.
> 
> This terminology will be used by all OMAP architecture devices,
> hence introducing to a common location.
> 
> With the creation of Kconfig for omap-common, moved the
> sourcing of the Kconfig files for the omap3/4/5 and am33xx
> devices from arch/arm/KConfig to the omap-common one.
> 
> Signed-off-by: Madan Srinivas <madans@ti.com>
> Signed-off-by: Daniel Allred <d-allred@ti.com>


Now that I've successfully boot-tested the patch series on actual AM437x
HS, DRA72x HS, and DRA74x HS hardware this common file gets my...

Tested-by: Andreas Dannenberg <dannenberg@ti.com>

--
Andreas Dannenberg
Texas Instruments Inc

[U-Boot] [PATCH 04/16] ti: omap-common: Add Kconfig file for secure device support

[Tom Rini]

On Mon, Apr 11, 2016 at 06:37:06PM -0500, Daniel Allred wrote:

> From: Madan Srinivas <madans@ti.com>
> 
> Defines CONFIG_TI_SECURE_DEVICE which needs to be turned on
> when building images for secure devices. This flag is used
> to invoke the secure image creation tools for creating a
> boot image that can be used on secure devices. This flag
> may also be used to conditionally compile code specific
> to secure devices.
> 
> This terminology will be used by all OMAP architecture devices,
> hence introducing to a common location.
> 
> With the creation of Kconfig for omap-common, moved the
> sourcing of the Kconfig files for the omap3/4/5 and am33xx
> devices from arch/arm/KConfig to the omap-common one.
> 
> Signed-off-by: Madan Srinivas <madans@ti.com>
> Signed-off-by: Daniel Allred <d-allred@ti.com>

Reviewed-by: Tom Rini <trini@konsulko.com>

-- 
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/20160421/2aa21848/attachment.sig>

[U-Boot] [PATCH 05/16] ti: omap-common: Add commands for generating secure SPL images

[Daniel Allred]

Adds a centralized config_secure.mk in omap-common for
OMAP-style TI secure devices to use for boot image generation

Depending on the boot media, different images are needed for
secure devices. These commands generates u-boot*_HS_* files that
need to be used to boot secure devices.

Please refer to README.ti-secure for more information.

Signed-off-by: Daniel Allred <d-allred@ti.com>
Signed-off-by: Madan Srinivas <madans@ti.com>
---
 arch/arm/cpu/armv7/omap-common/config_secure.mk | 66 +++++++++++++++++++++++++
 1 file changed, 66 insertions(+)
 create mode 100644 arch/arm/cpu/armv7/omap-common/config_secure.mk

diff --git a/arch/arm/cpu/armv7/omap-common/config_secure.mk b/arch/arm/cpu/armv7/omap-common/config_secure.mk
new file mode 100644
index 0000000..c7bb101
--- /dev/null
+++ b/arch/arm/cpu/armv7/omap-common/config_secure.mk
@@ -0,0 +1,66 @@
+#
+# Copyright (C) 2016, Texas Instruments, Incorporated - http://www.ti.com/
+#
+# SPDX-License-Identifier:	GPL-2.0+
+#
+quiet_cmd_mkomapsecimg = MKIMAGE $@
+ifneq ($(TI_SECURE_DEV_PKG),)
+ifneq ($(wildcard $(TI_SECURE_DEV_PKG)/scripts/create-boot-image.sh),)
+ifneq ($(CONFIG_SPL_BUILD),)
+cmd_mkomapsecimg = $(TI_SECURE_DEV_PKG)/scripts/create-boot-image.sh \
+	$(patsubst u-boot-spl_HS_%,%,$(@F)) $< $@ $(CONFIG_ISW_ENTRY_ADDR) \
+	$(if $(KBUILD_VERBOSE:1=), >/dev/null)
+else
+cmd_mkomapsecimg = $(TI_SECURE_DEV_PKG)/scripts/create-boot-image.sh \
+    $(patsubst u-boot_HS_%,%,$(@F)) $< $@ $(CONFIG_ISW_ENTRY_ADDR) \
+    $(if $(KBUILD_VERBOSE:1=), >/dev/null)
+endif
+else
+cmd_mkomapsecimg = echo "WARNING:" \
+	"$(TI_SECURE_DEV_PKG)/scripts/create-boot-image.sh not found." \
+	"$@ was NOT created!"
+endif
+else
+cmd_mkomapsecimg = echo "WARNING: TI_SECURE_DEV_PKG environment" \
+	"variable must be defined for TI secure devices. $@ was NOT created!"
+endif
+
+# Standard X-LOADER target (QPSI, NOR flash)
+u-boot-spl_HS_X-LOADER: $(obj)/u-boot-spl.bin
+	$(call if_changed,mkomapsecimg)
+
+# For MLO targets (SD card boot) the final file name
+# that is copied to the SD card fAT partition must
+# be MLO, so we make a copy of the output file to a
+# new file with that name
+u-boot-spl_HS_MLO: $(obj)/u-boot-spl.bin
+	$(call if_changed,mkomapsecimg)
+	@if [ -f $@ ]; then \
+		cp -f $@ MLO; \
+	fi
+
+# Standard 2ND target (certain peripheral boot modes)
+u-boot-spl_HS_2ND: $(obj)/u-boot-spl.bin
+	$(call if_changed,mkomapsecimg)
+
+# Standard ULO target (certain peripheral boot modes)
+u-boot-spl_HS_ULO: $(obj)/u-boot-spl.bin
+	$(call if_changed,mkomapsecimg)
+
+# Standard ISSW target (certain devices, various boot modes)
+u-boot-spl_HS_ISSW: $(obj)/u-boot-spl.bin
+	$(call if_changed,mkomapsecimg)
+
+# For SPI flash on AM335x and AM43xx, these
+# require special byte swap handling so we use
+# the SPI_X-LOADER target instead of X-LOADER
+# and let the create-boot-image.sh script handle
+# that
+u-boot-spl_HS_SPI_X-LOADER: $(obj)/u-boot-spl.bin
+	$(call if_changed,mkomapsecimg)
+
+# For supporting single stage XiP QSPI on AM43xx, the
+# image is a full u-boot file, not an SPL. In this case
+# the mkomapsecimg command looks for a u-boot-HS_* prefix
+u-boot_HS_XIP_X-LOADER: $(obj)/u-boot.bin
+	$(call if_changed,mkomapsecimg)
-- 
1.9.1

[U-Boot] [PATCH 05/16] ti: omap-common: Add commands for generating secure SPL images

[Lokesh Vutla]

On Tuesday 12 April 2016 05:07 AM, Daniel Allred wrote:
> Adds a centralized config_secure.mk in omap-common for
> OMAP-style TI secure devices to use for boot image generation
> 
> Depending on the boot media, different images are needed for
> secure devices. These commands generates u-boot*_HS_* files that
> need to be used to boot secure devices.
> 
> Please refer to README.ti-secure for more information.

Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>

Thanks and regards,
Lokesh

[U-Boot] [PATCH 05/16] ti: omap-common: Add commands for generating secure SPL images

[Andreas Dannenberg]

On Mon, Apr 11, 2016 at 06:37:07PM -0500, Daniel Allred wrote:
> Adds a centralized config_secure.mk in omap-common for
> OMAP-style TI secure devices to use for boot image generation
> 
> Depending on the boot media, different images are needed for
> secure devices. These commands generates u-boot*_HS_* files that
> need to be used to boot secure devices.
> 
> Please refer to README.ti-secure for more information.
> 
> Signed-off-by: Daniel Allred <d-allred@ti.com>
> Signed-off-by: Madan Srinivas <madans@ti.com>

Now that I've successfully boot-tested the patch series on actual AM437x
HS, DRA72x HS, and DRA74x HS hardware this common file gets my...

Tested-by: Andreas Dannenberg <dannenberg@ti.com>

--
Andreas Dannenberg
Texas Instruments Inc

[U-Boot] [PATCH 05/16] ti: omap-common: Add commands for generating secure SPL images

[Tom Rini]

On Mon, Apr 11, 2016 at 06:37:07PM -0500, Daniel Allred wrote:

> Adds a centralized config_secure.mk in omap-common for
> OMAP-style TI secure devices to use for boot image generation
> 
> Depending on the boot media, different images are needed for
> secure devices. These commands generates u-boot*_HS_* files that
> need to be used to boot secure devices.
> 
> Please refer to README.ti-secure for more information.
> 
> Signed-off-by: Daniel Allred <d-allred@ti.com>
> Signed-off-by: Madan Srinivas <madans@ti.com>

Reviewed-by: Tom Rini <trini@konsulko.com>

-- 
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/20160421/de8b6637/attachment.sig>

[U-Boot] [PATCH 06/16] ti: AM43xx: config.mk: Add support for generating secure boot images

[Daniel Allred]

Modifies the config.mk to build secure images when building
the SPL for secure devices.

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. The same u-boot
binary file is processed slightly differently to produce a
different boot image, depending on whether the user wants to
boot off SPI, QSPI or other boot media.

Refer to README.ti-secure for more information.

Signed-off-by: Madan Srinivas <madans@ti.com>
Signed-off-by: Daniel Allred <d-allred@ti.com>
---
 arch/arm/cpu/armv7/am33xx/config.mk | 20 ++++++++++++++++++++
 1 file changed, 20 insertions(+)

diff --git a/arch/arm/cpu/armv7/am33xx/config.mk b/arch/arm/cpu/armv7/am33xx/config.mk
index 5294d16..6d95d32 100644
--- a/arch/arm/cpu/armv7/am33xx/config.mk
+++ b/arch/arm/cpu/armv7/am33xx/config.mk
@@ -3,9 +3,29 @@
 #
 # SPDX-License-Identifier:	GPL-2.0+
 #
+
+include  $(srctree)/$(CPUDIR)/omap-common/config_secure.mk
+
 ifdef CONFIG_SPL_BUILD
+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
+#
+# 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
+else
 ALL-y	+= MLO
 ALL-$(CONFIG_SPL_SPI_SUPPORT) += MLO.byteswap
+endif
 else
+ifeq ($(CONFIG_TI_SECURE_DEVICE),y)
+ALL-$(CONFIG_QSPI_BOOT) += u-boot_HS_XIP_X-LOADER
+endif
 ALL-y	+= u-boot.img
 endif
-- 
1.9.1

[U-Boot] [PATCH 06/16] ti: AM43xx: config.mk: Add support for generating secure boot images

[Lokesh Vutla]

On Tuesday 12 April 2016 05:07 AM, Daniel Allred wrote:
> Modifies the config.mk to build secure images when building
> the SPL for secure devices.
> 
> 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. The same u-boot
> binary file is processed slightly differently to produce a
> different boot image, depending on whether the user wants to
> boot off SPI, QSPI or other boot media.
> 
> Refer to README.ti-secure for more information.

Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>

Thanks and regards,
Lokesh

[U-Boot] [PATCH 06/16] ti: AM43xx: config.mk: Add support for generating secure boot images

[Andreas Dannenberg]

On Mon, Apr 11, 2016 at 06:37:08PM -0500, Daniel Allred wrote:
> Modifies the config.mk to build secure images when building
> the SPL for secure devices.
> 
> 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. The same u-boot
> binary file is processed slightly differently to produce a
> different boot image, depending on whether the user wants to
> boot off SPI, QSPI or other boot media.
> 
> Refer to README.ti-secure for more information.
> 
> Signed-off-by: Madan Srinivas <madans@ti.com>
> Signed-off-by: Daniel Allred <d-allred@ti.com>

Tested-by: Andreas Dannenberg <dannenberg@ti.com>

--
Andreas Dannenberg
Texas Instruments Inc

[U-Boot] [PATCH 06/16] ti: AM43xx: config.mk: Add support for generating secure boot images

[Tom Rini]

On Mon, Apr 11, 2016 at 06:37:08PM -0500, Daniel Allred wrote:

> Modifies the config.mk to build secure images when building
> the SPL for secure devices.
> 
> 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. The same u-boot
> binary file is processed slightly differently to produce a
> different boot image, depending on whether the user wants to
> boot off SPI, QSPI or other boot media.
> 
> Refer to README.ti-secure for more information.
> 
> Signed-off-by: Madan Srinivas <madans@ti.com>
> Signed-off-by: Daniel Allred <d-allred@ti.com>

Reviewed-by: Tom Rini <trini@konsulko.com>

-- 
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/20160421/87689b90/attachment.sig>

[U-Boot] [PATCH 07/16] ti: AM43xx: Use CONFIG options from SOC Kconfig

[Daniel Allred]

From: Madan Srinivas <madans@ti.com>

Updates configs/am43xx_evm.h to use CONFIG options from
SOC specific Kconfig file for various calculations.

On AM43x devices, the address of SPL entry point  depends on
the device type, i.e. whether it is secure or non-secure.

Further, for non-secure devices, the SPL entry point is different
between  USB HOST boot mode, other "memory" boot modes (MMC, NAND)
and "peripheral" boot modes (UART, USB)

To add to the complexity, on secure devices, in addition to the
above differences, the SPL entry point can change because of the
space occupied by other components (other than u-boot or spl)
that go into a secure boot image.

To prevent the user from having to modify source files every time
any component of the secure image changes, the value of
CONFIG_SPL_TEXT_BASE has been set using a Kconfig option that
is supplied in the am43xx_*_defconfig files

Using the CONFIG options also enables us to do away with some
compile time flags that were used to specify CONFIG_SPL_TEXT_BASE
for different boot modes.

On QSPI devices, the same problem described above occurs w.r.t. the
address of the u-boot entry point in flash, when booting secure
devices. To handle this, CONFIG_SYS_TEXT_BASE is also setup via
a Kconfig option and the defconfig files.

Signed-off-by: Madan Srinivas <madans@ti.com>
Signed-off-by: Daniel Allred <d-allred@ti.com>
---
 configs/am43xx_evm_qspiboot_defconfig     |  1 +
 configs/am43xx_evm_usbhost_boot_defconfig |  1 +
 include/configs/am43xx_evm.h              | 19 +++++++------------
 3 files changed, 9 insertions(+), 12 deletions(-)

diff --git a/configs/am43xx_evm_qspiboot_defconfig b/configs/am43xx_evm_qspiboot_defconfig
index 2170a68..7b08eca 100644
--- a/configs/am43xx_evm_qspiboot_defconfig
+++ b/configs/am43xx_evm_qspiboot_defconfig
@@ -1,6 +1,7 @@
 CONFIG_ARM=y
 CONFIG_AM43XX=y
 CONFIG_TARGET_AM43XX_EVM=y
+CONFIG_ISW_ENTRY_ADDR=0x30000000
 CONFIG_SYS_EXTRA_OPTIONS="SERIAL1,CONS_INDEX=1,QSPI,QSPI_BOOT"
 # CONFIG_CMD_IMLS is not set
 # CONFIG_CMD_FLASH is not set
diff --git a/configs/am43xx_evm_usbhost_boot_defconfig b/configs/am43xx_evm_usbhost_boot_defconfig
index 14343a9..cb421a4 100644
--- a/configs/am43xx_evm_usbhost_boot_defconfig
+++ b/configs/am43xx_evm_usbhost_boot_defconfig
@@ -2,6 +2,7 @@ CONFIG_ARM=y
 CONFIG_AM43XX=y
 CONFIG_TARGET_AM43XX_EVM=y
 CONFIG_SPL=y
+CONFIG_ISW_ENTRY_ADDR=0x40300350
 CONFIG_SYS_EXTRA_OPTIONS="SERIAL1,CONS_INDEX=1,NAND,SPL_USB_HOST_SUPPORT"
 # CONFIG_CMD_IMLS is not set
 # CONFIG_CMD_FLASH is not set
diff --git a/include/configs/am43xx_evm.h b/include/configs/am43xx_evm.h
index b98f7a1..d027c79 100644
--- a/include/configs/am43xx_evm.h
+++ b/include/configs/am43xx_evm.h
@@ -39,17 +39,10 @@
 #define CONFIG_POWER_TPS62362
 
 /* SPL defines. */
-#ifdef CONFIG_SPL_USB_HOST_SUPPORT
-/*
- * For USB host boot, ROM uses DMA for copying MLO from USB storage
- * and ARM internal ram is not accessible for DMA, so SPL text base
- * should be in OCMC ram
- */
-#define CONFIG_SPL_TEXT_BASE		0x40300350
-#else
-#define CONFIG_SPL_TEXT_BASE		0x402F4000
-#endif
-#define CONFIG_SPL_MAX_SIZE		(220 << 10)	/* 220KB */
+#define CONFIG_SPL_TEXT_BASE		CONFIG_ISW_ENTRY_ADDR
+#define CONFIG_SPL_MAX_SIZE		(NON_SECURE_SRAM_END - \
+					CONFIG_PUB_ROM_DATA_SIZE - \
+					CONFIG_SPL_TEXT_BASE)
 #define CONFIG_SYS_SPL_ARGS_ADDR	(CONFIG_SYS_SDRAM_BASE + \
 					 (128 << 20))
 #define CONFIG_SPL_POWER_SUPPORT
@@ -196,7 +189,9 @@
 #endif
 
 #ifdef CONFIG_QSPI_BOOT
-#define CONFIG_SYS_TEXT_BASE           0x30000000
+#ifndef CONFIG_SYS_TEXT_BASE
+#define CONFIG_SYS_TEXT_BASE		CONFIG_ISW_ENTRY_ADDR
+#endif
 #undef CONFIG_ENV_IS_IN_FAT
 #define CONFIG_ENV_IS_IN_SPI_FLASH
 #define CONFIG_SYS_REDUNDAND_ENVIRONMENT
-- 
1.9.1

[U-Boot] [PATCH 07/16] ti: AM43xx: Use CONFIG options from SOC Kconfig

[Lokesh Vutla]

On Tuesday 12 April 2016 05:07 AM, Daniel Allred wrote:
> From: Madan Srinivas <madans@ti.com>
> 
> Updates configs/am43xx_evm.h to use CONFIG options from
> SOC specific Kconfig file for various calculations.
> 
> On AM43x devices, the address of SPL entry point  depends on
> the device type, i.e. whether it is secure or non-secure.
> 
> Further, for non-secure devices, the SPL entry point is different
> between  USB HOST boot mode, other "memory" boot modes (MMC, NAND)
> and "peripheral" boot modes (UART, USB)
> 
> To add to the complexity, on secure devices, in addition to the
> above differences, the SPL entry point can change because of the
> space occupied by other components (other than u-boot or spl)
> that go into a secure boot image.
> 
> To prevent the user from having to modify source files every time
> any component of the secure image changes, the value of
> CONFIG_SPL_TEXT_BASE has been set using a Kconfig option that
> is supplied in the am43xx_*_defconfig files
> 
> Using the CONFIG options also enables us to do away with some
> compile time flags that were used to specify CONFIG_SPL_TEXT_BASE
> for different boot modes.
> 
> On QSPI devices, the same problem described above occurs w.r.t. the
> address of the u-boot entry point in flash, when booting secure
> devices. To handle this, CONFIG_SYS_TEXT_BASE is also setup via
> a Kconfig option and the defconfig files.

Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>

Thanks and regards,
Lokesh

[U-Boot] [PATCH 07/16] ti: AM43xx: Use CONFIG options from SOC Kconfig

[Andreas Dannenberg]

On Mon, Apr 11, 2016 at 06:37:09PM -0500, Daniel Allred wrote:
> From: Madan Srinivas <madans@ti.com>
> 
> Updates configs/am43xx_evm.h to use CONFIG options from
> SOC specific Kconfig file for various calculations.
> 
> On AM43x devices, the address of SPL entry point  depends on
> the device type, i.e. whether it is secure or non-secure.
> 
> Further, for non-secure devices, the SPL entry point is different
> between  USB HOST boot mode, other "memory" boot modes (MMC, NAND)
> and "peripheral" boot modes (UART, USB)
> 
> To add to the complexity, on secure devices, in addition to the
> above differences, the SPL entry point can change because of the
> space occupied by other components (other than u-boot or spl)
> that go into a secure boot image.
> 
> To prevent the user from having to modify source files every time
> any component of the secure image changes, the value of
> CONFIG_SPL_TEXT_BASE has been set using a Kconfig option that
> is supplied in the am43xx_*_defconfig files
> 
> Using the CONFIG options also enables us to do away with some
> compile time flags that were used to specify CONFIG_SPL_TEXT_BASE
> for different boot modes.
> 
> On QSPI devices, the same problem described above occurs w.r.t. the
> address of the u-boot entry point in flash, when booting secure
> devices. To handle this, CONFIG_SYS_TEXT_BASE is also setup via
> a Kconfig option and the defconfig files.
> 
> Signed-off-by: Madan Srinivas <madans@ti.com>
> Signed-off-by: Daniel Allred <d-allred@ti.com>

Tested-by: Andreas Dannenberg <dannenberg@ti.com>

Regards,

--
Andreas Dannenberg
Texas Instruments Inc

[U-Boot] [PATCH 07/16] ti: AM43xx: Use CONFIG options from SOC Kconfig

[Tom Rini]

On Mon, Apr 11, 2016 at 06:37:09PM -0500, Daniel Allred wrote:

> From: Madan Srinivas <madans@ti.com>
> 
> Updates configs/am43xx_evm.h to use CONFIG options from
> SOC specific Kconfig file for various calculations.
> 
> On AM43x devices, the address of SPL entry point  depends on
> the device type, i.e. whether it is secure or non-secure.
> 
> Further, for non-secure devices, the SPL entry point is different
> between  USB HOST boot mode, other "memory" boot modes (MMC, NAND)
> and "peripheral" boot modes (UART, USB)
> 
> To add to the complexity, on secure devices, in addition to the
> above differences, the SPL entry point can change because of the
> space occupied by other components (other than u-boot or spl)
> that go into a secure boot image.
> 
> To prevent the user from having to modify source files every time
> any component of the secure image changes, the value of
> CONFIG_SPL_TEXT_BASE has been set using a Kconfig option that
> is supplied in the am43xx_*_defconfig files
> 
> Using the CONFIG options also enables us to do away with some
> compile time flags that were used to specify CONFIG_SPL_TEXT_BASE
> for different boot modes.
> 
> On QSPI devices, the same problem described above occurs w.r.t. the
> address of the u-boot entry point in flash, when booting secure
> devices. To handle this, CONFIG_SYS_TEXT_BASE is also setup via
> a Kconfig option and the defconfig files.
> 
> Signed-off-by: Madan Srinivas <madans@ti.com>
> Signed-off-by: Daniel Allred <d-allred@ti.com>

Reviewed-by: Tom Rini <trini@konsulko.com>

-- 
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/20160421/49675e68/attachment.sig>

[U-Boot] [PATCH 08/16] ti: AM43xx: board: Detect AM43xx HS EVM

[Daniel Allred]

From: Madan Srinivas <madans@ti.com>

Adds code to detect AM43xx HS EVMS - the string in the
I2C EEPROM for HS EVMs differs from GP EVMs. Adds code to
for evm detection, regardless of whether the evm is for
GP or HS parts, and updates board init to use that.

Modifies findfdt command to pick up am437x-gp-evm.dtb for
the HS EVMs also, as the boards are similar except for
some security specific changes around power supply and
enclosure protection.

Signed-off-by: Madan Srinivas <madans@ti.com>
Signed-off-by: Daniel Allred <d-allred@ti.com>
Signed-off-by: Andreas Dannenberg <dannenberg@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
---
 board/ti/am43xx/board.c      |  4 ++--
 board/ti/am43xx/board.h      | 14 ++++++++++++--
 board/ti/am43xx/mux.c        |  2 +-
 include/configs/am43xx_evm.h |  2 ++
 4 files changed, 17 insertions(+), 5 deletions(-)

diff --git a/board/ti/am43xx/board.c b/board/ti/am43xx/board.c
index d208d2f..7247107 100644
--- a/board/ti/am43xx/board.c
+++ b/board/ti/am43xx/board.c
@@ -341,7 +341,7 @@ const struct dpll_params *get_dpll_ddr_params(void)
 
 	if (board_is_eposevm())
 		return &epos_evm_dpll_ddr[ind];
-	else if (board_is_gpevm() || board_is_sk())
+	else if (board_is_evm() || board_is_sk())
 		return &gp_evm_dpll_ddr;
 	else if (board_is_idk())
 		return &idk_dpll_ddr;
@@ -553,7 +553,7 @@ void sdram_init(void)
 		enable_vtt_regulator();
 		config_ddr(0, &ioregs_ddr3, NULL, NULL,
 			   &ddr3_emif_regs_400Mhz_beta, 0);
-	} else if (board_is_gpevm()) {
+	} else if (board_is_evm()) {
 		enable_vtt_regulator();
 		config_ddr(0, &ioregs_ddr3, NULL, NULL,
 			   &ddr3_emif_regs_400Mhz, 0);
diff --git a/board/ti/am43xx/board.h b/board/ti/am43xx/board.h
index 2cf7a77..3f93d13 100644
--- a/board/ti/am43xx/board.h
+++ b/board/ti/am43xx/board.h
@@ -37,14 +37,24 @@ static inline int board_is_idk(void)
 	return board_ti_is("AM43_IDK");
 }
 
+static inline int board_is_hsevm(void)
+{
+	return board_ti_is("AM43XXHS");
+}
+
+static inline int board_is_evm(void)
+{
+	return board_is_gpevm() || board_is_hsevm();
+}
+
 static inline int board_is_evm_14_or_later(void)
 {
-	return (board_is_gpevm() && strncmp("1.4", board_ti_get_rev(), 3) <= 0);
+	return board_is_evm() && strncmp("1.4", board_ti_get_rev(), 3) <= 0;
 }
 
 static inline int board_is_evm_12_or_later(void)
 {
-	return (board_is_gpevm() && strncmp("1.2", board_ti_get_rev(), 3) <= 0);
+	return board_is_evm() && strncmp("1.2", board_ti_get_rev(), 3) <= 0;
 }
 
 void enable_uart0_pin_mux(void);
diff --git a/board/ti/am43xx/mux.c b/board/ti/am43xx/mux.c
index e03b1bc..f26b21e 100644
--- a/board/ti/am43xx/mux.c
+++ b/board/ti/am43xx/mux.c
@@ -126,7 +126,7 @@ void enable_board_pin_mux(void)
 	configure_module_pin_mux(i2c0_pin_mux);
 	configure_module_pin_mux(mdio_pin_mux);
 
-	if (board_is_gpevm()) {
+	if (board_is_evm()) {
 		configure_module_pin_mux(gpio5_7_pin_mux);
 		configure_module_pin_mux(rgmii1_pin_mux);
 #if defined(CONFIG_NAND)
diff --git a/include/configs/am43xx_evm.h b/include/configs/am43xx_evm.h
index d027c79..acb8bf9 100644
--- a/include/configs/am43xx_evm.h
+++ b/include/configs/am43xx_evm.h
@@ -297,6 +297,8 @@
 			"setenv fdtfile am43x-epos-evm.dtb; fi; " \
 		"if test $board_name = AM43__GP; then " \
 			"setenv fdtfile am437x-gp-evm.dtb; fi; " \
+		"if test $board_name = AM43XXHS; then " \
+			"setenv fdtfile am437x-gp-evm.dtb; fi; " \
 		"if test $board_name = AM43__SK; then " \
 			"setenv fdtfile am437x-sk-evm.dtb; fi; " \
 		"if test $board_name = AM43_IDK; then " \
-- 
1.9.1

[U-Boot] [PATCH 08/16] ti: AM43xx: board: Detect AM43xx HS EVM

[Lokesh Vutla]

On Tuesday 12 April 2016 05:07 AM, Daniel Allred wrote:
> From: Madan Srinivas <madans@ti.com>
> 
> Adds code to detect AM43xx HS EVMS - the string in the
> I2C EEPROM for HS EVMs differs from GP EVMs. Adds code to
> for evm detection, regardless of whether the evm is for
> GP or HS parts, and updates board init to use that.
> 
> Modifies findfdt command to pick up am437x-gp-evm.dtb for
> the HS EVMs also, as the boards are similar except for
> some security specific changes around power supply and
> enclosure protection.

Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>

Thanks and regards,
Lokesh

[U-Boot] [PATCH 08/16] ti: AM43xx: board: Detect AM43xx HS EVM

[Tom Rini]

On Mon, Apr 11, 2016 at 06:37:10PM -0500, Daniel Allred wrote:

> From: Madan Srinivas <madans@ti.com>
> 
> Adds code to detect AM43xx HS EVMS - the string in the
> I2C EEPROM for HS EVMs differs from GP EVMs. Adds code to
> for evm detection, regardless of whether the evm is for
> GP or HS parts, and updates board init to use that.
> 
> Modifies findfdt command to pick up am437x-gp-evm.dtb for
> the HS EVMs also, as the boards are similar except for
> some security specific changes around power supply and
> enclosure protection.
> 
> Signed-off-by: Madan Srinivas <madans@ti.com>
> Signed-off-by: Daniel Allred <d-allred@ti.com>
> Signed-off-by: Andreas Dannenberg <dannenberg@ti.com>
> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>

Reviewed-by: Tom Rini <trini@konsulko.com>

-- 
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/20160421/28b8ddc6/attachment.sig>

[U-Boot] [PATCH 09/16] defconfig: Add configs for AM43xx secure parts

[Daniel Allred]

From: Madan Srinivas <madans@ti.com>

Adds new defconfig files for AM43xx secure devices.
These are the same as the non-secure parts, except for
	CONFIG_TI_SECURE_DEVICE option set to 'y'
	CONFIG_ISW_ENTRY_ADDR updated for secure images.

Signed-off-by: Daniel Allred <d-allred@ti.com>
Signed-off-by: Madan Srinivas <madans@ti.com>
---
 configs/am43xx_hs_evm_defconfig              | 12 ++++++++++++
 configs/am43xx_hs_evm_ethboot_defconfig      | 11 +++++++++++
 configs/am43xx_hs_evm_qspiboot_defconfig     | 10 ++++++++++
 configs/am43xx_hs_evm_rtconly_defconfig      | 12 ++++++++++++
 configs/am43xx_hs_evm_usbhost_boot_defconfig | 11 +++++++++++
 configs/am43xx_hs_evm_usbspl_defconfig       | 12 ++++++++++++
 6 files changed, 68 insertions(+)
 create mode 100644 configs/am43xx_hs_evm_defconfig
 create mode 100644 configs/am43xx_hs_evm_ethboot_defconfig
 create mode 100644 configs/am43xx_hs_evm_qspiboot_defconfig
 create mode 100644 configs/am43xx_hs_evm_rtconly_defconfig
 create mode 100644 configs/am43xx_hs_evm_usbhost_boot_defconfig
 create mode 100644 configs/am43xx_hs_evm_usbspl_defconfig

diff --git a/configs/am43xx_hs_evm_defconfig b/configs/am43xx_hs_evm_defconfig
new file mode 100644
index 0000000..a79a82b
--- /dev/null
+++ b/configs/am43xx_hs_evm_defconfig
@@ -0,0 +1,12 @@
+CONFIG_ARM=y
+CONFIG_AM43XX=y
+CONFIG_TI_SECURE_DEVICE=y
+CONFIG_TARGET_AM43XX_EVM=y
+CONFIG_SPL=y
+CONFIG_ISW_ENTRY_ADDR=0x40302ae0
+CONFIG_SYS_EXTRA_OPTIONS="SERIAL1,CONS_INDEX=1,NAND"
+# CONFIG_CMD_IMLS is not set
+# CONFIG_CMD_FLASH is not set
+# CONFIG_CMD_SETEXPR is not set
+CONFIG_SPI_FLASH_BAR=y
+CONFIG_SPI_FLASH=y
diff --git a/configs/am43xx_hs_evm_ethboot_defconfig b/configs/am43xx_hs_evm_ethboot_defconfig
new file mode 100644
index 0000000..06729fd
--- /dev/null
+++ b/configs/am43xx_hs_evm_ethboot_defconfig
@@ -0,0 +1,11 @@
+CONFIG_ARM=y
+CONFIG_AM43XX=y
+CONFIG_TI_SECURE_DEVICE=y
+CONFIG_TARGET_AM43XX_EVM=y
+CONFIG_SPL=y
+CONFIG_ISW_ENTRY_ADDR=0x40302ae0
+CONFIG_SYS_EXTRA_OPTIONS="SERIAL1,CONS_INDEX=1,NAND,SPL_ETH_SUPPORT"
+# CONFIG_CMD_IMLS is not set
+# CONFIG_CMD_FLASH is not set
+# CONFIG_CMD_SETEXPR is not set
+CONFIG_SPI_FLASH=y
diff --git a/configs/am43xx_hs_evm_qspiboot_defconfig b/configs/am43xx_hs_evm_qspiboot_defconfig
new file mode 100644
index 0000000..8ae4672
--- /dev/null
+++ b/configs/am43xx_hs_evm_qspiboot_defconfig
@@ -0,0 +1,10 @@
+CONFIG_ARM=y
+CONFIG_AM43XX=y
+CONFIG_TI_SECURE_DEVICE=y
+CONFIG_TARGET_AM43XX_EVM=y
+CONFIG_ISW_ENTRY_ADDR=0x30002ae0
+CONFIG_SYS_EXTRA_OPTIONS="SERIAL1,CONS_INDEX=1,QSPI,QSPI_BOOT"
+# CONFIG_CMD_IMLS is not set
+# CONFIG_CMD_FLASH is not set
+# CONFIG_CMD_SETEXPR is not set
+CONFIG_SPI_FLASH=y
diff --git a/configs/am43xx_hs_evm_rtconly_defconfig b/configs/am43xx_hs_evm_rtconly_defconfig
new file mode 100644
index 0000000..25c2db2
--- /dev/null
+++ b/configs/am43xx_hs_evm_rtconly_defconfig
@@ -0,0 +1,12 @@
+CONFIG_ARM=y
+CONFIG_AM43XX=y
+CONFIG_TI_SECURE_DEVICE=y
+CONFIG_TARGET_AM43XX_EVM=y
+CONFIG_SPL=y
+CONFIG_ISW_ENTRY_ADDR=0x40302ae0
+CONFIG_SYS_EXTRA_OPTIONS="SERIAL1,CONS_INDEX=1,NAND,SPL_RTC_ONLY_SUPPORT"
+# CONFIG_CMD_IMLS is not set
+# CONFIG_CMD_FLASH is not set
+# CONFIG_CMD_SETEXPR is not set
+CONFIG_SPI_FLASH_BAR=y
+CONFIG_SPI_FLASH=y
diff --git a/configs/am43xx_hs_evm_usbhost_boot_defconfig b/configs/am43xx_hs_evm_usbhost_boot_defconfig
new file mode 100644
index 0000000..776f669
--- /dev/null
+++ b/configs/am43xx_hs_evm_usbhost_boot_defconfig
@@ -0,0 +1,11 @@
+CONFIG_ARM=y
+CONFIG_AM43XX=y
+CONFIG_TI_SECURE_DEVICE=y
+CONFIG_TARGET_AM43XX_EVM=y
+CONFIG_SPL=y
+CONFIG_ISW_ENTRY_ADDR=0x40302ae0
+CONFIG_SYS_EXTRA_OPTIONS="SERIAL1,CONS_INDEX=1,NAND,SPL_USB_HOST_SUPPORT"
+# CONFIG_CMD_IMLS is not set
+# CONFIG_CMD_FLASH is not set
+# CONFIG_CMD_SETEXPR is not set
+CONFIG_SPI_FLASH=y
diff --git a/configs/am43xx_hs_evm_usbspl_defconfig b/configs/am43xx_hs_evm_usbspl_defconfig
new file mode 100644
index 0000000..5a3f566
--- /dev/null
+++ b/configs/am43xx_hs_evm_usbspl_defconfig
@@ -0,0 +1,12 @@
+CONFIG_ARM=y
+CONFIG_AM43XX=y
+CONFIG_TI_SECURE_DEVICE=y
+CONFIG_TARGET_AM43XX_EVM=y
+CONFIG_SPL=y
+CONFIG_ISW_ENTRY_ADDR=0x40302ae0
+CONFIG_SYS_EXTRA_OPTIONS="SERIAL1,CONS_INDEX=1,NAND,SPL_USBETH_SUPPORT"
+# CONFIG_CMD_IMLS is not set
+# CONFIG_CMD_FLASH is not set
+# CONFIG_CMD_SETEXPR is not set
+CONFIG_SPI_FLASH_BAR=y
+CONFIG_SPI_FLASH=y
-- 
1.9.1

[U-Boot] [PATCH 09/16] defconfig: Add configs for AM43xx secure parts

[Lokesh Vutla]

On Tuesday 12 April 2016 05:07 AM, Daniel Allred wrote:
> From: Madan Srinivas <madans@ti.com>
> 
> Adds new defconfig files for AM43xx secure devices.
> These are the same as the non-secure parts, except for
> 	CONFIG_TI_SECURE_DEVICE option set to 'y'
> 	CONFIG_ISW_ENTRY_ADDR updated for secure images.
> 
> Signed-off-by: Daniel Allred <d-allred@ti.com>
> Signed-off-by: Madan Srinivas <madans@ti.com>
> ---
>  configs/am43xx_hs_evm_defconfig              | 12 ++++++++++++
>  configs/am43xx_hs_evm_ethboot_defconfig      | 11 +++++++++++
>  configs/am43xx_hs_evm_qspiboot_defconfig     | 10 ++++++++++
>  configs/am43xx_hs_evm_rtconly_defconfig      | 12 ++++++++++++

You do not need this defconfig. Also now only DT enabled configs are
accepted. Ill let Tom to comment here.

Thanks and regards,
Lokesh

>  configs/am43xx_hs_evm_usbhost_boot_defconfig | 11 +++++++++++
>  configs/am43xx_hs_evm_usbspl_defconfig       | 12 ++++++++++++
>  6 files changed, 68 insertions(+)
>  create mode 100644 configs/am43xx_hs_evm_defconfig
>  create mode 100644 configs/am43xx_hs_evm_ethboot_defconfig
>  create mode 100644 configs/am43xx_hs_evm_qspiboot_defconfig
>  create mode 100644 configs/am43xx_hs_evm_rtconly_defconfig
>  create mode 100644 configs/am43xx_hs_evm_usbhost_boot_defconfig
>  create mode 100644 configs/am43xx_hs_evm_usbspl_defconfig
> 
> diff --git a/configs/am43xx_hs_evm_defconfig b/configs/am43xx_hs_evm_defconfig
> new file mode 100644
> index 0000000..a79a82b
> --- /dev/null
> +++ b/configs/am43xx_hs_evm_defconfig
> @@ -0,0 +1,12 @@
> +CONFIG_ARM=y
> +CONFIG_AM43XX=y
> +CONFIG_TI_SECURE_DEVICE=y
> +CONFIG_TARGET_AM43XX_EVM=y
> +CONFIG_SPL=y
> +CONFIG_ISW_ENTRY_ADDR=0x40302ae0
> +CONFIG_SYS_EXTRA_OPTIONS="SERIAL1,CONS_INDEX=1,NAND"
> +# CONFIG_CMD_IMLS is not set
> +# CONFIG_CMD_FLASH is not set
> +# CONFIG_CMD_SETEXPR is not set
> +CONFIG_SPI_FLASH_BAR=y
> +CONFIG_SPI_FLASH=y
> diff --git a/configs/am43xx_hs_evm_ethboot_defconfig b/configs/am43xx_hs_evm_ethboot_defconfig
> new file mode 100644
> index 0000000..06729fd
> --- /dev/null
> +++ b/configs/am43xx_hs_evm_ethboot_defconfig
> @@ -0,0 +1,11 @@
> +CONFIG_ARM=y
> +CONFIG_AM43XX=y
> +CONFIG_TI_SECURE_DEVICE=y
> +CONFIG_TARGET_AM43XX_EVM=y
> +CONFIG_SPL=y
> +CONFIG_ISW_ENTRY_ADDR=0x40302ae0
> +CONFIG_SYS_EXTRA_OPTIONS="SERIAL1,CONS_INDEX=1,NAND,SPL_ETH_SUPPORT"
> +# CONFIG_CMD_IMLS is not set
> +# CONFIG_CMD_FLASH is not set
> +# CONFIG_CMD_SETEXPR is not set
> +CONFIG_SPI_FLASH=y
> diff --git a/configs/am43xx_hs_evm_qspiboot_defconfig b/configs/am43xx_hs_evm_qspiboot_defconfig
> new file mode 100644
> index 0000000..8ae4672
> --- /dev/null
> +++ b/configs/am43xx_hs_evm_qspiboot_defconfig
> @@ -0,0 +1,10 @@
> +CONFIG_ARM=y
> +CONFIG_AM43XX=y
> +CONFIG_TI_SECURE_DEVICE=y
> +CONFIG_TARGET_AM43XX_EVM=y
> +CONFIG_ISW_ENTRY_ADDR=0x30002ae0
> +CONFIG_SYS_EXTRA_OPTIONS="SERIAL1,CONS_INDEX=1,QSPI,QSPI_BOOT"
> +# CONFIG_CMD_IMLS is not set
> +# CONFIG_CMD_FLASH is not set
> +# CONFIG_CMD_SETEXPR is not set
> +CONFIG_SPI_FLASH=y
> diff --git a/configs/am43xx_hs_evm_rtconly_defconfig b/configs/am43xx_hs_evm_rtconly_defconfig
> new file mode 100644
> index 0000000..25c2db2
> --- /dev/null
> +++ b/configs/am43xx_hs_evm_rtconly_defconfig
> @@ -0,0 +1,12 @@
> +CONFIG_ARM=y
> +CONFIG_AM43XX=y
> +CONFIG_TI_SECURE_DEVICE=y
> +CONFIG_TARGET_AM43XX_EVM=y
> +CONFIG_SPL=y
> +CONFIG_ISW_ENTRY_ADDR=0x40302ae0
> +CONFIG_SYS_EXTRA_OPTIONS="SERIAL1,CONS_INDEX=1,NAND,SPL_RTC_ONLY_SUPPORT"
> +# CONFIG_CMD_IMLS is not set
> +# CONFIG_CMD_FLASH is not set
> +# CONFIG_CMD_SETEXPR is not set
> +CONFIG_SPI_FLASH_BAR=y
> +CONFIG_SPI_FLASH=y
> diff --git a/configs/am43xx_hs_evm_usbhost_boot_defconfig b/configs/am43xx_hs_evm_usbhost_boot_defconfig
> new file mode 100644
> index 0000000..776f669
> --- /dev/null
> +++ b/configs/am43xx_hs_evm_usbhost_boot_defconfig
> @@ -0,0 +1,11 @@
> +CONFIG_ARM=y
> +CONFIG_AM43XX=y
> +CONFIG_TI_SECURE_DEVICE=y
> +CONFIG_TARGET_AM43XX_EVM=y
> +CONFIG_SPL=y
> +CONFIG_ISW_ENTRY_ADDR=0x40302ae0
> +CONFIG_SYS_EXTRA_OPTIONS="SERIAL1,CONS_INDEX=1,NAND,SPL_USB_HOST_SUPPORT"
> +# CONFIG_CMD_IMLS is not set
> +# CONFIG_CMD_FLASH is not set
> +# CONFIG_CMD_SETEXPR is not set
> +CONFIG_SPI_FLASH=y
> diff --git a/configs/am43xx_hs_evm_usbspl_defconfig b/configs/am43xx_hs_evm_usbspl_defconfig
> new file mode 100644
> index 0000000..5a3f566
> --- /dev/null
> +++ b/configs/am43xx_hs_evm_usbspl_defconfig
> @@ -0,0 +1,12 @@
> +CONFIG_ARM=y
> +CONFIG_AM43XX=y
> +CONFIG_TI_SECURE_DEVICE=y
> +CONFIG_TARGET_AM43XX_EVM=y
> +CONFIG_SPL=y
> +CONFIG_ISW_ENTRY_ADDR=0x40302ae0
> +CONFIG_SYS_EXTRA_OPTIONS="SERIAL1,CONS_INDEX=1,NAND,SPL_USBETH_SUPPORT"
> +# CONFIG_CMD_IMLS is not set
> +# CONFIG_CMD_FLASH is not set
> +# CONFIG_CMD_SETEXPR is not set
> +CONFIG_SPI_FLASH_BAR=y
> +CONFIG_SPI_FLASH=y
> 

[U-Boot] [PATCH 09/16] defconfig: Add configs for AM43xx secure parts

[Tom Rini]

On Fri, Apr 15, 2016 at 03:28:07PM +0530, Lokesh Vutla wrote:
> 
> 
> On Tuesday 12 April 2016 05:07 AM, Daniel Allred wrote:
> > From: Madan Srinivas <madans@ti.com>
> > 
> > Adds new defconfig files for AM43xx secure devices.
> > These are the same as the non-secure parts, except for
> > 	CONFIG_TI_SECURE_DEVICE option set to 'y'
> > 	CONFIG_ISW_ENTRY_ADDR updated for secure images.
> > 
> > Signed-off-by: Daniel Allred <d-allred@ti.com>
> > Signed-off-by: Madan Srinivas <madans@ti.com>
> > ---
> >  configs/am43xx_hs_evm_defconfig              | 12 ++++++++++++
> >  configs/am43xx_hs_evm_ethboot_defconfig      | 11 +++++++++++
> >  configs/am43xx_hs_evm_qspiboot_defconfig     | 10 ++++++++++
> >  configs/am43xx_hs_evm_rtconly_defconfig      | 12 ++++++++++++
> 
> You do not need this defconfig. Also now only DT enabled configs are
> accepted. Ill let Tom to comment here.

Yes, just like was done for the dra7xa/am57xx HS parts, we need to be
doing DM+DT here too.

-- 
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/20160421/4bd9b4a5/attachment.sig>

[U-Boot] [PATCH 09/16] defconfig: Add configs for AM43xx secure parts

[Allred, Daniel]

On 4/21/2016 8:40 AM, Tom Rini wrote:
> On Fri, Apr 15, 2016 at 03:28:07PM +0530, Lokesh Vutla wrote:
>>
>>
>> On Tuesday 12 April 2016 05:07 AM, Daniel Allred wrote:
>>> From: Madan Srinivas <madans@ti.com>
>>>
>>> Adds new defconfig files for AM43xx secure devices.
>>> These are the same as the non-secure parts, except for
>>> 	CONFIG_TI_SECURE_DEVICE option set to 'y'
>>> 	CONFIG_ISW_ENTRY_ADDR updated for secure images.
>>>
>>> Signed-off-by: Daniel Allred <d-allred@ti.com>
>>> Signed-off-by: Madan Srinivas <madans@ti.com>
>>> ---
>>>   configs/am43xx_hs_evm_defconfig              | 12 ++++++++++++
>>>   configs/am43xx_hs_evm_ethboot_defconfig      | 11 +++++++++++
>>>   configs/am43xx_hs_evm_qspiboot_defconfig     | 10 ++++++++++
>>>   configs/am43xx_hs_evm_rtconly_defconfig      | 12 ++++++++++++
>>
>> You do not need this defconfig. Also now only DT enabled configs are
>> accepted. Ill let Tom to comment here.
>
> Yes, just like was done for the dra7xa/am57xx HS parts, we need to be
> doing DM+DT here too.
>
So I understand to not create any new defconfigs that are not DM+DT, but 
what happens to these old ones? Are they deprecated? Or does someone 
need to patch/convert them?

I guess I'll just simplify this to make a single am437x_hs_evm_defconfig 
that mirrors the am437x_gp_evm_defconfig.

Daniel

[U-Boot] [PATCH 09/16] defconfig: Add configs for AM43xx secure parts

[Tom Rini]

On Thu, Apr 21, 2016 at 01:24:00PM -0500, Allred, Daniel wrote:
> On 4/21/2016 8:40 AM, Tom Rini wrote:
> >On Fri, Apr 15, 2016 at 03:28:07PM +0530, Lokesh Vutla wrote:
> >>
> >>
> >>On Tuesday 12 April 2016 05:07 AM, Daniel Allred wrote:
> >>>From: Madan Srinivas <madans@ti.com>
> >>>
> >>>Adds new defconfig files for AM43xx secure devices.
> >>>These are the same as the non-secure parts, except for
> >>>	CONFIG_TI_SECURE_DEVICE option set to 'y'
> >>>	CONFIG_ISW_ENTRY_ADDR updated for secure images.
> >>>
> >>>Signed-off-by: Daniel Allred <d-allred@ti.com>
> >>>Signed-off-by: Madan Srinivas <madans@ti.com>
> >>>---
> >>>  configs/am43xx_hs_evm_defconfig              | 12 ++++++++++++
> >>>  configs/am43xx_hs_evm_ethboot_defconfig      | 11 +++++++++++
> >>>  configs/am43xx_hs_evm_qspiboot_defconfig     | 10 ++++++++++
> >>>  configs/am43xx_hs_evm_rtconly_defconfig      | 12 ++++++++++++
> >>
> >>You do not need this defconfig. Also now only DT enabled configs are
> >>accepted. Ill let Tom to comment here.
> >
> >Yes, just like was done for the dra7xa/am57xx HS parts, we need to be
> >doing DM+DT here too.
> >
> So I understand to not create any new defconfigs that are not DM+DT,
> but what happens to these old ones? Are they deprecated? Or does
> someone need to patch/convert them?
> 
> I guess I'll just simplify this to make a single
> am437x_hs_evm_defconfig that mirrors the am437x_gp_evm_defconfig.

So, with Lokesh's series that lets us read FIT images in SPL from most
media forms, we can migrate things like am43xx_evm from non-DM+DT to
DM+DT and still support all of the various EVMs that includes and delete
the single board configs.  We should leverage this as much as possible
also for the HS versions.

-- 
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/20160421/7d6dfc90/attachment.sig>

[U-Boot] [PATCH 10/16] ti_omap5_common: Update SPL start address on secure parts

[Daniel Allred]

Updated the CONFIG_SPL_TEXT_BASE to support secure parts (moving
the start address past secure reserved memory and the size of the
security certificate that precedes the boot image on secure devices).
Updated the related CONFIG_SPL_MAX_SIZE to properly reflect the
internal memory actually available on the various device flavors
(Common minimum internal RAM guaranteed for various flavors of
DRA7xx/AM57xx is 512KB).

Signed-off-by: Daniel Allred <d-allred@ti.com>
Signed-off-by: Madan Srinivas <madans@ti.com>
---
 include/configs/ti_omap5_common.h | 32 +++++++++++++++++++++++++++-----
 1 file changed, 27 insertions(+), 5 deletions(-)

diff --git a/include/configs/ti_omap5_common.h b/include/configs/ti_omap5_common.h
index 202b18c..b2d4a0b 100644
--- a/include/configs/ti_omap5_common.h
+++ b/include/configs/ti_omap5_common.h
@@ -132,13 +132,35 @@
 
 /*
  * SPL related defines.  The Public RAM memory map the ROM defines the
- * area between 0x40300000 and 0x4031E000 as a download area for OMAP5
- * (dra7xx is larger, but we do not need to be larger at this time).  We
- * set CONFIG_SPL_DISPLAY_PRINT to have omap_rev_string() called and
+ * area between 0x40300000 and 0x4031E000 as a download area for OMAP5.
+ * On DRA7xx/AM57XX the download area is between 0x40300000 and 0x4037E000.
+ * We set CONFIG_SPL_DISPLAY_PRINT to have omap_rev_string() called and
  * print some information.
  */
-#define CONFIG_SPL_TEXT_BASE		0x40300000
-#define CONFIG_SPL_MAX_SIZE		(0x4031E000 - CONFIG_SPL_TEXT_BASE)
+#ifdef CONFIG_TI_SECURE_DEVICE
+/*
+ * For memory booting on HS parts, the first 4KB of the internal RAM is
+ * reserved for secure world use and the flash loader image is
+ * preceded by a secure certificate. The SPL will therefore run in internal
+ * RAM from address 0x40301350 (0x40300000+0x1000(reserved)+0x350(cert)).
+ */
+#define CONFIG_SECURE_BOOT_SRAM 0x1000
+#define CONFIG_SPL_TEXT_BASE	0x40301350
+#else
+/*
+ * For all booting on GP parts, the flash loader image is
+ * downloaded into internal RAM at address 0x40300000.
+ */
+#define CONFIG_SPL_TEXT_BASE	0x40300000
+#endif
+
+/* DRA7xx/AM57xx have 512K of SRAM, OMAP5 only 128K */
+#if defined(CONFIG_DRA7XX) || defined(CONFIG_AM57XX)
+#define CONFIG_SPL_BOOT_END		0x4037E000
+#else
+#define CONFIG_SPL_BOOT_END		0x4031E000
+#endif
+#define CONFIG_SPL_MAX_SIZE     (CONFIG_SPL_BOOT_END - CONFIG_SPL_TEXT_BASE)
 #define CONFIG_SPL_DISPLAY_PRINT
 #define CONFIG_SPL_LDSCRIPT "$(CPUDIR)/omap-common/u-boot-spl.lds"
 #define CONFIG_SYS_SPL_ARGS_ADDR	(CONFIG_SYS_SDRAM_BASE + \
-- 
1.9.1

[U-Boot] [PATCH 10/16] ti_omap5_common: Update SPL start address on secure parts

[Lokesh Vutla]

On Tuesday 12 April 2016 05:07 AM, Daniel Allred wrote:
> Updated the CONFIG_SPL_TEXT_BASE to support secure parts (moving
> the start address past secure reserved memory and the size of the
> security certificate that precedes the boot image on secure devices).
> Updated the related CONFIG_SPL_MAX_SIZE to properly reflect the
> internal memory actually available on the various device flavors
> (Common minimum internal RAM guaranteed for various flavors of
> DRA7xx/AM57xx is 512KB).

Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>

Thanks and regards,
Lokesh

[U-Boot] [PATCH 10/16] ti_omap5_common: Update SPL start address on secure parts

[Andreas Dannenberg]

On Mon, Apr 11, 2016 at 06:37:12PM -0500, Daniel Allred wrote:
> Updated the CONFIG_SPL_TEXT_BASE to support secure parts (moving
> the start address past secure reserved memory and the size of the
> security certificate that precedes the boot image on secure devices).
> Updated the related CONFIG_SPL_MAX_SIZE to properly reflect the
> internal memory actually available on the various device flavors
> (Common minimum internal RAM guaranteed for various flavors of
> DRA7xx/AM57xx is 512KB).
> 
> Signed-off-by: Daniel Allred <d-allred@ti.com>
> Signed-off-by: Madan Srinivas <madans@ti.com>


Successfully boot-tested the patch on actual DRA72x HS and DRA74x HS
hardware.

Tested-by: Andreas Dannenberg <dannenberg@ti.com>

--
Andreas Dannenberg
Texas Instruments Inc

[U-Boot] [PATCH 10/16] ti_omap5_common: Update SPL start address on secure parts

[Tom Rini]

On Mon, Apr 11, 2016 at 06:37:12PM -0500, Daniel Allred wrote:

> Updated the CONFIG_SPL_TEXT_BASE to support secure parts (moving
> the start address past secure reserved memory and the size of the
> security certificate that precedes the boot image on secure devices).
> Updated the related CONFIG_SPL_MAX_SIZE to properly reflect the
> internal memory actually available on the various device flavors
> (Common minimum internal RAM guaranteed for various flavors of
> DRA7xx/AM57xx is 512KB).
> 
> Signed-off-by: Daniel Allred <d-allred@ti.com>
> Signed-off-by: Madan Srinivas <madans@ti.com>
> ---
>  include/configs/ti_omap5_common.h | 32 +++++++++++++++++++++++++++-----
>  1 file changed, 27 insertions(+), 5 deletions(-)
> 
> diff --git a/include/configs/ti_omap5_common.h b/include/configs/ti_omap5_common.h
> index 202b18c..b2d4a0b 100644
> --- a/include/configs/ti_omap5_common.h
> +++ b/include/configs/ti_omap5_common.h
> @@ -132,13 +132,35 @@
>  
>  /*
>   * SPL related defines.  The Public RAM memory map the ROM defines the
> - * area between 0x40300000 and 0x4031E000 as a download area for OMAP5
> - * (dra7xx is larger, but we do not need to be larger at this time).  We
> - * set CONFIG_SPL_DISPLAY_PRINT to have omap_rev_string() called and
> + * area between 0x40300000 and 0x4031E000 as a download area for OMAP5.
> + * On DRA7xx/AM57XX the download area is between 0x40300000 and 0x4037E000.
> + * We set CONFIG_SPL_DISPLAY_PRINT to have omap_rev_string() called and
>   * print some information.
>   */
> -#define CONFIG_SPL_TEXT_BASE		0x40300000
> -#define CONFIG_SPL_MAX_SIZE		(0x4031E000 - CONFIG_SPL_TEXT_BASE)
> +#ifdef CONFIG_TI_SECURE_DEVICE
> +/*
> + * For memory booting on HS parts, the first 4KB of the internal RAM is
> + * reserved for secure world use and the flash loader image is
> + * preceded by a secure certificate. The SPL will therefore run in internal
> + * RAM from address 0x40301350 (0x40300000+0x1000(reserved)+0x350(cert)).
> + */
> +#define CONFIG_SECURE_BOOT_SRAM 0x1000

I don't like setting CONFIG_SECURE_BOOT_SRAM as it's not configurable.
I see it's used later in the series but I think we should toggle that on
CONFIG_TI_SECURE_DEVICE and then reference things like
TI_OMAP5_SECURE_BOOT_RESV_SRAM_SZ or whatever makes sense.

-- 
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/20160421/f3a0a427/attachment.sig>

[U-Boot] [PATCH 11/16] spl: build: ti: add support for secure boot images

[Daniel Allred]

Updates the SPL build so that when CONFIG_TI_SECURE_DEVICE
is in use (which it should be when building for secure parts),
the TI secure development package is used to create a valid
secure boot image. The u-boot SPL build processes is NOT aware
of the details of creating the boot image - all of that information
is encapsulated in the TI secure development package, which is
available from TI. More info can be found in README.ti-secure

Right now, two image types are generated, MLO and X-LOADER. The types
are important, as certain boot modes implemented by the device's ROM
boot loader require one or the other (they are not equivalent). The
output filenames are u-boot-spl_HS_MLO and u-boot-spl_HS_X-LOADER. The
u-boot-spl_HS_MLO image is also copied to a file named MLO, which is
the name that the device ROM bootloader requires for loading from the
FAT partition of an SD card (same as on non-secure devices).

Signed-off-by: Daniel Allred <d-allred@ti.com>
Signed-off-by: Madan Srinivas <madans@ti.com>
---
 arch/arm/cpu/armv7/omap5/config.mk | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm/cpu/armv7/omap5/config.mk b/arch/arm/cpu/armv7/omap5/config.mk
index ef2725a..a7e55a5 100644
--- a/arch/arm/cpu/armv7/omap5/config.mk
+++ b/arch/arm/cpu/armv7/omap5/config.mk
@@ -6,8 +6,14 @@
 # SPDX-License-Identifier:	GPL-2.0+
 #
 
+include  $(srctree)/$(CPUDIR)/omap-common/config_secure.mk
+
 ifdef CONFIG_SPL_BUILD
+ifeq ($(CONFIG_TI_SECURE_DEVICE),y)
+ALL-y	+= u-boot-spl_HS_MLO u-boot-spl_HS_X-LOADER
+else
 ALL-y	+= MLO
+endif
 else
 ALL-y	+= u-boot.img
 endif
-- 
1.9.1

[U-Boot] [PATCH 11/16] spl: build: ti: add support for secure boot images

[Lokesh Vutla]

On Tuesday 12 April 2016 05:07 AM, Daniel Allred wrote:
> Updates the SPL build so that when CONFIG_TI_SECURE_DEVICE
> is in use (which it should be when building for secure parts),
> the TI secure development package is used to create a valid
> secure boot image. The u-boot SPL build processes is NOT aware
> of the details of creating the boot image - all of that information
> is encapsulated in the TI secure development package, which is
> available from TI. More info can be found in README.ti-secure
> 
> Right now, two image types are generated, MLO and X-LOADER. The types
> are important, as certain boot modes implemented by the device's ROM
> boot loader require one or the other (they are not equivalent). The
> output filenames are u-boot-spl_HS_MLO and u-boot-spl_HS_X-LOADER. The
> u-boot-spl_HS_MLO image is also copied to a file named MLO, which is
> the name that the device ROM bootloader requires for loading from the
> FAT partition of an SD card (same as on non-secure devices).

Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>

Thanks and regards,
Lokesh

[U-Boot] [PATCH 11/16] spl: build: ti: add support for secure boot images

[Tom Rini]

On Mon, Apr 11, 2016 at 06:37:13PM -0500, Daniel Allred wrote:

> Updates the SPL build so that when CONFIG_TI_SECURE_DEVICE
> is in use (which it should be when building for secure parts),
> the TI secure development package is used to create a valid
> secure boot image. The u-boot SPL build processes is NOT aware
> of the details of creating the boot image - all of that information
> is encapsulated in the TI secure development package, which is
> available from TI. More info can be found in README.ti-secure
> 
> Right now, two image types are generated, MLO and X-LOADER. The types
> are important, as certain boot modes implemented by the device's ROM
> boot loader require one or the other (they are not equivalent). The
> output filenames are u-boot-spl_HS_MLO and u-boot-spl_HS_X-LOADER. The
> u-boot-spl_HS_MLO image is also copied to a file named MLO, which is
> the name that the device ROM bootloader requires for loading from the
> FAT partition of an SD card (same as on non-secure devices).
> 
> Signed-off-by: Daniel Allred <d-allred@ti.com>
> Signed-off-by: Madan Srinivas <madans@ti.com>

Reviewed-by: Tom Rini <trini@konsulko.com>

-- 
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/20160421/df37efa3/attachment.sig>

[U-Boot] [PATCH 11/16] spl: build: ti: add support for secure boot images

[Andreas Dannenberg]

On Mon, Apr 11, 2016 at 06:37:13PM -0500, Daniel Allred wrote:
> Updates the SPL build so that when CONFIG_TI_SECURE_DEVICE
> is in use (which it should be when building for secure parts),
> the TI secure development package is used to create a valid
> secure boot image. The u-boot SPL build processes is NOT aware
> of the details of creating the boot image - all of that information
> is encapsulated in the TI secure development package, which is
> available from TI. More info can be found in README.ti-secure
> 
> Right now, two image types are generated, MLO and X-LOADER. The types
> are important, as certain boot modes implemented by the device's ROM
> boot loader require one or the other (they are not equivalent). The
> output filenames are u-boot-spl_HS_MLO and u-boot-spl_HS_X-LOADER. The
> u-boot-spl_HS_MLO image is also copied to a file named MLO, which is
> the name that the device ROM bootloader requires for loading from the
> FAT partition of an SD card (same as on non-secure devices).
> 
> Signed-off-by: Daniel Allred <d-allred@ti.com>
> Signed-off-by: Madan Srinivas <madans@ti.com>

Successfully boot-tested the patch on actual DRA72x HS and DRA74x HS
hardware.

Tested-by: Andreas Dannenberg <dannenberg@ti.com>

--
Andreas Dannenberg
Texas Instruments Inc

[U-Boot] [PATCH 12/16] ARM: omap4/5: Add device type to CPU string

[Daniel Allred]

Update the CPU string output so that the device
type is now included as part of the CPU string that
is printed as the SPL or u-boot comes up. This update
adds a suffix of the form "-GP" or "-HS" for production
devices, so that general purpose (GP) and high security
(HS) can be distiguished. Applies to all OMAP5 variants.

Signed-off-by: Daniel Allred <d-allred@ti.com>
Signed-off-by: Madan Srinivas <madans@ti.com>
---
 arch/arm/cpu/armv7/omap-common/hwinit-common.c | 22 ++++++++++++++++++++--
 arch/arm/include/asm/arch-omap4/cpu.h          |  7 +++++++
 arch/arm/include/asm/arch-omap5/cpu.h          |  7 +++++++
 3 files changed, 34 insertions(+), 2 deletions(-)

diff --git a/arch/arm/cpu/armv7/omap-common/hwinit-common.c b/arch/arm/cpu/armv7/omap-common/hwinit-common.c
index 01c2d57..078bdd8 100644
--- a/arch/arm/cpu/armv7/omap-common/hwinit-common.c
+++ b/arch/arm/cpu/armv7/omap-common/hwinit-common.c
@@ -65,12 +65,30 @@ static void omap_rev_string(void)
 	u32 major_rev = (omap_rev & 0x00000F00) >> 8;
 	u32 minor_rev = (omap_rev & 0x000000F0) >> 4;
 
+	const char *sec_s;
+
+	switch (get_device_type()) {
+	case TST_DEVICE:
+		sec_s = "TST";
+		break;
+	case EMU_DEVICE:
+		sec_s = "EMU";
+		break;
+	case HS_DEVICE:
+		sec_s = "HS";
+		break;
+	case GP_DEVICE:
+		sec_s = "GP";
+		break;
+	default:
+		sec_s = "?";
+	}
+
 	if (soc_variant)
 		printf("OMAP");
 	else
 		printf("DRA");
-	printf("%x ES%x.%x\n", omap_variant, major_rev,
-	       minor_rev);
+	printf("%x-%s ES%x.%x\n", omap_variant, sec_s, major_rev, minor_rev);
 }
 
 #ifdef CONFIG_SPL_BUILD
diff --git a/arch/arm/include/asm/arch-omap4/cpu.h b/arch/arm/include/asm/arch-omap4/cpu.h
index f7595ae..34609b9 100644
--- a/arch/arm/include/asm/arch-omap4/cpu.h
+++ b/arch/arm/include/asm/arch-omap4/cpu.h
@@ -59,6 +59,13 @@ struct watchdog {
 #define TCLR_AR			(0x1 << 1)
 #define TCLR_PRE		(0x1 << 5)
 
+/* device type */
+#define DEVICE_MASK         (BIT(8) | BIT(9) | BIT(10))
+#define TST_DEVICE          0x0
+#define EMU_DEVICE          0x1
+#define HS_DEVICE           0x2
+#define GP_DEVICE           0x3
+
 /* I2C base */
 #define I2C_BASE1		(OMAP44XX_L4_PER_BASE + 0x70000)
 #define I2C_BASE2		(OMAP44XX_L4_PER_BASE + 0x72000)
diff --git a/arch/arm/include/asm/arch-omap5/cpu.h b/arch/arm/include/asm/arch-omap5/cpu.h
index b1513e9..1d53da6 100644
--- a/arch/arm/include/asm/arch-omap5/cpu.h
+++ b/arch/arm/include/asm/arch-omap5/cpu.h
@@ -63,6 +63,13 @@ struct watchdog {
 #define TCLR_AR			(0x1 << 1)
 #define TCLR_PRE		(0x1 << 5)
 
+/* device type */
+#define DEVICE_MASK         (BIT(8) | BIT(9) | BIT(10))
+#define TST_DEVICE          0x0
+#define EMU_DEVICE          0x1
+#define HS_DEVICE           0x2
+#define GP_DEVICE           0x3
+
 /* I2C base */
 #define I2C_BASE1		(OMAP54XX_L4_PER_BASE + 0x70000)
 #define I2C_BASE2		(OMAP54XX_L4_PER_BASE + 0x72000)
-- 
1.9.1

[U-Boot] [PATCH 12/16] ARM: omap4/5: Add device type to CPU string

[Lokesh Vutla]

On Tuesday 12 April 2016 05:07 AM, Daniel Allred wrote:
> Update the CPU string output so that the device
> type is now included as part of the CPU string that
> is printed as the SPL or u-boot comes up. This update
> adds a suffix of the form "-GP" or "-HS" for production
> devices, so that general purpose (GP) and high security
> (HS) can be distiguished. Applies to all OMAP5 variants.
> 
> Signed-off-by: Daniel Allred <d-allred@ti.com>
> Signed-off-by: Madan Srinivas <madans@ti.com>

Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>

Thanks and regards,
Lokesh

[U-Boot] [PATCH 12/16] ARM: omap4/5: Add device type to CPU string

[Andreas Dannenberg]

On Mon, Apr 11, 2016 at 06:37:14PM -0500, Daniel Allred wrote:
> Update the CPU string output so that the device
> type is now included as part of the CPU string that
> is printed as the SPL or u-boot comes up. This update
> adds a suffix of the form "-GP" or "-HS" for production
> devices, so that general purpose (GP) and high security
> (HS) can be distiguished. Applies to all OMAP5 variants.

When I'm building for AM437x HS and running on the device I don't see
that output. It seems like there is something funny going on with
CONFIG_SPL_DISPLAY_PRINT. Even though this definition is activated in
ti_omap4_common.h and ti_omap5_common.h it is not seen by
preloader_console_init() in spl.c, hence the function that prints the
chip-type/rev specifics never gets invoked.

Madan,
can you please confirm that behavior on your end?

Thanks,

--
Andreas Dannenberg
Texas Instruments Inc



> 
> Signed-off-by: Daniel Allred <d-allred@ti.com>
> Signed-off-by: Madan Srinivas <madans@ti.com>
> ---
>  arch/arm/cpu/armv7/omap-common/hwinit-common.c | 22 ++++++++++++++++++++--
>  arch/arm/include/asm/arch-omap4/cpu.h          |  7 +++++++
>  arch/arm/include/asm/arch-omap5/cpu.h          |  7 +++++++
>  3 files changed, 34 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm/cpu/armv7/omap-common/hwinit-common.c b/arch/arm/cpu/armv7/omap-common/hwinit-common.c
> index 01c2d57..078bdd8 100644
> --- a/arch/arm/cpu/armv7/omap-common/hwinit-common.c
> +++ b/arch/arm/cpu/armv7/omap-common/hwinit-common.c
> @@ -65,12 +65,30 @@ static void omap_rev_string(void)
>  	u32 major_rev = (omap_rev & 0x00000F00) >> 8;
>  	u32 minor_rev = (omap_rev & 0x000000F0) >> 4;
>  
> +	const char *sec_s;
> +
> +	switch (get_device_type()) {
> +	case TST_DEVICE:
> +		sec_s = "TST";
> +		break;
> +	case EMU_DEVICE:
> +		sec_s = "EMU";
> +		break;
> +	case HS_DEVICE:
> +		sec_s = "HS";
> +		break;
> +	case GP_DEVICE:
> +		sec_s = "GP";
> +		break;
> +	default:
> +		sec_s = "?";
> +	}
> +
>  	if (soc_variant)
>  		printf("OMAP");
>  	else
>  		printf("DRA");
> -	printf("%x ES%x.%x\n", omap_variant, major_rev,
> -	       minor_rev);
> +	printf("%x-%s ES%x.%x\n", omap_variant, sec_s, major_rev, minor_rev);
>  }
>  
>  #ifdef CONFIG_SPL_BUILD
> diff --git a/arch/arm/include/asm/arch-omap4/cpu.h b/arch/arm/include/asm/arch-omap4/cpu.h
> index f7595ae..34609b9 100644
> --- a/arch/arm/include/asm/arch-omap4/cpu.h
> +++ b/arch/arm/include/asm/arch-omap4/cpu.h
> @@ -59,6 +59,13 @@ struct watchdog {
>  #define TCLR_AR			(0x1 << 1)
>  #define TCLR_PRE		(0x1 << 5)
>  
> +/* device type */
> +#define DEVICE_MASK         (BIT(8) | BIT(9) | BIT(10))
> +#define TST_DEVICE          0x0
> +#define EMU_DEVICE          0x1
> +#define HS_DEVICE           0x2
> +#define GP_DEVICE           0x3
> +
>  /* I2C base */
>  #define I2C_BASE1		(OMAP44XX_L4_PER_BASE + 0x70000)
>  #define I2C_BASE2		(OMAP44XX_L4_PER_BASE + 0x72000)
> diff --git a/arch/arm/include/asm/arch-omap5/cpu.h b/arch/arm/include/asm/arch-omap5/cpu.h
> index b1513e9..1d53da6 100644
> --- a/arch/arm/include/asm/arch-omap5/cpu.h
> +++ b/arch/arm/include/asm/arch-omap5/cpu.h
> @@ -63,6 +63,13 @@ struct watchdog {
>  #define TCLR_AR			(0x1 << 1)
>  #define TCLR_PRE		(0x1 << 5)
>  
> +/* device type */
> +#define DEVICE_MASK         (BIT(8) | BIT(9) | BIT(10))
> +#define TST_DEVICE          0x0
> +#define EMU_DEVICE          0x1
> +#define HS_DEVICE           0x2
> +#define GP_DEVICE           0x3
> +
>  /* I2C base */
>  #define I2C_BASE1		(OMAP54XX_L4_PER_BASE + 0x70000)
>  #define I2C_BASE2		(OMAP54XX_L4_PER_BASE + 0x72000)
> -- 
> 1.9.1
> 
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH 12/16] ARM: omap4/5: Add device type to CPU string

[Andreas Dannenberg]

On Tue, Apr 19, 2016 at 11:26:30AM -0500, Andreas Dannenberg wrote:
> On Mon, Apr 11, 2016 at 06:37:14PM -0500, Daniel Allred wrote:
> > Update the CPU string output so that the device
> > type is now included as part of the CPU string that
> > is printed as the SPL or u-boot comes up. This update
> > adds a suffix of the form "-GP" or "-HS" for production
> > devices, so that general purpose (GP) and high security
> > (HS) can be distiguished. Applies to all OMAP5 variants.
> 
> When I'm building for AM437x HS and running on the device I don't see
> that output. It seems like there is something funny going on with
> CONFIG_SPL_DISPLAY_PRINT. Even though this definition is activated in
> ti_omap4_common.h and ti_omap5_common.h it is not seen by
> preloader_console_init() in spl.c, hence the function that prints the
> chip-type/rev specifics never gets invoked.

So when I run the patches on actual DRA72x HS and DRA74x HS hardware
I'll get the device name/type output by SPL as expected so that piece
works. However this patch's commit message  implies the same should also
work on AM437x HS which it doesn't. I don't have AM437x non-secure
hardware at my desk but I looked at some boot logs from our test farms
and I also don't see the device ID output by SPL so that may be just how
it currently is implemented generally for AM437* and has nothing to do
with the patch discussed here.

Madan, please comment/chime-in as needed.


Tested-by: Andreas Dannenberg <dannenberg@ti.com>

--
Andreas Dannenberg
Texas Instruments Inc

[U-Boot] [PATCH 12/16] ARM: omap4/5: Add device type to CPU string

[Allred, Daniel]

On 4/21/2016 12:55 PM, Andreas Dannenberg wrote:
> On Tue, Apr 19, 2016 at 11:26:30AM -0500, Andreas Dannenberg wrote:
>> On Mon, Apr 11, 2016 at 06:37:14PM -0500, Daniel Allred wrote:
>>> Update the CPU string output so that the device
>>> type is now included as part of the CPU string that
>>> is printed as the SPL or u-boot comes up. This update
>>> adds a suffix of the form "-GP" or "-HS" for production
>>> devices, so that general purpose (GP) and high security
>>> (HS) can be distiguished. Applies to all OMAP5 variants.
>>
>> When I'm building for AM437x HS and running on the device I don't see
>> that output. It seems like there is something funny going on with
>> CONFIG_SPL_DISPLAY_PRINT. Even though this definition is activated in
>> ti_omap4_common.h and ti_omap5_common.h it is not seen by
>> preloader_console_init() in spl.c, hence the function that prints the
>> chip-type/rev specifics never gets invoked.
>
> So when I run the patches on actual DRA72x HS and DRA74x HS hardware
> I'll get the device name/type output by SPL as expected so that piece
> works. However this patch's commit message  implies the same should also
> work on AM437x HS which it doesn't. I don't have AM437x non-secure
> hardware at my desk but I looked at some boot logs from our test farms
> and I also don't see the device ID output by SPL so that may be just how
> it currently is implemented generally for AM437* and has nothing to do
> with the patch discussed here.
This hwinit-common.c is not used by the AM335x/AM437x parts, hence the 
statement "Applies to all OMAP5 variants" in the commit message. The 
omap4/5 use in the commit header is because the omap4 cpu.h header file 
had to be updated in order to not break omap4 builds (because those 
builds DO use this hwinit-common.c).

Daniel
>
> Madan, please comment/chime-in as needed.
>
>
> Tested-by: Andreas Dannenberg <dannenberg@ti.com>
>
> --
> Andreas Dannenberg
> Texas Instruments Inc
>

[U-Boot] [PATCH 12/16] ARM: omap4/5: Add device type to CPU string

[Andreas Dannenberg]

On Thu, Apr 21, 2016 at 01:01:43PM -0500, Allred, Daniel wrote:
> On 4/21/2016 12:55 PM, Andreas Dannenberg wrote:
> >On Tue, Apr 19, 2016 at 11:26:30AM -0500, Andreas Dannenberg wrote:
> >>On Mon, Apr 11, 2016 at 06:37:14PM -0500, Daniel Allred wrote:
> >>>Update the CPU string output so that the device
> >>>type is now included as part of the CPU string that
> >>>is printed as the SPL or u-boot comes up. This update
> >>>adds a suffix of the form "-GP" or "-HS" for production
> >>>devices, so that general purpose (GP) and high security
> >>>(HS) can be distiguished. Applies to all OMAP5 variants.
> >>
> >>When I'm building for AM437x HS and running on the device I don't see
> >>that output. It seems like there is something funny going on with
> >>CONFIG_SPL_DISPLAY_PRINT. Even though this definition is activated in
> >>ti_omap4_common.h and ti_omap5_common.h it is not seen by
> >>preloader_console_init() in spl.c, hence the function that prints the
> >>chip-type/rev specifics never gets invoked.
> >
> >So when I run the patches on actual DRA72x HS and DRA74x HS hardware
> >I'll get the device name/type output by SPL as expected so that piece
> >works. However this patch's commit message  implies the same should also
> >work on AM437x HS which it doesn't. I don't have AM437x non-secure
> >hardware at my desk but I looked at some boot logs from our test farms
> >and I also don't see the device ID output by SPL so that may be just how
> >it currently is implemented generally for AM437* and has nothing to do
> >with the patch discussed here.
> This hwinit-common.c is not used by the AM335x/AM437x parts, hence the
> statement "Applies to all OMAP5 variants" in the commit message. The omap4/5
> use in the commit header is because the omap4 cpu.h header file had to be
> updated in order to not break omap4 builds (because those builds DO use this
> hwinit-common.c).

Daniel,
thanks for clarifying/confirming my suspicion. Then I'm okay with this patch.

Regards,

--
Andreas Dannenberg
Texas Instruments Inc

[U-Boot] [PATCH 12/16] ARM: omap4/5: Add device type to CPU string

[Tom Rini]

On Thu, Apr 21, 2016 at 01:59:48PM -0500, Andreas Dannenberg wrote:
> On Thu, Apr 21, 2016 at 01:01:43PM -0500, Allred, Daniel wrote:
> > On 4/21/2016 12:55 PM, Andreas Dannenberg wrote:
> > >On Tue, Apr 19, 2016 at 11:26:30AM -0500, Andreas Dannenberg wrote:
> > >>On Mon, Apr 11, 2016 at 06:37:14PM -0500, Daniel Allred wrote:
> > >>>Update the CPU string output so that the device
> > >>>type is now included as part of the CPU string that
> > >>>is printed as the SPL or u-boot comes up. This update
> > >>>adds a suffix of the form "-GP" or "-HS" for production
> > >>>devices, so that general purpose (GP) and high security
> > >>>(HS) can be distiguished. Applies to all OMAP5 variants.
> > >>
> > >>When I'm building for AM437x HS and running on the device I don't see
> > >>that output. It seems like there is something funny going on with
> > >>CONFIG_SPL_DISPLAY_PRINT. Even though this definition is activated in
> > >>ti_omap4_common.h and ti_omap5_common.h it is not seen by
> > >>preloader_console_init() in spl.c, hence the function that prints the
> > >>chip-type/rev specifics never gets invoked.
> > >
> > >So when I run the patches on actual DRA72x HS and DRA74x HS hardware
> > >I'll get the device name/type output by SPL as expected so that piece
> > >works. However this patch's commit message  implies the same should also
> > >work on AM437x HS which it doesn't. I don't have AM437x non-secure
> > >hardware at my desk but I looked at some boot logs from our test farms
> > >and I also don't see the device ID output by SPL so that may be just how
> > >it currently is implemented generally for AM437* and has nothing to do
> > >with the patch discussed here.
> > This hwinit-common.c is not used by the AM335x/AM437x parts, hence the
> > statement "Applies to all OMAP5 variants" in the commit message. The omap4/5
> > use in the commit header is because the omap4 cpu.h header file had to be
> > updated in order to not break omap4 builds (because those builds DO use this
> > hwinit-common.c).
> 
> Daniel,
> thanks for clarifying/confirming my suspicion. Then I'm okay with this patch.

Can we do a follow-up that moves this otherwise common code into the
rest of the families?

-- 
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/20160421/c349e350/attachment.sig>

[U-Boot] [PATCH 12/16] ARM: omap4/5: Add device type to CPU string

[Andreas Dannenberg]

On Thu, Apr 21, 2016 at 04:27:42PM -0400, Tom Rini wrote:
> On Thu, Apr 21, 2016 at 01:59:48PM -0500, Andreas Dannenberg wrote:
> > On Thu, Apr 21, 2016 at 01:01:43PM -0500, Allred, Daniel wrote:
> > > On 4/21/2016 12:55 PM, Andreas Dannenberg wrote:
> > > >On Tue, Apr 19, 2016 at 11:26:30AM -0500, Andreas Dannenberg wrote:
> > > >>On Mon, Apr 11, 2016 at 06:37:14PM -0500, Daniel Allred wrote:
> > > >>>Update the CPU string output so that the device
> > > >>>type is now included as part of the CPU string that
> > > >>>is printed as the SPL or u-boot comes up. This update
> > > >>>adds a suffix of the form "-GP" or "-HS" for production
> > > >>>devices, so that general purpose (GP) and high security
> > > >>>(HS) can be distiguished. Applies to all OMAP5 variants.
> > > >>
> > > >>When I'm building for AM437x HS and running on the device I don't see
> > > >>that output. It seems like there is something funny going on with
> > > >>CONFIG_SPL_DISPLAY_PRINT. Even though this definition is activated in
> > > >>ti_omap4_common.h and ti_omap5_common.h it is not seen by
> > > >>preloader_console_init() in spl.c, hence the function that prints the
> > > >>chip-type/rev specifics never gets invoked.
> > > >
> > > >So when I run the patches on actual DRA72x HS and DRA74x HS hardware
> > > >I'll get the device name/type output by SPL as expected so that piece
> > > >works. However this patch's commit message  implies the same should also
> > > >work on AM437x HS which it doesn't. I don't have AM437x non-secure
> > > >hardware at my desk but I looked at some boot logs from our test farms
> > > >and I also don't see the device ID output by SPL so that may be just how
> > > >it currently is implemented generally for AM437* and has nothing to do
> > > >with the patch discussed here.
> > > This hwinit-common.c is not used by the AM335x/AM437x parts, hence the
> > > statement "Applies to all OMAP5 variants" in the commit message. The omap4/5
> > > use in the commit header is because the omap4 cpu.h header file had to be
> > > updated in order to not break omap4 builds (because those builds DO use this
> > > hwinit-common.c).
> > 
> > Daniel,
> > thanks for clarifying/confirming my suspicion. Then I'm okay with this patch.
> 
> Can we do a follow-up that moves this otherwise common code into the
> rest of the families?

Hi Tom,
just to make sure I understand your suggestion correctly, this is about
a behind the scenes optimization to remove the code duplication we
currently have in .../asm/arch-omap(4|5)/cpu.h, rather than making the
CPU string output as part of SPL work on all of our (TI) platforms, yes?

Thanks and Regards,

--
Andreas Dannenberg
Texas Instruments Inc

[U-Boot] [PATCH 12/16] ARM: omap4/5: Add device type to CPU string

[Tom Rini]

On Thu, Apr 21, 2016 at 05:56:11PM -0500, Andreas Dannenberg wrote:
> On Thu, Apr 21, 2016 at 04:27:42PM -0400, Tom Rini wrote:
> > On Thu, Apr 21, 2016 at 01:59:48PM -0500, Andreas Dannenberg wrote:
> > > On Thu, Apr 21, 2016 at 01:01:43PM -0500, Allred, Daniel wrote:
> > > > On 4/21/2016 12:55 PM, Andreas Dannenberg wrote:
> > > > >On Tue, Apr 19, 2016 at 11:26:30AM -0500, Andreas Dannenberg wrote:
> > > > >>On Mon, Apr 11, 2016 at 06:37:14PM -0500, Daniel Allred wrote:
> > > > >>>Update the CPU string output so that the device
> > > > >>>type is now included as part of the CPU string that
> > > > >>>is printed as the SPL or u-boot comes up. This update
> > > > >>>adds a suffix of the form "-GP" or "-HS" for production
> > > > >>>devices, so that general purpose (GP) and high security
> > > > >>>(HS) can be distiguished. Applies to all OMAP5 variants.
> > > > >>
> > > > >>When I'm building for AM437x HS and running on the device I don't see
> > > > >>that output. It seems like there is something funny going on with
> > > > >>CONFIG_SPL_DISPLAY_PRINT. Even though this definition is activated in
> > > > >>ti_omap4_common.h and ti_omap5_common.h it is not seen by
> > > > >>preloader_console_init() in spl.c, hence the function that prints the
> > > > >>chip-type/rev specifics never gets invoked.
> > > > >
> > > > >So when I run the patches on actual DRA72x HS and DRA74x HS hardware
> > > > >I'll get the device name/type output by SPL as expected so that piece
> > > > >works. However this patch's commit message  implies the same should also
> > > > >work on AM437x HS which it doesn't. I don't have AM437x non-secure
> > > > >hardware at my desk but I looked at some boot logs from our test farms
> > > > >and I also don't see the device ID output by SPL so that may be just how
> > > > >it currently is implemented generally for AM437* and has nothing to do
> > > > >with the patch discussed here.
> > > > This hwinit-common.c is not used by the AM335x/AM437x parts, hence the
> > > > statement "Applies to all OMAP5 variants" in the commit message. The omap4/5
> > > > use in the commit header is because the omap4 cpu.h header file had to be
> > > > updated in order to not break omap4 builds (because those builds DO use this
> > > > hwinit-common.c).
> > > 
> > > Daniel,
> > > thanks for clarifying/confirming my suspicion. Then I'm okay with this patch.
> > 
> > Can we do a follow-up that moves this otherwise common code into the
> > rest of the families?
> 
> Hi Tom,
> just to make sure I understand your suggestion correctly, this is about
> a behind the scenes optimization to remove the code duplication we
> currently have in .../asm/arch-omap(4|5)/cpu.h, rather than making the
> CPU string output as part of SPL work on all of our (TI) platforms, yes?

I want as much consolidate and consistency of output as is both feasible
and practical.

-- 
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/20160421/9d390acb/attachment.sig>

[U-Boot] [PATCH 12/16] ARM: omap4/5: Add device type to CPU string

[Andreas Dannenberg]

On Thu, Apr 21, 2016 at 07:38:17PM -0400, Tom Rini wrote:
> On Thu, Apr 21, 2016 at 05:56:11PM -0500, Andreas Dannenberg wrote:
> > On Thu, Apr 21, 2016 at 04:27:42PM -0400, Tom Rini wrote:
> > > On Thu, Apr 21, 2016 at 01:59:48PM -0500, Andreas Dannenberg wrote:
> > > > On Thu, Apr 21, 2016 at 01:01:43PM -0500, Allred, Daniel wrote:
> > > > > On 4/21/2016 12:55 PM, Andreas Dannenberg wrote:
> > > > > >On Tue, Apr 19, 2016 at 11:26:30AM -0500, Andreas Dannenberg wrote:
> > > > > >>On Mon, Apr 11, 2016 at 06:37:14PM -0500, Daniel Allred wrote:
> > > > > >>>Update the CPU string output so that the device
> > > > > >>>type is now included as part of the CPU string that
> > > > > >>>is printed as the SPL or u-boot comes up. This update
> > > > > >>>adds a suffix of the form "-GP" or "-HS" for production
> > > > > >>>devices, so that general purpose (GP) and high security
> > > > > >>>(HS) can be distiguished. Applies to all OMAP5 variants.
> > > > > >>
> > > > > >>When I'm building for AM437x HS and running on the device I don't see
> > > > > >>that output. It seems like there is something funny going on with
> > > > > >>CONFIG_SPL_DISPLAY_PRINT. Even though this definition is activated in
> > > > > >>ti_omap4_common.h and ti_omap5_common.h it is not seen by
> > > > > >>preloader_console_init() in spl.c, hence the function that prints the
> > > > > >>chip-type/rev specifics never gets invoked.
> > > > > >
> > > > > >So when I run the patches on actual DRA72x HS and DRA74x HS hardware
> > > > > >I'll get the device name/type output by SPL as expected so that piece
> > > > > >works. However this patch's commit message  implies the same should also
> > > > > >work on AM437x HS which it doesn't. I don't have AM437x non-secure
> > > > > >hardware at my desk but I looked at some boot logs from our test farms
> > > > > >and I also don't see the device ID output by SPL so that may be just how
> > > > > >it currently is implemented generally for AM437* and has nothing to do
> > > > > >with the patch discussed here.
> > > > > This hwinit-common.c is not used by the AM335x/AM437x parts, hence the
> > > > > statement "Applies to all OMAP5 variants" in the commit message. The omap4/5
> > > > > use in the commit header is because the omap4 cpu.h header file had to be
> > > > > updated in order to not break omap4 builds (because those builds DO use this
> > > > > hwinit-common.c).
> > > > 
> > > > Daniel,
> > > > thanks for clarifying/confirming my suspicion. Then I'm okay with this patch.
> > > 
> > > Can we do a follow-up that moves this otherwise common code into the
> > > rest of the families?
> > 
> > Hi Tom,
> > just to make sure I understand your suggestion correctly, this is about
> > a behind the scenes optimization to remove the code duplication we
> > currently have in .../asm/arch-omap(4|5)/cpu.h, rather than making the
> > CPU string output as part of SPL work on all of our (TI) platforms, yes?
> 
> I want as much consolidate and consistency of output as is both feasible
> and practical.

Agreed. Consistency and consolidation would make sense here. I just
added an item to our internal issue tracker to capture this suggestion
but I can't yet comment on when we'll get to it.

Thanks and Regards,
Andreas

[U-Boot] [PATCH 12/16] ARM: omap4/5: Add device type to CPU string

[Tom Rini]

On Mon, Apr 11, 2016 at 06:37:14PM -0500, Daniel Allred wrote:

> Update the CPU string output so that the device
> type is now included as part of the CPU string that
> is printed as the SPL or u-boot comes up. This update
> adds a suffix of the form "-GP" or "-HS" for production
> devices, so that general purpose (GP) and high security
> (HS) can be distiguished. Applies to all OMAP5 variants.
[snip]
> diff --git a/arch/arm/include/asm/arch-omap4/cpu.h b/arch/arm/include/asm/arch-omap4/cpu.h
> index f7595ae..34609b9 100644
> --- a/arch/arm/include/asm/arch-omap4/cpu.h
> +++ b/arch/arm/include/asm/arch-omap4/cpu.h
> @@ -59,6 +59,13 @@ struct watchdog {
>  #define TCLR_AR			(0x1 << 1)
>  #define TCLR_PRE		(0x1 << 5)
>  
> +/* device type */
> +#define DEVICE_MASK         (BIT(8) | BIT(9) | BIT(10))
> +#define TST_DEVICE          0x0
> +#define EMU_DEVICE          0x1
> +#define HS_DEVICE           0x2
> +#define GP_DEVICE           0x3

Lets move these to arch/arm/include/asm/omap_common.h (which someday we
need to re-work using the mach infrastructure or similar).

-- 
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/20160421/0d6db28c/attachment.sig>

[U-Boot] [PATCH 13/16] ARM: omap5: add hooks for cpu/SoC fdt fixups

[Daniel Allred]

Adds an fdt.c file in that defines the ft_cpu_setup() function,
which should be called from a board-specific ft_board_setup()).
This ft_cpu_setup() will currently do nothing for non-secure (GP)
devices	but contains pertinent updates for booting on secure (HS)
devices.

Update the omap5 Makefile to include the fdt.c in the build.

Signed-off-by: Daniel Allred <d-allred@ti.com>
Signed-off-by: Madan Srinivas <madans@ti.com>
---
 arch/arm/cpu/armv7/omap5/Makefile |   1 +
 arch/arm/cpu/armv7/omap5/fdt.c    | 183 ++++++++++++++++++++++++++++++++++++++
 2 files changed, 184 insertions(+)
 create mode 100644 arch/arm/cpu/armv7/omap5/fdt.c

diff --git a/arch/arm/cpu/armv7/omap5/Makefile b/arch/arm/cpu/armv7/omap5/Makefile
index f2930d5..3caba86 100644
--- a/arch/arm/cpu/armv7/omap5/Makefile
+++ b/arch/arm/cpu/armv7/omap5/Makefile
@@ -12,4 +12,5 @@ obj-y	+= sdram.o
 obj-y	+= prcm-regs.o
 obj-y	+= hw_data.o
 obj-y	+= abb.o
+obj-y	+= fdt.o
 obj-$(CONFIG_IODELAY_RECALIBRATION) += dra7xx_iodelay.o
diff --git a/arch/arm/cpu/armv7/omap5/fdt.c b/arch/arm/cpu/armv7/omap5/fdt.c
new file mode 100644
index 0000000..f2f40f0
--- /dev/null
+++ b/arch/arm/cpu/armv7/omap5/fdt.c
@@ -0,0 +1,183 @@
+/*
+ * Copyright 2016 Texas Instruments, Inc.
+ *
+ * SPDX-License-Identifier: GPL-2.0+
+ */
+
+#include <common.h>
+#include <libfdt.h>
+#include <fdt_support.h>
+#include <malloc.h>
+
+#include <asm/omap_common.h>
+#include <asm/arch-omap5/sys_proto.h>
+
+#ifdef CONFIG_TI_SECURE_DEVICE
+
+/* Give zero values if not already defined */
+#ifndef CONFIG_SECURE_BOOT_SRAM
+#define CONFIG_SECURE_BOOT_SRAM (0)
+#endif
+#ifndef CONFIG_SECURE_RUN_SRAM
+#define CONFIG_SECURE_RUN_SRAM (0)
+#endif
+
+static u32 hs_irq_skip[] = {
+	8,	/* Secure violation reporting interrupt */
+	15,	/* One interrupt for SDMA by secure world */
+	118	/* One interrupt for Crypto DMA by secure world */
+};
+
+static int ft_hs_fixup_crossbar(void *fdt, bd_t *bd)
+{
+	const char *path;
+	int offs;
+	int ret;
+	int len, i, old_cnt, new_cnt;
+	u32 *temp;
+	const u32 *p_data;
+
+	/*
+	 * Increase the size of the fdt
+	 * so we have some breathing room
+	 */
+	ret = fdt_increase_size(fdt, 512);
+	if (ret < 0) {
+		printf("Could not increase size of device tree: %s\n",
+		       fdt_strerror(ret));
+		return ret;
+	}
+
+	/* Reserve IRQs that are used/needed by secure world */
+	path = "/ocp/crossbar";
+	offs = fdt_path_offset(fdt, path);
+	if (offs < 0) {
+		debug("Node %s not found.\n", path);
+		return 0;
+	}
+
+	/* Get current entries */
+	p_data = fdt_getprop(fdt, offs, "ti,irqs-skip", &len);
+	if (p_data)
+		old_cnt = len / sizeof(u32);
+	else
+		old_cnt = 0;
+
+	new_cnt = sizeof(hs_irq_skip) /
+				sizeof(hs_irq_skip[0]);
+
+	/* Create new/updated skip list for HS parts */
+	temp = malloc(sizeof(u32) * (old_cnt + new_cnt));
+	for (i = 0; i < new_cnt; i++)
+		temp[i] = cpu_to_fdt32(hs_irq_skip[i]);
+	for (i = 0; i < old_cnt; i++)
+		temp[i + new_cnt] = p_data[i];
+
+	/* Blow away old data and set new data */
+	fdt_delprop(fdt, offs, "ti,irqs-skip");
+	ret = fdt_setprop(fdt, offs, "ti,irqs-skip",
+			  temp,
+			  (old_cnt + new_cnt) * sizeof(u32));
+	free(temp);
+
+	/* Check if the update worked */
+	if (ret < 0) {
+		printf("Could not add ti,irqs-skip property to node %s: %s\n",
+		       path, fdt_strerror(ret));
+		return ret;
+	}
+
+	return 0;
+}
+
+static int ft_hs_disable_rng(void *fdt, bd_t *bd)
+{
+	const char *path;
+	int offs;
+	int ret;
+
+	/* Make HW RNG reserved for secure world use */
+	path = "/ocp/rng";
+	offs = fdt_path_offset(fdt, path);
+	if (offs < 0) {
+		debug("Node %s not found.\n", path);
+		return 0;
+	}
+	ret = fdt_setprop_string(fdt, offs,
+				 "status", "disabled");
+	if (ret < 0) {
+		printf("Could not add status property to node %s: %s\n",
+		       path, fdt_strerror(ret));
+		return ret;
+	}
+	return 0;
+}
+
+#if (CONFIG_SECURE_BOOT_SRAM != 0) || (CONFIG_SECURE_RUN_SRAM != 0)
+static int ft_hs_fixup_sram(void *fdt, bd_t *bd)
+{
+	const char *path;
+	int offs;
+	int ret;
+	u32 temp[2];
+
+	/*
+	 * Update SRAM reservations on secure devices. The OCMC RAM
+	 * is always reserved for secure use from the start of that
+	 * memory region
+	 */
+	path = "/ocp/ocmcram@40300000/sram-hs";
+	offs = fdt_path_offset(fdt, path);
+	if (offs < 0) {
+		debug("Node %s not found.\n", path);
+		return 0;
+	}
+
+	/* relative start offset */
+	temp[0] = cpu_to_fdt32(0);
+	/* reservation size */
+	temp[1] = cpu_to_fdt32(max(CONFIG_SECURE_BOOT_SRAM,
+				   CONFIG_SECURE_RUN_SRAM));
+	fdt_delprop(fdt, offs, "reg");
+	ret = fdt_setprop(fdt, offs, "reg", temp, 2 * sizeof(u32));
+	if (ret < 0) {
+		printf("Could not add reg property to node %s: %s\n",
+		       path, fdt_strerror(ret));
+		return ret;
+	}
+
+	return 0;
+}
+#else
+static int ft_hs_fixup_sram(void *fdt, bd_t *bd) { return 0; }
+#endif
+
+static void ft_hs_fixups(void *fdt, bd_t *bd)
+{
+	/* Check we are running on an HS/EMU device type */
+	if (GP_DEVICE != get_device_type()) {
+		if ((ft_hs_fixup_crossbar(fdt, bd) == 0) &&
+		    (ft_hs_disable_rng(fdt, bd) == 0) &&
+		    (ft_hs_fixup_sram(fdt, bd) == 0))
+			return;
+	} else {
+		printf("ERROR: Incorrect device type (GP) detected!");
+	}
+	/* Fixup failed or wrong device type */
+	hang();
+}
+#else
+static void ft_hs_fixups(void *fdt, bd_t *bd)
+{
+}
+#endif
+
+/*
+ * Place for general cpu/SoC FDT fixups. Board specific
+ * fixups should remain in the board files which is where
+ * this function should be called from.
+ */
+void ft_cpu_setup(void *fdt, bd_t *bd)
+{
+	ft_hs_fixups(fdt, bd);
+}
-- 
1.9.1

[U-Boot] [PATCH 13/16] ARM: omap5: add hooks for cpu/SoC fdt fixups

[Lokesh Vutla]

On Tuesday 12 April 2016 05:07 AM, Daniel Allred wrote:
> Adds an fdt.c file in that defines the ft_cpu_setup() function,
> which should be called from a board-specific ft_board_setup()).
> This ft_cpu_setup() will currently do nothing for non-secure (GP)
> devices	but contains pertinent updates for booting on secure (HS)
> devices.
> 
> Update the omap5 Makefile to include the fdt.c in the build.

Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>

Thanks and regards,
Lokesh

> 
> Signed-off-by: Daniel Allred <d-allred@ti.com>
> Signed-off-by: Madan Srinivas <madans@ti.com>
> ---
>  arch/arm/cpu/armv7/omap5/Makefile |   1 +
>  arch/arm/cpu/armv7/omap5/fdt.c    | 183 ++++++++++++++++++++++++++++++++++++++
>  2 files changed, 184 insertions(+)
>  create mode 100644 arch/arm/cpu/armv7/omap5/fdt.c
> 
> diff --git a/arch/arm/cpu/armv7/omap5/Makefile b/arch/arm/cpu/armv7/omap5/Makefile
> index f2930d5..3caba86 100644
> --- a/arch/arm/cpu/armv7/omap5/Makefile
> +++ b/arch/arm/cpu/armv7/omap5/Makefile
> @@ -12,4 +12,5 @@ obj-y	+= sdram.o
>  obj-y	+= prcm-regs.o
>  obj-y	+= hw_data.o
>  obj-y	+= abb.o
> +obj-y	+= fdt.o
>  obj-$(CONFIG_IODELAY_RECALIBRATION) += dra7xx_iodelay.o
> diff --git a/arch/arm/cpu/armv7/omap5/fdt.c b/arch/arm/cpu/armv7/omap5/fdt.c
> new file mode 100644
> index 0000000..f2f40f0
> --- /dev/null
> +++ b/arch/arm/cpu/armv7/omap5/fdt.c
> @@ -0,0 +1,183 @@
> +/*
> + * Copyright 2016 Texas Instruments, Inc.
> + *
> + * SPDX-License-Identifier: GPL-2.0+
> + */
> +
> +#include <common.h>
> +#include <libfdt.h>
> +#include <fdt_support.h>
> +#include <malloc.h>
> +
> +#include <asm/omap_common.h>
> +#include <asm/arch-omap5/sys_proto.h>
> +
> +#ifdef CONFIG_TI_SECURE_DEVICE
> +
> +/* Give zero values if not already defined */
> +#ifndef CONFIG_SECURE_BOOT_SRAM
> +#define CONFIG_SECURE_BOOT_SRAM (0)
> +#endif
> +#ifndef CONFIG_SECURE_RUN_SRAM
> +#define CONFIG_SECURE_RUN_SRAM (0)
> +#endif
> +
> +static u32 hs_irq_skip[] = {
> +	8,	/* Secure violation reporting interrupt */
> +	15,	/* One interrupt for SDMA by secure world */
> +	118	/* One interrupt for Crypto DMA by secure world */
> +};
> +
> +static int ft_hs_fixup_crossbar(void *fdt, bd_t *bd)
> +{
> +	const char *path;
> +	int offs;
> +	int ret;
> +	int len, i, old_cnt, new_cnt;
> +	u32 *temp;
> +	const u32 *p_data;
> +
> +	/*
> +	 * Increase the size of the fdt
> +	 * so we have some breathing room
> +	 */
> +	ret = fdt_increase_size(fdt, 512);
> +	if (ret < 0) {
> +		printf("Could not increase size of device tree: %s\n",
> +		       fdt_strerror(ret));
> +		return ret;
> +	}
> +
> +	/* Reserve IRQs that are used/needed by secure world */
> +	path = "/ocp/crossbar";
> +	offs = fdt_path_offset(fdt, path);
> +	if (offs < 0) {
> +		debug("Node %s not found.\n", path);
> +		return 0;
> +	}
> +
> +	/* Get current entries */
> +	p_data = fdt_getprop(fdt, offs, "ti,irqs-skip", &len);
> +	if (p_data)
> +		old_cnt = len / sizeof(u32);
> +	else
> +		old_cnt = 0;
> +
> +	new_cnt = sizeof(hs_irq_skip) /
> +				sizeof(hs_irq_skip[0]);
> +
> +	/* Create new/updated skip list for HS parts */
> +	temp = malloc(sizeof(u32) * (old_cnt + new_cnt));
> +	for (i = 0; i < new_cnt; i++)
> +		temp[i] = cpu_to_fdt32(hs_irq_skip[i]);
> +	for (i = 0; i < old_cnt; i++)
> +		temp[i + new_cnt] = p_data[i];
> +
> +	/* Blow away old data and set new data */
> +	fdt_delprop(fdt, offs, "ti,irqs-skip");
> +	ret = fdt_setprop(fdt, offs, "ti,irqs-skip",
> +			  temp,
> +			  (old_cnt + new_cnt) * sizeof(u32));
> +	free(temp);
> +
> +	/* Check if the update worked */
> +	if (ret < 0) {
> +		printf("Could not add ti,irqs-skip property to node %s: %s\n",
> +		       path, fdt_strerror(ret));
> +		return ret;
> +	}
> +
> +	return 0;
> +}
> +
> +static int ft_hs_disable_rng(void *fdt, bd_t *bd)
> +{
> +	const char *path;
> +	int offs;
> +	int ret;
> +
> +	/* Make HW RNG reserved for secure world use */
> +	path = "/ocp/rng";
> +	offs = fdt_path_offset(fdt, path);
> +	if (offs < 0) {
> +		debug("Node %s not found.\n", path);
> +		return 0;
> +	}
> +	ret = fdt_setprop_string(fdt, offs,
> +				 "status", "disabled");
> +	if (ret < 0) {
> +		printf("Could not add status property to node %s: %s\n",
> +		       path, fdt_strerror(ret));
> +		return ret;
> +	}
> +	return 0;
> +}
> +
> +#if (CONFIG_SECURE_BOOT_SRAM != 0) || (CONFIG_SECURE_RUN_SRAM != 0)
> +static int ft_hs_fixup_sram(void *fdt, bd_t *bd)
> +{
> +	const char *path;
> +	int offs;
> +	int ret;
> +	u32 temp[2];
> +
> +	/*
> +	 * Update SRAM reservations on secure devices. The OCMC RAM
> +	 * is always reserved for secure use from the start of that
> +	 * memory region
> +	 */
> +	path = "/ocp/ocmcram at 40300000/sram-hs";
> +	offs = fdt_path_offset(fdt, path);
> +	if (offs < 0) {
> +		debug("Node %s not found.\n", path);
> +		return 0;
> +	}
> +
> +	/* relative start offset */
> +	temp[0] = cpu_to_fdt32(0);
> +	/* reservation size */
> +	temp[1] = cpu_to_fdt32(max(CONFIG_SECURE_BOOT_SRAM,
> +				   CONFIG_SECURE_RUN_SRAM));
> +	fdt_delprop(fdt, offs, "reg");
> +	ret = fdt_setprop(fdt, offs, "reg", temp, 2 * sizeof(u32));
> +	if (ret < 0) {
> +		printf("Could not add reg property to node %s: %s\n",
> +		       path, fdt_strerror(ret));
> +		return ret;
> +	}
> +
> +	return 0;
> +}
> +#else
> +static int ft_hs_fixup_sram(void *fdt, bd_t *bd) { return 0; }
> +#endif
> +
> +static void ft_hs_fixups(void *fdt, bd_t *bd)
> +{
> +	/* Check we are running on an HS/EMU device type */
> +	if (GP_DEVICE != get_device_type()) {
> +		if ((ft_hs_fixup_crossbar(fdt, bd) == 0) &&
> +		    (ft_hs_disable_rng(fdt, bd) == 0) &&
> +		    (ft_hs_fixup_sram(fdt, bd) == 0))
> +			return;
> +	} else {
> +		printf("ERROR: Incorrect device type (GP) detected!");
> +	}
> +	/* Fixup failed or wrong device type */
> +	hang();
> +}
> +#else
> +static void ft_hs_fixups(void *fdt, bd_t *bd)
> +{
> +}
> +#endif
> +
> +/*
> + * Place for general cpu/SoC FDT fixups. Board specific
> + * fixups should remain in the board files which is where
> + * this function should be called from.
> + */
> +void ft_cpu_setup(void *fdt, bd_t *bd)
> +{
> +	ft_hs_fixups(fdt, bd);
> +}
> 

[U-Boot] [PATCH 13/16] ARM: omap5: add hooks for cpu/SoC fdt fixups

[Andreas Dannenberg]

On Mon, Apr 11, 2016 at 06:37:15PM -0500, Daniel Allred wrote:
> Adds an fdt.c file in that defines the ft_cpu_setup() function,
> which should be called from a board-specific ft_board_setup()).
> This ft_cpu_setup() will currently do nothing for non-secure (GP)
> devices	but contains pertinent updates for booting on secure (HS)
> devices.
> 
> Update the omap5 Makefile to include the fdt.c in the build.
> 
> Signed-off-by: Daniel Allred <d-allred@ti.com>
> Signed-off-by: Madan Srinivas <madans@ti.com>

Successfully boot-tested this patch on actual DRA72x HS and DRA74x
HS hardware.

Tested-by: Andreas Dannenberg <dannenberg@ti.com>

--
Andreas Dannenberg
Texas Instruments Inc

[U-Boot] [PATCH 13/16] ARM: omap5: add hooks for cpu/SoC fdt fixups

[Tom Rini]

On Mon, Apr 11, 2016 at 06:37:15PM -0500, Daniel Allred wrote:

> Adds an fdt.c file in that defines the ft_cpu_setup() function,
> which should be called from a board-specific ft_board_setup()).
> This ft_cpu_setup() will currently do nothing for non-secure (GP)
> devices	but contains pertinent updates for booting on secure (HS)
> devices.
> 
> Update the omap5 Makefile to include the fdt.c in the build.
> 
> Signed-off-by: Daniel Allred <d-allred@ti.com>
> Signed-off-by: Madan Srinivas <madans@ti.com>

Conceptually fine but will need reworking based on my previous comments.

-- 
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/20160421/646e7737/attachment.sig>

[U-Boot] [PATCH 14/16] ARM: omap5: add ft_board_setup for dra7xx/am57xx

[Daniel Allred]

Adds the board specific ft_board_setup() functions that
are called when CONFIG_OF_BOARD_SETUP is defined. These functions
will currently just call the ft_cpu_setup() function.

Signed-off-by: Daniel Allred <d-allred@ti.com>
Signed-off-by: Madan Srinivas <madans@ti.com>
---
 board/ti/am57xx/board.c | 9 +++++++++
 board/ti/dra7xx/evm.c   | 9 +++++++++
 2 files changed, 18 insertions(+)

diff --git a/board/ti/am57xx/board.c b/board/ti/am57xx/board.c
index 18416ef..4d06362 100644
--- a/board/ti/am57xx/board.c
+++ b/board/ti/am57xx/board.c
@@ -657,3 +657,12 @@ int board_early_init_f(void)
 	return 0;
 }
 #endif
+
+#if defined(CONFIG_OF_LIBFDT) && defined(CONFIG_OF_BOARD_SETUP)
+int ft_board_setup(void *blob, bd_t *bd)
+{
+	ft_cpu_setup(blob, bd);
+
+	return 0;
+}
+#endif
diff --git a/board/ti/dra7xx/evm.c b/board/ti/dra7xx/evm.c
index 9bd71d8..d01c785 100644
--- a/board/ti/dra7xx/evm.c
+++ b/board/ti/dra7xx/evm.c
@@ -718,3 +718,12 @@ int board_early_init_f(void)
 	return 0;
 }
 #endif
+
+#if defined(CONFIG_OF_LIBFDT) && defined(CONFIG_OF_BOARD_SETUP)
+int ft_board_setup(void *blob, bd_t *bd)
+{
+	ft_cpu_setup(blob, bd);
+
+	return 0;
+}
+#endif
-- 
1.9.1

[U-Boot] [PATCH 14/16] ARM: omap5: add ft_board_setup for dra7xx/am57xx

[Lokesh Vutla]

On Tuesday 12 April 2016 05:07 AM, Daniel Allred wrote:
> Adds the board specific ft_board_setup() functions that
> are called when CONFIG_OF_BOARD_SETUP is defined. These functions
> will currently just call the ft_cpu_setup() function.
> 
> Signed-off-by: Daniel Allred <d-allred@ti.com>
> Signed-off-by: Madan Srinivas <madans@ti.com>

Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>

Thanks and regards,
Lokesh

[U-Boot] [PATCH 14/16] ARM: omap5: add ft_board_setup for dra7xx/am57xx

[Andreas Dannenberg]

On Mon, Apr 11, 2016 at 06:37:16PM -0500, Daniel Allred wrote:
> Adds the board specific ft_board_setup() functions that
> are called when CONFIG_OF_BOARD_SETUP is defined. These functions
> will currently just call the ft_cpu_setup() function.
> 
> Signed-off-by: Daniel Allred <d-allred@ti.com>
> Signed-off-by: Madan Srinivas <madans@ti.com>


Successfully boot-tested this patch on actual DRA72x HS and DRA74x HS
hardware.

Tested-by: Andreas Dannenberg <dannenberg@ti.com>

--
Andreas Dannenberg
Texas Instruments Inc

[U-Boot] [PATCH 14/16] ARM: omap5: add ft_board_setup for dra7xx/am57xx

[Tom Rini]

On Mon, Apr 11, 2016 at 06:37:16PM -0500, Daniel Allred wrote:

> Adds the board specific ft_board_setup() functions that
> are called when CONFIG_OF_BOARD_SETUP is defined. These functions
> will currently just call the ft_cpu_setup() function.
> 
> Signed-off-by: Daniel Allred <d-allred@ti.com>
> Signed-off-by: Madan Srinivas <madans@ti.com>

Reviewed-by: Tom Rini <trini@konsulko.com>

-- 
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/20160421/91576cb8/attachment.sig>

[U-Boot] [PATCH 15/16] ARM: omap5: Add config for board/cpu fdt fixups

[Daniel Allred]

Adds CONFIG_OF_BOARD_SETUP to the config header files
for dra7xx_evm and am57xx_evm.

Signed-off-by: Daniel Allred <d-allred@ti.com>
Signed-off-by: Madan Srinivas <madans@ti.com>
---
 include/configs/am57xx_evm.h | 3 +++
 include/configs/dra7xx_evm.h | 3 +++
 2 files changed, 6 insertions(+)

diff --git a/include/configs/am57xx_evm.h b/include/configs/am57xx_evm.h
index 1fffdb1..5e629a6 100644
--- a/include/configs/am57xx_evm.h
+++ b/include/configs/am57xx_evm.h
@@ -20,6 +20,9 @@
 
 #define CONFIG_BOARD_EARLY_INIT_F
 
+/* Linux interfacing, DTB/FDT fixups */
+#define CONFIG_OF_BOARD_SETUP
+
 #define CONFIG_NR_DRAM_BANKS		2
 
 #define CONFIG_ENV_SIZE			(64 << 10)
diff --git a/include/configs/dra7xx_evm.h b/include/configs/dra7xx_evm.h
index 7734e8d..25b03b3 100644
--- a/include/configs/dra7xx_evm.h
+++ b/include/configs/dra7xx_evm.h
@@ -15,6 +15,9 @@
 #define CONFIG_DRA7XX
 #define CONFIG_BOARD_EARLY_INIT_F
 
+/* Linux interfacing, DTB/FDT fixups */
+#define CONFIG_OF_BOARD_SETUP
+
 #ifdef CONFIG_SPL_BUILD
 #define CONFIG_IODELAY_RECALIBRATION
 #endif
-- 
1.9.1

[U-Boot] [PATCH 15/16] ARM: omap5: Add config for board/cpu fdt fixups

[Lokesh Vutla]

On Tuesday 12 April 2016 05:07 AM, Daniel Allred wrote:
> Adds CONFIG_OF_BOARD_SETUP to the config header files
> for dra7xx_evm and am57xx_evm.
> 
> Signed-off-by: Daniel Allred <d-allred@ti.com>
> Signed-off-by: Madan Srinivas <madans@ti.com>

Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>

Thanks and regards,
Lokesh

[U-Boot] [PATCH 15/16] ARM: omap5: Add config for board/cpu fdt fixups

[Andreas Dannenberg]

On Mon, Apr 11, 2016 at 06:37:17PM -0500, Daniel Allred wrote:
> Adds CONFIG_OF_BOARD_SETUP to the config header files
> for dra7xx_evm and am57xx_evm.
> 
> Signed-off-by: Daniel Allred <d-allred@ti.com>
> Signed-off-by: Madan Srinivas <madans@ti.com>


Successfully boot-tested this patch on actual DRA72x HS and DRA74x HS
hardware.

Tested-by: Andreas Dannenberg <dannenberg@ti.com>

--
Andreas Dannenberg
Texas Instruments Inc

[U-Boot] [PATCH 15/16] ARM: omap5: Add config for board/cpu fdt fixups

[Tom Rini]

On Mon, Apr 11, 2016 at 06:37:17PM -0500, Daniel Allred wrote:

> Adds CONFIG_OF_BOARD_SETUP to the config header files
> for dra7xx_evm and am57xx_evm.
> 
> Signed-off-by: Daniel Allred <d-allred@ti.com>
> Signed-off-by: Madan Srinivas <madans@ti.com>

Fold this into the patch that adds the functions, thanks.

-- 
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/20160421/3cbec4c1/attachment.sig>

[U-Boot] [PATCH 16/16] defconfig: ti: Add configs for OMAP5-class secure parts

[Daniel Allred]

Adds new defconfig files for DRA7xx and AM57xx secure devices.
These are the same as the non-secure parts, but with the addition
of the CONFIG_TI_SECURE_DEVICE option set to 'y'.

Signed-off-by: Daniel Allred <d-allred@ti.com>
Signed-off-by: Madan Srinivas <madans@ti.com>
---
 configs/am57xx_hs_evm_defconfig | 20 ++++++++++++++++++++
 configs/dra72_hs_evm_defconfig  | 28 ++++++++++++++++++++++++++++
 configs/dra74_hs_evm_defconfig  | 27 +++++++++++++++++++++++++++
 3 files changed, 75 insertions(+)
 create mode 100644 configs/am57xx_hs_evm_defconfig
 create mode 100644 configs/dra72_hs_evm_defconfig
 create mode 100644 configs/dra74_hs_evm_defconfig

diff --git a/configs/am57xx_hs_evm_defconfig b/configs/am57xx_hs_evm_defconfig
new file mode 100644
index 0000000..062471e
--- /dev/null
+++ b/configs/am57xx_hs_evm_defconfig
@@ -0,0 +1,20 @@
+CONFIG_ARM=y
+CONFIG_OMAP54XX=y
+CONFIG_TI_SECURE_DEVICE=y
+CONFIG_TARGET_BEAGLE_X15=y
+CONFIG_DM_SERIAL=y
+CONFIG_DM_GPIO=y
+CONFIG_SPL_STACK_R_ADDR=0x82000000
+CONFIG_DEFAULT_DEVICE_TREE="am57xx-beagle-x15"
+CONFIG_SPL=y
+CONFIG_SPL_STACK_R=y
+# CONFIG_CMD_IMLS is not set
+# CONFIG_CMD_FLASH is not set
+CONFIG_CMD_GPIO=y
+# CONFIG_CMD_SETEXPR is not set
+CONFIG_OF_CONTROL=y
+CONFIG_DM=y
+CONFIG_DM_MMC=y
+CONFIG_SPI_FLASH=y
+CONFIG_SPI_FLASH_BAR=y
+CONFIG_SYS_NS16550=y
diff --git a/configs/dra72_hs_evm_defconfig b/configs/dra72_hs_evm_defconfig
new file mode 100644
index 0000000..49f2b49
--- /dev/null
+++ b/configs/dra72_hs_evm_defconfig
@@ -0,0 +1,28 @@
+CONFIG_ARM=y
+CONFIG_OMAP54XX=y
+CONFIG_TI_SECURE_DEVICE=y
+CONFIG_SYS_MALLOC_F_LEN=0x2000
+CONFIG_TARGET_DRA7XX_EVM=y
+CONFIG_DM_SERIAL=y
+CONFIG_DM_SPI=y
+CONFIG_DM_SPI_FLASH=y
+CONFIG_DM_GPIO=y
+CONFIG_SPL_STACK_R_ADDR=0x82000000
+CONFIG_DEFAULT_DEVICE_TREE="dra72-evm"
+CONFIG_SPL=y
+CONFIG_SPL_STACK_R=y
+# CONFIG_CMD_IMLS is not set
+# CONFIG_CMD_FLASH is not set
+CONFIG_CMD_GPIO=y
+# CONFIG_CMD_SETEXPR is not set
+CONFIG_OF_CONTROL=y
+CONFIG_DM=y
+CONFIG_SPI_FLASH=y
+CONFIG_SPI_FLASH_BAR=y
+CONFIG_SPI_FLASH_SPANSION=y
+CONFIG_SYS_NS16550=y
+CONFIG_TI_QSPI=y
+CONFIG_TIMER=y
+CONFIG_OMAP_TIMER=y
+CONFIG_USB=y
+CONFIG_USB_GADGET=y
diff --git a/configs/dra74_hs_evm_defconfig b/configs/dra74_hs_evm_defconfig
new file mode 100644
index 0000000..0339d7f
--- /dev/null
+++ b/configs/dra74_hs_evm_defconfig
@@ -0,0 +1,27 @@
+CONFIG_ARM=y
+CONFIG_OMAP54XX=y
+CONFIG_TI_SECURE_DEVICE=y
+CONFIG_TARGET_DRA7XX_EVM=y
+CONFIG_DM_SERIAL=y
+CONFIG_DM_SPI=y
+CONFIG_DM_SPI_FLASH=y
+CONFIG_DM_GPIO=y
+CONFIG_SPL_STACK_R_ADDR=0x82000000
+CONFIG_DEFAULT_DEVICE_TREE="dra7-evm"
+CONFIG_SPL=y
+CONFIG_SPL_STACK_R=y
+# CONFIG_CMD_IMLS is not set
+# CONFIG_CMD_FLASH is not set
+CONFIG_CMD_GPIO=y
+# CONFIG_CMD_SETEXPR is not set
+CONFIG_OF_CONTROL=y
+CONFIG_DM=y
+CONFIG_SPI_FLASH=y
+CONFIG_SPI_FLASH_BAR=y
+CONFIG_SPI_FLASH_SPANSION=y
+CONFIG_SYS_NS16550=y
+CONFIG_TI_QSPI=y
+CONFIG_TIMER=y
+CONFIG_OMAP_TIMER=y
+CONFIG_USB=y
+CONFIG_USB_GADGET=y
-- 
1.9.1

[U-Boot] [PATCH 16/16] defconfig: ti: Add configs for OMAP5-class secure parts

[Lokesh Vutla]

On Tuesday 12 April 2016 05:07 AM, Daniel Allred wrote:
> Adds new defconfig files for DRA7xx and AM57xx secure devices.
> These are the same as the non-secure parts, but with the addition
> of the CONFIG_TI_SECURE_DEVICE option set to 'y'.
> 
> Signed-off-by: Daniel Allred <d-allred@ti.com>
> Signed-off-by: Madan Srinivas <madans@ti.com>

Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>

Thanks and regards,
Lokesh

> ---
>  configs/am57xx_hs_evm_defconfig | 20 ++++++++++++++++++++
>  configs/dra72_hs_evm_defconfig  | 28 ++++++++++++++++++++++++++++
>  configs/dra74_hs_evm_defconfig  | 27 +++++++++++++++++++++++++++
>  3 files changed, 75 insertions(+)
>  create mode 100644 configs/am57xx_hs_evm_defconfig
>  create mode 100644 configs/dra72_hs_evm_defconfig
>  create mode 100644 configs/dra74_hs_evm_defconfig
> 
> diff --git a/configs/am57xx_hs_evm_defconfig b/configs/am57xx_hs_evm_defconfig
> new file mode 100644
> index 0000000..062471e
> --- /dev/null
> +++ b/configs/am57xx_hs_evm_defconfig
> @@ -0,0 +1,20 @@
> +CONFIG_ARM=y
> +CONFIG_OMAP54XX=y
> +CONFIG_TI_SECURE_DEVICE=y
> +CONFIG_TARGET_BEAGLE_X15=y
> +CONFIG_DM_SERIAL=y
> +CONFIG_DM_GPIO=y
> +CONFIG_SPL_STACK_R_ADDR=0x82000000
> +CONFIG_DEFAULT_DEVICE_TREE="am57xx-beagle-x15"
> +CONFIG_SPL=y
> +CONFIG_SPL_STACK_R=y
> +# CONFIG_CMD_IMLS is not set
> +# CONFIG_CMD_FLASH is not set
> +CONFIG_CMD_GPIO=y
> +# CONFIG_CMD_SETEXPR is not set
> +CONFIG_OF_CONTROL=y
> +CONFIG_DM=y
> +CONFIG_DM_MMC=y
> +CONFIG_SPI_FLASH=y
> +CONFIG_SPI_FLASH_BAR=y
> +CONFIG_SYS_NS16550=y
> diff --git a/configs/dra72_hs_evm_defconfig b/configs/dra72_hs_evm_defconfig
> new file mode 100644
> index 0000000..49f2b49
> --- /dev/null
> +++ b/configs/dra72_hs_evm_defconfig
> @@ -0,0 +1,28 @@
> +CONFIG_ARM=y
> +CONFIG_OMAP54XX=y
> +CONFIG_TI_SECURE_DEVICE=y
> +CONFIG_SYS_MALLOC_F_LEN=0x2000
> +CONFIG_TARGET_DRA7XX_EVM=y
> +CONFIG_DM_SERIAL=y
> +CONFIG_DM_SPI=y
> +CONFIG_DM_SPI_FLASH=y
> +CONFIG_DM_GPIO=y
> +CONFIG_SPL_STACK_R_ADDR=0x82000000
> +CONFIG_DEFAULT_DEVICE_TREE="dra72-evm"
> +CONFIG_SPL=y
> +CONFIG_SPL_STACK_R=y
> +# CONFIG_CMD_IMLS is not set
> +# CONFIG_CMD_FLASH is not set
> +CONFIG_CMD_GPIO=y
> +# CONFIG_CMD_SETEXPR is not set
> +CONFIG_OF_CONTROL=y
> +CONFIG_DM=y
> +CONFIG_SPI_FLASH=y
> +CONFIG_SPI_FLASH_BAR=y
> +CONFIG_SPI_FLASH_SPANSION=y
> +CONFIG_SYS_NS16550=y
> +CONFIG_TI_QSPI=y
> +CONFIG_TIMER=y
> +CONFIG_OMAP_TIMER=y
> +CONFIG_USB=y
> +CONFIG_USB_GADGET=y
> diff --git a/configs/dra74_hs_evm_defconfig b/configs/dra74_hs_evm_defconfig
> new file mode 100644
> index 0000000..0339d7f
> --- /dev/null
> +++ b/configs/dra74_hs_evm_defconfig
> @@ -0,0 +1,27 @@
> +CONFIG_ARM=y
> +CONFIG_OMAP54XX=y
> +CONFIG_TI_SECURE_DEVICE=y
> +CONFIG_TARGET_DRA7XX_EVM=y
> +CONFIG_DM_SERIAL=y
> +CONFIG_DM_SPI=y
> +CONFIG_DM_SPI_FLASH=y
> +CONFIG_DM_GPIO=y
> +CONFIG_SPL_STACK_R_ADDR=0x82000000
> +CONFIG_DEFAULT_DEVICE_TREE="dra7-evm"
> +CONFIG_SPL=y
> +CONFIG_SPL_STACK_R=y
> +# CONFIG_CMD_IMLS is not set
> +# CONFIG_CMD_FLASH is not set
> +CONFIG_CMD_GPIO=y
> +# CONFIG_CMD_SETEXPR is not set
> +CONFIG_OF_CONTROL=y
> +CONFIG_DM=y
> +CONFIG_SPI_FLASH=y
> +CONFIG_SPI_FLASH_BAR=y
> +CONFIG_SPI_FLASH_SPANSION=y
> +CONFIG_SYS_NS16550=y
> +CONFIG_TI_QSPI=y
> +CONFIG_TIMER=y
> +CONFIG_OMAP_TIMER=y
> +CONFIG_USB=y
> +CONFIG_USB_GADGET=y
> 

[U-Boot] [PATCH 16/16] defconfig: ti: Add configs for OMAP5-class secure parts

[Andreas Dannenberg]

On Mon, Apr 11, 2016 at 06:37:18PM -0500, Daniel Allred wrote:
> Adds new defconfig files for DRA7xx and AM57xx secure devices.
> These are the same as the non-secure parts, but with the addition
> of the CONFIG_TI_SECURE_DEVICE option set to 'y'.
> 
> Signed-off-by: Daniel Allred <d-allred@ti.com>
> Signed-off-by: Madan Srinivas <madans@ti.com>


Successfully boot-tested the respective defconfig-based U-Boot builds on
actual DRA72x HS and DRA74x HS hardware.

Tested-by: Andreas Dannenberg <dannenberg@ti.com>

--
Andreas Dannenberg
Texas Instruments Inc

[U-Boot] [PATCH 16/16] defconfig: ti: Add configs for OMAP5-class secure parts

[Tom Rini]

On Mon, Apr 11, 2016 at 06:37:18PM -0500, Daniel Allred wrote:

> Adds new defconfig files for DRA7xx and AM57xx secure devices.
> These are the same as the non-secure parts, but with the addition
> of the CONFIG_TI_SECURE_DEVICE option set to 'y'.
> 
> Signed-off-by: Daniel Allred <d-allred@ti.com>
> Signed-off-by: Madan Srinivas <madans@ti.com>

Reviewed-by: Tom Rini <trini@konsulko.com>

-- 
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/20160421/3dc205a2/attachment.sig>