trusted-firmware for vim3

[m5p3nc3r]

I would like to get trusted-firmware-a running on the Khadas Vim3, so am working on a recipe to make this happen. meta-arm has vanilla recipes to do this, and upstream has support for g12a, which I believe is compatible with the g12b on the Vim3.

The problem I have is that won't be able to boot with the vendor u-boot as is the current supported mode with these recipes.

I would therefor need to create a u-boot recipe for the vim3 as well. But I am struggling to see the best way to achieve this with the current setup? Any pointers/suggestions would be appreciated - I don't mind doing the implementation work.

My plan would be to create a u-boot_2020.%.bbappend and add the signing code required to create the bootable image. Has anybody done this before?

The code required seems to be available in this repo https://github.com/LibreELEC/amlogic-boot-fip, and the plan would be to use this as apart of the u-boot overlay.

[superna9999]

Hi @m5p3nc3r,

The SoC is already running TF-A but with Amlogic closed source implementation.

the upstream implementation only provided the bl31.bin binary, so you can keep the current scheme but take the bl31.bin binary from the TF-A build and replace the bl31 provided by prebuilt-FIPs and keep the current u-boot generate scheme since the other binaries are still needed.

I recently pushed a commit on master using https://github.com/LibreELEC/amlogic-boot-fip as source for the prebuilt binaries.

[m5p3nc3r]

Thanks for the feedback - I tend to have an allergic reaction to sources that I can't see! The problem I am trying to debug is that when booting Xen I don't seem to be able to bring up any processors (other than CPU0 which is hard-wired on). I was suspecting an invalid SMC call, but assuming that this wil be picked up by bl31, I wanted to have something there that I could debug. This may of course be the red herring? And my problem lies elsewhere??

[superna9999]

So yeah, at some point you'll need to use closed source code... the closed source portions only do DDR setup and system low-level setup like plls & bus optimization. It also provides a complete secure & trusted boot implementation (if you get the eFuses mapping and fusing protocol :-p) For your processor bring up issue, indeed the BL31 is the one intercepting these calls and forwarding the proper power-up to the M3 SCP co-processor, so it's the right one to debug. But I'm not sure it supports G12B with it's secondary cluster, and may need some love.

[m5p3nc3r]

Ok, thanks. I have enough to work with here. Will close.