On Fri, Aug 21 2026, Tom Rini <[email protected]> wrote:
> On Fri, Aug 21, 2026 at 03:10:58PM +0200, Rasmus Villemoes wrote:
>> On Tue, Jul 14 2026, Tom Rini <[email protected]> wrote:
>>
>> > On Tue, Jul 14, 2026 at 03:04:42AM +0000, [email protected] wrote:
>> >> > > I use master branch of OSS u-boot repo and meet the issue with below
>> >> > > commands:
>> >> > >
>> >> > > make mx6qsabrelite_defconfig
>> >> > > make -j8
>> >> > > make tools envtools
>> >> >
>> >> > What host distribution are you building on? And, <config.h> *must* come
>> >> > first
>> >> > in the include list, for it to function correctly.
>> >>
>> >> Host OS is Ubuntu 22.04.3 LTS.
>> >> Toolchain is Arm GNU Toolchain 11.3.Rel1(arm-none-linux-gnueabihf-).
>> >> Also tried Ubuntu 24.04.4 LTS and Arm GNU Toolchain 15.3.Rel1,
>> >> the issue still happens.
>> >
>> > So, are you on an ARM host too? You aren't specifying where you are /
>> > aren't using the ARM toolchain in the above. Thanks.
>>
>> It doesn't matter what toolchain one uses. The mentioned commit does
>> break "make envtools" for all our boards, building through Yocto. And
>> when I build manually using my distro's cross-compiler, the same thing
>> happens.
>>
>> Note, it's not the board build itself that breaks, only the "make
>> envtools", which I assume few people do these days.
>
> I can't replicate this failure, is part of my problem. I get something
> else entirely. Using the CI build containers:
>
> $ make
> CROSS_COMPILE=/opt/gcc-15.2.0-nolibc/arm-linux-gnueabi/bin/arm-linux-gnueabi-
> mx6qsabrelite_defconfig tools envtools
> HOSTCC scripts/basic/fixdep
> HOSTCC scripts/kconfig/conf.o
> YACC scripts/kconfig/zconf.tab.[ch]
> LEX scripts/kconfig/zconf.lex.c
> HOSTCC scripts/kconfig/zconf.tab.o
> HOSTLD scripts/kconfig/conf
> #
> # configuration written to .config
> #
> scripts/kconfig/conf --syncconfig Kconfig
> UPD include/config.h
> CFG u-boot.cfg
> [snip]
> HOSTCC tools/env/crc32.o
> In file included from tools/env/crc32.c:1:
> tools/env/../../lib/crc32.c:12:10: fatal error: arpa/inet.h: No such file or
> directory
> 12 | #include <arpa/inet.h>
> | ^~~~~~~~~~~~~
> compilation terminated.
> make[2]: *** [scripts/Makefile.host:113: tools/env/crc32.o] Error 1
> make[1]: *** [Makefile:2520: envtools] Error 2
> make: *** [Makefile:362: __build_one_by_one] Error 2
Well, building stuff that is supposed to run on target in a hosted
environment with a -nolibc compiler is probably expected to fail with
missing libc headers like that one. I don't think that has ever been
expected to work. Try with a "normal" cross-compiler and you should see
similar errors to what is reported.
The failure is a bit different depending on the board config (and as you
and others observed, using "tools-only_defconfig" as the "board" means
there's no build error, but that's not exactly a solution). For example,
for beagleboneblack (am335x_evm_defconfig) I get
In file included from include/config.h:3,
from include/env.h:12,
from tools/env/../../env/flags.c:7,
from tools/env/env_flags.c:1:
include/configs/am335x_evm.h:50:15: error: missing binary operator before token
'('
50 | #if IS_ENABLED(CONFIG_CMD_USB)
while wandboard_defconfig (and other imx6 variants) gives that
In file included from ./arch/arm/include/asm/mach-imx/regs-lcdif.h:16,
from ./arch/arm/include/asm/arch/imx-regs.h:371,
from include/configs/mx6_common.h:21,
from include/configs/wandboard.h:11,
from include/config.h:3,
from include/env.h:12,
from tools/env/../../env/flags.c:7,
from tools/env/env_flags.c:1:
./arch/arm/include/asm/mach-imx/regs-common.h:51:9: error: unknown type name
'uint8_t'
51 | __mxs_reg_8(reg)
| ^~~~~~~~~~~
> So I don't even get to build that reported to fail to compile file, and
> if I toss in a -k to make, I get a bunch of different failures. And if
> instead I do "make tools-only_defconfig tools envtools" everything
> builds. There is a use case here, and I assume it has to do with wanting
> fw_setenv to have a specific default environment? Or something else?
It has to do with wanting to be able to build the envtools as shipped
with U-Boot. Yes, I presume most people nowadays use Stefano's
libubootenv, but some of us dinosaurs have build scripts that do "make
envtools" as part of the U-Boot build. In part, yes, to ensure that the
default environment that gets baked into fw_setenv is identical to the
default environment baked into the U-Boot binary.
What makes this somewhat baffling is that I don't see the rationale for
this new helper, at all.
board/tq/common/tq_sysinfo.c: The compiler can elide the
env_set_runtime() calls themselves, but presumably not any of the
sysinfo_* work leading up to those unless it can prove that none of
those calls have side effects. The whole thing would be better served by
"if (!IS_ENABLED(...))) return 0;" early in tq_common_sysinfo_setup().
board/tq/tqma6/tqma6.c: It really doesn't feel right to just not set
fdtfile, and if the board boot logic requires ENV_VARS_UBOOT_RUNTIME_CONFIG,
then that env_set_runtime() might as well just had been a plain
env_set() in the first place.
board/tq/tqma7/tqma7.c: There is already a
CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG block, the setting of board_name
might as well have been inside that, along with obtaining the value to
put in.
board/tq/tqma7/tqma7_mba7.c: Judging from the env snippets in
include/env/tq/, it doesn't really seem that setting mmcdev and
mmcblkdev can just be elided.
Rasmus
