Tool/software:
On the AM62 in Kirkstone, it appears the current TI support for multiple U-Boot configs for the R5 are broken. To be clear, I am referencing this functionality:
docs.yoctoproject.org/.../variables.html
For one, I believe these definitions in k3r5.inc are likely incorrect for this platform:
SPL_SUFFIX = "bin"
SPL_BINARY = "tiboot3-${SYSFW_SOC}-${SYSFW_SUFFIX}-${SYSFW_CONFIG}.${SPL_SUFFIX}"
SPL_SYMLINK = "tiboot3.${SPL_SUFFIX}"
UBOOT_SUFFIX = "bin"
UBOOT_BINARY = "u-boot-r5spl.${UBOOT_SUFFIX}"
UBOOT_IMAGE = "u-boot-r5spl-${MAINMACHINE}-${PV}-${PR}.${UBOOT_SUFFIX}"
UBOOT_SYMLINK = "u-boot-r5spl-${MAINMACHINE}.${UBOOT_SUFFIX}"
UBOOT_BINARY and UBOOT_IMAGE are incorrect, because the build does not produce any file prefixed with "u-boot-r5spl." The SPL_BINARY is also incorrect, as the SPL binary itself is produced within the spl subdirectory of the build directory. This will go unnoticed if a single UBOOT_MACHINE is defined without multiple configs, however, results in an immediate failure if for example you do something like the following in your k3r5 machine:
UBOOT_MACHINE = "" # Last config in the list is default UBOOT_CONFIG ??= "usb emmc" UBOOT_CONFIG[usb] = "mymachine_r5_usbdfu_defconfig" UBOOT_CONFIG[emmc] = "mymachine_r5_defconfig"
Yocto will err as the default U-Boot class attempts to copy the SPL file u-boot-r5-spl* which does not exist.
I got some hints from beaglebone-ai64-k3r5.conf of what these should probably be, and I think it may be something like this:
SPL_SUFFIX = "bin"
SPL_BINARY = "spl/u-boot-spl.${UBOOT_SUFFIX}"
SPL_SYMLINK = "u-boot-r5spl.${UBOOT_SUFFIX}"
UBOOT_SUFFIX = "bin"
UBOOT_BINARY = "tiboot3.${UBOOT_SUFFIX}"
UBOOT_IMAGE = "tiboot3-${MAINMACHINE}-${PV}-${PR}.${UBOOT_SUFFIX}"
UBOOT_SYMLINK = "tiboot3-${MAINMACHINE}.${UBOOT_SUFFIX}"
The other portion that is broken is then the deploy half. Specifically here:
This probably needs to extended as other portions for compile have, as when multiple configs are built, the tiboot3 files will not reside in the ${B} directory but rather within ${B}/${config}:
i.e. something like
if [ -n "${UBOOT_CONFIG}" ]
then
for config in ${UBOOT_MACHINE}; do
i=$(expr $i + 1);
for type in ${UBOOT_CONFIG}; do
j=$(expr $j + 1);
if [ $j -eq $i ]
then
for f in ${B}/${config}/tiboot3-*.bin; do
if [ -f "$f" ]; then
install -m 644 $f ${DEPLOYDIR}/$(basename "$f")-${type}
fi
done
fi
done
done
fi
This would also then break what currently resides in IMAGE_BOOT_FILES, so that might require a user work around in the case the user is attempting to build multiple configs.
I believe this functionality should be fixed to allow proper support. I could possibly submit some patches, but I wanted to post here first to get feedback on this in case I am missing something. Correcting the items as I have proposed above works to fix the problems for my platform.
