All of lore.kernel.org
 help / color / mirror / Atom feed
From: Heiko Schocher <hs@denx.de>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH] imx: Introduce CONFIG_SPL_FORCE_MMC_BOOT to force MMC boot on falcon mode
Date: Wed, 4 Sep 2019 06:45:56 +0200	[thread overview]
Message-ID: <ec4203bc-5adf-1b70-0f88-13ca622089e1@denx.de> (raw)
In-Reply-To: <20190903214358.5127-1-lukma@denx.de>

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

  reply	other threads:[~2019-09-04  4:45 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-09-03 21:43 [U-Boot] [PATCH] imx: Introduce CONFIG_SPL_FORCE_MMC_BOOT to force MMC boot on falcon mode Lukasz Majewski
2019-09-04  4:45 ` Heiko Schocher [this message]
2019-09-04  8:46   ` Lukasz Majewski
2019-09-04  8:59     ` Stefano Babic
2019-09-04  9:54       ` Lukasz Majewski
2019-09-04 10:35         ` Lukasz Majewski
2019-09-05  8:08           ` Stefano Babic
2019-09-05  9:42             ` Lukasz Majewski
2019-09-05 10:18               ` Heiko Schocher
2019-09-09  8:02                 ` Lukasz Majewski
2019-09-09 11:27                   ` Stefano Babic
2019-09-05 10:02             ` Heiko Schocher

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ec4203bc-5adf-1b70-0f88-13ca622089e1@denx.de \
    --to=hs@denx.de \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.