[U-Boot] [PATCH 1/2] rockchip: make_fit_atf.py: allow inclusion of a tee binary

[Simon Glass]

Hi Heiko,

On Thu, 10 Oct 2019 at 12:28, Heiko Stübner <heiko at sntech.de> wrote:
>
> Hi Simon,
>
> Am Donnerstag, 10. Oktober 2019, 19:06:12 CEST schrieb Simon Glass:
> > On Tue, 1 Oct 2019 at 14:23, Heiko Stuebner <heiko at sntech.de> wrote:
> > > A trusted execution environment should also get loaded as loadable from
> > > a fit image, so add the possibility to present a tee.elf to make_fit_atf.py
> > > that then gets included as additional loadable into the generated its.
> > >
> > > For ease of integration the additional loadable is created as atf_(x+1)
> > > after all others to re-use core generation loops.
> > >
> > > Tested against the combinations of 1-part-atf and multi-part-atf each
> > > time with and without a tee binary present.
> > >
> > > Signed-off-by: Heiko Stuebner <heiko at sntech.de>
> > > ---
> > >  arch/arm/mach-rockchip/make_fit_atf.py | 52 +++++++++++++++++++++++---
> > >  1 file changed, 46 insertions(+), 6 deletions(-)
> > >
> >
> > Instead of building up another tool, could we use binman for this? If
> > not, what is missing?
>
> make_fit_atf.py is the existing tool and I've no real experience with
> binman so far, so I don't really know.
>
> make_fit_atf.py is the script used to create the u-boot.its used as base
> for the uboot fit image loaded from SPL, so it's the script set in the
> SPL_FIT_GENERATOR Kconfig similar to sunxi and riscv.
>
> For this it parses the ATF.elf and (now) TEE.elf to get the actual load
> addresses for the loadables (the ATF.elf contains separate sections for
> main DDR and often additional SRAM locations for loadables of variable
> number) and creates the .its based on this data.

binman has functionality to obtain symbol addresses (see for example

>
>
> Looking at the binman README:
> "Binman considers FIT to be one of the binaries it can place in the image.
> Where possible it is best to put as much as possible in the FIT, with binman
> used to deal with cases not covered by FIT."

Also see the slides from a recent talk [1].

>
> So it looks like that should stay as it is? Or is that documentation outdated?

It seems like we should create a FIT generator in binman. FIT support
is in the TODO but not yet done.

Do you want to have a try? It basically involves creating a new entry
type, e.g. 'rockchip-fit.py' that generates the FIT (from a template)
and then runs mkimage.

Regards,
Simon

[1] https://osfc.io/uploads/talk/paper/45/Binman_-_A_data-controlled_firmware_packer_for_U-Boot.pdf