[Bug]: rk3528: edge U-Boot cached artifact has empty device tree (0-byte FDT in u-boot.itb)

[rubycomm]

What happened?

Summary

The ORAS-cached U-Boot artifact for RK3528 edge contains a u-boot.itb with a 0-byte FDT, causing all RK3528 edge builds to fail at U-Boot with:

No valid device tree binary found - please append one to U-Boot binary
ERROR ### Please RESET the board

The current variant works correctly with a valid 7992-byte FDT.

Affected artifact

ghcr.io/armbian/os/uboot-nanopi-zero2-edge:2017.09-S8e7d-Pb178-Hedea-V2226-B61c5-R448a

Analysis

Using dumpimage -l on the u-boot.itb from each variant:

	current	edge
FDT Data Size	7992 Bytes	0 Bytes
FDT SHA256	db83a073...	e3b0c442... (SHA256 of empty data)
Boot result	Works	Fails - no DTB

The ATF blobs (atf-1, atf-2, atf-3) are identical between both variants. Only the U-Boot binary and FDT differ.

Reproduction

bash
# Build edge image for any RK3528 board
./compile.sh BOARD=nanopi-zero2 BRANCH=edge RELEASE=noble BUILD_MINIMAL=yes BUILD_DESKTOP=no KERNEL_CONFIGURE=no

The board fails to boot with the error above.

Additional finding: local build also affected

Building with ARTIFACT_IGNORE_CACHE=yes correctly compiles U-Boot from source. The build tree contains a valid 7992-byte u-boot.dtb and a correct u-boot.itb. These get packaged into a correct deb in output/packages-hashed/. However, the reversioned deb that ends up in output/debs/ still contains the old broken artifact with the 0-byte FDT.

Workaround

After building with ARTIFACT_IGNORE_CACHE=yes, manually copy the correct deb:

cp output/packages-hashed/global/linux-u-boot-nanopi-zero2-edge_*.deb \
   output/debs/linux-u-boot-nanopi-zero2-edge_26.02.0-trunk_arm64__*.deb

```Then rebuild the image.

## Impact
Currently only the NanoPi Zero2 has edge in its KERNEL_TARGET for RK3528, but this would block any other RK3528 board from enabling edge kernel support.

Discovered while working on [#9500](https://github.com/armbian/build/pull/9500).

### How to reproduce?

Build edge image for any RK3528 board

./compile.sh BOARD=nanopi-zero2 BRANCH=edge RELEASE=noble BUILD_MINIMAL=yes BUILD_DESKTOP=no KERNEL_CONFIGURE=no

Then try to boot the image on a Nanopi Zero2

### 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?

- [x] Yes, my Ubuntu/Debian/OtherOS is running on WSL2

### Relevant log URL

_No response_

### Code of Conduct

- [x] I agree to follow this project's Code of Conduct

[github-actions]

Jira ticket: AR-2831

[rpardini]

Interesting. It seems this has surfaced before, as the CI which builds the ORAS cache runs on some different userspace (jammy?) than most developers, and that causes some crazy. I hadn't noticed the 0-byte thing yet while searching for differences. Does the binwalk output (from #9192) reveal anything?