armbian
rock-5b-plus u-boot build error
error log: https://github.com/armbian/os/actions/runs/15214928430/job/42800625037#step:8:982
As a result, the u-boot.itb in the built deb package does not contain the device tree and other content:
[chen@ChenArchLinux 15:07]
[0 /tmp/ark-mOgieT/usr/lib/linux-u-boot-vendor-rock-5b-plus]$ binwalk u-boot.itb
/tmp/ark-mOgieT/usr/lib/linux-u-boot-vendor-rock-5b-plus/u-boot.itb
-------------------------------------------------------------------------------------------------------------------------------------------------------------
DECIMAL HEXADECIMAL DESCRIPTION
-------------------------------------------------------------------------------------------------------------------------------------------------------------
0 0x0 Device tree blob (DTB), version: 17, CPU ID: 0, total size: 1971 bytes
793612 0xC1C0C CRC32 polynomial table, little endian
-------------------------------------------------------------------------------------------------------------------------------------------------------------
Analyzed 1 file for 85 file signatures (187 magic patterns) in 15.0 milliseconds
Trying to rebuild the uboot deb package using armbian/build does not cause this problem
![github-actions[bot] avatar](https://avatars.githubusercontent.com/in/15368?v=4 "Published by a pub.dev verified publisher"){kind=small}
It is probably related to compiler change - we switched to Ubuntu Noble recently.
https://github.com/armbian/build/pull/8220
For comparison these are the build logs for u-boot on: Jammy Log: https://paste.armbian.com/icunejacix Noble Log: https://paste.armbian.com/awadewuzif
While both build without errors only Jammy produces a working spi image. (EMMC/SD-Card boot not affected)
While I can build working uboot on arm64 noble without docker. But the uboot built by workflow can't boot.
@amazingfate
While I can build working uboot on arm64 noble without docker. But the uboot built by workflow can't boot.
The logs were from my arm64 debian host with docker. Both variants boot via EMMC but with the rkspi img built from Noble-Docker the status LED stays green while Jammy-Docker turns blue and boots the test NVMe I have
But the uboot built by workflow can't boot.
Exactly. And that is pushed to cache and also local image build that is (by default) using oras cache ... have failed u-boot.
Now the latest image built from workflow shows correct binwalk output:
$ binwalk /mnt/usr/lib/linux-u-boot-vendor-rock-5b-plus/u-boot.itb
DECIMAL HEXADECIMAL DESCRIPTION
--------------------------------------------------------------------------------
0 0x0 Flattened device tree, size: 1971 bytes, version: 17
793620 0xC1C14 CRC32 polynomial table, little endian
831429 0xCAFC5 Intel x86 or x64 microcode, sig 0xe6001916, pf_mask 0xc101c1fe, 1C1C-13-10, rev 0x1c0d0a1f, size 255
904092 0xDCB9C Android bootimg, kernel size: 1684095488 bytes, kernel addr: 0x646E6120, ramdisk size: 1684631410 bytes, ramdisk addr: 0x616D6920, product name: "der"
@CodeChenL is this image bootable?
Beware that we are overriding BASE_DOCKER_IMAGE in configs: https://github.com/armbian/os/blob/main/userpatches/config-armbian-community.conf#L21 https://github.com/armbian/os/blob/main/userpatches/config-armbian-images.conf#L22-L23 As otherwise there are still troubles.
Now the latest image built from workflow shows correct binwalk output:现在从工作流程构建的最新镜像显示了正确的 binwalk 输出：
$ binwalk /mnt/usr/lib/linux-u-boot-vendor-rock-5b-plus/u-boot.itb DECIMAL HEXADECIMAL DESCRIPTION -------------------------------------------------------------------------------- 0 0x0 Flattened device tree, size: 1971 bytes, version: 17 793620 0xC1C14 CRC32 polynomial table, little endian 831429 0xCAFC5 Intel x86 or x64 microcode, sig 0xe6001916, pf_mask 0xc101c1fe, 1C1C-13-10, rev 0x1c0d0a1f, size 255 904092 0xDCB9C Android bootimg, kernel size: 1684095488 bytes, kernel addr: 0x646E6120, ramdisk size: 1684631410 bytes, ramdisk addr: 0x616D6920, product name: "der"@CodeChenL is this image bootable?这张镜像可启动吗？
Thank you for the reminder, I will test it when I have time
As no one found the culprit besides using a jammy build host to solve the issue I'll close this as stale with the warning from #8783 for traceability if looked at in the future
This has come up again, due to all/most armbian/os builds having been changed to ubuntu:jammy (while armbian/build defaults to noble for the Docker scenario).
We should introduce binwalk's of all the produced files in the u-boot deb in the build logs, so we could more easily compare binwalks between what works and what doesn't, and then maybe we can divine what linker/compiler flag (or whatever...) is needed to make it work again on modern build hosts.
@HeyMeco reports the 3576 + UFS case only works on Jammy, not on Noble, and not on Trixie. I wonder what Bookworm does, etc.
