[U-Boot] [PATCH v2 4/5] autoboot: fix a bunch of misconversion of CONFIG_BOOTDELAY

[Masahiro Yamada]

Hi.

2016-06-11 20:31 GMT+09:00 Hans de Goede <hdegoede at redhat.com>:
> Hi,
>
> On 11-06-16 11:44, Masahiro Yamada wrote:
>>
>> Commit bb597c0eeb7e ("common: bootdelay: move CONFIG_BOOTDELAY into
>> a Kconfig option") made a number of misconversion.
>>
>> [1] CONFIG_BOOTDELAY=-1 all gone
>> [2] CONFIG_BOOTDELAY=1 all gone
>> [3] CONFIG_BOOTDELAY=2 all gone
>> [4] Conditionally defined CONFIG_BOOTDELAY all gone
>>
>> All of the misconverted boards now use the default value,
>> CONFIG_BOOTDELAY=0, which came from the Kconfig entry.
>>
>> I am imagining some reasons for this.
>>
>> For [1], due to the bug of tools/scripts/define2mk.sed (now fixed),
>>   #define CONFIG_BOOTDELAY -1
>> was converted to
>>   CONFIG_BOOTDELAY="-1"
>> in the include/autoconf.mk, so the tools/moveconfig.py regarded it
>> as a string type option, and failed to move it.
>>
>> For [2], as you see in the comment block in the define2mk.sed,
>>   #define CONFIG_BOOTDELAY 1
>> is converted to
>>   CONFIG_BOOTDELAY=y
>> in the include/autoconf.mk.  This needs a special care because we do
>> not know whether we are moving a bool option with value y or an
>> integer option with value 1.  A recently-sent patch fixes this issue.
>>
>> I do not understand the reason for [3].
>>
>> [4] is another case the current moveconfig cannot handle correctly.
>> If the define is surrounded by #ifndef CONFIG_BOOTDELAY like follows,
>> the default value from Kconfig entry beats the define in C header.
>>
>>   #ifndef CONFIG_BOOTDELAY
>>   #define CONFIG_BOOTDELAY      3
>>   #endif
>>
>> Joe's patch can solve this issue.
>>
>> Anyway, I ran the newest moveconfig tool based on commit 3191d8408053
>> (=immediately prior to the bad commit) to generate this patch.
>>
>> Signed-off-by: Masahiro Yamada <yamada.masahiro at socionext.com>
>> ---
>>
>> Changes in v2:
>>   - Fix case [4]
>>

>
>
> No, just no NACK at least for all the sunxi boards.
>
> This madness where everytime we convert something to Kconfig
> we end up bloating ALL the defconfigs needs to stop and it
> needs to stop now.
>
> I'm 100% done with fixing up things everytime after someone
> thinks this is a good idea.
>
> This is not a good idea, it is a REALLY REALLY bad idea.
>
> The defconfig files should contain board specific settings,
> we had the same nonsense when some of the CONFIG_CMD_FOO
> things were converted, and all of a sudden we had the
> same 5 extra lines in every defconfig for every board
> which used to use config_distro_bootcmd.h
>
> Apparently no one was smart enough to realize that if
> we were moving stuff from a common config header to
> Kconfig, we would need something like
>
> CONFIG_DISTRO_BOOTCMD in Kconfig which would then select
> all CONFIG_CMD_FOO options which were moved, and then
> board / soc Kconfig snippets could simply do:
>
>         select CONFIG_DISTRO_BOOTCMD

Right.

(I had already noticed this, but I was not picky about it
just because I was not using distro on my boards.)

Recently, when I decided to try distro,
the first thing I did was
"git log include/include/config_distro_defaults.h"
to find out what has gone to Kconfig.




> I've hacked around this for sunxi:
>
> config ARCH_SUNXI
>         bool "Support sunxi (Allwinner) SoCs"
>         select CMD_BOOTZ
>         select CMD_DHCP
>         select CMD_EXT2
>         select CMD_EXT4
>         select CMD_FAT
>         select CMD_FS_GENERIC
>         select CMD_GPIO
>         select CMD_MII
>         select CMD_MMC if MMC
>         select CMD_PING
>         select CMD_USB
>         ...
>
> But I'm sick and tired of this nonsense repeating over
> and over again.
>
> This needs to stop and it needs to stop NOW.
>
> If Commit bb597c0eeb7e ("common: bootdelay: move CONFIG_BOOTDELAY into
> a Kconfig option") breaks things on 436 boards, then clearly it needs
> to be reverted rather then messing up 436 defconfig files with cruft.
>
> Why am I so against filling defconfigs with a couple of innocent lines?
> Because this makes it much harder for people to add support for new
> boards. The more cruft we put there, the harder it becomes for people
> to see the actual board specific things.
>
> And clearly 0 is a very very poor default for CONFIG_BOOTDELAY, I can
> pretty much live with any default for sunxi other then 0, generic distro
> users  need to be able to easily stop auto-boot, so 0 is just no good.
>
> If the new default were 1 or 2, or 3, then that would be fine with me,
> even if 1 and 3 are a change from the current sunxi setting I can live
> with this.

Agree.

CONFIG_BOOTDELAY=0 can still have a chance to
enter the command prompt if CONFIG_ZERO_BOOTDELAY_CHECK is set.
But, anyway, this is absolutely poor default.


When I was fixing the broken boards, I realized that
really small number of boards set it as 0.

According to my analysis,

 CONFIG_BOOTDELAY is not set:  28
 CONFIG_BOOTDELAY=-1        :  21
 CONFIG_BOOTDELAY=0         :  17
 CONFIG_BOOTDELAY=1         :  76
 CONFIG_BOOTDELAY=2         :  265
 CONFIG_BOOTDELAY=3         :  289
 CONFIG_BOOTDELAY=5         :  158
 CONFIG_BOOTDELAY=6         :  25
 CONFIG_BOOTDELAY=10        :  275
 CONFIG_BOOTDELAY=30        :  1

So, of the 1155 defconfigs, only 17 defconfigs set the value 0.
This default is poor also from the point of view of
"the most frequently used value".


The commit should have chosen 3 for the default.

As you pointed out, the boards with value 2, 3, 5, 6 would probably
not care about it very much
as long as it is greater than 0.



I am OK with reverting the bad commit completely.

Anyway, a big churn of Kconfig re-sync will happen again to change the default,
and move "config BOOTDELAY" entry to the correct place.

Despite that we already have the "autoboot" menu in cmd/Kconfig,
the entry for BOOTDELAY has gone to a completely unrelated place.
We need to fix this too.


> If we need a way to override this for some boards / SoCs, then
> we need something which we can do at the Kconfig level, iow something
> which can be select-ed on e.g. a per SoC basis, so that we do not need
> to mess up 436 defconfigs.


The problem for "select" is that
it disables users to un'select it.

We also agreed to not do

    config BOOTDELAY
           default 3

in board Kconfig.



In the first place, having many defconfigs is painful in terms of
maintainability.

I always try to support multiple boards with one defconfig.

The recently-added feature for FIT might be helpful to merge similar defconfigs
(but, this does not seem to be a perfect solution given that FIT is
heavy for SPL)

Linux supports multi-platform and barebox as well.
For example, "tegra_v7_defconfig" in barebox covers all the ARMv7 Tegra SoCs.



On the other hand, in U-boot, I am worried that the more and more
defconfigs are being added
just for a small difference.

For example, the recent commit d8ccbe93b57669 added 7 defconfigs just
for one board.

And the difference between the following two is just CONFIG_BOOTDELAY.

--- configs/am335x_shc_sdboot_defconfig 2016-06-11 21:42:19.189376179 +0900
+++ configs/am335x_shc_sdboot_prompt_defconfig 2016-06-11
21:42:19.189376179 +0900
@@ -6,7 +6,7 @@
 CONFIG_SPL=y
 CONFIG_SPL_STACK_R=y
 CONFIG_FIT=y
-CONFIG_BOOTDELAY=0
+CONFIG_BOOTDELAY=5
 CONFIG_SYS_PROMPT="U-Boot# "
 CONFIG_AUTOBOOT_KEYED=y
 CONFIG_AUTOBOOT_PROMPT="Enter 'shc' to enter prompt (times out) %d
\nEnter 'noautoboot' to enter prompt without timeout\n"




-- 
Best Regards
Masahiro Yamada