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

Tom Rini trini at konsulko.com
Wed Jun 29 04:08:21 CEST 2016


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 at 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 at 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 at nxp.com>
> >>> >> Cc: Simon Glass <sjg at chromium.org>
> >>> >> Cc: Heiko Schocher <hs at denx.de>
> >>> >> Cc: Joe Hershberger <joe.hershberger at ni.com>
> >>> >> Cc: Bin Meng <bmeng.cn at gmail.com>
> >>> >> Cc: Christophe Ricard <christophe-h.ricard at st.com>
> >>> >> Cc: Nikita Kiryanov <nikita at compulab.co.il>
> >>> >> Cc: Francois Retief <fgretief at spaceteq.co.za>
> >>> >> Cc: Tom Rini <trini at 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>


More information about the U-Boot mailing list