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

Heiko Schocher
2019-09-04T04:45:56Z

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@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