[Bug]: several boot loaders doesn't compile when switching host to Noble

[igorpecovnik]

What happened?

How to reproduce?

./compile DOCKER_ARMBIAN_BASE_IMAGE="ubuntu:noble"

Branch

main (main development branch)

On which host OS are you running the build script and observing this problem?

Ubuntu 24.04 Noble

Are you building on Windows WSL2?

• Yes, my Ubuntu/Debian/OtherOS is running on WSL2

Relevant log URL

https://paste.armbian.com/duyodikako

Code of Conduct

• I agree to follow this project's Code of Conduct

[github-actions]

Jira ticket: AR-2402

[The-going]

On ubuntu-22.04 all build target done, but 1 bpi-f3 fail
On ubuntu-24.04 12 target fail

Did I understand correctly?

[igorpecovnik]

On ubuntu-22.04 all build target done, but 1 bpi-f3 fail

yes

On ubuntu-24.04 12 target fail

yes

[The-going]

Currently, there is an old and bad external compiler mechanism in the build system.
It's bad because everything is loaded, but you only need to download the necessary version for the architecture.
Or use one that already exists with the user. That is, just specify the path to the folder.

If you approve, I will implement it.
The riscv64 compiler can be taken here:
http://archive.spacemit.com/toolchain/

https://archive.spacemit.com/toolchain/spacemit-toolchain-linux-glibc-x86_64-v1.0.0.tar.xz
or
https://archive.spacemit.com/toolchain/spacemit-toolchain-linux-glibc-x86_64-v0.3.3.tar.xz

After that, some special cases can be solved using an external compiler from buildroot or another, or self-assembled.

[ColorfulRhino]

I believe the issue here is less "how can we stay on the old jammy hosts" but more "what needs to be updated to get the old stuff running on the new noble system"?

First thing to collect is the info, what do the failing u-boots have in common? A specific version?

Edit:

• 1x 2022.04 (nanopi-neo3)
• 5x 2022.07
• 1x 2017.09 vendor (raxda-e25)

[ColorfulRhino]

I figured it out :) Semantic versioning 🎉
PR soon.

[amazingfate]

I just fixed uboot of rock5b building with -Werror: radxa/u-boot#81
But there are so many rockchip's vendor uboot sources.

[ColorfulRhino]

Fix: #6867

But OrangePi5 U-Boot building fails because it's using a vendor U-Boot from Xunlong. I have pinged @efectn

@igorpecovnik actually, most of those should also fail compiling even on jammy ./compile DOCKER_ARMBIAN_BASE_IMAGE="ubuntu:jammy" since it's setuptools not GCC causing this.

[igorpecovnik]

There are several others:
https://github.com/armbian/os/actions/runs/9769962830/attempts/5

[ColorfulRhino]

Yeah I have noticed Indiedroid Nova failing to build, it's using some external vendor U-Boot.
@lanefu You may consider also moving to the default family uboot :)

Next set of fixes: #6877

[ColorfulRhino]

Odroid XU4 uses some ancient vendor uboot:

build/config/sources/families/odroidxu4.conf

Lines 10 to 13 in 654d208

	BOOTSOURCE='https://github.com/hardkernel/u-boot.git'
	BOOTSCRIPT='boot-odroid-xu4.ini:boot.ini'
	BOOTDIR='u-boot-odroidxu'
	BOOTBRANCH='branch:odroidxu4-v2017.05'

Doing a short research I could not see that this board is supported by mainline unfortunately. Since I don't have the board myself and the SoC is unknown to me, I can only ping the maintainer to try porting this to mainline using a defconfig and dts. @joekhoobyar
Mainline does have support for Odroid XU3 so it may not be too far of a stretch :)

[igorpecovnik]

[lanefu]

Yeah I have noticed Indiedroid Nova failing to build, it's using some external vendor U-Boot. @lanefu You may consider also moving to the default family uboot :)

Next set of fixes: #6877

Thanks for heads up. Ill try to dig out and tinker with it soon.

[rpardini]

@ColorfulRhino I guess there is a bug introduced here #6819 -- you're reading uboot_cflags into uboot_make_envs before it is set. Thus all u-boots are being built without the CFLAGS that might tone down some errors to warnings. That explains also the problem @amazingfate fixed upstream (-Werror=maybe-uninitialized etc) that was previously forcibly ignored by cflags.