From: Harald Seiler <hws@denx.de>
To: u-boot@lists.denx.de
Subject: [PATCH 0/5] Fix spl_mmc_boot_mode() implementation for IMX
Date: Thu, 23 Apr 2020 13:07:48 +0200 [thread overview]
Message-ID: <20200423110753.51231-1-hws@denx.de> (raw)
The spl_mmc_boot_mode() (formerly spl_boot_mode()) implementation for
IMX has grown quite big over time [1]. It has also started to steer
away from what it is meant to do in its current form and breaks some
use-cases of the SPL. Namely, the issue is that nowadays SPL can
attempt loading U-Boot from multiple MMC devices and this function needs
to return the correct mode for each one which it currently does not.
There have been multiple attempts to fix this in the past, starting with
a (rejected) patch from Anatolij [2]. Most recently, a patch from
Lukasz [3] was merged which introduces a config option
CONFIG_SPL_FORCE_MMC_BOOT.
I think this is going in the wrong direction when the real solution lies
in cutting the function back down as much as possible. IMX currently
has the biggest implementation in the tree and I don't really see
a reason why all that complexity is necessary. I have spend some time
to find out the full story here and have summarized that in a previous
mail [4].
To cut it as short as possible: I believe CONFIG_SPL_FORCE_MMC_BOOT is
superfluous as enabling it is the only correct behavior and
CONFIG_SPL_FORCE_MMC_BOOT=n is faulty and will lead to problems when
customizing the SPL boot sequence e.g. using board_boot_order().
Thus, this series contains Anatolij's original patch, reverts the
introduction of CONFIG_SPL_FORCE_MMC_BOOT and cleans up the
implementation a bit. One thing which is left out, which still needs to
happen in the future is getting rid of the big #if for IMX{7,8,8M}.
I don't have hardware to test IMX7 or 8 right now and haven't looked too
deep into what needs to be done here.
I'm pretty certain this series should not break any use-case and if it
does anyway, a breakage caused by it indicates the need to fix SPL
configuration for that board. I'm happy to help with that if the need
arises.
[1]: https://gitlab.denx.de/u-boot/u-boot/-/blob/v2020.04/arch/arm/mach-imx/spl.c#L192-251
[2]: https://patchwork.ozlabs.org/patch/796237/
[3]: https://gitlab.denx.de/u-boot/u-boot/-/commit/772b55723bcbe8ebe84f579d9cdc831d8e18579d
[4]: https://lists.denx.de/pipermail/u-boot/2020-April/405979.html
Anatolij Gustschin (1):
imx: spl: return boot mode for asked MMC device in spl_mmc_boot_mode()
Harald Seiler (4):
Revert "imx: Introduce CONFIG_SPL_FORCE_MMC_BOOT to force MMC boot on
falcon mode"
Revert "imx: defconfig: Enable CONFIG_SPL_FORCE_MMC_BOOT"
imx: spl: Remove ifdefs in spl_mmc_boot_mode()
imx: spl: Fix use of removed SPL_FAT_SUPPORT config
arch/arm/mach-imx/spl.c | 49 ++++++++++++-------------------------
common/spl/Kconfig | 9 -------
configs/display5_defconfig | 1 -
configs/imx28_xea_defconfig | 1 -
4 files changed, 16 insertions(+), 44 deletions(-)
--
2.26.1
next reply other threads:[~2020-04-23 11:07 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-23 11:07 Harald Seiler [this message]
2020-04-23 11:07 ` [PATCH 1/5] imx: spl: return boot mode for asked MMC device in spl_mmc_boot_mode() Harald Seiler
2020-05-02 9:08 ` sbabic at denx.de
2020-04-23 11:07 ` [PATCH 2/5] Revert "imx: Introduce CONFIG_SPL_FORCE_MMC_BOOT to force MMC boot on falcon mode" Harald Seiler
2020-05-02 9:08 ` sbabic at denx.de
2020-04-23 11:07 ` [PATCH 3/5] Revert "imx: defconfig: Enable CONFIG_SPL_FORCE_MMC_BOOT" Harald Seiler
2020-05-02 9:08 ` sbabic at denx.de
2020-04-23 11:07 ` [PATCH 4/5] imx: spl: Remove ifdefs in spl_mmc_boot_mode() Harald Seiler
2020-05-02 9:08 ` sbabic at denx.de
2020-04-23 11:07 ` [PATCH 5/5] imx: spl: Fix use of removed SPL_FAT_SUPPORT config Harald Seiler
2020-05-02 9:08 ` sbabic at denx.de
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=20200423110753.51231-1-hws@denx.de \
--to=hws@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox