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

[Masahiro Yamada <yamada.masahiro@socionext.com>]

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