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
