Re: Regression in TF-A installed/deployed artifacts

Hi Quentin,

On 1/9/26 15:27, Quentin Schulz wrote:
> Hi,
>
> I believe there's been a regression since commit 7bce36a2c64b 
> ("arm/trusted-firmware-a: Use firmware.bbclass") where the installed 
> name isn't bl31-<platform>.elf anymore, but simply bl31.elf.
>
> This commit removed -${TFA_PLATFORM} from the installed firmware 
> filename (and the symlink). The commit log seems to hint that this was 
> intended "Drop the redundant ${TFA_PLATFORM} suffixes."... which isn't?
>
> Changing TFA_INSTALL_SUFFIX to the value of TFA_PLATFORM (it currently 
> is the empty string) would help with that but then you either have 
> bl31.elf or bl31-rk3399.elf (for example). I don't mind about that, 
> but still odd to remove a symlink.

The changes are intentional and mainly motivated by the fact that we now 
have TF-M, TF-A and sometimes SCP-firmware all putting files in 
DEPLOY_DIR_IMAGE with similar filenames (bl1.bin, bl2.bin etc) and it 
was getting quite confusing for people to know which binaries originate 
from which project. So I felt that some sort of additional namespacing 
was needed.

The ${TFA_PLATFORM} redundancy comment relates to the whole filename - 
tmp/deploy/images/rk3568/trusted-firmware-a/bl31.bin is already 
guaranteed not to clash with 
tmp/deploy/images/rk3566/trusted-firmware-a/bl31.bin if you are sharing 
TMPDIRs.

> meta-rockchip has support for TF-A binary blobs from Rockchip, which 
> we do name bl31-rk3399.elf and since this filename needs to be 
> consistent between upstream tf-a and blob tf-a (and we cannot modify 
> U-Boot's BL31 variable from TF-A's recipe due to variable scope), this 
> broke builds of meta-rockchip and forced the following (yet 
> incomplete) band-aid patch 
> https://git.yoctoproject.org/meta-rockchip/commit/?id=2a13a49da4af4487ee71db6aff19364220da694a. 
> I'm now trying to figure out how to properly fix that.
>
> Additionally, the binaries are now forced into a subdirectory named 
> after the recipe (see do_deploy in firmware.bbclass) and cannot be 
> modified. So I need to patch our TF-A blob recipe to install in the 
> identically named directory (that is, trusted-firmware-a/) so that 
> U-Boot can find the binary named the same in the same location 
> regardless of the kind of TF-A we're building. It does feel kinda 
> wrong doing that.

This would be my suggestion. Looking at u-boot-rockchip.inc, this might 
simplify the logic there as you no longer need to handle 
machine-specific differences between ${SOC_FAMILY} - it'll always be 
just "${DEPLOY_DIR_IMAGE}/trusted-firmware-a/bl31.elf"?

I could add a variable to firmware.bbclass (say, FIRMWARE_INSTALL_DIR ?= 
"${PN}") so that the subdirectory can be customized from the recipe?

Thanks,

Peter