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.free...@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.free...@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....@nxp.com> >>>> >> Cc: Simon Glass <s...@chromium.org> >>>> >> Cc: Heiko Schocher <h...@denx.de> >>>> >> Cc: Joe Hershberger <joe.hershber...@ni.com> >>>> >> Cc: Bin Meng <bmeng...@gmail.com> >>>> >> Cc: Christophe Ricard <christophe-h.ric...@st.com> >>>> >> Cc: Nikita Kiryanov <nik...@compulab.co.il> >>>> >> Cc: Francois Retief <fgret...@spaceteq.co.za> >>>> >> Cc: Tom Rini <tr...@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 mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot