On Thu, Jul 26, 2018 at 09:31:08AM +0100, Alex Kiernan wrote: > On Fri, Jul 20, 2018 at 11:34 PM Tom Rini <tr...@konsulko.com> wrote: > > > > On Thu, Jul 05, 2018 at 12:38:15PM +0000, Alex Kiernan wrote: > > > > > The test for (CONFIG_BOOTDELAY >= 0) has been in U-Boot since the > > > beginning, but the meaning of it has changed over time. Allow the > > > default to be set for any value, including -ve ones. This allows > > > (for example) CONFIG_ENV_IS_NOWHERE to have values for bootdelay in > > > its compiled in environment. > > > > > > The only thing this changes is where the default for bootdelay can be > > > fetched from; before this change you get a compiled in default, after > > > you'll pull it from the default value in the environment, but both values > > > will be the same. Also if there's a value set in the environment then > > > that will take precedence (as before). > > > > > > Signed-off-by: Alex Kiernan <alex.kier...@gmail.com> > > > > Applied to u-boot/master, thanks! > > > > I've just realised that if you had an existing hardcoded bootdelay= to > cover the case where it wasn't being inserted through env_defaults you > would now end up with two. > > However checking there's 6 boards (9 configs) which possibly have this > problem, but none of them have a -ve value for CONFIG_BOOTDELAY. If I > revert this change and then grep out bootdelay from the generated > environments for those configs, 7 have duplicates before this change > (the last two are odroid-c2 and odroid-xu3 which are fine): > > cl-som-am57x/uboot.env: bootdelay=2 > cl-som-am57x/uboot.env: bootdelay=3 > cm_t54/uboot.env: bootdelay=3 > cm_t54/uboot.env: bootdelay=3 > display5_factory/uboot.env: bootdelay=3 > display5_factory/uboot.env: bootdelay=1 > display5/uboot.env: bootdelay=2 > display5/uboot.env: bootdelay=1 > nas220/uboot.env: bootdelay=3 > nas220/uboot.env: bootdelay=-1 > odroid/uboot.env: bootdelay=2 > odroid/uboot.env: bootdelay=0 > vinco/uboot.env: bootdelay=3 > vinco/uboot.env: bootdelay=0
Ah, good catch. In the end, it's probably OK. > I don't think there's anything here for me to fix up, but the > maintainers of those boards probably want to figure out which of the > bootdelay values they wanted. > > I wonder if we want some QA process off the end of the build (or in > buildman?) which verifies the extracted environment for duplicate > entries. That would be a great addition to buildman, yes. -- Tom
signature.asc
Description: PGP signature
_______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
