On Fri, Jun 29, 2018 at 09:19:34PM -0700, Simon Glass wrote: > +Tom > > Hi Alex, > > On 29 June 2018 at 02:31, Alex Kiernan <alex.kier...@gmail.com> wrote: > > > > I've just been digging into a problem where I've got both > > CONFIG_ENV_IS_NOWHERE set and CONFIG_BOOTDELAY set to -2 and it turns > > out in env_default.h we have: > > > > #if defined(CONFIG_BOOTDELAY) && (CONFIG_BOOTDELAY >= 0) > > "bootdelay=" __stringify(CONFIG_BOOTDELAY) "\0" > > #endif > > > > So the -ve values never make it into the default environment, which > > means I don't have it at all when CONFIG_ENV_IS_NOWHERE. > > > > The (CONFIG_BOOTDELAY >= 0) seems to have been there forever > > (c609719b8d1b2dca590e0ed499016d041203e403, Sun Nov 3 00:24:07 2002 > > +0000 is as far back as I've gone), but we've then changed the > > behaviours of the bootdelay values in (the commit I was looking at was > > 2fbb8462b0e18893b4b739705db047ffda82d4fc from Mon Jun 27 16:23:01 2016 > > +0900, but I'm not sure that's really the right one) > > > > I think we should change the code to a simple #if defined(CONFIG_BOOTDELAY) > > > > ? > > I don't know what the check was supposed to do and the comment on the > 'bootdelay' env variable just says 'see CONFIG_BOOTDELAY'. Your > solution sounds reasonable to me but perhaps Tom or Wolfgang have more > insight.
It seems like a historical oversight. But.. what happens before and after when you have a negative bootdelay value in the default environment? -- Tom
signature.asc
Description: PGP signature
_______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
