build: pin CROSS_COMPILE for the U-Boot defconfig, and silence statx

[daniel-rossier]

Two fixes that only surface away from a 64-bit workstation. Both were found
while building a 32-bit tree inside a container that ships no aarch64
toolchain, which is why they survived this long.

uboot: the defconfig step used the wrong compiler

do_build pinned CROSS_COMPILE per platform, do_configure did not. So
make <platform>_defconfig fell back to the Makefile's patched-in
aarch64-none-linux-gnu- default. That step probes the compiler
(scripts/gcc-version.sh, clang-version.sh), so with the toolchain absent
Kconfig dies with syntax error and the build stops before compiling
anything:

/bin/sh: 1: aarch64-none-linux-gnu-gcc: not found
Kconfig:66: syntax error
make[1]: *** [scripts/kconfig/Makefile:96: virt32_defconfig] Error 1

A host that happens to have the 64-bit toolchain installed hides it — the
defconfig step does not really compile, it only asks for a version.

so3: one "unhandled syscall" per directory entry on arm32

Every ls printed syscall_handle: unhandled syscall: 397 per entry. 397 is
statx on arm32, and MUSL reaches for it first: in fstatat.c,
sizeof(kstat.st_atime_sec) < sizeof(time_t) holds on a 32-bit time64 build,
so __fstatat tries statx and only falls back to fstatat64 on -ENOSYS.
The fallback worked — listings were correct — but the table entry was NULL,
so the kernel logged the miss first.

It never showed on arm64: there kstat already carries 64-bit times and MUSL
goes straight to newfstatat.

syscall.tbl already models exactly this case. Mapping it to empty makes
__sys_empty() return -ENOSYS silently, as munmap and mprotect already
do. Behaviour is unchanged, the noise is gone.

Testing

Both verified on virt32 (QEMU virt, Cortex-A15), kernel v6.3.0: a full
bsp-so3 build and deploy inside the 32-bit container now completes, and
ls -l runs with zero unhandled syscall lines.

🤖 Generated with Claude Code

https://claude.ai/code/session_012cxnJsuSbSBYtEi5nrgb68