[PATCH v3 11/19] am64x: dts: binman: Package tiboot3.bin, tispl.bin u-boot.img

[Simon Glass]

Hi Neha,

On Tue, 25 Apr 2023 at 01:32, Neha Malcom Francis <n-francis at ti.com> wrote:
>
> Hi Simon
>
> On 25/04/23 01:12, Simon Glass wrote:
> > Hi Neha,
> >
> > On Fri, 21 Apr 2023 at 06:32, Neha Malcom Francis <n-francis at ti.com> wrote:
> >>
> >> Support added for HS and GP boot binaries for AM64x.
> >>
> >> tiboot3.bin, tispl.bin and u-boot.img: For HS-SE devices
> >> tiboot3.bin_fs, tispl.bin and u-boot.img: For HS-FS devices
> >> tiboot3.bin_unsigned, tispl.bin_unsigned, u-boot.img_unsigned: For GP
> >> devices
> >>
> >> Note that the bootflow followed by AM64x requires:
> >>
> >> tiboot3.bin:
> >>          * R5 SPL
> >>          * R5 SPL dtbs
> >>          * sysfw
> >>          * board-cfg
> >>          * pm-cfg
> >>          * sec-cfg
> >>          * rm-cfg
> >>
> >> tispl.bin:
> >>          * ATF
> >>          * OPTEE
> >>          * A53 SPL
> >>          * A53 SPL dtbs
> >>
> >> u-boot.img:
> >>          * A53 U-Boot
> >>          * A53 U-Boot dtbs
> >>
> >> Signed-off-by: Neha Malcom Francis <n-francis at ti.com>
> >> ---
> >>   arch/arm/dts/k3-am642-evm-u-boot.dtsi |   2 +
> >>   arch/arm/dts/k3-am642-r5-evm.dts      |   1 +
> >>   arch/arm/dts/k3-am64x-binman.dtsi     | 569 ++++++++++++++++++++++++++
> >>   board/ti/am64x/Kconfig                |   2 +
> >>   4 files changed, 574 insertions(+)
> >>   create mode 100644 arch/arm/dts/k3-am64x-binman.dtsi
> >
> > Reviewed-by: Simon Glass <sjg at chromium.org>
> >
> > I notice that some of the entries are optional. Do you actual make use
> > of this (i.e. that when they are missing binman removes the entries)?
> >
>
> So right now the build generates binaries for all three types: HS-FS,
> HS-SE and GP devices. It's not necessary for the user to provide
> component binaries for all three of them, say they only have GP SYSFW
> binaries available with them. So that was the reasoning behind putting
> those binaries as optional, we should not have a failed build in those
> cases. However binaries like DM and board-config binaries that are
> common between all three needs to be there so it's not optional.

The way 'optional' is supposed to work is that an etype decides that
an optional entry is absent and so marks it as absent. Then when
drop_absent() is called, the entry is removed from its section.

You can certainly add that functionality if you like.

But we must have a reliable signal for whether an image is valid or not.

Regards,
Simon