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.
  
  

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!

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.

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!

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

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.

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. :(

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))

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 */