From mboxrd@z Thu Jan 1 00:00:00 1970 From: Masahiro Yamada Date: Tue, 28 Jun 2016 14:24:00 +0900 Subject: [U-Boot] [PATCH V2 2/2] common: add new boot media kconfig entry In-Reply-To: <20160628050246.GA28340@linux-7smt.suse> References: <1466156391-26514-1-git-send-email-peng.fan@nxp.com> <1466156391-26514-2-git-send-email-peng.fan@nxp.com> <20160619102050.GA28565@linux-7smt.suse> <20160624225744.GH19080@bill-the-cat> <20160628050246.GA28340@linux-7smt.suse> Message-ID: List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Hi. 2016-06-28 14:02 GMT+09:00 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 : >>> >> 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 >>> >> Cc: Simon Glass >>> >> Cc: Heiko Schocher >>> >> Cc: Joe Hershberger >>> >> Cc: Bin Meng >>> >> Cc: Christophe Ricard >>> >> Cc: Nikita Kiryanov >>> >> Cc: Francois Retief >>> >> Cc: Tom Rini >>> >> --- >>> >> >>> >> 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