Fixes the K3 am62p / am62-lp u-boot builds that were failing across all vendor branches (vendor, vendor-rt, vendor-edge) plus mainline edge — the R5 first-stage SPL overflowing its SRAM size limit, and the tispl/u-boot rename breaking on newer u-boot. Touches two files: config/sources/families/include/k3_common.inc and lib/functions/artifacts/artifact-uboot.sh. The R5 stage builds with soft-float gcc-13-arm-linux-gnueabi, already present in the framework image (armbian/docker-armbian-build#37, merged).

1. R5 SPL overruns its SRAM size limit → GCC 13 + per-SoC size handling

The R5 first-stage SPL (tiboot3) for am62p and am62-lp overruns CONFIG_SPL_SIZE_LIMIT:

spl/u-boot-spl.bin exceeds file size limit

Two forces push it over: GCC 14 (the Trixie default) produces larger SPL code than TI validated, and the newer TI vendor trees (ti-u-boot-2026.01, TI SDK 12.00.00.07) grew the SPL. GCC 13 is necessary but not sufficient on its own, so compile_k3_bootgen combines it with a size remedy chosen per SoC.

Compiler: the R5 stage is built with CC=arm-linux-gnueabi-gcc-13 (u-boot Kbuild honours a command-line CC; CROSS_COMPILE stays for binutils). Passing CC explicitly means no silent fallback — an early -dumpversion check asserts the major version is 13 and fails loudly otherwise, rather than reverting to gcc-14 and reintroducing the overflow. Only the R5 first stage changes compiler; the A53 SPL and u-boot proper are untouched.

The two SoCs need different size remedies because their MCU SRAM layout differs:

• am62p — there is ~58 KB of unused MCU SRAM above the limit, so raise SPL_SIZE_LIMIT 0x3C000→0x40000 and SPL_MAX_SIZE 0x3B000→0x3F000 (both stay well below the stack pointer) and build for size (-Os). No boot paths are removed — SPI-NOR and SPI-NAND stay intact.
• am62-lp — the limit already sits exactly at the stack pointer with BSS immediately above, so there is nowhere to raise into; the image must shrink instead. Armbian boots tiboot3 from SD/eMMC-FAT only, so drop the unused SPI-NOR and SPI-NAND/MTD boot stacks that am62x_lpsk adds over am62x_evm (SPL_SPI_FLASH*, DM_SPI_FLASH, SPI_FLASH_*, SPL_MTD*, SPL_NAND_SPI_SUPPORT, MTD_SPI_NAND, DM_MTD, SPL_YMODEM_SUPPORT) and build for size (-Os). olddefconfig cascades the dependencies.

2. tispl/u-boot rename breaks on newer u-boot (beagleplay & other GP boards)

post_uboot_custom_postprocess__update_uboot_names copied a board's override image (TISPL_FILE/UBOOT_FILE) onto tispl.bin/u-boot.img. Newer u-boot broke this two ways, each tripping Armbian's ERR trap:

• renamed outputs — mainline 2026.07 / recent TI SDK renamed the GP outputs to ti-spl_unsigned.fit.*; the old *_unsigned files no longer exist, so cp <absent> failed (broke beagleplay-{edge,vendor,vendor-rt}, sk-tda4vm, beaglebone-ai64);
• same file — on GP parts binman can make the *_unsigned image and tispl.bin the same file, so cp src dst errors "are the same file".

Fix: guard each copy on the file existing (an if, since [[ -f x ]] && cp returns 1 when absent and would itself trap) and keep || true so a same-file copy is tolerated. When skipped, binman's standard tispl.bin/u-boot.img is left in place. (nounset is off, so this is not an unbound-var issue.)

3. u-boot artifact hash now tracks the K3 recipe

The u-boot artifact version hashes specific hook/function bodies, but compile_k3_bootgen/compile_k3_optee weren't among them — the hashed pre_config_uboot_target hook only calls them. So changing the R5 recipe (e.g. the GCC 13 switch and size handling above) didn't change the artifact hash and a stale cached u-boot was reused. Add both to calculate_hash_for_function_bodies; it skips functions that don't exist, so non-K3 families are unaffected (K3 boards rebuild once, then track correctly).

Testing

All affected u-boot artifacts compile once the gcc-13 image is live; the size remedies were verified against CI run 30202614279 (the pre-fix R5 overflow of 0x1c8a–0x1dfe on am62p and 0xe88–0xfe0 on am62-lp).

A card boot smoke test is still needed before merge — to confirm the raised-limit am62p R5 SPL boots, and that am62-lp boots from SD/eMMC with the SPI-NOR/SPI-NAND stacks stripped.