ARM Sunxi Platform Development
 help / color / mirror / Atom feed
From: Andre Przywara <andre.przywara@arm.com>
To: Samuel Holland <samuel@sholland.org>
Cc: Jagan Teki <jagan@amarulasolutions.com>,
	u-boot@lists.denx.de, linux-sunxi@lists.linux.dev,
	Jernej Skrabec <jernej.skrabec@gmail.com>,
	Chris Morgan <macroalpha82@gmail.com>
Subject: Re: [PATCH] sunxi: fix initial environment loading without MMC
Date: Tue, 26 Apr 2022 15:25:56 +0100	[thread overview]
Message-ID: <20220426152556.4a3ba3fb@donnerap.cambridge.arm.com> (raw)
In-Reply-To: <bed703d6-1820-8df4-747a-6114877dedee@sholland.org>

On Sat, 23 Apr 2022 16:01:00 -0500
Samuel Holland <samuel@sholland.org> wrote:

Hi Samuel,

thanks for having a look and the comments.

> On 4/20/22 7:34 PM, Andre Przywara wrote:
> > Commit e42dad4168fe ("sunxi: use boot source for determining environment
> > location") changed our implementation of env_get_location() and enabled
> > it for every board, even those without MMC support (like the C.H.I.P.
> > boards). However the default fallback location of ENVL_FAT does not cope
> > very well without MMC support compiled in, so the board hangs when trying
> > to initially load the environment.
> > 
> > Change the default fallback location to be ENVL_FAT only when the FAT
> > environment support is enabled, and use ENVL_NOWHERE and ENVL_UBI as
> > alternative fallbacks, when those sources are enabled.
> > 
> > This fixes U-Boot loading on the C.H.I.P. boards.
> > 
> > Fixes: e42dad4168fe ("sunxi: use boot source for determining environment location")
> > Reported-by: Chris Morgan <macroalpha82@gmail.com>
> > Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> > ---
> >  board/sunxi/board.c | 9 ++++++++-
> >  1 file changed, 8 insertions(+), 1 deletion(-)
> > 
> > diff --git a/board/sunxi/board.c b/board/sunxi/board.c
> > index 89324159d55..befb6076ca6 100644
> > --- a/board/sunxi/board.c
> > +++ b/board/sunxi/board.c
> > @@ -132,7 +132,14 @@ void i2c_init_board(void)
> >   */
> >  enum env_location env_get_location(enum env_operation op, int prio)
> >  {
> > -	enum env_location boot_loc = ENVL_FAT;
> > +	enum env_location boot_loc;
> > +
> > +	if (IS_ENABLED(CONFIG_ENV_IS_NOWHERE))
> > +		boot_loc = ENVL_NOWHERE;
> > +	else if (IS_ENABLED(CONFIG_ENV_IS_IN_FAT))
> > +		boot_loc = ENVL_FAT;
> > +	else if (IS_ENABLED(CONFIG_ENV_IS_IN_UBI))
> > +		boot_loc = ENVL_UBI;
> 
> This could leave boot_loc uninitialized. And there is still an unconditional use
> of ENVL_FAT in the BOOT_DEVICE_MMCx case.

Yeah, it's a mess, and there doesn't seem to be a one-fits-all fallback
value. Returning ENVL_UNKNOWN when prio is 0 definitely hangs, as does
returning some source without having the corresponding driver compiled in,
so getting this right *and* nice-looking is a bit tricky.

> >  	gd->env_load_prio = prio;
> 
> I don't think the hook is supposed to change this variable.

Yeah, don't remember why I initially put that in, I must have copied that
from somewhere. All I remember is that this code is touchy (as the bug
report leading to that patch shows), and there are quite some corner cases
to test.

> I'm still a bit confused on the fallback logic you have in place. Splitting it
> up into three blocks doesn't help. If the goal is to load the environment from
> the boot device, while preferring filesystems over raw block devices, I propose
> the following:

Admittedly this gets messier, I mainly wanted to fix the regression
quickly, since it already broke the release for the CHIP boards.
I will have a closer look at your suggestion and check for those corner
cases, but will probably go with that instead of piling up more cruft on
my previous code ;-)

Thanks,
Andre

> 
> diff --git a/board/sunxi/board.c b/board/sunxi/board.c
> index 427113534b..27508bd306 100644
> --- a/board/sunxi/board.c
> +++ b/board/sunxi/board.c
> @@ -129,26 +129,38 @@
>   * Try to use the environment from the boot source first.
>   * For MMC, this means a FAT partition on the boot device (SD or eMMC).
>   * If the raw MMC environment is also enabled, this is tried next.
> - * SPI flash falls back to FAT (on SD card).
>   */
>  enum env_location env_get_location(enum env_operation op, int prio)
>  {
> -	enum env_location boot_loc = ENVL_FAT;
> +	if (prio > 1)
> +		return ENVL_UNKNOWN;
> 
> -	gd->env_load_prio = prio;
> +	if (IS_ENABLED(CONFIG_ENV_IS_NOWHERE))
> +		return ENVL_NOWHERE;
> 
>  	switch (sunxi_get_boot_device()) {
>  	case BOOT_DEVICE_MMC1:
>  	case BOOT_DEVICE_MMC2:
> -		boot_loc = ENVL_FAT;
> +		if (prio == 0) {
> +			if (IS_ENABLED(CONFIG_ENV_IS_IN_EXT4))
> +				return ENVL_EXT4;
> +			if (IS_ENABLED(CONFIG_ENV_IS_IN_FAT))
> +				return ENVL_FAT;
> +		}
> +		if (IS_ENABLED(CONFIG_ENV_IS_IN_MMC))
> +			return ENVL_MMC;
>  		break;
>  	case BOOT_DEVICE_NAND:
> +		if (prio == 0 && IS_ENABLED(CONFIG_ENV_IS_IN_UBI))
> +			return ENVL_UBI;
>  		if (IS_ENABLED(CONFIG_ENV_IS_IN_NAND))
> -			boot_loc = ENVL_NAND;
> +			return ENVL_NAND;
>  		break;
>  	case BOOT_DEVICE_SPI:
> +		if (prio == 0 && IS_ENABLED(CONFIG_ENV_IS_IN_UBI))
> +			return ENVL_UBI;
>  		if (IS_ENABLED(CONFIG_ENV_IS_IN_SPI_FLASH))
> -			boot_loc = ENVL_SPI_FLASH;
> +			return ENVL_SPI_FLASH;
>  		break;
>  	case BOOT_DEVICE_BOARD:
>  		break;
> @@ -156,23 +168,6 @@
>  		break;
>  	}
> 
> -	/* Always try to access the environment on the boot device first. */
> -	if (prio == 0)
> -		return boot_loc;
> -
> -	if (prio == 1) {
> -		switch (boot_loc) {
> -		case ENVL_SPI_FLASH:
> -			return ENVL_FAT;
> -		case ENVL_FAT:
> -			if (IS_ENABLED(CONFIG_ENV_IS_IN_MMC))
> -				return ENVL_MMC;
> -			break;
> -		default:
> -			break;
> -		}
> -	}
> -
>  	return ENVL_UNKNOWN;
>  }
> 
> 
> Regards,
> Samuel


  reply	other threads:[~2022-04-26 14:26 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-21  0:34 [PATCH] sunxi: fix initial environment loading without MMC Andre Przywara
2022-04-23 21:01 ` Samuel Holland
2022-04-26 14:25   ` Andre Przywara [this message]
2022-06-24  1:00     ` Andre Przywara
2022-06-24  1:21       ` Samuel Holland
2022-06-24 16:03         ` Tom Rini

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=20220426152556.4a3ba3fb@donnerap.cambridge.arm.com \
    --to=andre.przywara@arm.com \
    --cc=jagan@amarulasolutions.com \
    --cc=jernej.skrabec@gmail.com \
    --cc=linux-sunxi@lists.linux.dev \
    --cc=macroalpha82@gmail.com \
    --cc=samuel@sholland.org \
    --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