[U-Boot] [PATCH V2 1/2] Kconfig: make NOR_BOOT a common option

[U-Boot] [PATCH V2 1/2] Kconfig: make NOR_BOOT a common option

[Peng Fan]

Not only am335x supports booting from NOR, i.MX6 SoCs also
supports booting from NOR. Make NOR_BOOT a common
option to let different SoCs share it.

Signed-off-by: Peng Fan <peng.fan@nxp.com>
Cc: Simon Glass <sjg@chromium.org>
Cc: Heiko Schocher <hs@denx.de>
Cc: Joe Hershberger <joe.hershberger@ni.com>
Cc: Christophe Ricard <christophe-h.ricard@st.com>
Cc: Bin Meng <bmeng.cn@gmail.com>
Cc: Francois Retief <fgretief@spaceteq.co.za>
Cc: Tom Rini <trini@konsulko.com>
---

V2:
 New patch

 board/ti/am335x/Kconfig |  9 ---------
 common/Kconfig          | 13 +++++++++++++
 2 files changed, 13 insertions(+), 9 deletions(-)

diff --git a/board/ti/am335x/Kconfig b/board/ti/am335x/Kconfig
index 11ef3ca..97374bd 100644
--- a/board/ti/am335x/Kconfig
+++ b/board/ti/am335x/Kconfig
@@ -29,15 +29,6 @@ config NOR
 	  In practice this is seen as a NOR flash module connected to the
 	  "memory cape" for the BeagleBone family.
 
-config NOR_BOOT
-	bool "Support for booting from NOR flash"
-	depends on NOR
-	help
-	  Enabling this will make a U-Boot binary that is capable of being
-	  booted via NOR.  In this case we will enable certain pinmux early
-	  as the ROM only partially sets up pinmux.  We also default to using
-	  NOR for environment.
-
 source "board/ti/common/Kconfig"
 
 endif
diff --git a/common/Kconfig b/common/Kconfig
index 4d17b10..04d092c 100644
--- a/common/Kconfig
+++ b/common/Kconfig
@@ -97,6 +97,19 @@ config BOOTSTAGE_STASH_SIZE
 
 endmenu
 
+menu "Boot media"
+
+config NOR_BOOT
+	bool "Support for booting from NOR flash"
+	depends on NOR
+	help
+	  Enabling this will make a U-Boot binary that is capable of being
+	  booted via NOR.  In this case we will enable certain pinmux early
+	  as the ROM only partially sets up pinmux.  We also default to using
+	  NOR for environment.
+
+endmenu
+
 config BOOTDELAY
 	int "delay in seconds before automatically booting"
 	default 0
-- 
2.6.2

[U-Boot] [PATCH V2 2/2] common: add new boot media kconfig entry

[Peng Fan]

Add CONFIG_{SD|NAND|ONENAND|SPI|QSPI|SATA}_BOOT kconfig entries.

SoCs supports loading U-Boot from different medias to DRAM, such as
i.MX6/7 supports loading U-Boot to DRAM from sd/emmc/nand/qspi/spi/sata
and etc. For i.MX, imximage will generate different IVT headers according
to boot medias.

Signed-off-by: Peng Fan <peng.fan@nxp.com>
Cc: Simon Glass <sjg@chromium.org>
Cc: Heiko Schocher <hs@denx.de>
Cc: Joe Hershberger <joe.hershberger@ni.com>
Cc: Bin Meng <bmeng.cn@gmail.com>
Cc: Christophe Ricard <christophe-h.ricard@st.com>
Cc: Nikita Kiryanov <nikita@compulab.co.il>
Cc: Francois Retief <fgretief@spaceteq.co.za>
Cc: Tom Rini <trini@konsulko.com>
---

V2:
 Move NOR_BOOT to the patch 1/2.
 The idea of this patch is for adding different boot media support for
 i.MXes. And I'll post out following patches if this patch is accepted.
 I ran moveconfig.py, but I did not include the results into a patch.
 This patch does not break the boards which defined NAND_BOOT/SD_BOOT and
 etc, and I prefer to let board owners to move to defconfig later.

 common/Kconfig | 48 ++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 48 insertions(+)

diff --git a/common/Kconfig b/common/Kconfig
index 04d092c..f0f6ee1 100644
--- a/common/Kconfig
+++ b/common/Kconfig
@@ -108,6 +108,54 @@ config NOR_BOOT
 	  as the ROM only partially sets up pinmux.  We also default to using
 	  NOR for environment.
 
+config NAND_BOOT
+	bool "Support for booting from NAND flash"
+	default n
+	help
+	  Enabling this will make a U-Boot binary that is capable of being
+	  booted via NAND flash. This is not a must, some SoCs need this,
+	  somes not.
+
+config ONENAND_BOOT
+	bool "Support for booting from ONENAND"
+	default n
+	help
+	  Enabling this will make a U-Boot binary that is capable of being
+	  booted via ONENAND. This is not a must, some SoCs need this,
+	  somes not.
+
+config QSPI_BOOT
+	bool "Support for booting from QSPI flash"
+	default n
+	help
+	  Enabling this will make a U-Boot binary that is capable of being
+	  booted via QSPI flash. This is not a must, some SoCs need this,
+	  somes not.
+
+config SATA_BOOT
+	bool "Support for booting from SATA"
+	default n
+	help
+	  Enabling this will make a U-Boot binary that is capable of being
+	  booted via SATA. This is not a must, some SoCs need this,
+	  somes not.
+
+config SD_BOOT
+	bool "Support for booting from SD/EMMC"
+	default n
+	help
+	  Enabling this will make a U-Boot binary that is capable of being
+	  booted via SD/EMMC. This is not a must, some SoCs need this,
+	  somes not.
+
+config SPI_BOOT
+	bool "Support for booting from SPI flash"
+	default n
+	help
+	  Enabling this will make a U-Boot binary that is capable of being
+	  booted via SPI flash. This is not a must, some SoCs need this,
+	  somes not.
+
 endmenu
 
 config BOOTDELAY
-- 
2.6.2

[U-Boot] [PATCH V2 2/2] common: add new boot media kconfig entry

[Masahiro Yamada]

2016-06-17 18:39 GMT+09:00 Peng Fan <van.freenix@gmail.com>:
> Add CONFIG_{SD|NAND|ONENAND|SPI|QSPI|SATA}_BOOT kconfig entries.
>
> SoCs supports loading U-Boot from different medias to DRAM, such as
> i.MX6/7 supports loading U-Boot to DRAM from sd/emmc/nand/qspi/spi/sata
> and etc. For i.MX, imximage will generate different IVT headers according
> to boot medias.
>
> Signed-off-by: Peng Fan <peng.fan@nxp.com>
> Cc: Simon Glass <sjg@chromium.org>
> Cc: Heiko Schocher <hs@denx.de>
> Cc: Joe Hershberger <joe.hershberger@ni.com>
> Cc: Bin Meng <bmeng.cn@gmail.com>
> Cc: Christophe Ricard <christophe-h.ricard@st.com>
> Cc: Nikita Kiryanov <nikita@compulab.co.il>
> Cc: Francois Retief <fgretief@spaceteq.co.za>
> Cc: Tom Rini <trini@konsulko.com>
> ---
>
> V2:
>  Move NOR_BOOT to the patch 1/2.
>  The idea of this patch is for adding different boot media support for
>  i.MXes. And I'll post out following patches if this patch is accepted.
>  I ran moveconfig.py, but I did not include the results into a patch.
>  This patch does not break the boards which defined NAND_BOOT/SD_BOOT and
>  etc, and I prefer to let board owners to move to defconfig later.
>
>  common/Kconfig | 48 ++++++++++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 48 insertions(+)
>
> diff --git a/common/Kconfig b/common/Kconfig
> index 04d092c..f0f6ee1 100644
> --- a/common/Kconfig
> +++ b/common/Kconfig
> @@ -108,6 +108,54 @@ config NOR_BOOT
>           as the ROM only partially sets up pinmux.  We also default to using
>           NOR for environment.
>
> +config NAND_BOOT
> +       bool "Support for booting from NAND flash"
> +       default n
> +       help
> +         Enabling this will make a U-Boot binary that is capable of being
> +         booted via NAND flash. This is not a must, some SoCs need this,
> +         somes not.
> +
> +config ONENAND_BOOT
> +       bool "Support for booting from ONENAND"
> +       default n
> +       help
> +         Enabling this will make a U-Boot binary that is capable of being
> +         booted via ONENAND. This is not a must, some SoCs need this,
> +         somes not.
> +
> +config QSPI_BOOT
> +       bool "Support for booting from QSPI flash"
> +       default n
> +       help
> +         Enabling this will make a U-Boot binary that is capable of being
> +         booted via QSPI flash. This is not a must, some SoCs need this,
> +         somes not.
> +
> +config SATA_BOOT
> +       bool "Support for booting from SATA"
> +       default n
> +       help
> +         Enabling this will make a U-Boot binary that is capable of being
> +         booted via SATA. This is not a must, some SoCs need this,
> +         somes not.
> +
> +config SD_BOOT
> +       bool "Support for booting from SD/EMMC"
> +       default n
> +       help
> +         Enabling this will make a U-Boot binary that is capable of being
> +         booted via SD/EMMC. This is not a must, some SoCs need this,
> +         somes not.
> +
> +config SPI_BOOT
> +       bool "Support for booting from SPI flash"
> +       default n
> +       help
> +         Enabling this will make a U-Boot binary that is capable of being
> +         booted via SPI flash. This is not a must, some SoCs need this,
> +         somes not.
> +
>  endmenu


Do you intend to replace
CONFIG_SPL_NOR_SUPPORT
CONFIG_SPL_NAND_SUPPORT
CONFIG_SPL_USB_SUPPORT
CONFIG_SPL_MMC_SUPPORT
etc. with these options?


Currently, common/spl/spl.c uses CONFIG_SPL_*_SUPPORT
to enable/disable capable boot devices.





-- 
Best Regards
Masahiro Yamada

[U-Boot] [PATCH V2 2/2] common: add new boot media kconfig entry

[Peng Fan]

Hi Masahiro,

+Simon
On Fri, Jun 17, 2016 at 07:08:23PM +0900, Masahiro Yamada wrote:
>2016-06-17 18:39 GMT+09:00 Peng Fan <van.freenix@gmail.com>:
>> Add CONFIG_{SD|NAND|ONENAND|SPI|QSPI|SATA}_BOOT kconfig entries.
>>
>> SoCs supports loading U-Boot from different medias to DRAM, such as
>> i.MX6/7 supports loading U-Boot to DRAM from sd/emmc/nand/qspi/spi/sata
>> and etc. For i.MX, imximage will generate different IVT headers according
>> to boot medias.
>>
>> Signed-off-by: Peng Fan <peng.fan@nxp.com>
>> Cc: Simon Glass <sjg@chromium.org>
>> Cc: Heiko Schocher <hs@denx.de>
>> Cc: Joe Hershberger <joe.hershberger@ni.com>
>> Cc: Bin Meng <bmeng.cn@gmail.com>
>> Cc: Christophe Ricard <christophe-h.ricard@st.com>
>> Cc: Nikita Kiryanov <nikita@compulab.co.il>
>> Cc: Francois Retief <fgretief@spaceteq.co.za>
>> Cc: Tom Rini <trini@konsulko.com>
>> ---
>>
>> V2:
>>  Move NOR_BOOT to the patch 1/2.
>>  The idea of this patch is for adding different boot media support for
>>  i.MXes. And I'll post out following patches if this patch is accepted.
>>  I ran moveconfig.py, but I did not include the results into a patch.
>>  This patch does not break the boards which defined NAND_BOOT/SD_BOOT and
>>  etc, and I prefer to let board owners to move to defconfig later.
>>
>>  common/Kconfig | 48 ++++++++++++++++++++++++++++++++++++++++++++++++
>>  1 file changed, 48 insertions(+)
>>
>> diff --git a/common/Kconfig b/common/Kconfig
>> index 04d092c..f0f6ee1 100644
>> --- a/common/Kconfig
>> +++ b/common/Kconfig
>> @@ -108,6 +108,54 @@ config NOR_BOOT
>>           as the ROM only partially sets up pinmux.  We also default to using
>>           NOR for environment.
>>
>> +config NAND_BOOT
>> +       bool "Support for booting from NAND flash"
>> +       default n
>> +       help
>> +         Enabling this will make a U-Boot binary that is capable of being
>> +         booted via NAND flash. This is not a must, some SoCs need this,
>> +         somes not.
>> +
>> +config ONENAND_BOOT
>> +       bool "Support for booting from ONENAND"
>> +       default n
>> +       help
>> +         Enabling this will make a U-Boot binary that is capable of being
>> +         booted via ONENAND. This is not a must, some SoCs need this,
>> +         somes not.
>> +
>> +config QSPI_BOOT
>> +       bool "Support for booting from QSPI flash"
>> +       default n
>> +       help
>> +         Enabling this will make a U-Boot binary that is capable of being
>> +         booted via QSPI flash. This is not a must, some SoCs need this,
>> +         somes not.
>> +
>> +config SATA_BOOT
>> +       bool "Support for booting from SATA"
>> +       default n
>> +       help
>> +         Enabling this will make a U-Boot binary that is capable of being
>> +         booted via SATA. This is not a must, some SoCs need this,
>> +         somes not.
>> +
>> +config SD_BOOT
>> +       bool "Support for booting from SD/EMMC"
>> +       default n
>> +       help
>> +         Enabling this will make a U-Boot binary that is capable of being
>> +         booted via SD/EMMC. This is not a must, some SoCs need this,
>> +         somes not.
>> +
>> +config SPI_BOOT
>> +       bool "Support for booting from SPI flash"
>> +       default n
>> +       help
>> +         Enabling this will make a U-Boot binary that is capable of being
>> +         booted via SPI flash. This is not a must, some SoCs need this,
>> +         somes not.
>> +
>>  endmenu
>
>
>Do you intend to replace
>CONFIG_SPL_NOR_SUPPORT
>CONFIG_SPL_NAND_SUPPORT
>CONFIG_SPL_USB_SUPPORT
>CONFIG_SPL_MMC_SUPPORT
>etc. with these options?
>

I missed these.

>
>Currently, common/spl/spl.c uses CONFIG_SPL_*_SUPPORT
>to enable/disable capable boot devices.

I think we could use a common option to replace the ones used in SPL.

Thanks,
Peng.
>
>
>
>
>
>-- 
>Best Regards
>Masahiro Yamada

[U-Boot] [PATCH V2 2/2] common: add new boot media kconfig entry

[Tom Rini]

On Sun, Jun 19, 2016 at 06:20:52PM +0800, Peng Fan wrote:
> Hi Masahiro,
> 
> +Simon
> On Fri, Jun 17, 2016 at 07:08:23PM +0900, Masahiro Yamada wrote:
> >2016-06-17 18:39 GMT+09:00 Peng Fan <van.freenix@gmail.com>:
> >> Add CONFIG_{SD|NAND|ONENAND|SPI|QSPI|SATA}_BOOT kconfig entries.
> >>
> >> SoCs supports loading U-Boot from different medias to DRAM, such as
> >> i.MX6/7 supports loading U-Boot to DRAM from sd/emmc/nand/qspi/spi/sata
> >> and etc. For i.MX, imximage will generate different IVT headers according
> >> to boot medias.
> >>
> >> Signed-off-by: Peng Fan <peng.fan@nxp.com>
> >> Cc: Simon Glass <sjg@chromium.org>
> >> Cc: Heiko Schocher <hs@denx.de>
> >> Cc: Joe Hershberger <joe.hershberger@ni.com>
> >> Cc: Bin Meng <bmeng.cn@gmail.com>
> >> Cc: Christophe Ricard <christophe-h.ricard@st.com>
> >> Cc: Nikita Kiryanov <nikita@compulab.co.il>
> >> Cc: Francois Retief <fgretief@spaceteq.co.za>
> >> Cc: Tom Rini <trini@konsulko.com>
> >> ---
> >>
> >> V2:
> >>  Move NOR_BOOT to the patch 1/2.
> >>  The idea of this patch is for adding different boot media support for
> >>  i.MXes. And I'll post out following patches if this patch is accepted.
> >>  I ran moveconfig.py, but I did not include the results into a patch.
> >>  This patch does not break the boards which defined NAND_BOOT/SD_BOOT and
> >>  etc, and I prefer to let board owners to move to defconfig later.
> >>
> >>  common/Kconfig | 48 ++++++++++++++++++++++++++++++++++++++++++++++++
> >>  1 file changed, 48 insertions(+)
> >>
> >> diff --git a/common/Kconfig b/common/Kconfig
> >> index 04d092c..f0f6ee1 100644
> >> --- a/common/Kconfig
> >> +++ b/common/Kconfig
> >> @@ -108,6 +108,54 @@ config NOR_BOOT
> >>           as the ROM only partially sets up pinmux.  We also default to using
> >>           NOR for environment.
> >>
> >> +config NAND_BOOT
> >> +       bool "Support for booting from NAND flash"
> >> +       default n
> >> +       help
> >> +         Enabling this will make a U-Boot binary that is capable of being
> >> +         booted via NAND flash. This is not a must, some SoCs need this,
> >> +         somes not.
> >> +
> >> +config ONENAND_BOOT
> >> +       bool "Support for booting from ONENAND"
> >> +       default n
> >> +       help
> >> +         Enabling this will make a U-Boot binary that is capable of being
> >> +         booted via ONENAND. This is not a must, some SoCs need this,
> >> +         somes not.
> >> +
> >> +config QSPI_BOOT
> >> +       bool "Support for booting from QSPI flash"
> >> +       default n
> >> +       help
> >> +         Enabling this will make a U-Boot binary that is capable of being
> >> +         booted via QSPI flash. This is not a must, some SoCs need this,
> >> +         somes not.
> >> +
> >> +config SATA_BOOT
> >> +       bool "Support for booting from SATA"
> >> +       default n
> >> +       help
> >> +         Enabling this will make a U-Boot binary that is capable of being
> >> +         booted via SATA. This is not a must, some SoCs need this,
> >> +         somes not.
> >> +
> >> +config SD_BOOT
> >> +       bool "Support for booting from SD/EMMC"
> >> +       default n
> >> +       help
> >> +         Enabling this will make a U-Boot binary that is capable of being
> >> +         booted via SD/EMMC. This is not a must, some SoCs need this,
> >> +         somes not.
> >> +
> >> +config SPI_BOOT
> >> +       bool "Support for booting from SPI flash"
> >> +       default n
> >> +       help
> >> +         Enabling this will make a U-Boot binary that is capable of being
> >> +         booted via SPI flash. This is not a must, some SoCs need this,
> >> +         somes not.
> >> +
> >>  endmenu
> >
> >
> >Do you intend to replace
> >CONFIG_SPL_NOR_SUPPORT
> >CONFIG_SPL_NAND_SUPPORT
> >CONFIG_SPL_USB_SUPPORT
> >CONFIG_SPL_MMC_SUPPORT
> >etc. with these options?
> >
> 
> I missed these.
> 
> >
> >Currently, common/spl/spl.c uses CONFIG_SPL_*_SUPPORT
> >to enable/disable capable boot devices.
> 
> I think we could use a common option to replace the ones used in SPL.

I'm not sure that CONFIG_xxx_BOOT and CONFIG_SPL_xxx_SUPPORT are the
same thing.  For example, CONFIG_NOR_BOOT on am335x means "we are
building to support booting from NOR, so include all of that stuff
that's normally not included".  While CONFIG_SPL_NAND_SUPPORT means
include NAND support in SPL, which is not mutually exclusive with MMC,
etc.

-- 
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/20160624/0a65d592/attachment.sig>

[U-Boot] [PATCH V2 2/2] common: add new boot media kconfig entry

[Peng Fan]

Hi Tom,

On Fri, Jun 24, 2016 at 06:57:44PM -0400, Tom Rini wrote:
>On Sun, Jun 19, 2016 at 06:20:52PM +0800, Peng Fan wrote:
>> Hi Masahiro,
>> 
>> +Simon
>> On Fri, Jun 17, 2016 at 07:08:23PM +0900, Masahiro Yamada wrote:
>> >2016-06-17 18:39 GMT+09:00 Peng Fan <van.freenix@gmail.com>:
>> >> Add CONFIG_{SD|NAND|ONENAND|SPI|QSPI|SATA}_BOOT kconfig entries.
>> >>
>> >> SoCs supports loading U-Boot from different medias to DRAM, such as
>> >> i.MX6/7 supports loading U-Boot to DRAM from sd/emmc/nand/qspi/spi/sata
>> >> and etc. For i.MX, imximage will generate different IVT headers according
>> >> to boot medias.
>> >>
>> >> Signed-off-by: Peng Fan <peng.fan@nxp.com>
>> >> Cc: Simon Glass <sjg@chromium.org>
>> >> Cc: Heiko Schocher <hs@denx.de>
>> >> Cc: Joe Hershberger <joe.hershberger@ni.com>
>> >> Cc: Bin Meng <bmeng.cn@gmail.com>
>> >> Cc: Christophe Ricard <christophe-h.ricard@st.com>
>> >> Cc: Nikita Kiryanov <nikita@compulab.co.il>
>> >> Cc: Francois Retief <fgretief@spaceteq.co.za>
>> >> Cc: Tom Rini <trini@konsulko.com>
>> >> ---
>> >>
>> >> V2:
>> >>  Move NOR_BOOT to the patch 1/2.
>> >>  The idea of this patch is for adding different boot media support for
>> >>  i.MXes. And I'll post out following patches if this patch is accepted.
>> >>  I ran moveconfig.py, but I did not include the results into a patch.
>> >>  This patch does not break the boards which defined NAND_BOOT/SD_BOOT and
>> >>  etc, and I prefer to let board owners to move to defconfig later.
>> >>
>> >>  common/Kconfig | 48 ++++++++++++++++++++++++++++++++++++++++++++++++
>> >>  1 file changed, 48 insertions(+)
>> >>
>> >> diff --git a/common/Kconfig b/common/Kconfig
>> >> index 04d092c..f0f6ee1 100644
>> >> --- a/common/Kconfig
>> >> +++ b/common/Kconfig
>> >> @@ -108,6 +108,54 @@ config NOR_BOOT
>> >>           as the ROM only partially sets up pinmux.  We also default to using
>> >>           NOR for environment.
>> >>
>> >> +config NAND_BOOT
>> >> +       bool "Support for booting from NAND flash"
>> >> +       default n
>> >> +       help
>> >> +         Enabling this will make a U-Boot binary that is capable of being
>> >> +         booted via NAND flash. This is not a must, some SoCs need this,
>> >> +         somes not.
>> >> +
>> >> +config ONENAND_BOOT
>> >> +       bool "Support for booting from ONENAND"
>> >> +       default n
>> >> +       help
>> >> +         Enabling this will make a U-Boot binary that is capable of being
>> >> +         booted via ONENAND. This is not a must, some SoCs need this,
>> >> +         somes not.
>> >> +
>> >> +config QSPI_BOOT
>> >> +       bool "Support for booting from QSPI flash"
>> >> +       default n
>> >> +       help
>> >> +         Enabling this will make a U-Boot binary that is capable of being
>> >> +         booted via QSPI flash. This is not a must, some SoCs need this,
>> >> +         somes not.
>> >> +
>> >> +config SATA_BOOT
>> >> +       bool "Support for booting from SATA"
>> >> +       default n
>> >> +       help
>> >> +         Enabling this will make a U-Boot binary that is capable of being
>> >> +         booted via SATA. This is not a must, some SoCs need this,
>> >> +         somes not.
>> >> +
>> >> +config SD_BOOT
>> >> +       bool "Support for booting from SD/EMMC"
>> >> +       default n
>> >> +       help
>> >> +         Enabling this will make a U-Boot binary that is capable of being
>> >> +         booted via SD/EMMC. This is not a must, some SoCs need this,
>> >> +         somes not.
>> >> +
>> >> +config SPI_BOOT
>> >> +       bool "Support for booting from SPI flash"
>> >> +       default n
>> >> +       help
>> >> +         Enabling this will make a U-Boot binary that is capable of being
>> >> +         booted via SPI flash. This is not a must, some SoCs need this,
>> >> +         somes not.
>> >> +
>> >>  endmenu
>> >
>> >
>> >Do you intend to replace
>> >CONFIG_SPL_NOR_SUPPORT
>> >CONFIG_SPL_NAND_SUPPORT
>> >CONFIG_SPL_USB_SUPPORT
>> >CONFIG_SPL_MMC_SUPPORT
>> >etc. with these options?
>> >
>> 
>> I missed these.
>> 
>> >
>> >Currently, common/spl/spl.c uses CONFIG_SPL_*_SUPPORT
>> >to enable/disable capable boot devices.
>> 
>> I think we could use a common option to replace the ones used in SPL.
>
>I'm not sure that CONFIG_xxx_BOOT and CONFIG_SPL_xxx_SUPPORT are the
>same thing.  For example, CONFIG_NOR_BOOT on am335x means "we are
>building to support booting from NOR, so include all of that stuff
>that's normally not included".  While CONFIG_SPL_NAND_SUPPORT means
>include NAND support in SPL, which is not mutually exclusive with MMC,
>etc.

ok. Then, better keep them. For i.MX6, CONFIG_XX_BOOT have the same meaning
with am335x as you said.

Do you have other comments? If not touching SPL, I would like to see this
patch set applied.

Thanks,
Peng.
>
>-- 
>Tom

[U-Boot] [PATCH V2 2/2] common: add new boot media kconfig entry

[Masahiro Yamada]

Hi.


2016-06-28 14:02 GMT+09:00 Peng Fan <van.freenix@gmail.com>:
> Hi Tom,
>
> On Fri, Jun 24, 2016 at 06:57:44PM -0400, Tom Rini wrote:
>>On Sun, Jun 19, 2016 at 06:20:52PM +0800, Peng Fan wrote:
>>> Hi Masahiro,
>>>
>>> +Simon
>>> On Fri, Jun 17, 2016 at 07:08:23PM +0900, Masahiro Yamada wrote:
>>> >2016-06-17 18:39 GMT+09:00 Peng Fan <van.freenix@gmail.com>:
>>> >> Add CONFIG_{SD|NAND|ONENAND|SPI|QSPI|SATA}_BOOT kconfig entries.
>>> >>
>>> >> SoCs supports loading U-Boot from different medias to DRAM, such as
>>> >> i.MX6/7 supports loading U-Boot to DRAM from sd/emmc/nand/qspi/spi/sata
>>> >> and etc. For i.MX, imximage will generate different IVT headers according
>>> >> to boot medias.
>>> >>
>>> >> Signed-off-by: Peng Fan <peng.fan@nxp.com>
>>> >> Cc: Simon Glass <sjg@chromium.org>
>>> >> Cc: Heiko Schocher <hs@denx.de>
>>> >> Cc: Joe Hershberger <joe.hershberger@ni.com>
>>> >> Cc: Bin Meng <bmeng.cn@gmail.com>
>>> >> Cc: Christophe Ricard <christophe-h.ricard@st.com>
>>> >> Cc: Nikita Kiryanov <nikita@compulab.co.il>
>>> >> Cc: Francois Retief <fgretief@spaceteq.co.za>
>>> >> Cc: Tom Rini <trini@konsulko.com>
>>> >> ---
>>> >>
>>> >> V2:
>>> >>  Move NOR_BOOT to the patch 1/2.
>>> >>  The idea of this patch is for adding different boot media support for
>>> >>  i.MXes. And I'll post out following patches if this patch is accepted.
>>> >>  I ran moveconfig.py, but I did not include the results into a patch.
>>> >>  This patch does not break the boards which defined NAND_BOOT/SD_BOOT and
>>> >>  etc, and I prefer to let board owners to move to defconfig later.
>>> >>
>>> >>  common/Kconfig | 48 ++++++++++++++++++++++++++++++++++++++++++++++++
>>> >>  1 file changed, 48 insertions(+)
>>> >>
>>> >> diff --git a/common/Kconfig b/common/Kconfig
>>> >> index 04d092c..f0f6ee1 100644
>>> >> --- a/common/Kconfig
>>> >> +++ b/common/Kconfig
>>> >> @@ -108,6 +108,54 @@ config NOR_BOOT
>>> >>           as the ROM only partially sets up pinmux.  We also default to using
>>> >>           NOR for environment.
>>> >>
>>> >> +config NAND_BOOT
>>> >> +       bool "Support for booting from NAND flash"
>>> >> +       default n
>>> >> +       help
>>> >> +         Enabling this will make a U-Boot binary that is capable of being
>>> >> +         booted via NAND flash. This is not a must, some SoCs need this,
>>> >> +         somes not.
>>> >> +
>>> >> +config ONENAND_BOOT
>>> >> +       bool "Support for booting from ONENAND"
>>> >> +       default n
>>> >> +       help
>>> >> +         Enabling this will make a U-Boot binary that is capable of being
>>> >> +         booted via ONENAND. This is not a must, some SoCs need this,
>>> >> +         somes not.
>>> >> +
>>> >> +config QSPI_BOOT
>>> >> +       bool "Support for booting from QSPI flash"
>>> >> +       default n
>>> >> +       help
>>> >> +         Enabling this will make a U-Boot binary that is capable of being
>>> >> +         booted via QSPI flash. This is not a must, some SoCs need this,
>>> >> +         somes not.
>>> >> +
>>> >> +config SATA_BOOT
>>> >> +       bool "Support for booting from SATA"
>>> >> +       default n
>>> >> +       help
>>> >> +         Enabling this will make a U-Boot binary that is capable of being
>>> >> +         booted via SATA. This is not a must, some SoCs need this,
>>> >> +         somes not.
>>> >> +
>>> >> +config SD_BOOT
>>> >> +       bool "Support for booting from SD/EMMC"
>>> >> +       default n
>>> >> +       help
>>> >> +         Enabling this will make a U-Boot binary that is capable of being
>>> >> +         booted via SD/EMMC. This is not a must, some SoCs need this,
>>> >> +         somes not.
>>> >> +
>>> >> +config SPI_BOOT
>>> >> +       bool "Support for booting from SPI flash"
>>> >> +       default n
>>> >> +       help
>>> >> +         Enabling this will make a U-Boot binary that is capable of being
>>> >> +         booted via SPI flash. This is not a must, some SoCs need this,
>>> >> +         somes not.
>>> >> +
>>> >>  endmenu
>>> >
>>> >
>>> >Do you intend to replace
>>> >CONFIG_SPL_NOR_SUPPORT
>>> >CONFIG_SPL_NAND_SUPPORT
>>> >CONFIG_SPL_USB_SUPPORT
>>> >CONFIG_SPL_MMC_SUPPORT
>>> >etc. with these options?
>>> >
>>>
>>> I missed these.
>>>
>>> >
>>> >Currently, common/spl/spl.c uses CONFIG_SPL_*_SUPPORT
>>> >to enable/disable capable boot devices.
>>>
>>> I think we could use a common option to replace the ones used in SPL.
>>
>>I'm not sure that CONFIG_xxx_BOOT and CONFIG_SPL_xxx_SUPPORT are the
>>same thing.  For example, CONFIG_NOR_BOOT on am335x means "we are
>>building to support booting from NOR, so include all of that stuff
>>that's normally not included".  While CONFIG_SPL_NAND_SUPPORT means
>>include NAND support in SPL, which is not mutually exclusive with MMC,
>>etc.
>
> ok. Then, better keep them. For i.MX6, CONFIG_XX_BOOT have the same meaning
> with am335x as you said.
>
> Do you have other comments? If not touching SPL, I would like to see this
> patch set applied.
>
> Thanks,
> Peng.
>>


I am not familiar with TI SoCs,
so please help me to understand this.


+config NOR_BOOT
+       bool "Boot from NOR"
+       default n
+       help
+         U-Boot image is stored in NOR flash.


In the statement "U-Boot image is stored in NOR flash",
what "U-Boot" stands for?
SPL? or U-Boot proper?


If it points to SPL, it makes sense.

Theoretically, we can store SPL and U-Boot proper in different devices.

CONFIG_FOO_BOOT means that SPL is stored in a FOO device.
(In other words, the hard-wired Boot ROM loads the SPL from the device FOO.


CONFIG_SPL_FOO_SUPPORT means that SPL supports loading U-Boot proper
from FOO a device.
In other words, the U-Boot proper can be stored in FOO device.


Correct?


One more question,
what will happen if both CONFIG_NOR_BOOT and CONFIG_NAND_BOOT are enabled?




-- 
Best Regards
Masahiro Yamada

[U-Boot] [PATCH V2 2/2] common: add new boot media kconfig entry

[Peng Fan]

Hi Masahiro,
On Tue, Jun 28, 2016 at 02:24:00PM +0900, Masahiro Yamada wrote:
>Hi.
>
>
>2016-06-28 14:02 GMT+09:00 Peng Fan <van.freenix@gmail.com>:
>> Hi Tom,
>>
>> On Fri, Jun 24, 2016 at 06:57:44PM -0400, Tom Rini wrote:
>>>On Sun, Jun 19, 2016 at 06:20:52PM +0800, Peng Fan wrote:
>>>> Hi Masahiro,
>>>>
>>>> +Simon
>>>> On Fri, Jun 17, 2016 at 07:08:23PM +0900, Masahiro Yamada wrote:
>>>> >2016-06-17 18:39 GMT+09:00 Peng Fan <van.freenix@gmail.com>:
>>>> >> Add CONFIG_{SD|NAND|ONENAND|SPI|QSPI|SATA}_BOOT kconfig entries.
>>>> >>
>>>> >> SoCs supports loading U-Boot from different medias to DRAM, such as
>>>> >> i.MX6/7 supports loading U-Boot to DRAM from sd/emmc/nand/qspi/spi/sata
>>>> >> and etc. For i.MX, imximage will generate different IVT headers according
>>>> >> to boot medias.
>>>> >>
>>>> >> Signed-off-by: Peng Fan <peng.fan@nxp.com>
>>>> >> Cc: Simon Glass <sjg@chromium.org>
>>>> >> Cc: Heiko Schocher <hs@denx.de>
>>>> >> Cc: Joe Hershberger <joe.hershberger@ni.com>
>>>> >> Cc: Bin Meng <bmeng.cn@gmail.com>
>>>> >> Cc: Christophe Ricard <christophe-h.ricard@st.com>
>>>> >> Cc: Nikita Kiryanov <nikita@compulab.co.il>
>>>> >> Cc: Francois Retief <fgretief@spaceteq.co.za>
>>>> >> Cc: Tom Rini <trini@konsulko.com>
>>>> >> ---
>>>> >>
>>>> >> V2:
>>>> >>  Move NOR_BOOT to the patch 1/2.
>>>> >>  The idea of this patch is for adding different boot media support for
>>>> >>  i.MXes. And I'll post out following patches if this patch is accepted.
>>>> >>  I ran moveconfig.py, but I did not include the results into a patch.
>>>> >>  This patch does not break the boards which defined NAND_BOOT/SD_BOOT and
>>>> >>  etc, and I prefer to let board owners to move to defconfig later.
>>>> >>
>>>> >>  common/Kconfig | 48 ++++++++++++++++++++++++++++++++++++++++++++++++
>>>> >>  1 file changed, 48 insertions(+)
>>>> >>
>>>> >> diff --git a/common/Kconfig b/common/Kconfig
>>>> >> index 04d092c..f0f6ee1 100644
>>>> >> --- a/common/Kconfig
>>>> >> +++ b/common/Kconfig
>>>> >> @@ -108,6 +108,54 @@ config NOR_BOOT
>>>> >>           as the ROM only partially sets up pinmux.  We also default to using
>>>> >>           NOR for environment.
>>>> >>
>>>> >> +config NAND_BOOT
>>>> >> +       bool "Support for booting from NAND flash"
>>>> >> +       default n
>>>> >> +       help
>>>> >> +         Enabling this will make a U-Boot binary that is capable of being
>>>> >> +         booted via NAND flash. This is not a must, some SoCs need this,
>>>> >> +         somes not.
>>>> >> +
>>>> >> +config ONENAND_BOOT
>>>> >> +       bool "Support for booting from ONENAND"
>>>> >> +       default n
>>>> >> +       help
>>>> >> +         Enabling this will make a U-Boot binary that is capable of being
>>>> >> +         booted via ONENAND. This is not a must, some SoCs need this,
>>>> >> +         somes not.
>>>> >> +
>>>> >> +config QSPI_BOOT
>>>> >> +       bool "Support for booting from QSPI flash"
>>>> >> +       default n
>>>> >> +       help
>>>> >> +         Enabling this will make a U-Boot binary that is capable of being
>>>> >> +         booted via QSPI flash. This is not a must, some SoCs need this,
>>>> >> +         somes not.
>>>> >> +
>>>> >> +config SATA_BOOT
>>>> >> +       bool "Support for booting from SATA"
>>>> >> +       default n
>>>> >> +       help
>>>> >> +         Enabling this will make a U-Boot binary that is capable of being
>>>> >> +         booted via SATA. This is not a must, some SoCs need this,
>>>> >> +         somes not.
>>>> >> +
>>>> >> +config SD_BOOT
>>>> >> +       bool "Support for booting from SD/EMMC"
>>>> >> +       default n
>>>> >> +       help
>>>> >> +         Enabling this will make a U-Boot binary that is capable of being
>>>> >> +         booted via SD/EMMC. This is not a must, some SoCs need this,
>>>> >> +         somes not.
>>>> >> +
>>>> >> +config SPI_BOOT
>>>> >> +       bool "Support for booting from SPI flash"
>>>> >> +       default n
>>>> >> +       help
>>>> >> +         Enabling this will make a U-Boot binary that is capable of being
>>>> >> +         booted via SPI flash. This is not a must, some SoCs need this,
>>>> >> +         somes not.
>>>> >> +
>>>> >>  endmenu
>>>> >
>>>> >
>>>> >Do you intend to replace
>>>> >CONFIG_SPL_NOR_SUPPORT
>>>> >CONFIG_SPL_NAND_SUPPORT
>>>> >CONFIG_SPL_USB_SUPPORT
>>>> >CONFIG_SPL_MMC_SUPPORT
>>>> >etc. with these options?
>>>> >
>>>>
>>>> I missed these.
>>>>
>>>> >
>>>> >Currently, common/spl/spl.c uses CONFIG_SPL_*_SUPPORT
>>>> >to enable/disable capable boot devices.
>>>>
>>>> I think we could use a common option to replace the ones used in SPL.
>>>
>>>I'm not sure that CONFIG_xxx_BOOT and CONFIG_SPL_xxx_SUPPORT are the
>>>same thing.  For example, CONFIG_NOR_BOOT on am335x means "we are
>>>building to support booting from NOR, so include all of that stuff
>>>that's normally not included".  While CONFIG_SPL_NAND_SUPPORT means
>>>include NAND support in SPL, which is not mutually exclusive with MMC,
>>>etc.
>>
>> ok. Then, better keep them. For i.MX6, CONFIG_XX_BOOT have the same meaning
>> with am335x as you said.
>>
>> Do you have other comments? If not touching SPL, I would like to see this
>> patch set applied.
>>
>> Thanks,
>> Peng.
>>>
>
>
>I am not familiar with TI SoCs,

Me too.

>so please help me to understand this.
>
>
>+config NOR_BOOT
>+       bool "Boot from NOR"
>+       default n
>+       help
>+         U-Boot image is stored in NOR flash.
>
>
>In the statement "U-Boot image is stored in NOR flash",
>what "U-Boot" stands for?
>SPL? or U-Boot proper?
>
>
>If it points to SPL, it makes sense.

In my case,
SPL + U-Boot + OS.   means SPL
Only U-Boot  + OS.   means U-Boot.

>
>Theoretically, we can store SPL and U-Boot proper in different devices.
>
>CONFIG_FOO_BOOT means that SPL is stored in a FOO device.
>(In other words, the hard-wired Boot ROM loads the SPL from the device FOO.
>
>
>CONFIG_SPL_FOO_SUPPORT means that SPL supports loading U-Boot proper
>from FOO a device.
>In other words, the U-Boot proper can be stored in FOO device.

From doc/README.SPL
To support generic U-Boot libraries and drivers in the SPL binary one can          
optionally define CONFIG_SPL_XXX_SUPPORT. Currently following options           
are supported:                                                                  

....
CONFIG_SPL_MMC_SUPPORT (drivers/mmc/libmmc.o)
....
CONFIG_SPL_NAND_SUPPORT (drivers/mtd/nand/libnand.o)
                                                                                
>
>
>Correct?
>
>
>One more question,
>what will happen if both CONFIG_NOR_BOOT and CONFIG_NAND_BOOT are enabled?

In my case, we do not allow CONFIG_NOR_BOOT and CONFIG_NAND_BOOT both defined.
If both defined, U-Boot(I do not use spl) may not boot up in my case.

Regards,
peng.

[U-Boot] [PATCH V2 2/2] common: add new boot media kconfig entry

[Masahiro Yamada]

Hi.

2016-06-28 15:39 GMT+09:00 Peng Fan <van.freenix@gmail.com>:
> Hi Masahiro,
> On Tue, Jun 28, 2016 at 02:24:00PM +0900, Masahiro Yamada wrote:
>>Hi.
>>
>>
>>2016-06-28 14:02 GMT+09:00 Peng Fan <van.freenix@gmail.com>:
>>> Hi Tom,
>>>
>>> On Fri, Jun 24, 2016 at 06:57:44PM -0400, Tom Rini wrote:
>>>>On Sun, Jun 19, 2016 at 06:20:52PM +0800, Peng Fan wrote:
>>>>> Hi Masahiro,
>>>>>
>>>>> +Simon
>>>>> On Fri, Jun 17, 2016 at 07:08:23PM +0900, Masahiro Yamada wrote:
>>>>> >2016-06-17 18:39 GMT+09:00 Peng Fan <van.freenix@gmail.com>:
>>>>> >> Add CONFIG_{SD|NAND|ONENAND|SPI|QSPI|SATA}_BOOT kconfig entries.
>>>>> >>
>>>>> >> SoCs supports loading U-Boot from different medias to DRAM, such as
>>>>> >> i.MX6/7 supports loading U-Boot to DRAM from sd/emmc/nand/qspi/spi/sata
>>>>> >> and etc. For i.MX, imximage will generate different IVT headers according
>>>>> >> to boot medias.
>>>>> >>
>>>>> >> Signed-off-by: Peng Fan <peng.fan@nxp.com>
>>>>> >> Cc: Simon Glass <sjg@chromium.org>
>>>>> >> Cc: Heiko Schocher <hs@denx.de>
>>>>> >> Cc: Joe Hershberger <joe.hershberger@ni.com>
>>>>> >> Cc: Bin Meng <bmeng.cn@gmail.com>
>>>>> >> Cc: Christophe Ricard <christophe-h.ricard@st.com>
>>>>> >> Cc: Nikita Kiryanov <nikita@compulab.co.il>
>>>>> >> Cc: Francois Retief <fgretief@spaceteq.co.za>
>>>>> >> Cc: Tom Rini <trini@konsulko.com>
>>>>> >> ---
>>>>> >>
>>>>> >> V2:
>>>>> >>  Move NOR_BOOT to the patch 1/2.
>>>>> >>  The idea of this patch is for adding different boot media support for
>>>>> >>  i.MXes. And I'll post out following patches if this patch is accepted.
>>>>> >>  I ran moveconfig.py, but I did not include the results into a patch.
>>>>> >>  This patch does not break the boards which defined NAND_BOOT/SD_BOOT and
>>>>> >>  etc, and I prefer to let board owners to move to defconfig later.
>>>>> >>
>>>>> >>  common/Kconfig | 48 ++++++++++++++++++++++++++++++++++++++++++++++++
>>>>> >>  1 file changed, 48 insertions(+)
>>>>> >>
>>>>> >> diff --git a/common/Kconfig b/common/Kconfig
>>>>> >> index 04d092c..f0f6ee1 100644
>>>>> >> --- a/common/Kconfig
>>>>> >> +++ b/common/Kconfig
>>>>> >> @@ -108,6 +108,54 @@ config NOR_BOOT
>>>>> >>           as the ROM only partially sets up pinmux.  We also default to using
>>>>> >>           NOR for environment.
>>>>> >>
>>>>> >> +config NAND_BOOT
>>>>> >> +       bool "Support for booting from NAND flash"
>>>>> >> +       default n
>>>>> >> +       help
>>>>> >> +         Enabling this will make a U-Boot binary that is capable of being
>>>>> >> +         booted via NAND flash. This is not a must, some SoCs need this,
>>>>> >> +         somes not.
>>>>> >> +
>>>>> >> +config ONENAND_BOOT
>>>>> >> +       bool "Support for booting from ONENAND"
>>>>> >> +       default n
>>>>> >> +       help
>>>>> >> +         Enabling this will make a U-Boot binary that is capable of being
>>>>> >> +         booted via ONENAND. This is not a must, some SoCs need this,
>>>>> >> +         somes not.
>>>>> >> +
>>>>> >> +config QSPI_BOOT
>>>>> >> +       bool "Support for booting from QSPI flash"
>>>>> >> +       default n
>>>>> >> +       help
>>>>> >> +         Enabling this will make a U-Boot binary that is capable of being
>>>>> >> +         booted via QSPI flash. This is not a must, some SoCs need this,
>>>>> >> +         somes not.
>>>>> >> +
>>>>> >> +config SATA_BOOT
>>>>> >> +       bool "Support for booting from SATA"
>>>>> >> +       default n
>>>>> >> +       help
>>>>> >> +         Enabling this will make a U-Boot binary that is capable of being
>>>>> >> +         booted via SATA. This is not a must, some SoCs need this,
>>>>> >> +         somes not.
>>>>> >> +
>>>>> >> +config SD_BOOT
>>>>> >> +       bool "Support for booting from SD/EMMC"
>>>>> >> +       default n
>>>>> >> +       help
>>>>> >> +         Enabling this will make a U-Boot binary that is capable of being
>>>>> >> +         booted via SD/EMMC. This is not a must, some SoCs need this,
>>>>> >> +         somes not.
>>>>> >> +
>>>>> >> +config SPI_BOOT
>>>>> >> +       bool "Support for booting from SPI flash"
>>>>> >> +       default n
>>>>> >> +       help
>>>>> >> +         Enabling this will make a U-Boot binary that is capable of being
>>>>> >> +         booted via SPI flash. This is not a must, some SoCs need this,
>>>>> >> +         somes not.
>>>>> >> +
>>>>> >>  endmenu
>>>>> >
>>>>> >
>>>>> >Do you intend to replace
>>>>> >CONFIG_SPL_NOR_SUPPORT
>>>>> >CONFIG_SPL_NAND_SUPPORT
>>>>> >CONFIG_SPL_USB_SUPPORT
>>>>> >CONFIG_SPL_MMC_SUPPORT
>>>>> >etc. with these options?
>>>>> >
>>>>>
>>>>> I missed these.
>>>>>
>>>>> >
>>>>> >Currently, common/spl/spl.c uses CONFIG_SPL_*_SUPPORT
>>>>> >to enable/disable capable boot devices.
>>>>>
>>>>> I think we could use a common option to replace the ones used in SPL.
>>>>
>>>>I'm not sure that CONFIG_xxx_BOOT and CONFIG_SPL_xxx_SUPPORT are the
>>>>same thing.  For example, CONFIG_NOR_BOOT on am335x means "we are
>>>>building to support booting from NOR, so include all of that stuff
>>>>that's normally not included".  While CONFIG_SPL_NAND_SUPPORT means
>>>>include NAND support in SPL, which is not mutually exclusive with MMC,
>>>>etc.
>>>
>>> ok. Then, better keep them. For i.MX6, CONFIG_XX_BOOT have the same meaning
>>> with am335x as you said.
>>>
>>> Do you have other comments? If not touching SPL, I would like to see this
>>> patch set applied.
>>>
>>> Thanks,
>>> Peng.
>>>>
>>
>>
>>I am not familiar with TI SoCs,
>
> Me too.

I missed to read git-log, I meant:
I am not familiar with i.MX SoCs.
(and I am not familiar with TI SoC, either)


>>so please help me to understand this.
>>
>>
>>+config NOR_BOOT
>>+       bool "Boot from NOR"
>>+       default n
>>+       help
>>+         U-Boot image is stored in NOR flash.
>>
>>
>>In the statement "U-Boot image is stored in NOR flash",
>>what "U-Boot" stands for?
>>SPL? or U-Boot proper?
>>
>>
>>If it points to SPL, it makes sense.
>
> In my case,
> SPL + U-Boot + OS.   means SPL
> Only U-Boot  + OS.   means U-Boot.


So, this board disables SPL
for an in-place executable device, like NOR.


I did likewise for my boards before,
and I found this was a PITA.

For a boot mode with SPL,
lowlevel_init code must be compiled into SPL.

For a boot mode without SPL,
lowlevel_init code must go into U-Boot proper.


Then, I ended up sprinkling ifdef CONFIG_SPL and
ifdef CONFIG_SPL_BUILD here are there.

This also loaded me per boot-mode testing
because boot sequence is too different for with/without SPL.


In my personal opinion, SPL should be enabled all the time.
Even for NOR boot, we can split the boot image
into SPL and U-Boot proper by using common/spl/spl_nor.c

Now, my SoC "select SPL"
and I can use an identical boot image
regardless of boot mode.

This may not be always possible,
but I am wondering if we could do someting
to mitigate the pain from per boot-mode defconfig.





>>
>>Theoretically, we can store SPL and U-Boot proper in different devices.
>>
>>CONFIG_FOO_BOOT means that SPL is stored in a FOO device.
>>(In other words, the hard-wired Boot ROM loads the SPL from the device FOO.
>>
>>
>>CONFIG_SPL_FOO_SUPPORT means that SPL supports loading U-Boot proper
>>from FOO a device.
>>In other words, the U-Boot proper can be stored in FOO device.
>
> From doc/README.SPL
> To support generic U-Boot libraries and drivers in the SPL binary one can
> optionally define CONFIG_SPL_XXX_SUPPORT. Currently following options
> are supported:
>
> ....
> CONFIG_SPL_MMC_SUPPORT (drivers/mmc/libmmc.o)
> ....
> CONFIG_SPL_NAND_SUPPORT (drivers/mtd/nand/libnand.o)
>
>>
>>
>>Correct?
>>
>>
>>One more question,
>>what will happen if both CONFIG_NOR_BOOT and CONFIG_NAND_BOOT are enabled?
>
> In my case, we do not allow CONFIG_NOR_BOOT and CONFIG_NAND_BOOT both defined.
> If both defined, U-Boot(I do not use spl) may not boot up in my case.


Perhaps, we should use a "choice" menu
to choose CONFIG_*_BOOT exclusively,
but I am not sure if it is the case for other vendors.
It looks like CONFIG_*_BOOT is used by TI as well as Freescale.


At least for my SoCs, I do not need these options at all
because one single boot image can boot from any device.


This patch is adding
  # CONFIG_NOR_BOOT is not set
  # CONFIG_NAND_BOOT is not set
  # CONFIG_QSPI_BOOT is not set
  ...

to my .config, which does not make sense.


Perhaps, can we define these symbols in an SoC Kconfig,
or surround them with "if <SOC>"?



-- 
Best Regards
Masahiro Yamada

[U-Boot] [PATCH V2 2/2] common: add new boot media kconfig entry

[Tom Rini]

On Tue, Jun 28, 2016 at 02:24:00PM +0900, Masahiro Yamada wrote:
> Hi.
> 
> 
> 2016-06-28 14:02 GMT+09:00 Peng Fan <van.freenix@gmail.com>:
> > Hi Tom,
> >
> > On Fri, Jun 24, 2016 at 06:57:44PM -0400, Tom Rini wrote:
> >>On Sun, Jun 19, 2016 at 06:20:52PM +0800, Peng Fan wrote:
> >>> Hi Masahiro,
> >>>
> >>> +Simon
> >>> On Fri, Jun 17, 2016 at 07:08:23PM +0900, Masahiro Yamada wrote:
> >>> >2016-06-17 18:39 GMT+09:00 Peng Fan <van.freenix@gmail.com>:
> >>> >> Add CONFIG_{SD|NAND|ONENAND|SPI|QSPI|SATA}_BOOT kconfig entries.
> >>> >>
> >>> >> SoCs supports loading U-Boot from different medias to DRAM, such as
> >>> >> i.MX6/7 supports loading U-Boot to DRAM from sd/emmc/nand/qspi/spi/sata
> >>> >> and etc. For i.MX, imximage will generate different IVT headers according
> >>> >> to boot medias.
> >>> >>
> >>> >> Signed-off-by: Peng Fan <peng.fan@nxp.com>
> >>> >> Cc: Simon Glass <sjg@chromium.org>
> >>> >> Cc: Heiko Schocher <hs@denx.de>
> >>> >> Cc: Joe Hershberger <joe.hershberger@ni.com>
> >>> >> Cc: Bin Meng <bmeng.cn@gmail.com>
> >>> >> Cc: Christophe Ricard <christophe-h.ricard@st.com>
> >>> >> Cc: Nikita Kiryanov <nikita@compulab.co.il>
> >>> >> Cc: Francois Retief <fgretief@spaceteq.co.za>
> >>> >> Cc: Tom Rini <trini@konsulko.com>
> >>> >> ---
> >>> >>
> >>> >> V2:
> >>> >>  Move NOR_BOOT to the patch 1/2.
> >>> >>  The idea of this patch is for adding different boot media support for
> >>> >>  i.MXes. And I'll post out following patches if this patch is accepted.
> >>> >>  I ran moveconfig.py, but I did not include the results into a patch.
> >>> >>  This patch does not break the boards which defined NAND_BOOT/SD_BOOT and
> >>> >>  etc, and I prefer to let board owners to move to defconfig later.
> >>> >>
> >>> >>  common/Kconfig | 48 ++++++++++++++++++++++++++++++++++++++++++++++++
> >>> >>  1 file changed, 48 insertions(+)
> >>> >>
> >>> >> diff --git a/common/Kconfig b/common/Kconfig
> >>> >> index 04d092c..f0f6ee1 100644
> >>> >> --- a/common/Kconfig
> >>> >> +++ b/common/Kconfig
> >>> >> @@ -108,6 +108,54 @@ config NOR_BOOT
> >>> >>           as the ROM only partially sets up pinmux.  We also default to using
> >>> >>           NOR for environment.
> >>> >>
> >>> >> +config NAND_BOOT
> >>> >> +       bool "Support for booting from NAND flash"
> >>> >> +       default n
> >>> >> +       help
> >>> >> +         Enabling this will make a U-Boot binary that is capable of being
> >>> >> +         booted via NAND flash. This is not a must, some SoCs need this,
> >>> >> +         somes not.
> >>> >> +
> >>> >> +config ONENAND_BOOT
> >>> >> +       bool "Support for booting from ONENAND"
> >>> >> +       default n
> >>> >> +       help
> >>> >> +         Enabling this will make a U-Boot binary that is capable of being
> >>> >> +         booted via ONENAND. This is not a must, some SoCs need this,
> >>> >> +         somes not.
> >>> >> +
> >>> >> +config QSPI_BOOT
> >>> >> +       bool "Support for booting from QSPI flash"
> >>> >> +       default n
> >>> >> +       help
> >>> >> +         Enabling this will make a U-Boot binary that is capable of being
> >>> >> +         booted via QSPI flash. This is not a must, some SoCs need this,
> >>> >> +         somes not.
> >>> >> +
> >>> >> +config SATA_BOOT
> >>> >> +       bool "Support for booting from SATA"
> >>> >> +       default n
> >>> >> +       help
> >>> >> +         Enabling this will make a U-Boot binary that is capable of being
> >>> >> +         booted via SATA. This is not a must, some SoCs need this,
> >>> >> +         somes not.
> >>> >> +
> >>> >> +config SD_BOOT
> >>> >> +       bool "Support for booting from SD/EMMC"
> >>> >> +       default n
> >>> >> +       help
> >>> >> +         Enabling this will make a U-Boot binary that is capable of being
> >>> >> +         booted via SD/EMMC. This is not a must, some SoCs need this,
> >>> >> +         somes not.
> >>> >> +
> >>> >> +config SPI_BOOT
> >>> >> +       bool "Support for booting from SPI flash"
> >>> >> +       default n
> >>> >> +       help
> >>> >> +         Enabling this will make a U-Boot binary that is capable of being
> >>> >> +         booted via SPI flash. This is not a must, some SoCs need this,
> >>> >> +         somes not.
> >>> >> +
> >>> >>  endmenu
> >>> >
> >>> >
> >>> >Do you intend to replace
> >>> >CONFIG_SPL_NOR_SUPPORT
> >>> >CONFIG_SPL_NAND_SUPPORT
> >>> >CONFIG_SPL_USB_SUPPORT
> >>> >CONFIG_SPL_MMC_SUPPORT
> >>> >etc. with these options?
> >>> >
> >>>
> >>> I missed these.
> >>>
> >>> >
> >>> >Currently, common/spl/spl.c uses CONFIG_SPL_*_SUPPORT
> >>> >to enable/disable capable boot devices.
> >>>
> >>> I think we could use a common option to replace the ones used in SPL.
> >>
> >>I'm not sure that CONFIG_xxx_BOOT and CONFIG_SPL_xxx_SUPPORT are the
> >>same thing.  For example, CONFIG_NOR_BOOT on am335x means "we are
> >>building to support booting from NOR, so include all of that stuff
> >>that's normally not included".  While CONFIG_SPL_NAND_SUPPORT means
> >>include NAND support in SPL, which is not mutually exclusive with MMC,
> >>etc.
> >
> > ok. Then, better keep them. For i.MX6, CONFIG_XX_BOOT have the same meaning
> > with am335x as you said.
> >
> > Do you have other comments? If not touching SPL, I would like to see this
> > patch set applied.
> >
> > Thanks,
> > Peng.
> >>
> 
> 
> I am not familiar with TI SoCs,
> so please help me to understand this.
> 
> 
> +config NOR_BOOT
> +       bool "Boot from NOR"
> +       default n
> +       help
> +         U-Boot image is stored in NOR flash.
> 
> 
> In the statement "U-Boot image is stored in NOR flash",
> what "U-Boot" stands for?
> SPL? or U-Boot proper?
> 
> 
> If it points to SPL, it makes sense.
> 
> Theoretically, we can store SPL and U-Boot proper in different devices.
> 
> CONFIG_FOO_BOOT means that SPL is stored in a FOO device.
> (In other words, the hard-wired Boot ROM loads the SPL from the device FOO.
> 
> 
> CONFIG_SPL_FOO_SUPPORT means that SPL supports loading U-Boot proper
> from FOO a device.
> In other words, the U-Boot proper can be stored in FOO device.
> 
> 
> Correct?
> 
> 
> One more question,
> what will happen if both CONFIG_NOR_BOOT and CONFIG_NAND_BOOT are enabled?

In this (TI) case, CONFIG_NOR_BOOT is for a literal "we are building
U-Boot (full) for NOR boot, only".

So as part of moving things out of config.h files and into Kconfig, and
being more "in the light" some odd bits of phrasing and naming will be
encountered and hopefully improved.  With DM perhaps we'll even finally
fix the thing where if you build in, but have no, NOR flash support,
U-Boot hangs.  That, in a nutshell, is why there was the flag for those
platforms.  The vast majority of the HW that exists does not have NOR
flash (it's only on a fairly uncommon expansion board, and was done to
show how custom hardware would work if it wanted to incorporate NOR).

-- 
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/20160628/7e1975f3/attachment.sig>

[U-Boot] [PATCH] configs: Re-sync after boot menu changes

[Tom Rini]

Signed-off-by: Tom Rini <trini@konsulko.com>
---
 configs/am335x_evm_spiboot_defconfig     |  2 +-
 configs/am43xx_evm_qspiboot_defconfig    |  2 +-
 configs/brppt1_spi_defconfig             |  1 +
 configs/ls1012afrdm_qspi_defconfig       |  1 +
 configs/ls1012aqds_qspi_defconfig        |  1 +
 configs/ls1012ardb_qspi_defconfig        |  1 +
 configs/ls1021aqds_nand_defconfig        |  1 +
 configs/ls1021aqds_qspi_defconfig        |  1 +
 configs/ls1021aqds_sdcard_ifc_defconfig  |  1 +
 configs/ls1021aqds_sdcard_qspi_defconfig |  1 +
 configs/ls1021atwr_qspi_defconfig        |  1 +
 configs/ls1021atwr_sdcard_ifc_defconfig  |  1 +
 configs/ls1021atwr_sdcard_qspi_defconfig |  1 +
 configs/ls1043aqds_nand_defconfig        |  1 +
 configs/ls1043aqds_qspi_defconfig        |  1 +
 configs/ls1043aqds_sdcard_ifc_defconfig  |  1 +
 configs/ls1043aqds_sdcard_qspi_defconfig |  1 +
 configs/ls1043ardb_nand_defconfig        |  1 +
 configs/ls1043ardb_sdcard_defconfig      |  1 +
 configs/ls2080aqds_qspi_defconfig        | 18 +++++++++---------
 20 files changed, 28 insertions(+), 11 deletions(-)

diff --git a/configs/am335x_evm_spiboot_defconfig b/configs/am335x_evm_spiboot_defconfig
index d5aa3a2..2fe1a25 100644
--- a/configs/am335x_evm_spiboot_defconfig
+++ b/configs/am335x_evm_spiboot_defconfig
@@ -5,6 +5,7 @@ CONFIG_SPL=y
 CONFIG_SPL_STACK_R=y
 CONFIG_FIT=y
 CONFIG_SYS_EXTRA_OPTIONS="SPI_BOOT"
+CONFIG_SPI_BOOT=y
 CONFIG_HUSH_PARSER=y
 CONFIG_CMD_BOOTZ=y
 # CONFIG_CMD_IMLS is not set
@@ -38,4 +39,3 @@ CONFIG_G_DNL_MANUFACTURER="Texas Instruments"
 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"
diff --git a/configs/am43xx_evm_qspiboot_defconfig b/configs/am43xx_evm_qspiboot_defconfig
index 5264332..c6bc8e4 100644
--- a/configs/am43xx_evm_qspiboot_defconfig
+++ b/configs/am43xx_evm_qspiboot_defconfig
@@ -3,6 +3,7 @@ CONFIG_AM43XX=y
 CONFIG_TARGET_AM43XX_EVM=y
 CONFIG_ISW_ENTRY_ADDR=0x30000000
 CONFIG_SYS_EXTRA_OPTIONS="SERIAL1,CONS_INDEX=1,QSPI,QSPI_BOOT"
+CONFIG_QSPI_BOOT=y
 CONFIG_HUSH_PARSER=y
 CONFIG_CMD_BOOTZ=y
 # CONFIG_CMD_IMLS is not set
@@ -41,4 +42,3 @@ CONFIG_G_DNL_MANUFACTURER="Texas Instruments"
 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"
diff --git a/configs/brppt1_spi_defconfig b/configs/brppt1_spi_defconfig
index 37b8bc9..f023ebf 100644
--- a/configs/brppt1_spi_defconfig
+++ b/configs/brppt1_spi_defconfig
@@ -3,6 +3,7 @@ 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_SPI_BOOT=y
 CONFIG_BOOTDELAY=0
 CONFIG_HUSH_PARSER=y
 CONFIG_CMD_BOOTZ=y
diff --git a/configs/ls1012afrdm_qspi_defconfig b/configs/ls1012afrdm_qspi_defconfig
index 1aed0c4..1d8e28b 100644
--- a/configs/ls1012afrdm_qspi_defconfig
+++ b/configs/ls1012afrdm_qspi_defconfig
@@ -9,6 +9,7 @@ CONFIG_FIT_VERBOSE=y
 CONFIG_OF_BOARD_SETUP=y
 CONFIG_OF_STDOUT_VIA_ALIAS=y
 CONFIG_SYS_EXTRA_OPTIONS="QSPI_BOOT"
+CONFIG_QSPI_BOOT=y
 CONFIG_BOOTDELAY=10
 CONFIG_HUSH_PARSER=y
 CONFIG_CMD_GREPENV=y
diff --git a/configs/ls1012aqds_qspi_defconfig b/configs/ls1012aqds_qspi_defconfig
index 86ddf71..bbfb118 100644
--- a/configs/ls1012aqds_qspi_defconfig
+++ b/configs/ls1012aqds_qspi_defconfig
@@ -9,6 +9,7 @@ CONFIG_FIT_VERBOSE=y
 CONFIG_OF_BOARD_SETUP=y
 CONFIG_OF_STDOUT_VIA_ALIAS=y
 CONFIG_SYS_EXTRA_OPTIONS="QSPI_BOOT"
+CONFIG_QSPI_BOOT=y
 CONFIG_BOOTDELAY=10
 CONFIG_HUSH_PARSER=y
 CONFIG_CMD_GREPENV=y
diff --git a/configs/ls1012ardb_qspi_defconfig b/configs/ls1012ardb_qspi_defconfig
index 3806412..b418d5c 100644
--- a/configs/ls1012ardb_qspi_defconfig
+++ b/configs/ls1012ardb_qspi_defconfig
@@ -9,6 +9,7 @@ CONFIG_FIT_VERBOSE=y
 CONFIG_OF_BOARD_SETUP=y
 CONFIG_OF_STDOUT_VIA_ALIAS=y
 CONFIG_SYS_EXTRA_OPTIONS="QSPI_BOOT"
+CONFIG_QSPI_BOOT=y
 CONFIG_BOOTDELAY=10
 CONFIG_HUSH_PARSER=y
 CONFIG_CMD_GREPENV=y
diff --git a/configs/ls1021aqds_nand_defconfig b/configs/ls1021aqds_nand_defconfig
index eca1cca..b79fc58 100644
--- a/configs/ls1021aqds_nand_defconfig
+++ b/configs/ls1021aqds_nand_defconfig
@@ -6,6 +6,7 @@ CONFIG_FIT_VERBOSE=y
 CONFIG_OF_BOARD_SETUP=y
 CONFIG_OF_STDOUT_VIA_ALIAS=y
 CONFIG_SYS_EXTRA_OPTIONS="RAMBOOT_PBL,SPL_FSL_PBL,NAND_BOOT"
+CONFIG_NAND_BOOT=y
 CONFIG_BOOTDELAY=3
 CONFIG_HUSH_PARSER=y
 CONFIG_CMD_BOOTZ=y
diff --git a/configs/ls1021aqds_qspi_defconfig b/configs/ls1021aqds_qspi_defconfig
index a1504c3..284cc07 100644
--- a/configs/ls1021aqds_qspi_defconfig
+++ b/configs/ls1021aqds_qspi_defconfig
@@ -7,6 +7,7 @@ CONFIG_FIT_VERBOSE=y
 CONFIG_OF_BOARD_SETUP=y
 CONFIG_OF_STDOUT_VIA_ALIAS=y
 CONFIG_SYS_EXTRA_OPTIONS="QSPI_BOOT"
+CONFIG_QSPI_BOOT=y
 CONFIG_BOOTDELAY=3
 CONFIG_HUSH_PARSER=y
 CONFIG_CMD_BOOTZ=y
diff --git a/configs/ls1021aqds_sdcard_ifc_defconfig b/configs/ls1021aqds_sdcard_ifc_defconfig
index f8bdfe8..b6f8d74 100644
--- a/configs/ls1021aqds_sdcard_ifc_defconfig
+++ b/configs/ls1021aqds_sdcard_ifc_defconfig
@@ -5,6 +5,7 @@ CONFIG_SPL=y
 CONFIG_FIT=y
 CONFIG_FIT_VERBOSE=y
 CONFIG_SYS_EXTRA_OPTIONS="RAMBOOT_PBL,SPL_FSL_PBL,SD_BOOT"
+CONFIG_SD_BOOT=y
 CONFIG_BOOTDELAY=3
 CONFIG_HUSH_PARSER=y
 CONFIG_CMD_BOOTZ=y
diff --git a/configs/ls1021aqds_sdcard_qspi_defconfig b/configs/ls1021aqds_sdcard_qspi_defconfig
index a1ee5b9..e3abe36 100644
--- a/configs/ls1021aqds_sdcard_qspi_defconfig
+++ b/configs/ls1021aqds_sdcard_qspi_defconfig
@@ -6,6 +6,7 @@ CONFIG_SPL=y
 CONFIG_FIT=y
 CONFIG_FIT_VERBOSE=y
 CONFIG_SYS_EXTRA_OPTIONS="RAMBOOT_PBL,SPL_FSL_PBL,SD_BOOT,SD_BOOT_QSPI"
+CONFIG_SD_BOOT=y
 CONFIG_BOOTDELAY=3
 CONFIG_HUSH_PARSER=y
 CONFIG_CMD_BOOTZ=y
diff --git a/configs/ls1021atwr_qspi_defconfig b/configs/ls1021atwr_qspi_defconfig
index 0a6cbcd..7e440b2 100644
--- a/configs/ls1021atwr_qspi_defconfig
+++ b/configs/ls1021atwr_qspi_defconfig
@@ -7,6 +7,7 @@ CONFIG_FIT_VERBOSE=y
 CONFIG_OF_BOARD_SETUP=y
 CONFIG_OF_STDOUT_VIA_ALIAS=y
 CONFIG_SYS_EXTRA_OPTIONS="QSPI_BOOT"
+CONFIG_QSPI_BOOT=y
 CONFIG_BOOTDELAY=3
 CONFIG_HUSH_PARSER=y
 CONFIG_CMD_BOOTZ=y
diff --git a/configs/ls1021atwr_sdcard_ifc_defconfig b/configs/ls1021atwr_sdcard_ifc_defconfig
index 2128c46..e735fa0 100644
--- a/configs/ls1021atwr_sdcard_ifc_defconfig
+++ b/configs/ls1021atwr_sdcard_ifc_defconfig
@@ -6,6 +6,7 @@ CONFIG_FIT_VERBOSE=y
 CONFIG_OF_BOARD_SETUP=y
 CONFIG_OF_STDOUT_VIA_ALIAS=y
 CONFIG_SYS_EXTRA_OPTIONS="RAMBOOT_PBL,SPL_FSL_PBL,SD_BOOT"
+CONFIG_SD_BOOT=y
 CONFIG_BOOTDELAY=3
 CONFIG_HUSH_PARSER=y
 CONFIG_CMD_BOOTZ=y
diff --git a/configs/ls1021atwr_sdcard_qspi_defconfig b/configs/ls1021atwr_sdcard_qspi_defconfig
index 8d1f8ed..6cf4dbc 100644
--- a/configs/ls1021atwr_sdcard_qspi_defconfig
+++ b/configs/ls1021atwr_sdcard_qspi_defconfig
@@ -8,6 +8,7 @@ CONFIG_FIT_VERBOSE=y
 CONFIG_OF_BOARD_SETUP=y
 CONFIG_OF_STDOUT_VIA_ALIAS=y
 CONFIG_SYS_EXTRA_OPTIONS="RAMBOOT_PBL,SPL_FSL_PBL,SD_BOOT,SD_BOOT_QSPI"
+CONFIG_SD_BOOT=y
 CONFIG_BOOTDELAY=3
 CONFIG_HUSH_PARSER=y
 CONFIG_CMD_BOOTZ=y
diff --git a/configs/ls1043aqds_nand_defconfig b/configs/ls1043aqds_nand_defconfig
index 6136887..3a95124 100644
--- a/configs/ls1043aqds_nand_defconfig
+++ b/configs/ls1043aqds_nand_defconfig
@@ -7,6 +7,7 @@ CONFIG_FIT=y
 CONFIG_FIT_VERBOSE=y
 CONFIG_OF_BOARD_SETUP=y
 CONFIG_SYS_EXTRA_OPTIONS="SYS_FSL_DDR4,RAMBOOT_PBL,SPL_FSL_PBL,NAND_BOOT"
+CONFIG_NAND_BOOT=y
 CONFIG_BOOTDELAY=10
 CONFIG_HUSH_PARSER=y
 CONFIG_CMD_BOOTZ=y
diff --git a/configs/ls1043aqds_qspi_defconfig b/configs/ls1043aqds_qspi_defconfig
index 2b2a714..cfc7310 100644
--- a/configs/ls1043aqds_qspi_defconfig
+++ b/configs/ls1043aqds_qspi_defconfig
@@ -6,6 +6,7 @@ CONFIG_FIT=y
 CONFIG_FIT_VERBOSE=y
 CONFIG_OF_BOARD_SETUP=y
 CONFIG_SYS_EXTRA_OPTIONS="SYS_FSL_DDR4,QSPI_BOOT"
+CONFIG_QSPI_BOOT=y
 CONFIG_BOOTDELAY=10
 CONFIG_HUSH_PARSER=y
 CONFIG_CMD_BOOTZ=y
diff --git a/configs/ls1043aqds_sdcard_ifc_defconfig b/configs/ls1043aqds_sdcard_ifc_defconfig
index f90a6be..f4f464e 100644
--- a/configs/ls1043aqds_sdcard_ifc_defconfig
+++ b/configs/ls1043aqds_sdcard_ifc_defconfig
@@ -7,6 +7,7 @@ CONFIG_FIT=y
 CONFIG_FIT_VERBOSE=y
 CONFIG_OF_BOARD_SETUP=y
 CONFIG_SYS_EXTRA_OPTIONS="SYS_FSL_DDR4,RAMBOOT_PBL,SPL_FSL_PBL,SD_BOOT"
+CONFIG_SD_BOOT=y
 CONFIG_BOOTDELAY=10
 CONFIG_HUSH_PARSER=y
 CONFIG_CMD_BOOTZ=y
diff --git a/configs/ls1043aqds_sdcard_qspi_defconfig b/configs/ls1043aqds_sdcard_qspi_defconfig
index d85f771..0a077a3 100644
--- a/configs/ls1043aqds_sdcard_qspi_defconfig
+++ b/configs/ls1043aqds_sdcard_qspi_defconfig
@@ -7,6 +7,7 @@ CONFIG_FIT=y
 CONFIG_FIT_VERBOSE=y
 CONFIG_OF_BOARD_SETUP=y
 CONFIG_SYS_EXTRA_OPTIONS="SYS_FSL_DDR4,RAMBOOT_PBL,SPL_FSL_PBL,SD_BOOT,SD_BOOT_QSPI"
+CONFIG_SD_BOOT=y
 CONFIG_BOOTDELAY=10
 CONFIG_HUSH_PARSER=y
 CONFIG_CMD_BOOTZ=y
diff --git a/configs/ls1043ardb_nand_defconfig b/configs/ls1043ardb_nand_defconfig
index c420548..dcf5de2 100644
--- a/configs/ls1043ardb_nand_defconfig
+++ b/configs/ls1043ardb_nand_defconfig
@@ -7,6 +7,7 @@ CONFIG_FIT=y
 CONFIG_FIT_VERBOSE=y
 CONFIG_OF_BOARD_SETUP=y
 CONFIG_SYS_EXTRA_OPTIONS="RAMBOOT_PBL,SPL_FSL_PBL,NAND_BOOT,SYS_FSL_DDR4"
+CONFIG_NAND_BOOT=y
 CONFIG_BOOTDELAY=10
 CONFIG_HUSH_PARSER=y
 CONFIG_CMD_MMC=y
diff --git a/configs/ls1043ardb_sdcard_defconfig b/configs/ls1043ardb_sdcard_defconfig
index a5a870b..9fd0679 100644
--- a/configs/ls1043ardb_sdcard_defconfig
+++ b/configs/ls1043ardb_sdcard_defconfig
@@ -7,6 +7,7 @@ CONFIG_FIT=y
 CONFIG_FIT_VERBOSE=y
 CONFIG_OF_BOARD_SETUP=y
 CONFIG_SYS_EXTRA_OPTIONS="RAMBOOT_PBL,SPL_FSL_PBL,SD_BOOT,SYS_FSL_DDR4"
+CONFIG_SD_BOOT=y
 CONFIG_BOOTDELAY=10
 CONFIG_HUSH_PARSER=y
 CONFIG_CMD_MMC=y
diff --git a/configs/ls2080aqds_qspi_defconfig b/configs/ls2080aqds_qspi_defconfig
index 0850a68..7826bbc 100644
--- a/configs/ls2080aqds_qspi_defconfig
+++ b/configs/ls2080aqds_qspi_defconfig
@@ -1,21 +1,19 @@
 CONFIG_ARM=y
 CONFIG_TARGET_LS2080AQDS=y
+CONFIG_DM_SPI=y
+CONFIG_DM_SPI_FLASH=y
+CONFIG_DEFAULT_DEVICE_TREE="fsl-ls2080a-qds"
 CONFIG_FIT=y
 CONFIG_FIT_VERBOSE=y
 CONFIG_OF_BOARD_SETUP=y
 CONFIG_OF_STDOUT_VIA_ALIAS=y
 CONFIG_SYS_EXTRA_OPTIONS="SYS_FSL_DDR4,QSPI_BOOT,LS2080A"
+CONFIG_QSPI_BOOT=y
 CONFIG_BOOTDELAY=10
 CONFIG_HUSH_PARSER=y
-CONFIG_DEFAULT_DEVICE_TREE="fsl-ls2080a-qds"
-CONFIG_OF_CONTROL=y
-CONFIG_OF_EMBED=y
-CONFIG_DM=y
-CONFIG_DM_SPI_FLASH=y
-CONFIG_DM_SPI=y
-CONFIG_FSL_QSPI=y
 CONFIG_CMD_GREPENV=y
 CONFIG_CMD_MMC=y
+CONFIG_CMD_SF=y
 CONFIG_CMD_I2C=y
 CONFIG_CMD_USB=y
 # CONFIG_CMD_SETEXPR is not set
@@ -25,13 +23,15 @@ CONFIG_CMD_PING=y
 CONFIG_CMD_CACHE=y
 CONFIG_CMD_EXT2=y
 CONFIG_CMD_FAT=y
-CONFIG_CMD_SF=y
+CONFIG_OF_CONTROL=y
+CONFIG_OF_EMBED=y
 CONFIG_NET_RANDOM_ETHADDR=y
+CONFIG_DM=y
 CONFIG_NETDEVICES=y
 CONFIG_E1000=y
 CONFIG_SYS_NS16550=y
+CONFIG_FSL_QSPI=y
 CONFIG_USB=y
 CONFIG_USB_XHCI_HCD=y
 CONFIG_USB_XHCI_DWC3=y
-CONFIG_OF_LIBFDT=y
 CONFIG_EFI_LOADER_BOUNCE_BUFFER=y
-- 
2.8.1

[U-Boot] [U-Boot, V2, 2/2] common: add new boot media kconfig entry

[Tom Rini]

On Fri, Jun 17, 2016 at 05:39:51PM +0800, Peng Fan wrote:

> Add CONFIG_{SD|NAND|ONENAND|SPI|QSPI|SATA}_BOOT kconfig entries.
> 
> SoCs supports loading U-Boot from different medias to DRAM, such as
> i.MX6/7 supports loading U-Boot to DRAM from sd/emmc/nand/qspi/spi/sata
> and etc. For i.MX, imximage will generate different IVT headers according
> to boot medias.
> 
> Signed-off-by: Peng Fan <peng.fan@nxp.com>
> Cc: Simon Glass <sjg@chromium.org>
> Cc: Heiko Schocher <hs@denx.de>
> Cc: Joe Hershberger <joe.hershberger@ni.com>
> Cc: Bin Meng <bmeng.cn@gmail.com>
> Cc: Christophe Ricard <christophe-h.ricard@st.com>
> Cc: Nikita Kiryanov <nikita@compulab.co.il>
> Cc: Francois Retief <fgretief@spaceteq.co.za>
> Cc: Tom Rini <trini@konsulko.com>

Applied to u-boot/master, 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/20160628/523b9e41/attachment.sig>

[U-Boot] [PATCH V2 1/2] Kconfig: make NOR_BOOT a common option

[Simon Glass]

On 17 June 2016 at 03:39, Peng Fan <van.freenix@gmail.com> wrote:
> Not only am335x supports booting from NOR, i.MX6 SoCs also
> supports booting from NOR. Make NOR_BOOT a common
> option to let different SoCs share it.
>
> Signed-off-by: Peng Fan <peng.fan@nxp.com>
> Cc: Simon Glass <sjg@chromium.org>
> Cc: Heiko Schocher <hs@denx.de>
> Cc: Joe Hershberger <joe.hershberger@ni.com>
> Cc: Christophe Ricard <christophe-h.ricard@st.com>
> Cc: Bin Meng <bmeng.cn@gmail.com>
> Cc: Francois Retief <fgretief@spaceteq.co.za>
> Cc: Tom Rini <trini@konsulko.com>
> ---
>
> V2:
>  New patch
>
>  board/ti/am335x/Kconfig |  9 ---------
>  common/Kconfig          | 13 +++++++++++++
>  2 files changed, 13 insertions(+), 9 deletions(-)

Reviewed-by: Simon Glass <sjg@chromium.org>

[U-Boot] [U-Boot, V2, 1/2] Kconfig: make NOR_BOOT a common option

[Tom Rini]

On Fri, Jun 17, 2016 at 05:39:50PM +0800, Peng Fan wrote:

> Not only am335x supports booting from NOR, i.MX6 SoCs also
> supports booting from NOR. Make NOR_BOOT a common
> option to let different SoCs share it.
> 
> Signed-off-by: Peng Fan <peng.fan@nxp.com>
> Cc: Simon Glass <sjg@chromium.org>
> Cc: Heiko Schocher <hs@denx.de>
> Cc: Joe Hershberger <joe.hershberger@ni.com>
> Cc: Christophe Ricard <christophe-h.ricard@st.com>
> Cc: Bin Meng <bmeng.cn@gmail.com>
> Cc: Francois Retief <fgretief@spaceteq.co.za>
> Cc: Tom Rini <trini@konsulko.com>
> Reviewed-by: Simon Glass <sjg@chromium.org>

Applied to u-boot/master, 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/20160628/1c050083/attachment.sig>