able to reproduce.

The issue is with make oldconfig. It is waiting for input to correct the missing information:

scripts/kconfig/conf  --oldconfig Kconfig
.config:49:warning: symbol value '' invalid for DEBUG_UART_BASE
*
* Restart config...
*
*
* Serial drivers
*
Default baudrate (BAUDRATE) [115200] 115200
Require a serial port for console (REQUIRE_SERIAL_CONSOLE) [Y/n/?] y
Specify the port number used for console (SPECIFY_CONSOLE_INDEX) [N/y/?] n
Provide a serial driver (SERIAL_PRESENT) [Y/n/?] y
Provide a serial driver in SPL (SPL_SERIAL_PRESENT) [Y/n/?] y
Enable Driver Model for serial drivers (DM_SERIAL) [Y/n/?] y
  Enable RX buffer for serial input (SERIAL_RX_BUFFER) [N/y/?] n
  Search for serial devices after default one failed (SERIAL_SEARCH_ALL) [N/y/?] n
  Enable Driver Model for serial drivers in SPL (SPL_DM_SERIAL) [Y/n/?] y
Enable an early debug UART for debugging (DEBUG_UART) [Y/n/?] y
  Select which UART will provide the debug UART
  > 1. ns16550 (DEBUG_UART_NS16550)
  choice[1]: 1
  Base address of UART (DEBUG_UART_BASE) [] (NEW) 


and then the cycle of death starts.

I do see a warrning before we get to running the make oldconfig via "cml1_do_configure"

We need to parse the return from "make qemu-x86_64_defconfig" for "symbol value '' invalid for" and error out.

The kernel handles this situation so maybe they have ideas on how to do that.

In case of kernel there is a error print

Console input/output is redirected. Run 'make oldconfig' to update configuration.

So probably fix can be on U-Boot Kconfig side.

not sure where to go from punting it back to unassigned.

I'll look into this.

I can reproduce on poky master with the steps provided by the reporter.

I can also reproduce on u-boot master :

vim configs/qemu-x86_64_defconfig
# => CONFIG_DEBUG_UART_BASE=
cp configs/qemu-x86_64_defconfig .config
echo -n | make oldconfig
# loop forever

u-boot kconfig scripts come from Linux 4.20

Can't reproduce on Linux master (kconfig scripts have changed since 4.20)

It may be a case of updating kconfig in upstream u-boot. I'll poke around.

I can reproduce it on Linux master! You only need a config entry of type hex that has no default value (Since i did not find such entry, I've added it) :

config TEST_KCONFIG
	hex "Test kconfig"
	# No default value

* CONFIG_DEBUG_UART_BASE defined here https://github.com/u-boot/u-boot/blob/master/drivers/serial/Kconfig#L482
* default values are conditional (my guess is for qemux86_64, no condition match and we have no default value)
* If I understood correctly, in kconfig, the global default is the empty string which is not a valid value for the hex type
* during make oldconfig, the new value for CONFIG_DEBUG_UART_BASE is ask to the user via stdin
* stdin is closed and the default (empty string) is chosen, this value is not valid and the value of CONFIG_DEBUG_UART_BASE is asked again (hence the loop we see)

While a config of hex type without default value is not illegal in the kconfig language. It is not recommended :
** https://docs.zephyrproject.org/1.14.0/guides/kconfig/index.html#redundant-defaults : Defaults should always be given for int and hex symbols, however, as they implicitly default to the empty string. This is partly for compatibility with the C Kconfig tools, though an implicit 0 default might be less likely to be what was intended compared to other symbol types as well.

Ideas for a fix :
* Patching upstream kconfig scripts to fail when a value is asked on a closed stdin instead of looping (It looks like it was the case at some point, see Comment 3)
* Changing our u-boot:do_configure task to use make olddefconfig instead of oldconfig : Since we do not intend to interactively choose values for these config, explicitly choosing default values seem fair (?). By using olddefconfig, the default (and invalid) "" is used for the hex config and error will be most likely be caught at compile time.

Note: kernel uses olddefconfig : https://git.yoctoproject.org/poky/tree/meta/classes-recipe/kernel.bbclass#n628

Even after searching for it in kernel tree, I could not find a hex config without default hex value. I guess that his is an untold rule (?).

As for U-boot, even if we don't use oldconfig, it uses syncconfig (really close to oldconfig) internally during compilation. So the loop still happens but later.

Where to go from here:
* Patch upstream kconfig script to abort on closed stdin instead of looping (in kernel tree which would be sync'ed in u-boot some day)
* Patch upstream u-boot to give a default hex value to all hex config (This might be controversial)
* Switch all oldconfig usage in oe-core to olddefconfig : There are some in cml1.bbclass and u-boot recipe.

From bug triage meeting 2023-07-27 :
* Contact upstream about this
* Start moving from oldconfig to olddefconfig. Let a way to override and keep the oldnoconfig for old kconfig (eg busybox). Note: use a function that the busybox can override/redefine after the "inherit cml1" (?)

Upstream contacted : https://lore.kernel.org/linux-kbuild/387d7f82-aa8e-759f-7e12-08dfc329c47f@smile.fr/T/#u

Maybe related patch : https://lore.kernel.org/lkml/20230824004747.GC3913@google.com/T/

Patch v3 sent to upstream kconfig maintainer (linux-kbuild)
https://lore.kernel.org/linux-kbuild/20230912154811.1338390-1-yoann.congal@smile.fr/T/#u

This bug was triggered by a coworker recently : He was playing with U-boot versions and defconfigs. The bug resulted in 28GB do_configure.log files -_-
I may need to find a proper workaround in Yocto before having the upstream trickle down to Yocto.

The proper path of the fix would be :
* fix it in Linux kbuild subsystem
* Port the fix in the kbuild in u-boot tree (either by updating it fully of backporting the patch)
* Update/backport the u-boot fix to the Yocto/u-boot recipe

Linux kbuild v5 patch sent : https://lore.kernel.org/linux-kbuild/20231104222715.3967791-1-yoann.congal@smile.fr/

Patch from kbuild maintainer (more likely to be merged -_-')
https://lore.kernel.org/all/20231125163559.824210-2-masahiroy@kernel.org/

Bumping target milestone to 5.0 M2

Upstream kbuild maintainer patch merged upstream https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=6262afa10ef7cc8fdf39b81a36f9546b68810431 (in Linux v6.8-rc1)

He chose to have "0" as default value for int and "0x0" as default value for hex.

Next steps :
* Let's port this to u-boot and other kconfig users. This time having "Submitted" patches in OE-Core may be acceptable
* Start moving from oldconfig to olddefconfig. Let a way to override and keep the oldnoconfig for old kconfig (eg busybox). Note: use a function that the busybox can override/redefine after the "inherit cml1" (?)

Bulk move to Milestone 5.0 M3

Bulk move to 5.0 M4

U-boot maintainer rejected[0] the patch setting "0x0" as hex default (understandably, he'd rather have a stuck build instead of a hard-to-debug runtime failure).

So we have Upstream(u-boot) disagreeing with Upstream's Upstream (Linux kconfig) :(

Maybe I need to go back to my initial Linux kconfig patch [1]: Make the config process exit on error instead of going into an infinite loop? (Beware, there was some valid reviews on this patch)

[0]: https://lists.denx.de/pipermail/u-boot/2024-May/553066.html
[1]: https://lore.kernel.org/all/20231031111647.111093-1-yoann.congal@smile.fr/

Other idea is to add a config check step somewhere. Based on a tool like https://pypi.org/project/kconfiglib/?

Discussed at bug triage today:
- Get Bruce's input on config handling
- Get back upstream with more ammunition to see if we can get a clean error exit on invalid config.

Bulk move to 6.0 M1

(Unassigning myself since a do not realistically have the time to work on this)

[RFC v2 0/2] add kconfirm - Julian Braha
https://lore.kernel.org/rust-for-linux/20260509203808.1142311-1-julianbraha@gmail.com/

looks interesting to fix this issue