[U-Boot] [PATCH] imx: Introduce CONFIG_SPL_FORCE_MMC_BOOT to force MMC boot on falcon mode

[Heiko Schocher]

Hello Lukasz,

added Stefano to cc as he is the imx custodian.

Am 03.09.2019 um 23:43 schrieb Lukasz Majewski:
> This change tries to fix the following problem:
> 
> - The board boots (to be more precise - ROM loads SPL) from a slow SPI-NOR
>    memory.
>    As a result the spl_boot_device() will return SPI-NOR as a boot device
>    (which is correct).
> 
> - The problem is that in 'falcon boot' the eMMC is used as a boot medium to
>    load kernel from its partition.
>    Calling spl_boot_device() will break things as it returns SPI-NOR device.
> 
> To fix this issue the new CONFIG_SPL_FORCE_MMC_BOOT Kconfig flag is
> introduced to handle this special use case. By default it is not defined,
> so there is no change in the legacy code flow.
> 
> Signed-off-by: Lukasz Majewski <lukma at denx.de>
> 
> 
> ---
> 
> This patch is a follow up of previous discussion/fix:
> https://patchwork.ozlabs.org/patch/796237/
> 
> Travis-CI:
> https://travis-ci.org/lmajewski/u-boot-dfu/builds/580272414
> ---
>   arch/arm/mach-imx/spl.c | 11 +++++++++++
>   common/spl/Kconfig      |  7 +++++++
>   2 files changed, 18 insertions(+)

I have just similiar change for an imx6ull based board ...
just antoher usecase: In factory empty board boots into USB SDP mode,
and SPL gets loaded with usb_loader ... SPL detects a sd card (there
is no sd card slot mounted, mmc boot is disabled! They attach only one
for installing software) and boots U-Boot and system from sd card.
Than all software gets installed fully automated with the help of
swupdate ...

> diff --git a/arch/arm/mach-imx/spl.c b/arch/arm/mach-imx/spl.c
> index 1f230aca3397..daa3d8f7ed94 100644
> --- a/arch/arm/mach-imx/spl.c
> +++ b/arch/arm/mach-imx/spl.c
> @@ -178,7 +178,18 @@ int g_dnl_bind_fixup(struct usb_device_descriptor *dev, const char *name)
>   /* called from spl_mmc to see type of boot mode for storage (RAW or FAT) */
>   u32 spl_boot_mode(const u32 boot_device)
>   {
> +/*
> + * When CONFIG_SPL_FORCE_MMC_BOOT is defined the 'boot_device' is used
> + * unconditionally to decide about device to use for booting.
> + * This is crucial for falcon boot mode, when board boots up (i.e. ROM
> + * loads SPL) from slow SPI-NOR memory and afterwards the SPL's 'falcon' boot
> + * mode is used to load Linux OS from eMMC partition.
> + */
> +#ifdef CONFIG_SPL_FORCE_MMC_BOOT
> +	switch (boot_device) {
> +#else
>   	switch (spl_boot_device()) {
> +#endif

Just dummy question .. couldn;t we switch to use always boot_device?

In my case I had a board specific:

void board_boot_order(u32 *spl_boot_list)
{
         spl_boot_list[0] = BOOT_DEVICE_MMC1;
         spl_boot_list[1] = BOOT_DEVICE_SPI;
         spl_boot_list[2] = BOOT_DEVICE_BOARD;
         spl_boot_list[3] = BOOT_DEVICE_NONE;
}

which leads that BOOT_DEVICE_MMC1 is passed to spl_boot_mode()

If MMC1 is not found, it tries to boot U-Boot from SPI, and if this is
empty, as fallback board go into USB SDP mode.

The weak function of board_boot_order is:

__weak void board_boot_order(u32 *spl_boot_list)
{
         spl_boot_list[0] = spl_boot_device();
}

which is exactly what we pass to spl_boot_mode() ... so instead calling
spl_boot_device() twice we can use the passed boot_device ... and
save the ifdef and new Kconfig option.

But may I oversee something ?

>   	/* for MMC return either RAW or FAT mode */
>   	case BOOT_DEVICE_MMC1:
>   	case BOOT_DEVICE_MMC2:
> diff --git a/common/spl/Kconfig b/common/spl/Kconfig
> index f467eca2be72..3460beb62d59 100644
> --- a/common/spl/Kconfig
> +++ b/common/spl/Kconfig
> @@ -607,6 +607,13 @@ config SPL_MMC_SUPPORT
>   	  this option to build the drivers in drivers/mmc as part of an SPL
>   	  build.
>   
> +config SPL_FORCE_MMC_BOOT
> +	bool "Force SPL's falcon boot from MMC"
> +	depends on SPL_MMC_SUPPORT
> +	default n
> +	help
> +	  Force SPL's falcon boot to use MMC device for Linux kernel booting.

Hmm... falcon boot is just one use case. I would drop "falcon boot"
It just to force boot from MMC.

> +
>   config SPL_MMC_TINY
>   	bool "Tiny MMC framework in SPL"
>   	depends on SPL_MMC_SUPPORT
> 

bye,
Heiko
-- 
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-52   Fax: +49-8142-66989-80   Email: hs at denx.de