On Thu, Jul 26, 2018 at 09:31:08AM +0100, Alex Kiernan wrote:
On Fri, Jul 20, 2018 at 11:34 PM Tom Rini trini@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.kiernan@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.