From mboxrd@z Thu Jan 1 00:00:00 1970 From: Lukasz Majewski Date: Mon, 26 Feb 2018 15:53:18 +0100 Subject: [U-Boot] [PATCH v1 3/5] bootcount: u-boot: Do not increment bootcount if already done in SPL In-Reply-To: <20180226142711.GM4311@bill-the-cat> References: <20180226122246.10595-1-lukma@denx.de> <20180226122246.10595-4-lukma@denx.de> <20180226142711.GM4311@bill-the-cat> Message-ID: <20180226155318.22163e6b@jawa> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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 > > --- > > > > 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: