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 nhelpEnabling this will make a U-Boot binary that is capable of beingbooted via NAND flash. This is not a must, some SoCs need this,somes not.+config ONENAND_BOOT
bool "Support for booting from ONENAND"default nhelpEnabling this will make a U-Boot binary that is capable of beingbooted via ONENAND. This is not a must, some SoCs need this,somes not.+config QSPI_BOOT
bool "Support for booting from QSPI flash"default nhelpEnabling this will make a U-Boot binary that is capable of beingbooted via QSPI flash. This is not a must, some SoCs need this,somes not.+config SATA_BOOT
bool "Support for booting from SATA"default nhelpEnabling this will make a U-Boot binary that is capable of beingbooted via SATA. This is not a must, some SoCs need this,somes not.+config SD_BOOT
bool "Support for booting from SD/EMMC"default nhelpEnabling this will make a U-Boot binary that is capable of beingbooted 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 nhelpEnabling this will make a U-Boot binary that is capable of beingbooted 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?