Re: Regression in TF-A installed/deployed artifacts

Hi Peter,

Thanks for the prompt answer :)

On 1/9/26 6:52 PM, Peter Hoyes wrote:
> 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.
> 

Indeed. It wasn't clear from the commit log what you were talking about, 
thanks for explaining. I sometimes forget the deploydir is 
machine-specific as I've been bitten in the past by different images 
stepping on each other's toes. Not an issue for TF-A as this isn't 
image-specific :)

>> 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:// 
>> eur02.safelinks.protection.outlook.com/? 
>> url=https%3A%2F%2Fgit.yoctoproject.org%2Fmeta- 
>> rockchip%2Fcommit%2F%3Fid%3D2a13a49da4af4487ee71db6aff19364220da694a&data=05%7C02%7Cquentin.schulz%40cherry.de%7C0373d36d1ba14647cfed08de4fa80e79%7C5e0e1b5221b54e7b83bb514ec460677e%7C0%7C0%7C639035780376094222%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=qVjkKpHFgYhWnTPwyKJW%2BiwCnU2hinm1s%2F7zOhpHg68%3D&reserved=0. 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"?
> 

Yeah, I don't know the historical reasons for going with the SoC family 
in the filename in meta-rockchip. It seems like it's coming from 
d26980364900 ("Use TF-A recipe from meta-arm") in meta-rockchip, maybe 
bl31-TFA_PLATFORM.elf was the only file deployed by meta-arm back then. 
In a way, it makes it explicit that if you have a bl31-rk3568.elf for an 
RK3399-based board, something's gone awfully wrong :)

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

I'll let Trevor (maintainer of meta-rockchip) speak his mind if he wants 
to, but considering someone will need to patch rockchip-rkbin-tf-a in 
any case, at first glance I don't mind if it's in a subdir. After all, 
*we* control where we can put rockchip-rkbin-tf-a's blob, and it can be 
in a trusted-firmware-a/ directory :)

On another topic, I'm not sure we actually support using upstream OP-TEE 
OS in meta-rockchip (I don't see a TEE=/path/to/bl32.bin mentioned 
anywhere in the code; and Rockchip's blob won't work with upstream 
U-Boot AFAIR), something I maybe should be looking into. You do also 
have a subdir for OP-TEE OS so a similar logic should be followed. /me 
thinks.

I'm inclined to say that nothing needs to be done from meta-arm's side 
and we shall fix things up in meta-rockchip.

Thanks again for the prompt answer and the explanations.

I'll look into patches for meta-rockchip next week if I don't forget.

Have a nice weekend,
Cheers,
Quentin

> Thanks,
> 
> Peter
> 
>