[U-Boot] [PATCH 00/13] Cleanups to allow secure boot on AM33xx devices

[U-Boot] [PATCH 00/13] Cleanups to allow secure boot on AM33xx devices

[Andrew F. Davis]

Hello all,

I've recently been tasked with enabling authenticated boot for AM33xx based
devices. This work is similar to what has already been done for the AM43xx
and AM57xx SoCs and leverages much of the infrastructure from them.

The big difference here is the size of SRAM available on AM33xx being much
less than on the other SoCs, when performing a secure boot this limits
the maximum size of the SPL to just ~41k, the SPL currently generated for
AM33xx SoCs is ~70k. To trim down the SPL we move various options from
the config headers to the Kconfig system so we can selectively disable
them in HS specific defconfigs.

To do this we start in patch 1 and 2 by creating Kconfig options for
specifying what for what media the SPL should be able to load U-Boot
from and for what media the SPL should itself be loaded from, respectively.
We do this as the secure signature contains the name of the SPL boot
media, and to reduce size. Also this works to reduce confusion
in build types vs load types, we fix such an issue in patch 8.

In patch 3 and 4 we use the newly added _SUPPORT Kconfigs on a couple
boards.

The rest are hopefully explained well enough in the commit message.

Thanks,
Andrew

Andrew F. Davis (13):
  spl: Kconfig: Add SPL_<media>_SUPPORT as Kconfig option
  spl: Kconfig: Add SPL_<media>_BOOT as Kconfig option
  spl: Kconfig: Add CONFIG_SPL_TEXT_BASE as Kconfig option
  config: am335x_evm: Move CONFIG_SPL_YMODEM_SUPPORT to Kconfig
  config: am43xx_evm: Move CONFIG_SPL_YMODEM_SUPPORT to Kconfig
  Kconfig: Separate AM33XX SOC config from target board config
  am33xx: config.mk: Add support for additional secure boot image types
  am33xx: config.mk: Fix option used to enable SPI SPL image type
  doc: Update info on using AM33xx secure devices from TI
  ti: omap-common: Allow AM33xx devices to be built securely
  omap: Use SD_BOOT in place of EMMC_BOOT
  config: Remove usage of CONFIG_STORAGE_EMMC
  board: am33xx-hs: spl: Allow post-processing of FIT image on AM33xx

 Kconfig                                   |  8 ++++
 arch/arm/Kconfig                          | 20 ++++----
 arch/arm/cpu/armv7/am33xx/Kconfig         | 18 ++++++++
 arch/arm/cpu/armv7/am33xx/config.mk       | 29 ++++++++++--
 arch/arm/cpu/armv7/omap-common/Kconfig    |  2 +-
 board/ti/am335x/board.c                   |  8 ++++
 board/ti/am335x/mux.c                     |  4 +-
 common/Kconfig                            | 76 +++++++++++++++++++++++++++++++
 common/spl/Kconfig                        | 54 ++++++++++++++++++++++
 configs/am335x_boneblack_defconfig        |  4 +-
 configs/am335x_boneblack_vboot_defconfig  |  5 +-
 configs/am335x_evm_defconfig              |  3 ++
 configs/am335x_evm_nor_defconfig          |  2 +
 configs/am335x_evm_norboot_defconfig      |  1 +
 configs/am335x_evm_spiboot_defconfig      |  2 +
 configs/am335x_evm_usbspl_defconfig       |  1 +
 configs/am335x_sl50_defconfig             |  2 +-
 configs/am43xx_evm_defconfig              |  1 +
 configs/am43xx_evm_ethboot_defconfig      |  1 +
 configs/am43xx_evm_qspiboot_defconfig     |  1 +
 configs/am43xx_evm_usbhost_boot_defconfig |  1 +
 configs/am43xx_hs_evm_defconfig           |  1 +
 configs/brppt1_mmc_defconfig              |  3 +-
 configs/brppt1_spi_defconfig              |  3 +-
 doc/README.ti-secure                      | 32 +++++++++++++
 include/configs/am335x_evm.h              |  6 +--
 include/configs/am335x_shc.h              |  2 -
 include/configs/am335x_sl50.h             |  4 +-
 include/configs/am43xx_evm.h              |  1 -
 include/configs/bav335x.h                 |  4 +-
 include/configs/brppt1.h                  |  6 +--
 include/configs/ti_am335x_common.h        |  4 ++
 32 files changed, 272 insertions(+), 37 deletions(-)
 create mode 100644 common/spl/Kconfig

-- 
2.9.2

[U-Boot] [PATCH 01/13] spl: Kconfig: Add SPL_<media>_SUPPORT as Kconfig option

[Andrew F. Davis]

Create a new Kconfig file to contain SPL boot media loading support
options as we begin moving these to the Kconfig system and out of header
files. Initially add new configs for all the existing boot media types,
giving them the same definition name as before to allow compatibility
with systems not yet using Kconfig.

Signed-off-by: Andrew F. Davis <afd@ti.com>
---
 common/Kconfig     |  7 +++++++
 common/spl/Kconfig | 54 ++++++++++++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 61 insertions(+)
 create mode 100644 common/spl/Kconfig

diff --git a/common/Kconfig b/common/Kconfig
index 46e7173..f594db5 100644
--- a/common/Kconfig
+++ b/common/Kconfig
@@ -156,6 +156,13 @@ config SPI_BOOT
 	  booted via SPI flash. This is not a must, some SoCs need this,
 	  somes not.
 
+menu "SPL Media Loading Support"
+	depends on SPL
+
+source "common/spl/Kconfig"
+
+endmenu
+
 endmenu
 
 config BOOTDELAY
diff --git a/common/spl/Kconfig b/common/spl/Kconfig
new file mode 100644
index 0000000..788ca14
--- /dev/null
+++ b/common/spl/Kconfig
@@ -0,0 +1,54 @@
+config SPL_YMODEM_SUPPORT
+	depends on SPL
+	bool "SPL Support for loading next stage from UART"
+	help
+	  This option enables SPL to load the next stage bootloader
+	  over a UART line using the x/y/z/modem protocol.
+
+config SPL_MMC_SUPPORT
+	bool "SPL Support for loading next stage from SD/MMC/eMMC"
+	help
+	  This option enables SPL to load the next stage bootloader
+	  from an SD/MMC/eMMC device.
+
+config SPL_SPI_SUPPORT
+	bool "SPL Support for loading next stage from SPI flash"
+	help
+	  This option enables SPL to load the next stage bootloader
+	  from SPI flash.
+
+config SPL_USB_SUPPORT
+	bool "SPL Support for loading next stage from USB"
+	help
+	  This option enables SPL to load the next stage bootloader
+	  from a USB device.
+
+config SPL_SATA_SUPPORT
+	bool "SPL Support for loading next stage from SATA"
+	help
+	  This option enables SPL to load the next stage bootloader
+	  from a SATA device.
+
+config SPL_NOR_SUPPORT
+	bool "SPL Support for loading next stage from NOR flash"
+	help
+	  This option enables SPL to load the next stage bootloader
+	  from NOR flash.
+
+config SPL_NAND_SUPPORT
+	bool "SPL Support for loading next stage from NAND flash"
+	help
+	  This option enables SPL to load the next stage bootloader
+	  from NAND flash.
+
+config SPL_ONENAND_SUPPORT
+	bool "SPL Support for loading next stage from ONENAND"
+	help
+	  This option enables SPL to load the next stage bootloader
+	  from ONENAND.
+
+config SPL_NET_SUPPORT
+	bool "SPL Support for loading next stage from NET"
+	help
+	  This option enables SPL to load the next stage bootloader
+	  from NET.
-- 
2.9.2

[U-Boot] [PATCH 01/13] spl: Kconfig: Add SPL_<media>_SUPPORT as Kconfig option

[Heiko Schocher]

Hello Andrew,

first thanks for this series!

Am 18.08.2016 um 17:41 schrieb Andrew F. Davis:
> Create a new Kconfig file to contain SPL boot media loading support
> options as we begin moving these to the Kconfig system and out of header
> files. Initially add new configs for all the existing boot media types,
> giving them the same definition name as before to allow compatibility
> with systems not yet using Kconfig.
>
> Signed-off-by: Andrew F. Davis <afd@ti.com>
> ---
>   common/Kconfig     |  7 +++++++
>   common/spl/Kconfig | 54 ++++++++++++++++++++++++++++++++++++++++++++++++++++++
>   2 files changed, 61 insertions(+)
>   create mode 100644 common/spl/Kconfig
>
> diff --git a/common/Kconfig b/common/Kconfig
> index 46e7173..f594db5 100644
> --- a/common/Kconfig
> +++ b/common/Kconfig
> @@ -156,6 +156,13 @@ config SPI_BOOT
>   	  booted via SPI flash. This is not a must, some SoCs need this,
>   	  somes not.
>
> +menu "SPL Media Loading Support"
> +	depends on SPL
> +
> +source "common/spl/Kconfig"
> +
> +endmenu
> +
>   endmenu
>
>   config BOOTDELAY
> diff --git a/common/spl/Kconfig b/common/spl/Kconfig
> new file mode 100644
> index 0000000..788ca14
> --- /dev/null
> +++ b/common/spl/Kconfig
> @@ -0,0 +1,54 @@
> +config SPL_YMODEM_SUPPORT
> +	depends on SPL
> +	bool "SPL Support for loading next stage from UART"
> +	help
> +	  This option enables SPL to load the next stage bootloader
> +	  over a UART line using the x/y/z/modem protocol.
> +
> +config SPL_MMC_SUPPORT
> +	bool "SPL Support for loading next stage from SD/MMC/eMMC"
> +	help
> +	  This option enables SPL to load the next stage bootloader
> +	  from an SD/MMC/eMMC device.

Hmm.. why do you not move, for existing board configs, which use
this symbols, them into their defconfigs? There is the great
script from Masahiro

u-boot:tools/moveconfig.py

which should do the most things for you ... also there is a tbot
testcase, with which you can test, that your new patch(es) do not
break an existing board, see for interests:

http://lists.denx.de/pipermail/u-boot/2016-June/258119.html

Same comment applies for your patches:
[U-Boot] [PATCH 02/13] spl: Kconfig: Add SPL_<media>_BOOT as Kconfig option
[U-Boot] [PATCH 03/13] spl: Kconfig: Add CONFIG_SPL_TEXT_BASE as Kconfig option

May you want to try it? If you have problems, feel free to contact me.

bye,
Heiko

> +
> +config SPL_SPI_SUPPORT
> +	bool "SPL Support for loading next stage from SPI flash"
> +	help
> +	  This option enables SPL to load the next stage bootloader
> +	  from SPI flash.
> +
> +config SPL_USB_SUPPORT
> +	bool "SPL Support for loading next stage from USB"
> +	help
> +	  This option enables SPL to load the next stage bootloader
> +	  from a USB device.
> +
> +config SPL_SATA_SUPPORT
> +	bool "SPL Support for loading next stage from SATA"
> +	help
> +	  This option enables SPL to load the next stage bootloader
> +	  from a SATA device.
> +
> +config SPL_NOR_SUPPORT
> +	bool "SPL Support for loading next stage from NOR flash"
> +	help
> +	  This option enables SPL to load the next stage bootloader
> +	  from NOR flash.
> +
> +config SPL_NAND_SUPPORT
> +	bool "SPL Support for loading next stage from NAND flash"
> +	help
> +	  This option enables SPL to load the next stage bootloader
> +	  from NAND flash.
> +
> +config SPL_ONENAND_SUPPORT
> +	bool "SPL Support for loading next stage from ONENAND"
> +	help
> +	  This option enables SPL to load the next stage bootloader
> +	  from ONENAND.
> +
> +config SPL_NET_SUPPORT
> +	bool "SPL Support for loading next stage from NET"
> +	help
> +	  This option enables SPL to load the next stage bootloader
> +	  from NET.
>

-- 
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany

[U-Boot] [PATCH 01/13] spl: Kconfig: Add SPL_<media>_SUPPORT as Kconfig option

[Andrew F. Davis]

On 08/19/2016 01:27 AM, Heiko Schocher wrote:
> Hello Andrew,
> 
> first thanks for this series!
> 
> Am 18.08.2016 um 17:41 schrieb Andrew F. Davis:
>> Create a new Kconfig file to contain SPL boot media loading support
>> options as we begin moving these to the Kconfig system and out of header
>> files. Initially add new configs for all the existing boot media types,
>> giving them the same definition name as before to allow compatibility
>> with systems not yet using Kconfig.
>>
>> Signed-off-by: Andrew F. Davis <afd@ti.com>
>> ---
>>   common/Kconfig     |  7 +++++++
>>   common/spl/Kconfig | 54
>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++
>>   2 files changed, 61 insertions(+)
>>   create mode 100644 common/spl/Kconfig
>>
>> diff --git a/common/Kconfig b/common/Kconfig
>> index 46e7173..f594db5 100644
>> --- a/common/Kconfig
>> +++ b/common/Kconfig
>> @@ -156,6 +156,13 @@ config SPI_BOOT
>>         booted via SPI flash. This is not a must, some SoCs need this,
>>         somes not.
>>
>> +menu "SPL Media Loading Support"
>> +    depends on SPL
>> +
>> +source "common/spl/Kconfig"
>> +
>> +endmenu
>> +
>>   endmenu
>>
>>   config BOOTDELAY
>> diff --git a/common/spl/Kconfig b/common/spl/Kconfig
>> new file mode 100644
>> index 0000000..788ca14
>> --- /dev/null
>> +++ b/common/spl/Kconfig
>> @@ -0,0 +1,54 @@
>> +config SPL_YMODEM_SUPPORT
>> +    depends on SPL
>> +    bool "SPL Support for loading next stage from UART"
>> +    help
>> +      This option enables SPL to load the next stage bootloader
>> +      over a UART line using the x/y/z/modem protocol.
>> +
>> +config SPL_MMC_SUPPORT
>> +    bool "SPL Support for loading next stage from SD/MMC/eMMC"
>> +    help
>> +      This option enables SPL to load the next stage bootloader
>> +      from an SD/MMC/eMMC device.
> 
> Hmm.. why do you not move, for existing board configs, which use
> this symbols, them into their defconfigs? There is the great
> script from Masahiro
> 
> u-boot:tools/moveconfig.py
> 
> which should do the most things for you ... 

Maybe I'm not understanding this script but after getting it to run it
doesn't seem to find any uses of the config, I'm not sure this works
with SPL configs, as the check looks only at the non-SPL build case as
far as I can tell.

There is also the more complex cases where _SUPPORT option are only
defined in the config.h files when some other option is defined, this
conditional dependency will need to be translated in each defconfig file.

Thanks,
Andrew

> also there is a tbot
> testcase, with which you can test, that your new patch(es) do not
> break an existing board, see for interests:
> 
> http://lists.denx.de/pipermail/u-boot/2016-June/258119.html
> 
> Same comment applies for your patches:
> [U-Boot] [PATCH 02/13] spl: Kconfig: Add SPL_<media>_BOOT as Kconfig option
> [U-Boot] [PATCH 03/13] spl: Kconfig: Add CONFIG_SPL_TEXT_BASE as Kconfig
> option
> 
> May you want to try it? If you have problems, feel free to contact me.
> 
> bye,
> Heiko
> 
>> +
>> +config SPL_SPI_SUPPORT
>> +    bool "SPL Support for loading next stage from SPI flash"
>> +    help
>> +      This option enables SPL to load the next stage bootloader
>> +      from SPI flash.
>> +
>> +config SPL_USB_SUPPORT
>> +    bool "SPL Support for loading next stage from USB"
>> +    help
>> +      This option enables SPL to load the next stage bootloader
>> +      from a USB device.
>> +
>> +config SPL_SATA_SUPPORT
>> +    bool "SPL Support for loading next stage from SATA"
>> +    help
>> +      This option enables SPL to load the next stage bootloader
>> +      from a SATA device.
>> +
>> +config SPL_NOR_SUPPORT
>> +    bool "SPL Support for loading next stage from NOR flash"
>> +    help
>> +      This option enables SPL to load the next stage bootloader
>> +      from NOR flash.
>> +
>> +config SPL_NAND_SUPPORT
>> +    bool "SPL Support for loading next stage from NAND flash"
>> +    help
>> +      This option enables SPL to load the next stage bootloader
>> +      from NAND flash.
>> +
>> +config SPL_ONENAND_SUPPORT
>> +    bool "SPL Support for loading next stage from ONENAND"
>> +    help
>> +      This option enables SPL to load the next stage bootloader
>> +      from ONENAND.
>> +
>> +config SPL_NET_SUPPORT
>> +    bool "SPL Support for loading next stage from NET"
>> +    help
>> +      This option enables SPL to load the next stage bootloader
>> +      from NET.
>>
> 

[U-Boot] [PATCH 01/13] spl: Kconfig: Add SPL_<media>_SUPPORT as Kconfig option

[Tom Rini]

On Fri, Aug 19, 2016 at 02:30:56PM -0500, Andrew F. Davis wrote:
> On 08/19/2016 01:27 AM, Heiko Schocher wrote:
> > Hello Andrew,
> > 
> > first thanks for this series!
> > 
> > Am 18.08.2016 um 17:41 schrieb Andrew F. Davis:
> >> Create a new Kconfig file to contain SPL boot media loading support
> >> options as we begin moving these to the Kconfig system and out of header
> >> files. Initially add new configs for all the existing boot media types,
> >> giving them the same definition name as before to allow compatibility
> >> with systems not yet using Kconfig.
> >>
> >> Signed-off-by: Andrew F. Davis <afd@ti.com>
> >> ---
> >>   common/Kconfig     |  7 +++++++
> >>   common/spl/Kconfig | 54
> >> ++++++++++++++++++++++++++++++++++++++++++++++++++++++
> >>   2 files changed, 61 insertions(+)
> >>   create mode 100644 common/spl/Kconfig
> >>
> >> diff --git a/common/Kconfig b/common/Kconfig
> >> index 46e7173..f594db5 100644
> >> --- a/common/Kconfig
> >> +++ b/common/Kconfig
> >> @@ -156,6 +156,13 @@ config SPI_BOOT
> >>         booted via SPI flash. This is not a must, some SoCs need this,
> >>         somes not.
> >>
> >> +menu "SPL Media Loading Support"
> >> +    depends on SPL
> >> +
> >> +source "common/spl/Kconfig"
> >> +
> >> +endmenu
> >> +
> >>   endmenu
> >>
> >>   config BOOTDELAY
> >> diff --git a/common/spl/Kconfig b/common/spl/Kconfig
> >> new file mode 100644
> >> index 0000000..788ca14
> >> --- /dev/null
> >> +++ b/common/spl/Kconfig
> >> @@ -0,0 +1,54 @@
> >> +config SPL_YMODEM_SUPPORT
> >> +    depends on SPL
> >> +    bool "SPL Support for loading next stage from UART"
> >> +    help
> >> +      This option enables SPL to load the next stage bootloader
> >> +      over a UART line using the x/y/z/modem protocol.
> >> +
> >> +config SPL_MMC_SUPPORT
> >> +    bool "SPL Support for loading next stage from SD/MMC/eMMC"
> >> +    help
> >> +      This option enables SPL to load the next stage bootloader
> >> +      from an SD/MMC/eMMC device.
> > 
> > Hmm.. why do you not move, for existing board configs, which use
> > this symbols, them into their defconfigs? There is the great
> > script from Masahiro
> > 
> > u-boot:tools/moveconfig.py
> > 
> > which should do the most things for you ... 
> 
> Maybe I'm not understanding this script but after getting it to run it
> doesn't seem to find any uses of the config, I'm not sure this works
> with SPL configs, as the check looks only at the non-SPL build case as
> far as I can tell.

Hmm, Masahiro?  Can we support SPL related migrations easily?  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/20160819/9ab5877d/attachment.sig>

[U-Boot] [PATCH 01/13] spl: Kconfig: Add SPL_<media>_SUPPORT as Kconfig option

[Andrew F. Davis]

On 08/19/2016 02:54 PM, Tom Rini wrote:
> On Fri, Aug 19, 2016 at 02:30:56PM -0500, Andrew F. Davis wrote:
>> On 08/19/2016 01:27 AM, Heiko Schocher wrote:
>>> Hello Andrew,
>>>
>>> first thanks for this series!
>>>
>>> Am 18.08.2016 um 17:41 schrieb Andrew F. Davis:
>>>> Create a new Kconfig file to contain SPL boot media loading support
>>>> options as we begin moving these to the Kconfig system and out of header
>>>> files. Initially add new configs for all the existing boot media types,
>>>> giving them the same definition name as before to allow compatibility
>>>> with systems not yet using Kconfig.
>>>>
>>>> Signed-off-by: Andrew F. Davis <afd@ti.com>
>>>> ---
>>>>   common/Kconfig     |  7 +++++++
>>>>   common/spl/Kconfig | 54
>>>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++
>>>>   2 files changed, 61 insertions(+)
>>>>   create mode 100644 common/spl/Kconfig
>>>>
>>>> diff --git a/common/Kconfig b/common/Kconfig
>>>> index 46e7173..f594db5 100644
>>>> --- a/common/Kconfig
>>>> +++ b/common/Kconfig
>>>> @@ -156,6 +156,13 @@ config SPI_BOOT
>>>>         booted via SPI flash. This is not a must, some SoCs need this,
>>>>         somes not.
>>>>
>>>> +menu "SPL Media Loading Support"
>>>> +    depends on SPL
>>>> +
>>>> +source "common/spl/Kconfig"
>>>> +
>>>> +endmenu
>>>> +
>>>>   endmenu
>>>>
>>>>   config BOOTDELAY
>>>> diff --git a/common/spl/Kconfig b/common/spl/Kconfig
>>>> new file mode 100644
>>>> index 0000000..788ca14
>>>> --- /dev/null
>>>> +++ b/common/spl/Kconfig
>>>> @@ -0,0 +1,54 @@
>>>> +config SPL_YMODEM_SUPPORT
>>>> +    depends on SPL
>>>> +    bool "SPL Support for loading next stage from UART"
>>>> +    help
>>>> +      This option enables SPL to load the next stage bootloader
>>>> +      over a UART line using the x/y/z/modem protocol.
>>>> +
>>>> +config SPL_MMC_SUPPORT
>>>> +    bool "SPL Support for loading next stage from SD/MMC/eMMC"
>>>> +    help
>>>> +      This option enables SPL to load the next stage bootloader
>>>> +      from an SD/MMC/eMMC device.
>>>
>>> Hmm.. why do you not move, for existing board configs, which use
>>> this symbols, them into their defconfigs? There is the great
>>> script from Masahiro
>>>
>>> u-boot:tools/moveconfig.py
>>>
>>> which should do the most things for you ... 
>>
>> Maybe I'm not understanding this script but after getting it to run it
>> doesn't seem to find any uses of the config, I'm not sure this works
>> with SPL configs, as the check looks only at the non-SPL build case as
>> far as I can tell.
> 
> Hmm, Masahiro?  Can we support SPL related migrations easily?  Thanks!
> 

Well a quick workaround I used was to add -DCONFIG_SPL_BUILD to the main
Makefile, this way it will pick up SPL_ defines that are blocked of by
conditionals for CONFIG_SPL_BUILD.

Anyway the bigger problem is that some boards conditionally define an
option based on what other configs are enabled, we don't have this kind
of thing in Kconfig, at least not at the board level as far as I know.
(Select could work, but it would end up with a lot of conditionals per
board supported)

Thanks,
Andrew

[U-Boot] [PATCH 01/13] spl: Kconfig: Add SPL_<media>_SUPPORT as Kconfig option

[Tom Rini]

On Sun, Aug 21, 2016 at 01:35:48PM -0500, Andrew F. Davis wrote:
> On 08/19/2016 02:54 PM, Tom Rini wrote:
> > On Fri, Aug 19, 2016 at 02:30:56PM -0500, Andrew F. Davis wrote:
> >> On 08/19/2016 01:27 AM, Heiko Schocher wrote:
> >>> Hello Andrew,
> >>>
> >>> first thanks for this series!
> >>>
> >>> Am 18.08.2016 um 17:41 schrieb Andrew F. Davis:
> >>>> Create a new Kconfig file to contain SPL boot media loading support
> >>>> options as we begin moving these to the Kconfig system and out of header
> >>>> files. Initially add new configs for all the existing boot media types,
> >>>> giving them the same definition name as before to allow compatibility
> >>>> with systems not yet using Kconfig.
> >>>>
> >>>> Signed-off-by: Andrew F. Davis <afd@ti.com>
> >>>> ---
> >>>>   common/Kconfig     |  7 +++++++
> >>>>   common/spl/Kconfig | 54
> >>>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++
> >>>>   2 files changed, 61 insertions(+)
> >>>>   create mode 100644 common/spl/Kconfig
> >>>>
> >>>> diff --git a/common/Kconfig b/common/Kconfig
> >>>> index 46e7173..f594db5 100644
> >>>> --- a/common/Kconfig
> >>>> +++ b/common/Kconfig
> >>>> @@ -156,6 +156,13 @@ config SPI_BOOT
> >>>>         booted via SPI flash. This is not a must, some SoCs need this,
> >>>>         somes not.
> >>>>
> >>>> +menu "SPL Media Loading Support"
> >>>> +    depends on SPL
> >>>> +
> >>>> +source "common/spl/Kconfig"
> >>>> +
> >>>> +endmenu
> >>>> +
> >>>>   endmenu
> >>>>
> >>>>   config BOOTDELAY
> >>>> diff --git a/common/spl/Kconfig b/common/spl/Kconfig
> >>>> new file mode 100644
> >>>> index 0000000..788ca14
> >>>> --- /dev/null
> >>>> +++ b/common/spl/Kconfig
> >>>> @@ -0,0 +1,54 @@
> >>>> +config SPL_YMODEM_SUPPORT
> >>>> +    depends on SPL
> >>>> +    bool "SPL Support for loading next stage from UART"
> >>>> +    help
> >>>> +      This option enables SPL to load the next stage bootloader
> >>>> +      over a UART line using the x/y/z/modem protocol.
> >>>> +
> >>>> +config SPL_MMC_SUPPORT
> >>>> +    bool "SPL Support for loading next stage from SD/MMC/eMMC"
> >>>> +    help
> >>>> +      This option enables SPL to load the next stage bootloader
> >>>> +      from an SD/MMC/eMMC device.
> >>>
> >>> Hmm.. why do you not move, for existing board configs, which use
> >>> this symbols, them into their defconfigs? There is the great
> >>> script from Masahiro
> >>>
> >>> u-boot:tools/moveconfig.py
> >>>
> >>> which should do the most things for you ... 
> >>
> >> Maybe I'm not understanding this script but after getting it to run it
> >> doesn't seem to find any uses of the config, I'm not sure this works
> >> with SPL configs, as the check looks only at the non-SPL build case as
> >> far as I can tell.
> > 
> > Hmm, Masahiro?  Can we support SPL related migrations easily?  Thanks!
> > 
> 
> Well a quick workaround I used was to add -DCONFIG_SPL_BUILD to the main
> Makefile, this way it will pick up SPL_ defines that are blocked of by
> conditionals for CONFIG_SPL_BUILD.
> 
> Anyway the bigger problem is that some boards conditionally define an
> option based on what other configs are enabled, we don't have this kind
> of thing in Kconfig, at least not at the board level as far as I know.
> (Select could work, but it would end up with a lot of conditionals per
> board supported)

I think the problem is that we have some "soft" dependencies here.  ie I
think that when I was making am335x_evm.h work for all of the various
possible board and feature combos that were desired I took some
short-cuts to say that A means lets grab B and C.  I think it's
perfectly reasonable that in moving to Kconfig we start out by getting
everything into Kconfig and worry about getting all of the select /
depends statements right as the second step.  So the defconfigs might
start out a bit fuller and we'll get options removed from them as the
Kconfig logic improves.

-- 
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/20160821/1bfbfd8e/attachment.sig>

[U-Boot] [PATCH 01/13] spl: Kconfig: Add SPL_<media>_SUPPORT as Kconfig option

[Andrew F. Davis]

On 08/21/2016 01:50 PM, Tom Rini wrote:
> On Sun, Aug 21, 2016 at 01:35:48PM -0500, Andrew F. Davis wrote:
>> On 08/19/2016 02:54 PM, Tom Rini wrote:
>>> On Fri, Aug 19, 2016 at 02:30:56PM -0500, Andrew F. Davis wrote:
>>>> On 08/19/2016 01:27 AM, Heiko Schocher wrote:
>>>>> Hello Andrew,
>>>>>
>>>>> first thanks for this series!
>>>>>
>>>>> Am 18.08.2016 um 17:41 schrieb Andrew F. Davis:
>>>>>> Create a new Kconfig file to contain SPL boot media loading support
>>>>>> options as we begin moving these to the Kconfig system and out of header
>>>>>> files. Initially add new configs for all the existing boot media types,
>>>>>> giving them the same definition name as before to allow compatibility
>>>>>> with systems not yet using Kconfig.
>>>>>>
>>>>>> Signed-off-by: Andrew F. Davis <afd@ti.com>
>>>>>> ---
>>>>>>   common/Kconfig     |  7 +++++++
>>>>>>   common/spl/Kconfig | 54
>>>>>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++
>>>>>>   2 files changed, 61 insertions(+)
>>>>>>   create mode 100644 common/spl/Kconfig
>>>>>>
>>>>>> diff --git a/common/Kconfig b/common/Kconfig
>>>>>> index 46e7173..f594db5 100644
>>>>>> --- a/common/Kconfig
>>>>>> +++ b/common/Kconfig
>>>>>> @@ -156,6 +156,13 @@ config SPI_BOOT
>>>>>>         booted via SPI flash. This is not a must, some SoCs need this,
>>>>>>         somes not.
>>>>>>
>>>>>> +menu "SPL Media Loading Support"
>>>>>> +    depends on SPL
>>>>>> +
>>>>>> +source "common/spl/Kconfig"
>>>>>> +
>>>>>> +endmenu
>>>>>> +
>>>>>>   endmenu
>>>>>>
>>>>>>   config BOOTDELAY
>>>>>> diff --git a/common/spl/Kconfig b/common/spl/Kconfig
>>>>>> new file mode 100644
>>>>>> index 0000000..788ca14
>>>>>> --- /dev/null
>>>>>> +++ b/common/spl/Kconfig
>>>>>> @@ -0,0 +1,54 @@
>>>>>> +config SPL_YMODEM_SUPPORT
>>>>>> +    depends on SPL
>>>>>> +    bool "SPL Support for loading next stage from UART"
>>>>>> +    help
>>>>>> +      This option enables SPL to load the next stage bootloader
>>>>>> +      over a UART line using the x/y/z/modem protocol.
>>>>>> +
>>>>>> +config SPL_MMC_SUPPORT
>>>>>> +    bool "SPL Support for loading next stage from SD/MMC/eMMC"
>>>>>> +    help
>>>>>> +      This option enables SPL to load the next stage bootloader
>>>>>> +      from an SD/MMC/eMMC device.
>>>>>
>>>>> Hmm.. why do you not move, for existing board configs, which use
>>>>> this symbols, them into their defconfigs? There is the great
>>>>> script from Masahiro
>>>>>
>>>>> u-boot:tools/moveconfig.py
>>>>>
>>>>> which should do the most things for you ... 
>>>>
>>>> Maybe I'm not understanding this script but after getting it to run it
>>>> doesn't seem to find any uses of the config, I'm not sure this works
>>>> with SPL configs, as the check looks only at the non-SPL build case as
>>>> far as I can tell.
>>>
>>> Hmm, Masahiro?  Can we support SPL related migrations easily?  Thanks!
>>>
>>
>> Well a quick workaround I used was to add -DCONFIG_SPL_BUILD to the main
>> Makefile, this way it will pick up SPL_ defines that are blocked of by
>> conditionals for CONFIG_SPL_BUILD.
>>
>> Anyway the bigger problem is that some boards conditionally define an
>> option based on what other configs are enabled, we don't have this kind
>> of thing in Kconfig, at least not at the board level as far as I know.
>> (Select could work, but it would end up with a lot of conditionals per
>> board supported)
> 
> I think the problem is that we have some "soft" dependencies here.  ie I
> think that when I was making am335x_evm.h work for all of the various
> possible board and feature combos that were desired I took some
> short-cuts to say that A means lets grab B and C.  I think it's
> perfectly reasonable that in moving to Kconfig we start out by getting
> everything into Kconfig and worry about getting all of the select /
> depends statements right as the second step.  So the defconfigs might
> start out a bit fuller and we'll get options removed from them as the
> Kconfig logic improves.
> 

If this is okay then I'll post a series with all these cleanups and the
config options moved. I believe they don't now make any changes to the
build output of any board (at lease according to buildman).

The patch for moving SPL_TEXT_BASE will probably have to be dropped as
it breaks a couple old powerpc boards for some strange reason (they look
like they depend on SPL_TEXT_BASE being unset, and giving it even a
default value breaks build for them) and I don't have any time to look
into how the build works on those. So I will depend on the
ISW_ENTRY_ADDR as a hacky work-around config option for setting an SPL
address in Kconfig like we do in AM43xx boards for now.

Thanks,
Andrew

[U-Boot] [PATCH 01/13] spl: Kconfig: Add SPL_<media>_SUPPORT as Kconfig option

[Tom Rini]

On Sun, Aug 21, 2016 at 02:12:03PM -0500, Andrew F. Davis wrote:
> On 08/21/2016 01:50 PM, Tom Rini wrote:
> > On Sun, Aug 21, 2016 at 01:35:48PM -0500, Andrew F. Davis wrote:
> >> On 08/19/2016 02:54 PM, Tom Rini wrote:
> >>> On Fri, Aug 19, 2016 at 02:30:56PM -0500, Andrew F. Davis wrote:
> >>>> On 08/19/2016 01:27 AM, Heiko Schocher wrote:
> >>>>> Hello Andrew,
> >>>>>
> >>>>> first thanks for this series!
> >>>>>
> >>>>> Am 18.08.2016 um 17:41 schrieb Andrew F. Davis:
> >>>>>> Create a new Kconfig file to contain SPL boot media loading support
> >>>>>> options as we begin moving these to the Kconfig system and out of header
> >>>>>> files. Initially add new configs for all the existing boot media types,
> >>>>>> giving them the same definition name as before to allow compatibility
> >>>>>> with systems not yet using Kconfig.
> >>>>>>
> >>>>>> Signed-off-by: Andrew F. Davis <afd@ti.com>
> >>>>>> ---
> >>>>>>   common/Kconfig     |  7 +++++++
> >>>>>>   common/spl/Kconfig | 54
> >>>>>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++
> >>>>>>   2 files changed, 61 insertions(+)
> >>>>>>   create mode 100644 common/spl/Kconfig
> >>>>>>
> >>>>>> diff --git a/common/Kconfig b/common/Kconfig
> >>>>>> index 46e7173..f594db5 100644
> >>>>>> --- a/common/Kconfig
> >>>>>> +++ b/common/Kconfig
> >>>>>> @@ -156,6 +156,13 @@ config SPI_BOOT
> >>>>>>         booted via SPI flash. This is not a must, some SoCs need this,
> >>>>>>         somes not.
> >>>>>>
> >>>>>> +menu "SPL Media Loading Support"
> >>>>>> +    depends on SPL
> >>>>>> +
> >>>>>> +source "common/spl/Kconfig"
> >>>>>> +
> >>>>>> +endmenu
> >>>>>> +
> >>>>>>   endmenu
> >>>>>>
> >>>>>>   config BOOTDELAY
> >>>>>> diff --git a/common/spl/Kconfig b/common/spl/Kconfig
> >>>>>> new file mode 100644
> >>>>>> index 0000000..788ca14
> >>>>>> --- /dev/null
> >>>>>> +++ b/common/spl/Kconfig
> >>>>>> @@ -0,0 +1,54 @@
> >>>>>> +config SPL_YMODEM_SUPPORT
> >>>>>> +    depends on SPL
> >>>>>> +    bool "SPL Support for loading next stage from UART"
> >>>>>> +    help
> >>>>>> +      This option enables SPL to load the next stage bootloader
> >>>>>> +      over a UART line using the x/y/z/modem protocol.
> >>>>>> +
> >>>>>> +config SPL_MMC_SUPPORT
> >>>>>> +    bool "SPL Support for loading next stage from SD/MMC/eMMC"
> >>>>>> +    help
> >>>>>> +      This option enables SPL to load the next stage bootloader
> >>>>>> +      from an SD/MMC/eMMC device.
> >>>>>
> >>>>> Hmm.. why do you not move, for existing board configs, which use
> >>>>> this symbols, them into their defconfigs? There is the great
> >>>>> script from Masahiro
> >>>>>
> >>>>> u-boot:tools/moveconfig.py
> >>>>>
> >>>>> which should do the most things for you ... 
> >>>>
> >>>> Maybe I'm not understanding this script but after getting it to run it
> >>>> doesn't seem to find any uses of the config, I'm not sure this works
> >>>> with SPL configs, as the check looks only at the non-SPL build case as
> >>>> far as I can tell.
> >>>
> >>> Hmm, Masahiro?  Can we support SPL related migrations easily?  Thanks!
> >>>
> >>
> >> Well a quick workaround I used was to add -DCONFIG_SPL_BUILD to the main
> >> Makefile, this way it will pick up SPL_ defines that are blocked of by
> >> conditionals for CONFIG_SPL_BUILD.
> >>
> >> Anyway the bigger problem is that some boards conditionally define an
> >> option based on what other configs are enabled, we don't have this kind
> >> of thing in Kconfig, at least not at the board level as far as I know.
> >> (Select could work, but it would end up with a lot of conditionals per
> >> board supported)
> > 
> > I think the problem is that we have some "soft" dependencies here.  ie I
> > think that when I was making am335x_evm.h work for all of the various
> > possible board and feature combos that were desired I took some
> > short-cuts to say that A means lets grab B and C.  I think it's
> > perfectly reasonable that in moving to Kconfig we start out by getting
> > everything into Kconfig and worry about getting all of the select /
> > depends statements right as the second step.  So the defconfigs might
> > start out a bit fuller and we'll get options removed from them as the
> > Kconfig logic improves.
> > 
> 
> If this is okay then I'll post a series with all these cleanups and the
> config options moved. I believe they don't now make any changes to the
> build output of any board (at lease according to buildman).

With sizechecks enabled?  You may way to look at the tbot test that
Heiko got setup after the last problematic Kconfig migration:
http://lists.denx.de/pipermail/u-boot/2016-June/258119.html

> The patch for moving SPL_TEXT_BASE will probably have to be dropped as
> it breaks a couple old powerpc boards for some strange reason (they look
> like they depend on SPL_TEXT_BASE being unset, and giving it even a
> default value breaks build for them) and I don't have any time to look
> into how the build works on those. So I will depend on the
> ISW_ENTRY_ADDR as a hacky work-around config option for setting an SPL
> address in Kconfig like we do in AM43xx boards for now.

OK. Can you do it as an RFC at the end of the series?  I'll try and take
a look at fixing that one up.  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/20160821/b5b297cb/attachment.sig>

[U-Boot] [PATCH 01/13] spl: Kconfig: Add SPL_<media>_SUPPORT as Kconfig option

[Andrew F. Davis]

On 08/21/2016 02:33 PM, Tom Rini wrote:
> On Sun, Aug 21, 2016 at 02:12:03PM -0500, Andrew F. Davis wrote:
>> On 08/21/2016 01:50 PM, Tom Rini wrote:
>>> On Sun, Aug 21, 2016 at 01:35:48PM -0500, Andrew F. Davis wrote:
>>>> On 08/19/2016 02:54 PM, Tom Rini wrote:
>>>>> On Fri, Aug 19, 2016 at 02:30:56PM -0500, Andrew F. Davis wrote:
>>>>>> On 08/19/2016 01:27 AM, Heiko Schocher wrote:
>>>>>>> Hello Andrew,
>>>>>>>
>>>>>>> first thanks for this series!
>>>>>>>
>>>>>>> Am 18.08.2016 um 17:41 schrieb Andrew F. Davis:
>>>>>>>> Create a new Kconfig file to contain SPL boot media loading support
>>>>>>>> options as we begin moving these to the Kconfig system and out of header
>>>>>>>> files. Initially add new configs for all the existing boot media types,
>>>>>>>> giving them the same definition name as before to allow compatibility
>>>>>>>> with systems not yet using Kconfig.
>>>>>>>>
>>>>>>>> Signed-off-by: Andrew F. Davis <afd@ti.com>
>>>>>>>> ---
>>>>>>>>   common/Kconfig     |  7 +++++++
>>>>>>>>   common/spl/Kconfig | 54
>>>>>>>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++
>>>>>>>>   2 files changed, 61 insertions(+)
>>>>>>>>   create mode 100644 common/spl/Kconfig
>>>>>>>>
>>>>>>>> diff --git a/common/Kconfig b/common/Kconfig
>>>>>>>> index 46e7173..f594db5 100644
>>>>>>>> --- a/common/Kconfig
>>>>>>>> +++ b/common/Kconfig
>>>>>>>> @@ -156,6 +156,13 @@ config SPI_BOOT
>>>>>>>>         booted via SPI flash. This is not a must, some SoCs need this,
>>>>>>>>         somes not.
>>>>>>>>
>>>>>>>> +menu "SPL Media Loading Support"
>>>>>>>> +    depends on SPL
>>>>>>>> +
>>>>>>>> +source "common/spl/Kconfig"
>>>>>>>> +
>>>>>>>> +endmenu
>>>>>>>> +
>>>>>>>>   endmenu
>>>>>>>>
>>>>>>>>   config BOOTDELAY
>>>>>>>> diff --git a/common/spl/Kconfig b/common/spl/Kconfig
>>>>>>>> new file mode 100644
>>>>>>>> index 0000000..788ca14
>>>>>>>> --- /dev/null
>>>>>>>> +++ b/common/spl/Kconfig
>>>>>>>> @@ -0,0 +1,54 @@
>>>>>>>> +config SPL_YMODEM_SUPPORT
>>>>>>>> +    depends on SPL
>>>>>>>> +    bool "SPL Support for loading next stage from UART"
>>>>>>>> +    help
>>>>>>>> +      This option enables SPL to load the next stage bootloader
>>>>>>>> +      over a UART line using the x/y/z/modem protocol.
>>>>>>>> +
>>>>>>>> +config SPL_MMC_SUPPORT
>>>>>>>> +    bool "SPL Support for loading next stage from SD/MMC/eMMC"
>>>>>>>> +    help
>>>>>>>> +      This option enables SPL to load the next stage bootloader
>>>>>>>> +      from an SD/MMC/eMMC device.
>>>>>>>
>>>>>>> Hmm.. why do you not move, for existing board configs, which use
>>>>>>> this symbols, them into their defconfigs? There is the great
>>>>>>> script from Masahiro
>>>>>>>
>>>>>>> u-boot:tools/moveconfig.py
>>>>>>>
>>>>>>> which should do the most things for you ... 
>>>>>>
>>>>>> Maybe I'm not understanding this script but after getting it to run it
>>>>>> doesn't seem to find any uses of the config, I'm not sure this works
>>>>>> with SPL configs, as the check looks only at the non-SPL build case as
>>>>>> far as I can tell.
>>>>>
>>>>> Hmm, Masahiro?  Can we support SPL related migrations easily?  Thanks!
>>>>>
>>>>
>>>> Well a quick workaround I used was to add -DCONFIG_SPL_BUILD to the main
>>>> Makefile, this way it will pick up SPL_ defines that are blocked of by
>>>> conditionals for CONFIG_SPL_BUILD.
>>>>
>>>> Anyway the bigger problem is that some boards conditionally define an
>>>> option based on what other configs are enabled, we don't have this kind
>>>> of thing in Kconfig, at least not at the board level as far as I know.
>>>> (Select could work, but it would end up with a lot of conditionals per
>>>> board supported)
>>>
>>> I think the problem is that we have some "soft" dependencies here.  ie I
>>> think that when I was making am335x_evm.h work for all of the various
>>> possible board and feature combos that were desired I took some
>>> short-cuts to say that A means lets grab B and C.  I think it's
>>> perfectly reasonable that in moving to Kconfig we start out by getting
>>> everything into Kconfig and worry about getting all of the select /
>>> depends statements right as the second step.  So the defconfigs might
>>> start out a bit fuller and we'll get options removed from them as the
>>> Kconfig logic improves.
>>>
>>
>> If this is okay then I'll post a series with all these cleanups and the
>> config options moved. I believe they don't now make any changes to the
>> build output of any board (at lease according to buildman).
> 
> With sizechecks enabled?  You may way to look at the tbot test that
> Heiko got setup after the last problematic Kconfig migration:
> http://lists.denx.de/pipermail/u-boot/2016-June/258119.html
> 
>> The patch for moving SPL_TEXT_BASE will probably have to be dropped as
>> it breaks a couple old powerpc boards for some strange reason (they look
>> like they depend on SPL_TEXT_BASE being unset, and giving it even a
>> default value breaks build for them) and I don't have any time to look
>> into how the build works on those. So I will depend on the
>> ISW_ENTRY_ADDR as a hacky work-around config option for setting an SPL
>> address in Kconfig like we do in AM43xx boards for now.
> 
> OK. Can you do it as an RFC at the end of the series?  I'll try and take
> a look at fixing that one up.  Thanks!
> 

Sure, this works well for me, should have v2 ready this afternoon.

Thanks,
Andrew

[U-Boot] [PATCH 02/13] spl: Kconfig: Add SPL_<media>_BOOT as Kconfig option

[Andrew F. Davis]

Currently U-Boot proper has Kconfig options that enable the generation
of U-Boot binaries that are capable of being booted from the selected
boot media type. The same set of generation targets for SPL are assumed
with various methods and config header hackery. On some platforms the
options for SPL, such as load address, are dependent on boot type
and cannot depend on boot image type selected for U-Boot proper.
Add a Kconfig menu to select SPL boot image types, and populate it
with the same media types as are already available for U-Boot proper.
Uses of this option are added later.

Signed-off-by: Andrew F. Davis <afd@ti.com>
---
 common/Kconfig | 69 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 69 insertions(+)

diff --git a/common/Kconfig b/common/Kconfig
index f594db5..90ba5b2 100644
--- a/common/Kconfig
+++ b/common/Kconfig
@@ -156,6 +156,75 @@ config SPI_BOOT
 	  booted via SPI flash. This is not a must, some SoCs need this,
 	  somes not.
 
+menu "SPL Boot media"
+	depends on SPL
+
+config SPL_NOR_BOOT
+	bool "Support for booting SPL from NOR flash"
+	default n
+	help
+	  Enabling this will make an SPL binary that is capable of being
+	  booted via NOR flash. This is not a must, some SoCs need this,
+	  some do not.
+
+config SPL_NAND_BOOT
+	bool "Support for booting SPL from NAND flash"
+	default n
+	help
+	  Enabling this will make an SPL binary that is capable of being
+	  booted via NAND flash. This is not a must, some SoCs need this,
+	  some do not.
+
+config SPL_ONENAND_BOOT
+	bool "Support for booting SPL from ONENAND"
+	default n
+	help
+	  Enabling this will make an SPL binary that is capable of being
+	  booted via ONENAND. This is not a must, some SoCs need this,
+	  some do not.
+
+config SPL_QSPI_BOOT
+	bool "Support for booting SPL from QSPI flash"
+	default n
+	help
+	  Enabling this will make an SPL binary that is capable of being
+	  booted via QSPI flash. This is not a must, some SoCs need this,
+	  some do not.
+
+config SPL_SATA_BOOT
+	bool "Support for booting SPL from SATA"
+	default n
+	help
+	  Enabling this will make an SPL binary that is capable of being
+	  booted via SATA. This is not a must, some SoCs need this,
+	  some do not.
+
+config SPL_SD_BOOT
+	bool "Support for booting SPL from SD/MMC/eMMC"
+	default n
+	help
+	  Enabling this will make an SPL binary that is capable of being
+	  booted via SD/MMC/eMMC. This is not a must, some SoCs need this,
+	  some do not.
+
+config SPL_SPI_BOOT
+	bool "Support for booting SPL from SPI flash"
+	default n
+	help
+	  Enabling this will make an SPL binary that is capable of being
+	  booted via SPI flash. This is not a must, some SoCs need this,
+	  some do not.
+
+config SPL_UART_BOOT
+	bool "Support for booting SPL from UART"
+	default n
+	help
+	  Enabling this will make an SPL binary that is capable of being
+	  booted via UART. This is not a must, some SoCs need this,
+	  some do not.
+
+endmenu
+
 menu "SPL Media Loading Support"
 	depends on SPL
 
-- 
2.9.2

[U-Boot] [PATCH 02/13] spl: Kconfig: Add SPL_<media>_BOOT as Kconfig option

[Lokesh Vutla]

On Thursday 18 August 2016 09:11 PM, Andrew F. Davis wrote:
> Currently U-Boot proper has Kconfig options that enable the generation
> of U-Boot binaries that are capable of being booted from the selected
> boot media type. The same set of generation targets for SPL are assumed
> with various methods and config header hackery. On some platforms the
> options for SPL, such as load address, are dependent on boot type
> and cannot depend on boot image type selected for U-Boot proper.
> Add a Kconfig menu to select SPL boot image types, and populate it
> with the same media types as are already available for U-Boot proper.
> Uses of this option are added later.
> 
> Signed-off-by: Andrew F. Davis <afd@ti.com>
> ---
>  common/Kconfig | 69 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 69 insertions(+)
> 
> diff --git a/common/Kconfig b/common/Kconfig
> index f594db5..90ba5b2 100644
> --- a/common/Kconfig
> +++ b/common/Kconfig
> @@ -156,6 +156,75 @@ config SPI_BOOT
>  	  booted via SPI flash. This is not a must, some SoCs need this,
>  	  somes not.
>  
> +menu "SPL Boot media"
> +	depends on SPL
> +
> +config SPL_NOR_BOOT
> +	bool "Support for booting SPL from NOR flash"
> +	default n

Shouldn't this depend on SPL_NOR_SUPPORT? Similarly others.

May be a dump question. Do you see any issue with using
SPL_<media>_SUPPORT config for the same purpose as SPL_<media>_BOOT
instead of creating a new defconfig?

Thanks and regards,
Lokesh

> +	help
> +	  Enabling this will make an SPL binary that is capable of being
> +	  booted via NOR flash. This is not a must, some SoCs need this,
> +	  some do not.
> +
> +config SPL_NAND_BOOT
> +	bool "Support for booting SPL from NAND flash"
> +	default n
> +	help
> +	  Enabling this will make an SPL binary that is capable of being
> +	  booted via NAND flash. This is not a must, some SoCs need this,
> +	  some do not.
> +
> +config SPL_ONENAND_BOOT
> +	bool "Support for booting SPL from ONENAND"
> +	default n
> +	help
> +	  Enabling this will make an SPL binary that is capable of being
> +	  booted via ONENAND. This is not a must, some SoCs need this,
> +	  some do not.
> +
> +config SPL_QSPI_BOOT
> +	bool "Support for booting SPL from QSPI flash"
> +	default n
> +	help
> +	  Enabling this will make an SPL binary that is capable of being
> +	  booted via QSPI flash. This is not a must, some SoCs need this,
> +	  some do not.
> +
> +config SPL_SATA_BOOT
> +	bool "Support for booting SPL from SATA"
> +	default n
> +	help
> +	  Enabling this will make an SPL binary that is capable of being
> +	  booted via SATA. This is not a must, some SoCs need this,
> +	  some do not.
> +
> +config SPL_SD_BOOT
> +	bool "Support for booting SPL from SD/MMC/eMMC"
> +	default n
> +	help
> +	  Enabling this will make an SPL binary that is capable of being
> +	  booted via SD/MMC/eMMC. This is not a must, some SoCs need this,
> +	  some do not.
> +
> +config SPL_SPI_BOOT
> +	bool "Support for booting SPL from SPI flash"
> +	default n
> +	help
> +	  Enabling this will make an SPL binary that is capable of being
> +	  booted via SPI flash. This is not a must, some SoCs need this,
> +	  some do not.
> +
> +config SPL_UART_BOOT
> +	bool "Support for booting SPL from UART"
> +	default n
> +	help
> +	  Enabling this will make an SPL binary that is capable of being
> +	  booted via UART. This is not a must, some SoCs need this,
> +	  some do not.
> +
> +endmenu
> +
>  menu "SPL Media Loading Support"
>  	depends on SPL
>  
> 

[U-Boot] [PATCH 02/13] spl: Kconfig: Add SPL_<media>_BOOT as Kconfig option

[Andrew F. Davis]

On 08/18/2016 11:10 PM, Lokesh Vutla wrote:
> 
> 
> On Thursday 18 August 2016 09:11 PM, Andrew F. Davis wrote:
>> Currently U-Boot proper has Kconfig options that enable the generation
>> of U-Boot binaries that are capable of being booted from the selected
>> boot media type. The same set of generation targets for SPL are assumed
>> with various methods and config header hackery. On some platforms the
>> options for SPL, such as load address, are dependent on boot type
>> and cannot depend on boot image type selected for U-Boot proper.
>> Add a Kconfig menu to select SPL boot image types, and populate it
>> with the same media types as are already available for U-Boot proper.
>> Uses of this option are added later.
>>
>> Signed-off-by: Andrew F. Davis <afd@ti.com>
>> ---
>>  common/Kconfig | 69 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>>  1 file changed, 69 insertions(+)
>>
>> diff --git a/common/Kconfig b/common/Kconfig
>> index f594db5..90ba5b2 100644
>> --- a/common/Kconfig
>> +++ b/common/Kconfig
>> @@ -156,6 +156,75 @@ config SPI_BOOT
>>  	  booted via SPI flash. This is not a must, some SoCs need this,
>>  	  somes not.
>>  
>> +menu "SPL Boot media"
>> +	depends on SPL
>> +
>> +config SPL_NOR_BOOT
>> +	bool "Support for booting SPL from NOR flash"
>> +	default n
> 
> Shouldn't this depend on SPL_NOR_SUPPORT? Similarly others.
> 

Nope, these simply enable the SPL to be built for being itself loaded
from this media, for instance the SPL does not need to know how to load
images over UART just because it itself was.

> May be a dump question. Do you see any issue with using
> SPL_<media>_SUPPORT config for the same purpose as SPL_<media>_BOOT
> instead of creating a new defconfig?
> 

Kind of the same answer as above, the idea is that _SUPPORT is for
adding the ability to load images from a media type to the SPL, and
_BOOT is to inform the make system to generate an SPL image that can be
loaded from this media. This mirrors, for SPL, the same options that
already exist for U-Boot proper.

Now something that I had considered was using the U-Boot proper _BOOT
options to determine what kinds of media the SPL should know how to load
images from, but this becomes very complex and would led to
misunderstandings of the options, like the one I correct in patch 8, so
I have kept them independent of each other.

Thanks,
Andrew

> Thanks and regards,
> Lokesh
> 
>> +	help
>> +	  Enabling this will make an SPL binary that is capable of being
>> +	  booted via NOR flash. This is not a must, some SoCs need this,
>> +	  some do not.
>> +
>> +config SPL_NAND_BOOT
>> +	bool "Support for booting SPL from NAND flash"
>> +	default n
>> +	help
>> +	  Enabling this will make an SPL binary that is capable of being
>> +	  booted via NAND flash. This is not a must, some SoCs need this,
>> +	  some do not.
>> +
>> +config SPL_ONENAND_BOOT
>> +	bool "Support for booting SPL from ONENAND"
>> +	default n
>> +	help
>> +	  Enabling this will make an SPL binary that is capable of being
>> +	  booted via ONENAND. This is not a must, some SoCs need this,
>> +	  some do not.
>> +
>> +config SPL_QSPI_BOOT
>> +	bool "Support for booting SPL from QSPI flash"
>> +	default n
>> +	help
>> +	  Enabling this will make an SPL binary that is capable of being
>> +	  booted via QSPI flash. This is not a must, some SoCs need this,
>> +	  some do not.
>> +
>> +config SPL_SATA_BOOT
>> +	bool "Support for booting SPL from SATA"
>> +	default n
>> +	help
>> +	  Enabling this will make an SPL binary that is capable of being
>> +	  booted via SATA. This is not a must, some SoCs need this,
>> +	  some do not.
>> +
>> +config SPL_SD_BOOT
>> +	bool "Support for booting SPL from SD/MMC/eMMC"
>> +	default n
>> +	help
>> +	  Enabling this will make an SPL binary that is capable of being
>> +	  booted via SD/MMC/eMMC. This is not a must, some SoCs need this,
>> +	  some do not.
>> +
>> +config SPL_SPI_BOOT
>> +	bool "Support for booting SPL from SPI flash"
>> +	default n
>> +	help
>> +	  Enabling this will make an SPL binary that is capable of being
>> +	  booted via SPI flash. This is not a must, some SoCs need this,
>> +	  some do not.
>> +
>> +config SPL_UART_BOOT
>> +	bool "Support for booting SPL from UART"
>> +	default n
>> +	help
>> +	  Enabling this will make an SPL binary that is capable of being
>> +	  booted via UART. This is not a must, some SoCs need this,
>> +	  some do not.
>> +
>> +endmenu
>> +
>>  menu "SPL Media Loading Support"
>>  	depends on SPL
>>  
>>

[U-Boot] [PATCH 02/13] spl: Kconfig: Add SPL_<media>_BOOT as Kconfig option

[Lokesh Vutla]

On Friday 19 August 2016 08:59 PM, Andrew F. Davis wrote:
> On 08/18/2016 11:10 PM, Lokesh Vutla wrote:
>>
>>
>> On Thursday 18 August 2016 09:11 PM, Andrew F. Davis wrote:
>>> Currently U-Boot proper has Kconfig options that enable the generation
>>> of U-Boot binaries that are capable of being booted from the selected
>>> boot media type. The same set of generation targets for SPL are assumed
>>> with various methods and config header hackery. On some platforms the
>>> options for SPL, such as load address, are dependent on boot type
>>> and cannot depend on boot image type selected for U-Boot proper.
>>> Add a Kconfig menu to select SPL boot image types, and populate it
>>> with the same media types as are already available for U-Boot proper.
>>> Uses of this option are added later.
>>>
>>> Signed-off-by: Andrew F. Davis <afd@ti.com>
>>> ---
>>>  common/Kconfig | 69 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>>>  1 file changed, 69 insertions(+)
>>>
>>> diff --git a/common/Kconfig b/common/Kconfig
>>> index f594db5..90ba5b2 100644
>>> --- a/common/Kconfig
>>> +++ b/common/Kconfig
>>> @@ -156,6 +156,75 @@ config SPI_BOOT
>>>  	  booted via SPI flash. This is not a must, some SoCs need this,
>>>  	  somes not.
>>>  
>>> +menu "SPL Boot media"
>>> +	depends on SPL
>>> +
>>> +config SPL_NOR_BOOT
>>> +	bool "Support for booting SPL from NOR flash"
>>> +	default n
>>
>> Shouldn't this depend on SPL_NOR_SUPPORT? Similarly others.
>>
> 
> Nope, these simply enable the SPL to be built for being itself loaded
> from this media, for instance the SPL does not need to know how to load
> images over UART just because it itself was.

Right, but how does SPL decide the boot media to load images?. Typically
it tries to load from the same boot media it was loaded. If it couldn't
find then it will fallback to other options. At least it is good to
select SPL_<media>_SUPPORT as it is the first thing SPL searches for.

Thanks and regards,
Lokesh

[U-Boot] [PATCH 02/13] spl: Kconfig: Add SPL_<media>_BOOT as Kconfig option

[Tom Rini]

On Mon, Aug 22, 2016 at 09:53:18AM +0530, Lokesh Vutla wrote:
> 
> 
> On Friday 19 August 2016 08:59 PM, Andrew F. Davis wrote:
> > On 08/18/2016 11:10 PM, Lokesh Vutla wrote:
> >>
> >>
> >> On Thursday 18 August 2016 09:11 PM, Andrew F. Davis wrote:
> >>> Currently U-Boot proper has Kconfig options that enable the generation
> >>> of U-Boot binaries that are capable of being booted from the selected
> >>> boot media type. The same set of generation targets for SPL are assumed
> >>> with various methods and config header hackery. On some platforms the
> >>> options for SPL, such as load address, are dependent on boot type
> >>> and cannot depend on boot image type selected for U-Boot proper.
> >>> Add a Kconfig menu to select SPL boot image types, and populate it
> >>> with the same media types as are already available for U-Boot proper.
> >>> Uses of this option are added later.
> >>>
> >>> Signed-off-by: Andrew F. Davis <afd@ti.com>
> >>> ---
> >>>  common/Kconfig | 69 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> >>>  1 file changed, 69 insertions(+)
> >>>
> >>> diff --git a/common/Kconfig b/common/Kconfig
> >>> index f594db5..90ba5b2 100644
> >>> --- a/common/Kconfig
> >>> +++ b/common/Kconfig
> >>> @@ -156,6 +156,75 @@ config SPI_BOOT
> >>>  	  booted via SPI flash. This is not a must, some SoCs need this,
> >>>  	  somes not.
> >>>  
> >>> +menu "SPL Boot media"
> >>> +	depends on SPL
> >>> +
> >>> +config SPL_NOR_BOOT
> >>> +	bool "Support for booting SPL from NOR flash"
> >>> +	default n
> >>
> >> Shouldn't this depend on SPL_NOR_SUPPORT? Similarly others.
> >>
> > 
> > Nope, these simply enable the SPL to be built for being itself loaded
> > from this media, for instance the SPL does not need to know how to load
> > images over UART just because it itself was.
> 
> Right, but how does SPL decide the boot media to load images?. Typically
> it tries to load from the same boot media it was loaded. If it couldn't
> find then it will fallback to other options. At least it is good to
> select SPL_<media>_SUPPORT as it is the first thing SPL searches for.

Yes, but this is different from just migrating everything into Kconfig.
I said this in another part of the series but I think we need to start
by getting the options in and then as a follow-up to get depends/selects
added.

-- 
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/20160822/6339183f/attachment.sig>

[U-Boot] [PATCH 02/13] spl: Kconfig: Add SPL_<media>_BOOT as Kconfig option

[Simon Glass]

Hi Tom,

On 22 August 2016 at 06:25, Tom Rini <trini@konsulko.com> wrote:
> On Mon, Aug 22, 2016 at 09:53:18AM +0530, Lokesh Vutla wrote:
>>
>>
>> On Friday 19 August 2016 08:59 PM, Andrew F. Davis wrote:
>> > On 08/18/2016 11:10 PM, Lokesh Vutla wrote:
>> >>
>> >>
>> >> On Thursday 18 August 2016 09:11 PM, Andrew F. Davis wrote:
>> >>> Currently U-Boot proper has Kconfig options that enable the generation
>> >>> of U-Boot binaries that are capable of being booted from the selected
>> >>> boot media type. The same set of generation targets for SPL are assumed
>> >>> with various methods and config header hackery. On some platforms the
>> >>> options for SPL, such as load address, are dependent on boot type
>> >>> and cannot depend on boot image type selected for U-Boot proper.
>> >>> Add a Kconfig menu to select SPL boot image types, and populate it
>> >>> with the same media types as are already available for U-Boot proper.
>> >>> Uses of this option are added later.
>> >>>
>> >>> Signed-off-by: Andrew F. Davis <afd@ti.com>
>> >>> ---
>> >>>  common/Kconfig | 69 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>> >>>  1 file changed, 69 insertions(+)
>> >>>
>> >>> diff --git a/common/Kconfig b/common/Kconfig
>> >>> index f594db5..90ba5b2 100644
>> >>> --- a/common/Kconfig
>> >>> +++ b/common/Kconfig
>> >>> @@ -156,6 +156,75 @@ config SPI_BOOT
>> >>>     booted via SPI flash. This is not a must, some SoCs need this,
>> >>>     somes not.
>> >>>
>> >>> +menu "SPL Boot media"
>> >>> + depends on SPL
>> >>> +
>> >>> +config SPL_NOR_BOOT
>> >>> + bool "Support for booting SPL from NOR flash"
>> >>> + default n
>> >>
>> >> Shouldn't this depend on SPL_NOR_SUPPORT? Similarly others.
>> >>
>> >
>> > Nope, these simply enable the SPL to be built for being itself loaded
>> > from this media, for instance the SPL does not need to know how to load
>> > images over UART just because it itself was.
>>
>> Right, but how does SPL decide the boot media to load images?. Typically
>> it tries to load from the same boot media it was loaded. If it couldn't
>> find then it will fallback to other options. At least it is good to
>> select SPL_<media>_SUPPORT as it is the first thing SPL searches for.
>
> Yes, but this is different from just migrating everything into Kconfig.
> I said this in another part of the series but I think we need to start
> by getting the options in and then as a follow-up to get depends/selects
> added.

Yes I agree. What is the status of this work? As it happened I ran
into this with some 64-bit x86 work recently and have created a series
that converts all the SPL_..._SUPPORT options to Kconfig. But it has
build errors which I have to resolve. I'll see if I can fix it up and
send it out

It would be good to fix the conflation of driver support with loading
from that driver, but that will be easier once things are in Kconfig.

>
> --
> Tom

Regards,
Simon

[U-Boot] [PATCH 02/13] spl: Kconfig: Add SPL_<media>_BOOT as Kconfig option

[Masahiro Yamada]

2016-08-20 0:29 GMT+09:00 Andrew F. Davis <afd@ti.com>:
> On 08/18/2016 11:10 PM, Lokesh Vutla wrote:
>>
>>
>> On Thursday 18 August 2016 09:11 PM, Andrew F. Davis wrote:
>>> Currently U-Boot proper has Kconfig options that enable the generation
>>> of U-Boot binaries that are capable of being booted from the selected
>>> boot media type. The same set of generation targets for SPL are assumed
>>> with various methods and config header hackery. On some platforms the
>>> options for SPL, such as load address, are dependent on boot type
>>> and cannot depend on boot image type selected for U-Boot proper.
>>> Add a Kconfig menu to select SPL boot image types, and populate it
>>> with the same media types as are already available for U-Boot proper.
>>> Uses of this option are added later.
>>>
>>> Signed-off-by: Andrew F. Davis <afd@ti.com>
>>> ---
>>>  common/Kconfig | 69 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>>>  1 file changed, 69 insertions(+)
>>>
>>> diff --git a/common/Kconfig b/common/Kconfig
>>> index f594db5..90ba5b2 100644
>>> --- a/common/Kconfig
>>> +++ b/common/Kconfig
>>> @@ -156,6 +156,75 @@ config SPI_BOOT
>>>        booted via SPI flash. This is not a must, some SoCs need this,
>>>        somes not.
>>>
>>> +menu "SPL Boot media"
>>> +    depends on SPL
>>> +
>>> +config SPL_NOR_BOOT
>>> +    bool "Support for booting SPL from NOR flash"
>>> +    default n
>>
>> Shouldn't this depend on SPL_NOR_SUPPORT? Similarly others.
>>
>
> Nope, these simply enable the SPL to be built for being itself loaded
> from this media, for instance the SPL does not need to know how to load
> images over UART just because it itself was.
>
>> May be a dump question. Do you see any issue with using
>> SPL_<media>_SUPPORT config for the same purpose as SPL_<media>_BOOT
>> instead of creating a new defconfig?
>>
>
> Kind of the same answer as above, the idea is that _SUPPORT is for
> adding the ability to load images from a media type to the SPL, and
> _BOOT is to inform the make system to generate an SPL image that can be
> loaded from this media. This mirrors, for SPL, the same options that
> already exist for U-Boot proper.
>
> Now something that I had considered was using the U-Boot proper _BOOT
> options to determine what kinds of media the SPL should know how to load
> images from, but this becomes very complex and would led to
> misunderstandings of the options, like the one I correct in patch 8, so
> I have kept them independent of each other.
>


I do not see anything systematic for CONFIG_*_BOOT,
i.e., you can use it for any purpose.

Why don't you use the existing CONFIG_*_BOOT
for deciding the boot media for U-Boot proper, or SPL, or whatever.

If SPL is supported on your board, the U-Boot proper image
can have generic format, which makes it independent of a specific media.
Why do you need both CONFIG_*_BOOT and CONFIG_SPL_*_BOOT?



I do not want to see even the current "Boot media" menu.

http://patchwork.ozlabs.org/patch/661706/


Your patch is adding more.  :(




-- 
Best Regards
Masahiro Yamada

[U-Boot] [PATCH 03/13] spl: Kconfig: Add CONFIG_SPL_TEXT_BASE as Kconfig option

[Andrew F. Davis]

Add a new Kconfig CONFIG_SPL_TEXT_BASE. Add its use to
am335x_evm_defconfig, then only conditionally define it in
ti_am335x_common.h when it is not already defined, this allows for
systems that have not fully converted to the Kconfig based config
system to still include this header without redefining this symbol
on platforms that have.

Signed-off-by: Andrew F. Davis <afd@ti.com>
---
 Kconfig                            | 8 ++++++++
 configs/am335x_evm_defconfig       | 1 +
 include/configs/ti_am335x_common.h | 2 ++
 3 files changed, 11 insertions(+)

diff --git a/Kconfig b/Kconfig
index cb5af5b..f67e7c8 100644
--- a/Kconfig
+++ b/Kconfig
@@ -319,6 +319,14 @@ config SYS_TEXT_BASE
 	help
 	  TODO: Move CONFIG_SYS_TEXT_BASE for all the architecture
 
+config SPL_TEXT_BASE
+	hex "Text Base"
+	depends on SPL
+	help
+	  When SPL is enabled the image is linked with this as the
+	  starting address in memeory for which the SPL will be loaded.
+	  TODO: Move CONFIG_SPL_TEXT_BASE for all the architecture
+
 config SPL_LOAD_FIT
 	bool "Enable SPL loading U-Boot as a FIT"
 	depends on FIT
diff --git a/configs/am335x_evm_defconfig b/configs/am335x_evm_defconfig
index 6885230..b1264d7 100644
--- a/configs/am335x_evm_defconfig
+++ b/configs/am335x_evm_defconfig
@@ -3,6 +3,7 @@ CONFIG_TARGET_AM335X_EVM=y
 CONFIG_SPL_STACK_R_ADDR=0x82000000
 CONFIG_DEFAULT_DEVICE_TREE="am335x-evm"
 CONFIG_SPL=y
+CONFIG_SPL_TEXT_BASE=0x402F0400
 CONFIG_SPL_STACK_R=y
 CONFIG_SYS_EXTRA_OPTIONS="NAND"
 CONFIG_HUSH_PARSER=y
diff --git a/include/configs/ti_am335x_common.h b/include/configs/ti_am335x_common.h
index bcd56fc..25c9643 100644
--- a/include/configs/ti_am335x_common.h
+++ b/include/configs/ti_am335x_common.h
@@ -58,7 +58,9 @@
  * supports X-MODEM loading via UART, and we leverage this and then use
  * Y-MODEM to load u-boot.img, when booted over UART.
  */
+#ifndef CONFIG_SPL_TEXT_BASE
 #define CONFIG_SPL_TEXT_BASE		0x402F0400
+#endif
 #define CONFIG_SPL_MAX_SIZE		(0x4030B800 - CONFIG_SPL_TEXT_BASE)
 #define CONFIG_SYS_SPL_ARGS_ADDR	(CONFIG_SYS_SDRAM_BASE + \
 					 (128 << 20))
-- 
2.9.2

[U-Boot] [PATCH 03/13] spl: Kconfig: Add CONFIG_SPL_TEXT_BASE as Kconfig option

[Lokesh Vutla]

On Thursday 18 August 2016 09:11 PM, Andrew F. Davis wrote:
> Add a new Kconfig CONFIG_SPL_TEXT_BASE. Add its use to
> am335x_evm_defconfig, then only conditionally define it in
> ti_am335x_common.h when it is not already defined, this allows for
> systems that have not fully converted to the Kconfig based config
> system to still include this header without redefining this symbol
> on platforms that have.
> 
> Signed-off-by: Andrew F. Davis <afd@ti.com>
> ---
>  Kconfig                            | 8 ++++++++
>  configs/am335x_evm_defconfig       | 1 +
>  include/configs/ti_am335x_common.h | 2 ++
>  3 files changed, 11 insertions(+)
> 
> diff --git a/Kconfig b/Kconfig
> index cb5af5b..f67e7c8 100644
> --- a/Kconfig
> +++ b/Kconfig
> @@ -319,6 +319,14 @@ config SYS_TEXT_BASE
>  	help
>  	  TODO: Move CONFIG_SYS_TEXT_BASE for all the architecture
>  
> +config SPL_TEXT_BASE
> +	hex "Text Base"
> +	depends on SPL
> +	help
> +	  When SPL is enabled the image is linked with this as the
> +	  starting address in memeory for which the SPL will be loaded.
> +	  TODO: Move CONFIG_SPL_TEXT_BASE for all the architecture

Nice to see this in a common place. There are some boards which has
already defined this as Kconfig option. You need to remove the current
definition or else build might break.

Thanks and regards,
Lokesh

> +
>  config SPL_LOAD_FIT
>  	bool "Enable SPL loading U-Boot as a FIT"
>  	depends on FIT
> diff --git a/configs/am335x_evm_defconfig b/configs/am335x_evm_defconfig
> index 6885230..b1264d7 100644
> --- a/configs/am335x_evm_defconfig
> +++ b/configs/am335x_evm_defconfig
> @@ -3,6 +3,7 @@ CONFIG_TARGET_AM335X_EVM=y
>  CONFIG_SPL_STACK_R_ADDR=0x82000000
>  CONFIG_DEFAULT_DEVICE_TREE="am335x-evm"
>  CONFIG_SPL=y
> +CONFIG_SPL_TEXT_BASE=0x402F0400
>  CONFIG_SPL_STACK_R=y
>  CONFIG_SYS_EXTRA_OPTIONS="NAND"
>  CONFIG_HUSH_PARSER=y
> diff --git a/include/configs/ti_am335x_common.h b/include/configs/ti_am335x_common.h
> index bcd56fc..25c9643 100644
> --- a/include/configs/ti_am335x_common.h
> +++ b/include/configs/ti_am335x_common.h
> @@ -58,7 +58,9 @@
>   * supports X-MODEM loading via UART, and we leverage this and then use
>   * Y-MODEM to load u-boot.img, when booted over UART.
>   */
> +#ifndef CONFIG_SPL_TEXT_BASE
>  #define CONFIG_SPL_TEXT_BASE		0x402F0400
> +#endif
>  #define CONFIG_SPL_MAX_SIZE		(0x4030B800 - CONFIG_SPL_TEXT_BASE)
>  #define CONFIG_SYS_SPL_ARGS_ADDR	(CONFIG_SYS_SDRAM_BASE + \
>  					 (128 << 20))
> 

[U-Boot] [PATCH 03/13] spl: Kconfig: Add CONFIG_SPL_TEXT_BASE as Kconfig option

[Simon Glass]

+Masahiro

Hi Andrew,

On 18 August 2016 at 22:12, Lokesh Vutla <lokeshvutla@ti.com> wrote:
>
>
> On Thursday 18 August 2016 09:11 PM, Andrew F. Davis wrote:
>> Add a new Kconfig CONFIG_SPL_TEXT_BASE. Add its use to
>> am335x_evm_defconfig, then only conditionally define it in
>> ti_am335x_common.h when it is not already defined, this allows for
>> systems that have not fully converted to the Kconfig based config
>> system to still include this header without redefining this symbol
>> on platforms that have.
>>
>> Signed-off-by: Andrew F. Davis <afd@ti.com>
>> ---
>>  Kconfig                            | 8 ++++++++
>>  configs/am335x_evm_defconfig       | 1 +
>>  include/configs/ti_am335x_common.h | 2 ++
>>  3 files changed, 11 insertions(+)
>>
>> diff --git a/Kconfig b/Kconfig
>> index cb5af5b..f67e7c8 100644
>> --- a/Kconfig
>> +++ b/Kconfig
>> @@ -319,6 +319,14 @@ config SYS_TEXT_BASE
>>       help
>>         TODO: Move CONFIG_SYS_TEXT_BASE for all the architecture
>>
>> +config SPL_TEXT_BASE
>> +     hex "Text Base"
>> +     depends on SPL
>> +     help
>> +       When SPL is enabled the image is linked with this as the
>> +       starting address in memeory for which the SPL will be loaded.
>> +       TODO: Move CONFIG_SPL_TEXT_BASE for all the architecture
>
> Nice to see this in a common place. There are some boards which has
> already defined this as Kconfig option. You need to remove the current
> definition or else build might break.

Yes it is great to see this!

You can use the moveconfig.py tool to help with finishing the migration.

Regards,
Simon

[U-Boot] [PATCH 04/13] config: am335x_evm: Move CONFIG_SPL_YMODEM_SUPPORT to Kconfig

[Andrew F. Davis]

CONFIG_SPL_YMODEM_SUPPORT is enabled in the am335x_evm.h config
header, move this to the defconfig files for the boards that
include this config header, then remove it from the header.

Signed-off-by: Andrew F. Davis <afd@ti.com>
---
 configs/am335x_boneblack_defconfig       | 1 +
 configs/am335x_boneblack_vboot_defconfig | 1 +
 configs/am335x_evm_defconfig             | 1 +
 configs/am335x_evm_nor_defconfig         | 1 +
 configs/am335x_evm_spiboot_defconfig     | 1 +
 include/configs/am335x_evm.h             | 2 --
 6 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/configs/am335x_boneblack_defconfig b/configs/am335x_boneblack_defconfig
index d310e0b..deb085d 100644
--- a/configs/am335x_boneblack_defconfig
+++ b/configs/am335x_boneblack_defconfig
@@ -43,3 +43,4 @@ CONFIG_G_DNL_MANUFACTURER="Texas Instruments"
 CONFIG_G_DNL_VENDOR_NUM=0x0451
 CONFIG_G_DNL_PRODUCT_NUM=0xd022
 CONFIG_OF_LIBFDT=y
+CONFIG_SPL_YMODEM_SUPPORT=y
diff --git a/configs/am335x_boneblack_vboot_defconfig b/configs/am335x_boneblack_vboot_defconfig
index c2f09cb..90e20d1 100644
--- a/configs/am335x_boneblack_vboot_defconfig
+++ b/configs/am335x_boneblack_vboot_defconfig
@@ -50,3 +50,4 @@ CONFIG_G_DNL_MANUFACTURER="Texas Instruments"
 CONFIG_G_DNL_VENDOR_NUM=0x0451
 CONFIG_G_DNL_PRODUCT_NUM=0xd022
 CONFIG_DM_I2C=y
+CONFIG_SPL_YMODEM_SUPPORT=y
diff --git a/configs/am335x_evm_defconfig b/configs/am335x_evm_defconfig
index b1264d7..0fdf103 100644
--- a/configs/am335x_evm_defconfig
+++ b/configs/am335x_evm_defconfig
@@ -51,3 +51,4 @@ CONFIG_SPL_OF_LIBFDT=y
 CONFIG_SPL_LOAD_FIT=y
 CONFIG_OF_LIST="am335x-evm am335x-bone am335x-boneblack am335x-evmsk am335x-bonegreen am335x-icev2"
 CONFIG_DM_I2C=y
+CONFIG_SPL_YMODEM_SUPPORT=y
diff --git a/configs/am335x_evm_nor_defconfig b/configs/am335x_evm_nor_defconfig
index 76a004e..6614f50 100644
--- a/configs/am335x_evm_nor_defconfig
+++ b/configs/am335x_evm_nor_defconfig
@@ -39,3 +39,4 @@ CONFIG_G_DNL_VENDOR_NUM=0x0451
 CONFIG_G_DNL_PRODUCT_NUM=0xd022
 CONFIG_OF_LIBFDT=y
 CONFIG_SPL_NET_VCI_STRING="AM335x U-Boot SPL"
+CONFIG_SPL_YMODEM_SUPPORT=y
diff --git a/configs/am335x_evm_spiboot_defconfig b/configs/am335x_evm_spiboot_defconfig
index 2fe1a25..be123d6 100644
--- a/configs/am335x_evm_spiboot_defconfig
+++ b/configs/am335x_evm_spiboot_defconfig
@@ -39,3 +39,4 @@ CONFIG_G_DNL_MANUFACTURER="Texas Instruments"
 CONFIG_G_DNL_VENDOR_NUM=0x0451
 CONFIG_G_DNL_PRODUCT_NUM=0xd022
 CONFIG_OF_LIBFDT=y
+CONFIG_SPL_YMODEM_SUPPORT=y
diff --git a/include/configs/am335x_evm.h b/include/configs/am335x_evm.h
index ba4c215..2b65890 100644
--- a/include/configs/am335x_evm.h
+++ b/include/configs/am335x_evm.h
@@ -207,7 +207,6 @@
 /* SPL */
 #ifndef CONFIG_NOR_BOOT
 #define CONFIG_SPL_POWER_SUPPORT
-#define CONFIG_SPL_YMODEM_SUPPORT
 
 /* Bootcount using the RTC block */
 #define CONFIG_BOOTCOUNT_LIMIT
@@ -330,7 +329,6 @@
 
 #if defined(CONFIG_SPL_BUILD) && defined(CONFIG_SPL_USBETH_SUPPORT)
 /* Remove other SPL modes. */
-#undef CONFIG_SPL_YMODEM_SUPPORT
 #undef CONFIG_SPL_NAND_SUPPORT
 #undef CONFIG_SPL_MMC_SUPPORT
 #define CONFIG_ENV_IS_NOWHERE
-- 
2.9.2

[U-Boot] [PATCH 05/13] config: am43xx_evm: Move CONFIG_SPL_YMODEM_SUPPORT to Kconfig

[Andrew F. Davis]

CONFIG_SPL_YMODEM_SUPPORT is enabled in the am43xx_evm.h config
header, move this to the defconfig files for the boards that
include this config header, then remove it from the header.

Signed-off-by: Andrew F. Davis <afd@ti.com>
---
 configs/am43xx_evm_defconfig              | 1 +
 configs/am43xx_evm_ethboot_defconfig      | 1 +
 configs/am43xx_evm_qspiboot_defconfig     | 1 +
 configs/am43xx_evm_usbhost_boot_defconfig | 1 +
 configs/am43xx_hs_evm_defconfig           | 1 +
 include/configs/am43xx_evm.h              | 1 -
 6 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/configs/am43xx_evm_defconfig b/configs/am43xx_evm_defconfig
index 56782f1..acf104b 100644
--- a/configs/am43xx_evm_defconfig
+++ b/configs/am43xx_evm_defconfig
@@ -57,3 +57,4 @@ CONFIG_G_DNL_PRODUCT_NUM=0xbd00
 CONFIG_SPL_OF_LIBFDT=y
 CONFIG_DM_I2C=y
 CONFIG_DM_ETH=y
+CONFIG_SPL_YMODEM_SUPPORT=y
diff --git a/configs/am43xx_evm_ethboot_defconfig b/configs/am43xx_evm_ethboot_defconfig
index 3b958d7..a2ada32 100644
--- a/configs/am43xx_evm_ethboot_defconfig
+++ b/configs/am43xx_evm_ethboot_defconfig
@@ -42,3 +42,4 @@ CONFIG_G_DNL_VENDOR_NUM=0x0403
 CONFIG_G_DNL_PRODUCT_NUM=0xbd00
 CONFIG_OF_LIBFDT=y
 CONFIG_SPL_NET_VCI_STRING="AM43xx U-Boot SPL"
+CONFIG_SPL_YMODEM_SUPPORT=y
diff --git a/configs/am43xx_evm_qspiboot_defconfig b/configs/am43xx_evm_qspiboot_defconfig
index c6bc8e4..d348a5a 100644
--- a/configs/am43xx_evm_qspiboot_defconfig
+++ b/configs/am43xx_evm_qspiboot_defconfig
@@ -42,3 +42,4 @@ CONFIG_G_DNL_MANUFACTURER="Texas Instruments"
 CONFIG_G_DNL_VENDOR_NUM=0x0403
 CONFIG_G_DNL_PRODUCT_NUM=0xbd00
 CONFIG_OF_LIBFDT=y
+CONFIG_SPL_YMODEM_SUPPORT=y
diff --git a/configs/am43xx_evm_usbhost_boot_defconfig b/configs/am43xx_evm_usbhost_boot_defconfig
index 34c875e..a50dee8 100644
--- a/configs/am43xx_evm_usbhost_boot_defconfig
+++ b/configs/am43xx_evm_usbhost_boot_defconfig
@@ -57,3 +57,4 @@ CONFIG_FIT=y
 CONFIG_SPL_OF_LIBFDT=y
 CONFIG_SPL_LOAD_FIT=y
 CONFIG_OF_LIST="am437x-gp-evm am437x-sk-evm am43x-epos-evm am437x-idk-evm"
+CONFIG_SPL_YMODEM_SUPPORT=y
diff --git a/configs/am43xx_hs_evm_defconfig b/configs/am43xx_hs_evm_defconfig
index 1553196..08135f2 100644
--- a/configs/am43xx_hs_evm_defconfig
+++ b/configs/am43xx_hs_evm_defconfig
@@ -60,3 +60,4 @@ CONFIG_G_DNL_PRODUCT_NUM=0xbd00
 CONFIG_SPL_OF_LIBFDT=y
 CONFIG_DM_I2C=y
 CONFIG_DM_ETH=y
+CONFIG_SPL_YMODEM_SUPPORT=y
diff --git a/include/configs/am43xx_evm.h b/include/configs/am43xx_evm.h
index 0467953..545b117 100644
--- a/include/configs/am43xx_evm.h
+++ b/include/configs/am43xx_evm.h
@@ -44,7 +44,6 @@
 #define CONFIG_SYS_SPL_ARGS_ADDR	(CONFIG_SYS_SDRAM_BASE + \
 					 (128 << 20))
 #define CONFIG_SPL_POWER_SUPPORT
-#define CONFIG_SPL_YMODEM_SUPPORT
 
 /* Enabling L2 Cache */
 #define CONFIG_SYS_L2_PL310
-- 
2.9.2

[U-Boot] [PATCH 06/13] Kconfig: Separate AM33XX SOC config from target board config

[Andrew F. Davis]

The config option AM33XX is used in several boards and should be
defined as a stand-alone option for this SOC. We break this out
from TARGET_AM335X_EVM then enable AM33XX on in all the boards that
used TARGET_AM335X_EVM to eliminate any functional change with
this patch. Also conditionally define this in ti_am335x_common.h to prevent
redefinition. The definition can be removed completely when all platforms
that include this header have this definition added to their defconfig.

This is similar to what has already been done in
9de852642cae ("arm: Kconfig: Add support for AM43xx SoC specific Kconfig")
and is done for the same reasons.

Signed-off-by: Andrew F. Davis <afd@ti.com>
---
 arch/arm/Kconfig                         | 20 +++++++++++---------
 arch/arm/cpu/armv7/am33xx/Kconfig        | 18 ++++++++++++++++++
 configs/am335x_boneblack_defconfig       |  1 +
 configs/am335x_boneblack_vboot_defconfig |  1 +
 configs/am335x_evm_defconfig             |  1 +
 configs/am335x_evm_nor_defconfig         |  1 +
 configs/am335x_evm_norboot_defconfig     |  1 +
 configs/am335x_evm_spiboot_defconfig     |  1 +
 configs/am335x_evm_usbspl_defconfig      |  1 +
 include/configs/ti_am335x_common.h       |  2 ++
 10 files changed, 38 insertions(+), 9 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 5ac9401..00f3bd7 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -411,15 +411,6 @@ config TARGET_AM335X_BALTOS
 	select DM_SERIAL
 	select DM_GPIO
 
-config TARGET_AM335X_EVM
-	bool "Support am335x_evm"
-	select CPU_V7
-	select SUPPORT_SPL
-	select DM
-	select DM_SERIAL
-	select DM_GPIO
-	select TI_I2C_BOARD_DETECT
-
 config TARGET_AM335X_SHC
 	bool "Support am335x based shc board from bosch"
 	select CPU_V7
@@ -579,6 +570,17 @@ config AM43XX
 	  protocols, dual camera support, optional 3D graphics
 	  and an optional customer programmable secure boot.
 
+config AM33XX
+	bool "AM33XX SoC"
+	select CPU_V7
+	select SUPPORT_SPL
+	help
+	  Support for AM335x SOC from Texas Instruments.
+	  The AM335x high performance SOC features a Cortex-A8
+	  ARM core, a dual core PRU-ICSS for industrial Ethernet
+	  protocols, optional 3D graphics and an optional customer
+	  programmable secure boot.
+
 config RMOBILE
 	bool "Renesas ARM SoCs"
 	select CPU_V7
diff --git a/arch/arm/cpu/armv7/am33xx/Kconfig b/arch/arm/cpu/armv7/am33xx/Kconfig
index dc51e9b..60f1b40 100644
--- a/arch/arm/cpu/armv7/am33xx/Kconfig
+++ b/arch/arm/cpu/armv7/am33xx/Kconfig
@@ -1,3 +1,19 @@
+if AM33XX
+config TARGET_AM335X_EVM
+	bool "Support am335x_evm"
+	select DM
+	select DM_SERIAL
+	select DM_GPIO
+	select TI_I2C_BOARD_DETECT
+	help
+	  This option specifies support for the AM335x
+	  GP and HS EVM development platforms. The AM335x
+	  GP EVM is a standalone test, development, and
+	  evaluation module system that enables developers
+	  to write software and develop hardware around
+	  an AM335x processor subsystem.
+endif
+
 if AM43XX
 config TARGET_AM43XX_EVM
 	bool "Support am43xx_evm"
@@ -9,7 +25,9 @@ config TARGET_AM43XX_EVM
 	  evaluation module system that enables developers
 	  to write software and develop hardware around
 	  an AM43xx processor subsystem.
+endif
 
+if AM43XX || AM33XX
 config ISW_ENTRY_ADDR
 	hex "Address in memory or XIP flash of bootloader entry point"
 	help
diff --git a/configs/am335x_boneblack_defconfig b/configs/am335x_boneblack_defconfig
index deb085d..30ff029 100644
--- a/configs/am335x_boneblack_defconfig
+++ b/configs/am335x_boneblack_defconfig
@@ -1,4 +1,5 @@
 CONFIG_ARM=y
+CONFIG_AM33XX=y
 CONFIG_TARGET_AM335X_EVM=y
 CONFIG_SPL_STACK_R_ADDR=0x82000000
 CONFIG_SPL=y
diff --git a/configs/am335x_boneblack_vboot_defconfig b/configs/am335x_boneblack_vboot_defconfig
index 90e20d1..7ff0c87 100644
--- a/configs/am335x_boneblack_vboot_defconfig
+++ b/configs/am335x_boneblack_vboot_defconfig
@@ -1,4 +1,5 @@
 CONFIG_ARM=y
+CONFIG_AM33XX=y
 CONFIG_TARGET_AM335X_EVM=y
 CONFIG_SPL_STACK_R_ADDR=0x82000000
 CONFIG_DEFAULT_DEVICE_TREE="am335x-boneblack"
diff --git a/configs/am335x_evm_defconfig b/configs/am335x_evm_defconfig
index 0fdf103..d44c0da 100644
--- a/configs/am335x_evm_defconfig
+++ b/configs/am335x_evm_defconfig
@@ -1,4 +1,5 @@
 CONFIG_ARM=y
+CONFIG_AM33XX=y
 CONFIG_TARGET_AM335X_EVM=y
 CONFIG_SPL_STACK_R_ADDR=0x82000000
 CONFIG_DEFAULT_DEVICE_TREE="am335x-evm"
diff --git a/configs/am335x_evm_nor_defconfig b/configs/am335x_evm_nor_defconfig
index 6614f50..e8fef13 100644
--- a/configs/am335x_evm_nor_defconfig
+++ b/configs/am335x_evm_nor_defconfig
@@ -1,4 +1,5 @@
 CONFIG_ARM=y
+CONFIG_AM33XX=y
 CONFIG_TARGET_AM335X_EVM=y
 CONFIG_SPL_STACK_R_ADDR=0x82000000
 CONFIG_NOR=y
diff --git a/configs/am335x_evm_norboot_defconfig b/configs/am335x_evm_norboot_defconfig
index 99fc555..063eea7 100644
--- a/configs/am335x_evm_norboot_defconfig
+++ b/configs/am335x_evm_norboot_defconfig
@@ -1,4 +1,5 @@
 CONFIG_ARM=y
+CONFIG_AM33XX=y
 CONFIG_TARGET_AM335X_EVM=y
 CONFIG_NOR=y
 CONFIG_NOR_BOOT=y
diff --git a/configs/am335x_evm_spiboot_defconfig b/configs/am335x_evm_spiboot_defconfig
index be123d6..f4c03a1 100644
--- a/configs/am335x_evm_spiboot_defconfig
+++ b/configs/am335x_evm_spiboot_defconfig
@@ -1,4 +1,5 @@
 CONFIG_ARM=y
+CONFIG_AM33XX=y
 CONFIG_TARGET_AM335X_EVM=y
 CONFIG_SPL_STACK_R_ADDR=0x82000000
 CONFIG_SPL=y
diff --git a/configs/am335x_evm_usbspl_defconfig b/configs/am335x_evm_usbspl_defconfig
index cba5e84..b689181 100644
--- a/configs/am335x_evm_usbspl_defconfig
+++ b/configs/am335x_evm_usbspl_defconfig
@@ -1,4 +1,5 @@
 CONFIG_ARM=y
+CONFIG_AM33XX=y
 CONFIG_TARGET_AM335X_EVM=y
 CONFIG_SPL_STACK_R_ADDR=0x82000000
 CONFIG_SPL=y
diff --git a/include/configs/ti_am335x_common.h b/include/configs/ti_am335x_common.h
index 25c9643..4294c25 100644
--- a/include/configs/ti_am335x_common.h
+++ b/include/configs/ti_am335x_common.h
@@ -12,7 +12,9 @@
 #ifndef __CONFIG_TI_AM335X_COMMON_H__
 #define __CONFIG_TI_AM335X_COMMON_H__
 
+#ifndef CONFIG_AM33XX
 #define CONFIG_AM33XX
+#endif
 #define CONFIG_ARCH_CPU_INIT
 #define CONFIG_SYS_CACHELINE_SIZE       64
 #define CONFIG_MAX_RAM_BANK_SIZE	(1024 << 20)	/* 1GB */
-- 
2.9.2

[U-Boot] [PATCH 06/13] Kconfig: Separate AM33XX SOC config from target board config

[Lokesh Vutla]

On Thursday 18 August 2016 09:11 PM, Andrew F. Davis wrote:
> The config option AM33XX is used in several boards and should be
> defined as a stand-alone option for this SOC. We break this out
> from TARGET_AM335X_EVM then enable AM33XX on in all the boards that
> used TARGET_AM335X_EVM to eliminate any functional change with
> this patch. Also conditionally define this in ti_am335x_common.h to prevent
> redefinition. The definition can be removed completely when all platforms
> that include this header have this definition added to their defconfig.
> 
> This is similar to what has already been done in
> 9de852642cae ("arm: Kconfig: Add support for AM43xx SoC specific Kconfig")
> and is done for the same reasons.
> 
> Signed-off-by: Andrew F. Davis <afd@ti.com>
> ---
>  arch/arm/Kconfig                         | 20 +++++++++++---------
>  arch/arm/cpu/armv7/am33xx/Kconfig        | 18 ++++++++++++++++++
>  configs/am335x_boneblack_defconfig       |  1 +
>  configs/am335x_boneblack_vboot_defconfig |  1 +
>  configs/am335x_evm_defconfig             |  1 +
>  configs/am335x_evm_nor_defconfig         |  1 +
>  configs/am335x_evm_norboot_defconfig     |  1 +
>  configs/am335x_evm_spiboot_defconfig     |  1 +
>  configs/am335x_evm_usbspl_defconfig      |  1 +
>  include/configs/ti_am335x_common.h       |  2 ++
>  10 files changed, 38 insertions(+), 9 deletions(-)
> 
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index 5ac9401..00f3bd7 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -411,15 +411,6 @@ config TARGET_AM335X_BALTOS
>  	select DM_SERIAL
>  	select DM_GPIO
>  
> -config TARGET_AM335X_EVM
> -	bool "Support am335x_evm"
> -	select CPU_V7
> -	select SUPPORT_SPL
> -	select DM
> -	select DM_SERIAL
> -	select DM_GPIO
> -	select TI_I2C_BOARD_DETECT
> -
>  config TARGET_AM335X_SHC

Can you move all TARGET_AM335X_*  similarly?

Thanks and regards,
Lokesh

>  	bool "Support am335x based shc board from bosch"
>  	select CPU_V7
> @@ -579,6 +570,17 @@ config AM43XX
>  	  protocols, dual camera support, optional 3D graphics
>  	  and an optional customer programmable secure boot.
>  
> +config AM33XX
> +	bool "AM33XX SoC"
> +	select CPU_V7
> +	select SUPPORT_SPL
> +	help
> +	  Support for AM335x SOC from Texas Instruments.
> +	  The AM335x high performance SOC features a Cortex-A8
> +	  ARM core, a dual core PRU-ICSS for industrial Ethernet
> +	  protocols, optional 3D graphics and an optional customer
> +	  programmable secure boot.
> +
>  config RMOBILE
>  	bool "Renesas ARM SoCs"
>  	select CPU_V7
> diff --git a/arch/arm/cpu/armv7/am33xx/Kconfig b/arch/arm/cpu/armv7/am33xx/Kconfig
> index dc51e9b..60f1b40 100644
> --- a/arch/arm/cpu/armv7/am33xx/Kconfig
> +++ b/arch/arm/cpu/armv7/am33xx/Kconfig
> @@ -1,3 +1,19 @@
> +if AM33XX
> +config TARGET_AM335X_EVM
> +	bool "Support am335x_evm"
> +	select DM
> +	select DM_SERIAL
> +	select DM_GPIO
> +	select TI_I2C_BOARD_DETECT
> +	help
> +	  This option specifies support for the AM335x
> +	  GP and HS EVM development platforms. The AM335x
> +	  GP EVM is a standalone test, development, and
> +	  evaluation module system that enables developers
> +	  to write software and develop hardware around
> +	  an AM335x processor subsystem.
> +endif
> +
>  if AM43XX
>  config TARGET_AM43XX_EVM
>  	bool "Support am43xx_evm"
> @@ -9,7 +25,9 @@ config TARGET_AM43XX_EVM
>  	  evaluation module system that enables developers
>  	  to write software and develop hardware around
>  	  an AM43xx processor subsystem.
> +endif
>  
> +if AM43XX || AM33XX
>  config ISW_ENTRY_ADDR
>  	hex "Address in memory or XIP flash of bootloader entry point"
>  	help
> diff --git a/configs/am335x_boneblack_defconfig b/configs/am335x_boneblack_defconfig
> index deb085d..30ff029 100644
> --- a/configs/am335x_boneblack_defconfig
> +++ b/configs/am335x_boneblack_defconfig
> @@ -1,4 +1,5 @@
>  CONFIG_ARM=y
> +CONFIG_AM33XX=y
>  CONFIG_TARGET_AM335X_EVM=y
>  CONFIG_SPL_STACK_R_ADDR=0x82000000
>  CONFIG_SPL=y
> diff --git a/configs/am335x_boneblack_vboot_defconfig b/configs/am335x_boneblack_vboot_defconfig
> index 90e20d1..7ff0c87 100644
> --- a/configs/am335x_boneblack_vboot_defconfig
> +++ b/configs/am335x_boneblack_vboot_defconfig
> @@ -1,4 +1,5 @@
>  CONFIG_ARM=y
> +CONFIG_AM33XX=y
>  CONFIG_TARGET_AM335X_EVM=y
>  CONFIG_SPL_STACK_R_ADDR=0x82000000
>  CONFIG_DEFAULT_DEVICE_TREE="am335x-boneblack"
> diff --git a/configs/am335x_evm_defconfig b/configs/am335x_evm_defconfig
> index 0fdf103..d44c0da 100644
> --- a/configs/am335x_evm_defconfig
> +++ b/configs/am335x_evm_defconfig
> @@ -1,4 +1,5 @@
>  CONFIG_ARM=y
> +CONFIG_AM33XX=y
>  CONFIG_TARGET_AM335X_EVM=y
>  CONFIG_SPL_STACK_R_ADDR=0x82000000
>  CONFIG_DEFAULT_DEVICE_TREE="am335x-evm"
> diff --git a/configs/am335x_evm_nor_defconfig b/configs/am335x_evm_nor_defconfig
> index 6614f50..e8fef13 100644
> --- a/configs/am335x_evm_nor_defconfig
> +++ b/configs/am335x_evm_nor_defconfig
> @@ -1,4 +1,5 @@
>  CONFIG_ARM=y
> +CONFIG_AM33XX=y
>  CONFIG_TARGET_AM335X_EVM=y
>  CONFIG_SPL_STACK_R_ADDR=0x82000000
>  CONFIG_NOR=y
> diff --git a/configs/am335x_evm_norboot_defconfig b/configs/am335x_evm_norboot_defconfig
> index 99fc555..063eea7 100644
> --- a/configs/am335x_evm_norboot_defconfig
> +++ b/configs/am335x_evm_norboot_defconfig
> @@ -1,4 +1,5 @@
>  CONFIG_ARM=y
> +CONFIG_AM33XX=y
>  CONFIG_TARGET_AM335X_EVM=y
>  CONFIG_NOR=y
>  CONFIG_NOR_BOOT=y
> diff --git a/configs/am335x_evm_spiboot_defconfig b/configs/am335x_evm_spiboot_defconfig
> index be123d6..f4c03a1 100644
> --- a/configs/am335x_evm_spiboot_defconfig
> +++ b/configs/am335x_evm_spiboot_defconfig
> @@ -1,4 +1,5 @@
>  CONFIG_ARM=y
> +CONFIG_AM33XX=y
>  CONFIG_TARGET_AM335X_EVM=y
>  CONFIG_SPL_STACK_R_ADDR=0x82000000
>  CONFIG_SPL=y
> diff --git a/configs/am335x_evm_usbspl_defconfig b/configs/am335x_evm_usbspl_defconfig
> index cba5e84..b689181 100644
> --- a/configs/am335x_evm_usbspl_defconfig
> +++ b/configs/am335x_evm_usbspl_defconfig
> @@ -1,4 +1,5 @@
>  CONFIG_ARM=y
> +CONFIG_AM33XX=y
>  CONFIG_TARGET_AM335X_EVM=y
>  CONFIG_SPL_STACK_R_ADDR=0x82000000
>  CONFIG_SPL=y
> diff --git a/include/configs/ti_am335x_common.h b/include/configs/ti_am335x_common.h
> index 25c9643..4294c25 100644
> --- a/include/configs/ti_am335x_common.h
> +++ b/include/configs/ti_am335x_common.h
> @@ -12,7 +12,9 @@
>  #ifndef __CONFIG_TI_AM335X_COMMON_H__
>  #define __CONFIG_TI_AM335X_COMMON_H__
>  
> +#ifndef CONFIG_AM33XX
>  #define CONFIG_AM33XX
> +#endif
>  #define CONFIG_ARCH_CPU_INIT
>  #define CONFIG_SYS_CACHELINE_SIZE       64
>  #define CONFIG_MAX_RAM_BANK_SIZE	(1024 << 20)	/* 1GB */
> 

[U-Boot] [PATCH 06/13] Kconfig: Separate AM33XX SOC config from target board config

[Andrew F. Davis]

On 08/18/2016 11:15 PM, Lokesh Vutla wrote:
> 
> 
> On Thursday 18 August 2016 09:11 PM, Andrew F. Davis wrote:
>> The config option AM33XX is used in several boards and should be
>> defined as a stand-alone option for this SOC. We break this out
>> from TARGET_AM335X_EVM then enable AM33XX on in all the boards that
>> used TARGET_AM335X_EVM to eliminate any functional change with
>> this patch. Also conditionally define this in ti_am335x_common.h to prevent
>> redefinition. The definition can be removed completely when all platforms
>> that include this header have this definition added to their defconfig.
>>
>> This is similar to what has already been done in
>> 9de852642cae ("arm: Kconfig: Add support for AM43xx SoC specific Kconfig")
>> and is done for the same reasons.
>>
>> Signed-off-by: Andrew F. Davis <afd@ti.com>
>> ---
>>  arch/arm/Kconfig                         | 20 +++++++++++---------
>>  arch/arm/cpu/armv7/am33xx/Kconfig        | 18 ++++++++++++++++++
>>  configs/am335x_boneblack_defconfig       |  1 +
>>  configs/am335x_boneblack_vboot_defconfig |  1 +
>>  configs/am335x_evm_defconfig             |  1 +
>>  configs/am335x_evm_nor_defconfig         |  1 +
>>  configs/am335x_evm_norboot_defconfig     |  1 +
>>  configs/am335x_evm_spiboot_defconfig     |  1 +
>>  configs/am335x_evm_usbspl_defconfig      |  1 +
>>  include/configs/ti_am335x_common.h       |  2 ++
>>  10 files changed, 38 insertions(+), 9 deletions(-)
>>
>> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
>> index 5ac9401..00f3bd7 100644
>> --- a/arch/arm/Kconfig
>> +++ b/arch/arm/Kconfig
>> @@ -411,15 +411,6 @@ config TARGET_AM335X_BALTOS
>>  	select DM_SERIAL
>>  	select DM_GPIO
>>  
>> -config TARGET_AM335X_EVM
>> -	bool "Support am335x_evm"
>> -	select CPU_V7
>> -	select SUPPORT_SPL
>> -	select DM
>> -	select DM_SERIAL
>> -	select DM_GPIO
>> -	select TI_I2C_BOARD_DETECT
>> -
>>  config TARGET_AM335X_SHC
> 
> Can you move all TARGET_AM335X_*  similarly?
> 

No problem, added to v2.

> Thanks and regards,
> Lokesh
> 
>>  	bool "Support am335x based shc board from bosch"
>>  	select CPU_V7
>> @@ -579,6 +570,17 @@ config AM43XX
>>  	  protocols, dual camera support, optional 3D graphics
>>  	  and an optional customer programmable secure boot.
>>  
>> +config AM33XX
>> +	bool "AM33XX SoC"
>> +	select CPU_V7
>> +	select SUPPORT_SPL
>> +	help
>> +	  Support for AM335x SOC from Texas Instruments.
>> +	  The AM335x high performance SOC features a Cortex-A8
>> +	  ARM core, a dual core PRU-ICSS for industrial Ethernet
>> +	  protocols, optional 3D graphics and an optional customer
>> +	  programmable secure boot.
>> +
>>  config RMOBILE
>>  	bool "Renesas ARM SoCs"
>>  	select CPU_V7
>> diff --git a/arch/arm/cpu/armv7/am33xx/Kconfig b/arch/arm/cpu/armv7/am33xx/Kconfig
>> index dc51e9b..60f1b40 100644
>> --- a/arch/arm/cpu/armv7/am33xx/Kconfig
>> +++ b/arch/arm/cpu/armv7/am33xx/Kconfig
>> @@ -1,3 +1,19 @@
>> +if AM33XX
>> +config TARGET_AM335X_EVM
>> +	bool "Support am335x_evm"
>> +	select DM
>> +	select DM_SERIAL
>> +	select DM_GPIO
>> +	select TI_I2C_BOARD_DETECT
>> +	help
>> +	  This option specifies support for the AM335x
>> +	  GP and HS EVM development platforms. The AM335x
>> +	  GP EVM is a standalone test, development, and
>> +	  evaluation module system that enables developers
>> +	  to write software and develop hardware around
>> +	  an AM335x processor subsystem.
>> +endif
>> +
>>  if AM43XX
>>  config TARGET_AM43XX_EVM
>>  	bool "Support am43xx_evm"
>> @@ -9,7 +25,9 @@ config TARGET_AM43XX_EVM
>>  	  evaluation module system that enables developers
>>  	  to write software and develop hardware around
>>  	  an AM43xx processor subsystem.
>> +endif
>>  
>> +if AM43XX || AM33XX
>>  config ISW_ENTRY_ADDR
>>  	hex "Address in memory or XIP flash of bootloader entry point"
>>  	help
>> diff --git a/configs/am335x_boneblack_defconfig b/configs/am335x_boneblack_defconfig
>> index deb085d..30ff029 100644
>> --- a/configs/am335x_boneblack_defconfig
>> +++ b/configs/am335x_boneblack_defconfig
>> @@ -1,4 +1,5 @@
>>  CONFIG_ARM=y
>> +CONFIG_AM33XX=y
>>  CONFIG_TARGET_AM335X_EVM=y
>>  CONFIG_SPL_STACK_R_ADDR=0x82000000
>>  CONFIG_SPL=y
>> diff --git a/configs/am335x_boneblack_vboot_defconfig b/configs/am335x_boneblack_vboot_defconfig
>> index 90e20d1..7ff0c87 100644
>> --- a/configs/am335x_boneblack_vboot_defconfig
>> +++ b/configs/am335x_boneblack_vboot_defconfig
>> @@ -1,4 +1,5 @@
>>  CONFIG_ARM=y
>> +CONFIG_AM33XX=y
>>  CONFIG_TARGET_AM335X_EVM=y
>>  CONFIG_SPL_STACK_R_ADDR=0x82000000
>>  CONFIG_DEFAULT_DEVICE_TREE="am335x-boneblack"
>> diff --git a/configs/am335x_evm_defconfig b/configs/am335x_evm_defconfig
>> index 0fdf103..d44c0da 100644
>> --- a/configs/am335x_evm_defconfig
>> +++ b/configs/am335x_evm_defconfig
>> @@ -1,4 +1,5 @@
>>  CONFIG_ARM=y
>> +CONFIG_AM33XX=y
>>  CONFIG_TARGET_AM335X_EVM=y
>>  CONFIG_SPL_STACK_R_ADDR=0x82000000
>>  CONFIG_DEFAULT_DEVICE_TREE="am335x-evm"
>> diff --git a/configs/am335x_evm_nor_defconfig b/configs/am335x_evm_nor_defconfig
>> index 6614f50..e8fef13 100644
>> --- a/configs/am335x_evm_nor_defconfig
>> +++ b/configs/am335x_evm_nor_defconfig
>> @@ -1,4 +1,5 @@
>>  CONFIG_ARM=y
>> +CONFIG_AM33XX=y
>>  CONFIG_TARGET_AM335X_EVM=y
>>  CONFIG_SPL_STACK_R_ADDR=0x82000000
>>  CONFIG_NOR=y
>> diff --git a/configs/am335x_evm_norboot_defconfig b/configs/am335x_evm_norboot_defconfig
>> index 99fc555..063eea7 100644
>> --- a/configs/am335x_evm_norboot_defconfig
>> +++ b/configs/am335x_evm_norboot_defconfig
>> @@ -1,4 +1,5 @@
>>  CONFIG_ARM=y
>> +CONFIG_AM33XX=y
>>  CONFIG_TARGET_AM335X_EVM=y
>>  CONFIG_NOR=y
>>  CONFIG_NOR_BOOT=y
>> diff --git a/configs/am335x_evm_spiboot_defconfig b/configs/am335x_evm_spiboot_defconfig
>> index be123d6..f4c03a1 100644
>> --- a/configs/am335x_evm_spiboot_defconfig
>> +++ b/configs/am335x_evm_spiboot_defconfig
>> @@ -1,4 +1,5 @@
>>  CONFIG_ARM=y
>> +CONFIG_AM33XX=y
>>  CONFIG_TARGET_AM335X_EVM=y
>>  CONFIG_SPL_STACK_R_ADDR=0x82000000
>>  CONFIG_SPL=y
>> diff --git a/configs/am335x_evm_usbspl_defconfig b/configs/am335x_evm_usbspl_defconfig
>> index cba5e84..b689181 100644
>> --- a/configs/am335x_evm_usbspl_defconfig
>> +++ b/configs/am335x_evm_usbspl_defconfig
>> @@ -1,4 +1,5 @@
>>  CONFIG_ARM=y
>> +CONFIG_AM33XX=y
>>  CONFIG_TARGET_AM335X_EVM=y
>>  CONFIG_SPL_STACK_R_ADDR=0x82000000
>>  CONFIG_SPL=y
>> diff --git a/include/configs/ti_am335x_common.h b/include/configs/ti_am335x_common.h
>> index 25c9643..4294c25 100644
>> --- a/include/configs/ti_am335x_common.h
>> +++ b/include/configs/ti_am335x_common.h
>> @@ -12,7 +12,9 @@
>>  #ifndef __CONFIG_TI_AM335X_COMMON_H__
>>  #define __CONFIG_TI_AM335X_COMMON_H__
>>  
>> +#ifndef CONFIG_AM33XX
>>  #define CONFIG_AM33XX
>> +#endif
>>  #define CONFIG_ARCH_CPU_INIT
>>  #define CONFIG_SYS_CACHELINE_SIZE       64
>>  #define CONFIG_MAX_RAM_BANK_SIZE	(1024 << 20)	/* 1GB */
>>

[U-Boot] [PATCH 07/13] am33xx: config.mk: Add support for additional secure boot image types

[Andrew F. Davis]

Depending on the boot media, different images are needed
for secure devices. The build generates u-boot*_HS_* files
as appropriate for the different boot modes.

For AM33xx devices additional image types are needed for
various SPL boot modes as the ROM checks for the name of
the boot mode in the file it loads.

Signed-off-by: Andrew F. Davis <afd@ti.com>
---
 arch/arm/cpu/armv7/am33xx/config.mk | 27 +++++++++++++++++++++++++--
 1 file changed, 25 insertions(+), 2 deletions(-)

diff --git a/arch/arm/cpu/armv7/am33xx/config.mk b/arch/arm/cpu/armv7/am33xx/config.mk
index d4eb21c..8e655d7 100644
--- a/arch/arm/cpu/armv7/am33xx/config.mk
+++ b/arch/arm/cpu/armv7/am33xx/config.mk
@@ -12,13 +12,36 @@ ifeq ($(CONFIG_TI_SECURE_DEVICE),y)
 # For booting from SPI use
 # u-boot-spl_HS_SPI_X-LOADER to program flash
 #
-# For booting spl from all other  media
-# use u-boot-spl_HS_ISSW
+# On AM43XX:
+#
+# For booting spl from all other media use
+# u-boot-spl_HS_ISSW
+#
+# On AM33XX:
+#
+# For booting spl from NOR flash or QSPI use
+# u-boot-spl_HS_XIP_X-LOADER
+#
+# For booting spl from NAND flash use
+# u-boot-spl_HS_X-LOADER
+#
+# For booting spl from SD/MMC/eMMC media use
+# u-boot-spl_HS_MLO
+#
+# For booting spl over UART, USB, or Ethernet use
+# u-boot-spl_HS_2ND
 #
 # Refer to README.ti-secure for more info
 #
 ALL-y	+= u-boot-spl_HS_ISSW
 ALL-$(CONFIG_SPL_SPI_SUPPORT) += u-boot-spl_HS_SPI_X-LOADER
+ALL-$(CONFIG_SPL_QSPI_BOOT) += u-boot-spl_HS_XIP_X-LOADER
+ALL-$(CONFIG_SPL_NOR_BOOT) += u-boot-spl_HS_XIP_X-LOADER
+ALL-$(CONFIG_SPL_NAND_BOOT) += u-boot-spl_HS_X-LOADER
+ALL-$(CONFIG_SPL_SD_BOOT) += u-boot-spl_HS_MLO
+ALL-$(CONFIG_SPL_UART_BOOT) += u-boot-spl_HS_2ND
+ALL-$(CONFIG_SPL_USB_BOOT) += u-boot-spl_HS_2ND
+ALL-$(CONFIG_SPL_NET_BOOT) += u-boot-spl_HS_2ND
 else
 ALL-y	+= MLO
 ALL-$(CONFIG_SPL_SPI_SUPPORT) += MLO.byteswap
-- 
2.9.2

[U-Boot] [PATCH 08/13] am33xx: config.mk: Fix option used to enable SPI SPL image type

[Andrew F. Davis]

Before the addition of SPL boot media type Kconfig options there was no
way to determine what boot media the SPL would be booted from, so
it was assumed that if the SPL could load U-Boot proper via SPI then
the SPL itself would probably also be loaded from SPI.

Use the new SPL_SPI_BOOT option to enable the generation an SPL image
capable of being booted from SPI, and not have this depend on the SPL's
media loading capabilities.

Signed-off-by: Andrew F. Davis <afd@ti.com>
---
 arch/arm/cpu/armv7/am33xx/config.mk | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/cpu/armv7/am33xx/config.mk b/arch/arm/cpu/armv7/am33xx/config.mk
index 8e655d7..2f53df8 100644
--- a/arch/arm/cpu/armv7/am33xx/config.mk
+++ b/arch/arm/cpu/armv7/am33xx/config.mk
@@ -34,7 +34,7 @@ ifeq ($(CONFIG_TI_SECURE_DEVICE),y)
 # Refer to README.ti-secure for more info
 #
 ALL-y	+= u-boot-spl_HS_ISSW
-ALL-$(CONFIG_SPL_SPI_SUPPORT) += u-boot-spl_HS_SPI_X-LOADER
+ALL-$(CONFIG_SPL_SPI_BOOT) += u-boot-spl_HS_SPI_X-LOADER
 ALL-$(CONFIG_SPL_QSPI_BOOT) += u-boot-spl_HS_XIP_X-LOADER
 ALL-$(CONFIG_SPL_NOR_BOOT) += u-boot-spl_HS_XIP_X-LOADER
 ALL-$(CONFIG_SPL_NAND_BOOT) += u-boot-spl_HS_X-LOADER
-- 
2.9.2

[U-Boot] [PATCH 09/13] doc: Update info on using AM33xx secure devices from TI

[Andrew F. Davis]

Add a section describing the additional boot types used on AM33xx
secure devices.

Signed-off-by: Andrew F. Davis <afd@ti.com>
---
 doc/README.ti-secure | 32 ++++++++++++++++++++++++++++++++
 1 file changed, 32 insertions(+)

diff --git a/doc/README.ti-secure b/doc/README.ti-secure
index 54c996d..9b0fbf9 100644
--- a/doc/README.ti-secure
+++ b/doc/README.ti-secure
@@ -43,6 +43,38 @@ Booting of U-Boot SPL
 	The script is basically the only required interface to the TI SECDEV
 	package for creating a bootable SPL image for secure TI devices.
 
+	Invoking the script for AM33xx Secure Devices
+	=============================================
+
+	create-boot-image.sh \
+		<IMAGE_FLAG> <INPUT_FILE> <OUTPUT_FILE> <SPL_LOAD_ADDR>
+
+	<IMAGE_FLAG> is a value that specifies the type of the image to
+	generate OR the action the image generation tool will take. Valid
+	values are:
+		SPI_X-LOADER - Generates an image for SPI flash (byte swapped)
+		X-LOADER - Generates an image for non-XIP flash
+		MLO - Generates an image for SD/MMC/eMMC media
+		2ND - Generates an image for USB, UART and Ethernet
+		XIP_X-LOADER - Generates a single stage u-boot for NOR/QSPI XiP
+
+	<INPUT_FILE> is the full path and filename of the public world boot
+	loaderbinary file (depending on the boot media, this is usually
+	either u-boot-spl.bin or u-boot.bin).
+
+	<OUTPUT_FILE> is the full path and filename of the final secure
+	image. The output binary images should be used in place of the standard
+	non-secure binary images (see the platform-specific user's guides and
+	releases notes for how the non-secure images are typically used)
+	u-boot-spl_HS_SPI_X-LOADER - byte swapped boot image for SPI flash
+	u-boot-spl_HS_X-LOADER - boot image for NAND or SD/MMC/eMMC rawmode
+	u-boot-spl_HS_MLO - boot image for SD/MMC/eMMC media
+	u-boot-spl_HS_2ND - boot image for USB, UART and Ethernet
+	u-boot_HS_XIP_X-LOADER - boot image for NOR or QSPI Xip flash
+
+	<SPL_LOAD_ADDR> is the address at which SOC ROM should load the
+	<INPUT_FILE>
+
 	Invoking the script for AM43xx Secure Devices
 	=============================================
 
-- 
2.9.2

[U-Boot] [PATCH 10/13] ti: omap-common: Allow AM33xx devices to be built securely

[Andrew F. Davis]

Like OMAP54xx and AM43xx family SoCs, AM33xx based SoCs have high
security enabled models. Allow AM33xx devices to be built with
HS Device Type Support.

Signed-off-by: Andrew F. Davis <afd@ti.com>
---
 arch/arm/cpu/armv7/omap-common/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/cpu/armv7/omap-common/Kconfig b/arch/arm/cpu/armv7/omap-common/Kconfig
index 7b39506..4daccd9 100644
--- a/arch/arm/cpu/armv7/omap-common/Kconfig
+++ b/arch/arm/cpu/armv7/omap-common/Kconfig
@@ -1,6 +1,6 @@
 config TI_SECURE_DEVICE
 	bool "HS Device Type Support"
-	depends on OMAP54XX || AM43XX
+	depends on OMAP54XX || AM43XX || AM33XX
 	help
 	  If a high secure (HS) device type is being used, this config
 	  must be set. This option impacts various aspects of the
-- 
2.9.2

[U-Boot] [PATCH 11/13] omap: Use SD_BOOT in place of EMMC_BOOT

[Andrew F. Davis]

The config option EMMC_BOOT is used in several OMAP based platforms with
the same meaning as the existing SD_BOOT. Convert all uses, no functional
changes.

Signed-off-by: Andrew F. Davis <afd@ti.com>
---
 board/ti/am335x/mux.c                    | 4 ++--
 configs/am335x_boneblack_defconfig       | 2 +-
 configs/am335x_boneblack_vboot_defconfig | 3 ++-
 configs/am335x_sl50_defconfig            | 2 +-
 configs/brppt1_mmc_defconfig             | 3 ++-
 configs/brppt1_spi_defconfig             | 3 ++-
 include/configs/am335x_evm.h             | 2 +-
 include/configs/am335x_sl50.h            | 2 +-
 include/configs/bav335x.h                | 2 +-
 include/configs/brppt1.h                 | 6 +++---
 10 files changed, 16 insertions(+), 13 deletions(-)

diff --git a/board/ti/am335x/mux.c b/board/ti/am335x/mux.c
index 8afa5f9..2d580d2 100644
--- a/board/ti/am335x/mux.c
+++ b/board/ti/am335x/mux.c
@@ -383,9 +383,9 @@ void enable_board_pin_mux(void)
 		/* Beaglebone LT pinmux */
 		configure_module_pin_mux(mii1_pin_mux);
 		configure_module_pin_mux(mmc0_pin_mux);
-#if defined(CONFIG_NAND) && defined(CONFIG_EMMC_BOOT)
+#if defined(CONFIG_NAND) && defined(CONFIG_SD_BOOT)
 		configure_module_pin_mux(nand_pin_mux);
-#elif defined(CONFIG_NOR) && defined(CONFIG_EMMC_BOOT)
+#elif defined(CONFIG_NOR) && defined(CONFIG_SD_BOOT)
 		configure_module_pin_mux(bone_norcape_pin_mux);
 #else
 		configure_module_pin_mux(mmc1_pin_mux);
diff --git a/configs/am335x_boneblack_defconfig b/configs/am335x_boneblack_defconfig
index 30ff029..2fc46ae 100644
--- a/configs/am335x_boneblack_defconfig
+++ b/configs/am335x_boneblack_defconfig
@@ -5,7 +5,7 @@ CONFIG_SPL_STACK_R_ADDR=0x82000000
 CONFIG_SPL=y
 CONFIG_SPL_STACK_R=y
 CONFIG_FIT=y
-CONFIG_SYS_EXTRA_OPTIONS="EMMC_BOOT"
+CONFIG_SD_BOOT=y
 CONFIG_HUSH_PARSER=y
 CONFIG_AUTOBOOT_KEYED=y
 CONFIG_AUTOBOOT_PROMPT="Press SPACE to abort autoboot in %d seconds\n"
diff --git a/configs/am335x_boneblack_vboot_defconfig b/configs/am335x_boneblack_vboot_defconfig
index 7ff0c87..57b2606 100644
--- a/configs/am335x_boneblack_vboot_defconfig
+++ b/configs/am335x_boneblack_vboot_defconfig
@@ -8,7 +8,8 @@ CONFIG_SPL_STACK_R=y
 CONFIG_FIT=y
 CONFIG_FIT_VERBOSE=y
 CONFIG_FIT_SIGNATURE=y
-CONFIG_SYS_EXTRA_OPTIONS="EMMC_BOOT,ENABLE_VBOOT"
+CONFIG_SYS_EXTRA_OPTIONS="ENABLE_VBOOT"
+CONFIG_SD_BOOT=y
 CONFIG_HUSH_PARSER=y
 CONFIG_AUTOBOOT_KEYED=y
 CONFIG_AUTOBOOT_PROMPT="Press SPACE to abort autoboot in %d seconds\n"
diff --git a/configs/am335x_sl50_defconfig b/configs/am335x_sl50_defconfig
index 01c1eeb..cdb94bb 100644
--- a/configs/am335x_sl50_defconfig
+++ b/configs/am335x_sl50_defconfig
@@ -4,7 +4,7 @@ CONFIG_SPL_STACK_R_ADDR=0x82000000
 CONFIG_SPL=y
 CONFIG_SPL_STACK_R=y
 CONFIG_FIT=y
-CONFIG_SYS_EXTRA_OPTIONS="EMMC_BOOT"
+CONFIG_SD_BOOT=y
 CONFIG_HUSH_PARSER=y
 # CONFIG_AUTOBOOT is not set
 CONFIG_CMD_BOOTZ=y
diff --git a/configs/brppt1_mmc_defconfig b/configs/brppt1_mmc_defconfig
index cf2800b..2a8b4c4 100644
--- a/configs/brppt1_mmc_defconfig
+++ b/configs/brppt1_mmc_defconfig
@@ -2,7 +2,8 @@ CONFIG_ARM=y
 CONFIG_TARGET_BRPPT1=y
 CONFIG_SPL=y
 CONFIG_OF_BOARD_SETUP=y
-CONFIG_SYS_EXTRA_OPTIONS="SERIAL1,CONS_INDEX=1,EMMC_BOOT"
+CONFIG_SYS_EXTRA_OPTIONS="SERIAL1,CONS_INDEX=1"
+CONFIG_SD_BOOT=y
 CONFIG_BOOTDELAY=-2
 CONFIG_HUSH_PARSER=y
 CONFIG_CMD_BOOTZ=y
diff --git a/configs/brppt1_spi_defconfig b/configs/brppt1_spi_defconfig
index fee9973..47636c7 100644
--- a/configs/brppt1_spi_defconfig
+++ b/configs/brppt1_spi_defconfig
@@ -2,7 +2,8 @@ CONFIG_ARM=y
 CONFIG_TARGET_BRPPT1=y
 CONFIG_SPL=y
 CONFIG_OF_BOARD_SETUP=y
-CONFIG_SYS_EXTRA_OPTIONS="SERIAL1,CONS_INDEX=1,SPI_BOOT,EMMC_BOOT"
+CONFIG_SYS_EXTRA_OPTIONS="SERIAL1,CONS_INDEX=1,SPI_BOOT"
+CONFIG_SD_BOOT=y
 CONFIG_SPI_BOOT=y
 CONFIG_BOOTDELAY=-2
 CONFIG_HUSH_PARSER=y
diff --git a/include/configs/am335x_evm.h b/include/configs/am335x_evm.h
index 2b65890..743ecb5 100644
--- a/include/configs/am335x_evm.h
+++ b/include/configs/am335x_evm.h
@@ -416,7 +416,7 @@
 					"512k(u-boot),128k(u-boot-env1)," \
 					"128k(u-boot-env2),3464k(kernel)," \
 					"-(rootfs)"
-#elif defined(CONFIG_EMMC_BOOT)
+#elif defined(CONFIG_SD_BOOT)
 #define CONFIG_ENV_IS_IN_MMC
 #define CONFIG_SPL_ENV_SUPPORT
 #define CONFIG_SYS_MMC_ENV_DEV		1
diff --git a/include/configs/am335x_sl50.h b/include/configs/am335x_sl50.h
index 8454872..2854536 100644
--- a/include/configs/am335x_sl50.h
+++ b/include/configs/am335x_sl50.h
@@ -114,7 +114,7 @@
 #define CONFIG_SPL_NET_VCI_STRING	"AM335x U-Boot SPL"
 #endif
 
-#if defined(CONFIG_EMMC_BOOT)
+#if defined(CONFIG_SD_BOOT)
 #undef CONFIG_ENV_IS_NOWHERE
 #define CONFIG_ENV_IS_IN_MMC
 #define CONFIG_SPL_ENV_SUPPORT
diff --git a/include/configs/bav335x.h b/include/configs/bav335x.h
index e391c91..8743db4 100644
--- a/include/configs/bav335x.h
+++ b/include/configs/bav335x.h
@@ -548,7 +548,7 @@ DEFAULT_LINUX_BOOT_ENV \
 					"512k(u-boot),128k(u-boot-env1)," \
 					"128k(u-boot-env2),3464k(kernel)," \
 					"-(rootfs)"
-#elif defined(CONFIG_EMMC_BOOT)
+#elif defined(CONFIG_SD_BOOT)
 #undef CONFIG_ENV_IS_NOWHERE
 #define CONFIG_ENV_IS_IN_MMC
 #define CONFIG_SPL_ENV_SUPPORT
diff --git a/include/configs/brppt1.h b/include/configs/brppt1.h
index 6a239b5..69a1adc 100644
--- a/include/configs/brppt1.h
+++ b/include/configs/brppt1.h
@@ -50,7 +50,7 @@
 #define CONFIG_MACH_TYPE		0xFFFFFFFF /* TODO: check with kernel*/
 
 /* MMC/SD IP block */
-#if defined(CONFIG_EMMC_BOOT)
+#if defined(CONFIG_SD_BOOT)
  #define CONFIG_MMC
  #define CONFIG_GENERIC_MMC
  #define CONFIG_OMAP_HSMMC
@@ -59,7 +59,7 @@
  #define CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR	0x300 /*addr. 0x60000 */
  #define CONFIG_SYS_U_BOOT_MAX_SIZE_SECTORS		0x200 /* 256 KB */
  #define CONFIG_SPL_MMC_SUPPORT
-#endif /* CONFIG_EMMC_BOOT */
+#endif /* CONFIG_SD_BOOT */
 
 /*
  * When we have SPI or NAND flash we expect to be making use of mtdparts,
@@ -269,7 +269,7 @@ MMCARGS
 #define CONFIG_ENV_OFFSET		(768 << 10) /* 768 KiB in */
 #define CONFIG_ENV_OFFSET_REDUND	(896 << 10) /* 896 KiB in */
 
-#elif defined(CONFIG_EMMC_BOOT)
+#elif defined(CONFIG_SD_BOOT)
 #undef CONFIG_ENV_IS_NOWHERE
 #define CONFIG_ENV_IS_IN_MMC
 #define CONFIG_SYS_MMC_ENV_DEV		0
-- 
2.9.2

[U-Boot] [PATCH 12/13] config: Remove usage of CONFIG_STORAGE_EMMC

[Andrew F. Davis]

This config option seems to be unused and is probably vestigial.
Remove it.

Signed-off-by: Andrew F. Davis <afd@ti.com>
---
 include/configs/am335x_evm.h  | 2 --
 include/configs/am335x_shc.h  | 2 --
 include/configs/am335x_sl50.h | 2 --
 include/configs/bav335x.h     | 2 --
 4 files changed, 8 deletions(-)

diff --git a/include/configs/am335x_evm.h b/include/configs/am335x_evm.h
index 743ecb5..e71069c 100644
--- a/include/configs/am335x_evm.h
+++ b/include/configs/am335x_evm.h
@@ -300,8 +300,6 @@
 #define CONFIG_FASTBOOT_BUF_ADDR	CONFIG_SYS_LOAD_ADDR
 #define CONFIG_FASTBOOT_BUF_SIZE	0x07000000
 
-/* To support eMMC booting */
-#define CONFIG_STORAGE_EMMC
 #define CONFIG_FASTBOOT_FLASH_MMC_DEV   1
 #endif
 
diff --git a/include/configs/am335x_shc.h b/include/configs/am335x_shc.h
index f2484cb..8708c91 100644
--- a/include/configs/am335x_shc.h
+++ b/include/configs/am335x_shc.h
@@ -287,8 +287,6 @@
 #define CONFIG_SPL_LDSCRIPT		"$(CPUDIR)/am33xx/u-boot-spl.lds"
 
 #ifndef CONFIG_SPL_USBETH_SUPPORT
-/* To support eMMC booting */
-#define CONFIG_STORAGE_EMMC
 #define CONFIG_FASTBOOT_FLASH_MMC_DEV   1
 #endif
 
diff --git a/include/configs/am335x_sl50.h b/include/configs/am335x_sl50.h
index 2854536..bad0317 100644
--- a/include/configs/am335x_sl50.h
+++ b/include/configs/am335x_sl50.h
@@ -91,8 +91,6 @@
 #define CONFIG_SPL_LDSCRIPT		"$(CPUDIR)/am33xx/u-boot-spl.lds"
 
 #ifndef CONFIG_SPL_USBETH_SUPPORT
-/* To support eMMC booting */
-#define CONFIG_STORAGE_EMMC
 #define CONFIG_FASTBOOT_FLASH_MMC_DEV   1
 #endif
 
diff --git a/include/configs/bav335x.h b/include/configs/bav335x.h
index 8743db4..b0f9cc4 100644
--- a/include/configs/bav335x.h
+++ b/include/configs/bav335x.h
@@ -451,8 +451,6 @@ DEFAULT_LINUX_BOOT_ENV \
 #define CONFIG_FASTBOOT_BUF_ADDR	CONFIG_SYS_LOAD_ADDR
 #define CONFIG_FASTBOOT_BUF_SIZE	0x07000000
 
-/* To support eMMC booting */
-#define CONFIG_STORAGE_EMMC
 #define CONFIG_FASTBOOT_FLASH_MMC_DEV   1
 #endif
 
-- 
2.9.2

[U-Boot] [PATCH 13/13] board: am33xx-hs: spl: Allow post-processing of FIT image on AM33xx

[Andrew F. Davis]

When CONFIG_FIT_IMAGE_POST_PROCESS or CONFIG_SPL_FIT_IMAGE_POST_PROCESS
is enabled board_fit_image_post_process will be called, add this
function to am33xx boards when CONFIG_TI_SECURE_DEVICE is set to
verify the loaded image.

Signed-off-by: Andrew F. Davis <afd@ti.com>
---
 board/ti/am335x/board.c | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/board/ti/am335x/board.c b/board/ti/am335x/board.c
index 56f4984..0ed16ca 100644
--- a/board/ti/am335x/board.c
+++ b/board/ti/am335x/board.c
@@ -25,6 +25,7 @@
 #include <asm/io.h>
 #include <asm/emif.h>
 #include <asm/gpio.h>
+#include <asm/omap_sec_common.h>
 #include <i2c.h>
 #include <miiphy.h>
 #include <cpsw.h>
@@ -775,3 +776,10 @@ int board_fit_config_name_match(const char *name)
 		return -1;
 }
 #endif
+
+#ifdef CONFIG_TI_SECURE_DEVICE
+void board_fit_image_post_process(void **p_image, size_t *p_size)
+{
+	secure_boot_verify_image(p_image, p_size);
+}
+#endif
-- 
2.9.2

[U-Boot] [PATCH 00/13] Cleanups to allow secure boot on AM33xx devices

[Lokesh Vutla]

On Thursday 18 August 2016 09:11 PM, Andrew F. Davis wrote:
> Hello all,
> 
> I've recently been tasked with enabling authenticated boot for AM33xx based
> devices. This work is similar to what has already been done for the AM43xx
> and AM57xx SoCs and leverages much of the infrastructure from them.
> 
> The big difference here is the size of SRAM available on AM33xx being much
> less than on the other SoCs, when performing a secure boot this limits
> the maximum size of the SPL to just ~41k, the SPL currently generated for
> AM33xx SoCs is ~70k. To trim down the SPL we move various options from
> the config headers to the Kconfig system so we can selectively disable
> them in HS specific defconfigs.
> 
> To do this we start in patch 1 and 2 by creating Kconfig options for
> specifying what for what media the SPL should be able to load U-Boot
> from and for what media the SPL should itself be loaded from, respectively.
> We do this as the secure signature contains the name of the SPL boot
> media, and to reduce size. Also this works to reduce confusion
> in build types vs load types, we fix such an issue in patch 8.
> 
> In patch 3 and 4 we use the newly added _SUPPORT Kconfigs on a couple
> boards.
> 
> The rest are hopefully explained well enough in the commit message.

Have you tried doing build tests using buildman?. It is throwing lot of
errors.

Thanks and regards,
Lokesh


> 
> Thanks,
> Andrew
> 
> Andrew F. Davis (13):
>   spl: Kconfig: Add SPL_<media>_SUPPORT as Kconfig option
>   spl: Kconfig: Add SPL_<media>_BOOT as Kconfig option
>   spl: Kconfig: Add CONFIG_SPL_TEXT_BASE as Kconfig option
>   config: am335x_evm: Move CONFIG_SPL_YMODEM_SUPPORT to Kconfig
>   config: am43xx_evm: Move CONFIG_SPL_YMODEM_SUPPORT to Kconfig
>   Kconfig: Separate AM33XX SOC config from target board config
>   am33xx: config.mk: Add support for additional secure boot image types
>   am33xx: config.mk: Fix option used to enable SPI SPL image type
>   doc: Update info on using AM33xx secure devices from TI
>   ti: omap-common: Allow AM33xx devices to be built securely
>   omap: Use SD_BOOT in place of EMMC_BOOT
>   config: Remove usage of CONFIG_STORAGE_EMMC
>   board: am33xx-hs: spl: Allow post-processing of FIT image on AM33xx
> 
>  Kconfig                                   |  8 ++++
>  arch/arm/Kconfig                          | 20 ++++----
>  arch/arm/cpu/armv7/am33xx/Kconfig         | 18 ++++++++
>  arch/arm/cpu/armv7/am33xx/config.mk       | 29 ++++++++++--
>  arch/arm/cpu/armv7/omap-common/Kconfig    |  2 +-
>  board/ti/am335x/board.c                   |  8 ++++
>  board/ti/am335x/mux.c                     |  4 +-
>  common/Kconfig                            | 76 +++++++++++++++++++++++++++++++
>  common/spl/Kconfig                        | 54 ++++++++++++++++++++++
>  configs/am335x_boneblack_defconfig        |  4 +-
>  configs/am335x_boneblack_vboot_defconfig  |  5 +-
>  configs/am335x_evm_defconfig              |  3 ++
>  configs/am335x_evm_nor_defconfig          |  2 +
>  configs/am335x_evm_norboot_defconfig      |  1 +
>  configs/am335x_evm_spiboot_defconfig      |  2 +
>  configs/am335x_evm_usbspl_defconfig       |  1 +
>  configs/am335x_sl50_defconfig             |  2 +-
>  configs/am43xx_evm_defconfig              |  1 +
>  configs/am43xx_evm_ethboot_defconfig      |  1 +
>  configs/am43xx_evm_qspiboot_defconfig     |  1 +
>  configs/am43xx_evm_usbhost_boot_defconfig |  1 +
>  configs/am43xx_hs_evm_defconfig           |  1 +
>  configs/brppt1_mmc_defconfig              |  3 +-
>  configs/brppt1_spi_defconfig              |  3 +-
>  doc/README.ti-secure                      | 32 +++++++++++++
>  include/configs/am335x_evm.h              |  6 +--
>  include/configs/am335x_shc.h              |  2 -
>  include/configs/am335x_sl50.h             |  4 +-
>  include/configs/am43xx_evm.h              |  1 -
>  include/configs/bav335x.h                 |  4 +-
>  include/configs/brppt1.h                  |  6 +--
>  include/configs/ti_am335x_common.h        |  4 ++
>  32 files changed, 272 insertions(+), 37 deletions(-)
>  create mode 100644 common/spl/Kconfig
>