[U-Boot] [PATCH v1 3/5] bootcount: u-boot: Do not increment bootcount if already done in SPL

[Lukasz Majewski]

Hi Tom,

> On Mon, Feb 26, 2018 at 01:22:44PM +0100, Lukasz Majewski wrote:
> 
> > If the CONFIG_SPL_BOOTCOUNT_LIMIT is defined, the bootcount
> > variable is already incremented after each boot attempt.
> > 
> > For that reason we shall not increment it again in u-boot.
> > 
> > Signed-off-by: Lukasz Majewski <lukma at denx.de>
> > ---
> > 
> >  common/autoboot.c | 2 ++
> >  1 file changed, 2 insertions(+)
> > 
> > diff --git a/common/autoboot.c b/common/autoboot.c
> > index 2eef7a04cc..87fca2ea92 100644
> > --- a/common/autoboot.c
> > +++ b/common/autoboot.c
> > @@ -298,7 +298,9 @@ const char *bootdelay_process(void)
> >  
> >  #ifdef CONFIG_BOOTCOUNT_LIMIT
> >  	bootcount = bootcount_load();
> > +#ifndef CONFIG_SPL_BOOTCOUNT_LIMIT
> >  	bootcount++;
> > +#endif
> >  	bootcount_store(bootcount);
> >  	env_set_ulong("bootcount", bootcount);
> >  	bootlimit = env_get_ulong("bootlimit", 10, 0);  
> 
> Shouldn't we make the whole bit of code here depend on
> !CONFIG_SPL_BOOTCOUNT_LIMIT ?  

Maybe I will try to present the scenario:

- We do use SPL to boot from either eMMC (if in falcon) or from SPI-NOR
  (if not in falcon)

- With bootcount:
	-- We may want to boot into eMMC directly, so we need to
	increment the bootcount (no matter where it is located).

	-- We intentionally (by setting other env variable) or not (by
	entering X resets) abort falcon mode boot from SPL and boot to
	u-boot (which is in spi-nor).
	In this case we do need all the bootcount limit functionality
	(i.e. altbootcmd) excluding increment bootcount (as it was
	done in SPL).
	
+#ifndef CONFIG_SPL_BOOTCOUNT_LIMIT is only required to achieve this
goal without making any more code change...

> Or for that matter, re-work the first
> patch to instead be:
> bool SUPPORT_BOOTCOUNT "Support bootcount in some way"
> choice "Bootcount location"
> bool SPL_BOOTCOUNT_LIMIT "Count boots from POV of SPL"
> bool BOOTCOUNT_LIMIT "Count boots from POV of full U-Boot"
> endchoice

But then SPL_BOOTCOUNT_LIMIT would select BOOTCOUNT_LIMIT to fulfil the
above scenario.

> 
> ?  Looking back at my old series from 2014 to do this, I just had a
> big warning saying you need to enable bootcount for SPL or for full
> U-Boot so you would never set BOOTCOUNT_LIMIT if doing SPL bootcount
> instead.

Such functionality can be achieved with SPL_BOOTCOUNT_LIMIT depending
on BOOTCOUNT_LIMIT.

If SPL_BOOTCOUNT_LIMIT selected, then "[PATCH v1 3/5] bootcount: u-boot:
Do not increment bootcount if already done in SPL" does its job.

> 




Best regards,

Lukasz Majewski

--

DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20180226/a68921cb/attachment.sig>