[PATCH v3 2/9] arm: dts: imx8mp: Add common u-boot dtsi

[Tim Harvey]

On Mon, Jul 12, 2021 at 12:44 PM Simon Glass <sjg at chromium.org> wrote:
>
> Hi Tim,
>
> On Mon, 12 Jul 2021 at 10:42, Tim Harvey <tharvey at gateworks.com> wrote:
> >
> > On Sat, Jul 10, 2021 at 5:23 AM Heiko Schocher <hs at denx.de> wrote:
> > >
> > > Hello Tim,
> > >
> > > On 09.07.21 16:47, Tim Harvey wrote:
> > > > On Wed, Jul 7, 2021 at 5:58 AM Teresa Remmet <t.remmet at phytec.de> wrote:
> > > >>
> > > >> Factor out the common node settings for dm-spl and dm-pre-reloc
> > > >> and move them to imx8mp-u-boot.dtsi
> > > >>
> > > >> Signed-off-by: Teresa Remmet <t.remmet at phytec.de>
> > > >> Reviewed-by: Fabio Estevam <festevam at gmail.com>
> > > >> Reviewed-by: Heiko Schocher <hs at denx.de>
> > > >> ---
> > > >> Changes in v3:
> > > >> - Moved binman nodes to common imx8mp-u-boot.dtsi
> > > >> Changes in v2:
> > > >> - none
> > > >>
> > > >>  arch/arm/dts/imx8mp-evk-u-boot.dtsi           | 143 +----------------
> > > >>  .../imx8mp-phyboard-pollux-rdk-u-boot.dtsi    |  39 +----
> > > >>  arch/arm/dts/imx8mp-u-boot.dtsi               | 149 ++++++++++++++++++
> > > >>  3 files changed, 153 insertions(+), 178 deletions(-)
> > > >>  create mode 100644 arch/arm/dts/imx8mp-u-boot.dtsi
> > > >>
> > <snip>
> > > >>
> > > >
> > > > Teresa,
> > > >
> > > > I've noticed many of the imx8m boards migrating to using binman for
> > > > image packaging.
> > > >
> > > > Doesn't this change from having a single flash.bin encompasing the SPL
> > > > and U-Boot proper to having split files? I noticed that happened with
> > > > imx8mm_evk for example when it switched to binman.
> > >
> > > Yes, but you can easy generate there a single image again.
> > >
> > > > What are the benefits to using binman?
> > >
> > > Beside the pros from binmal in general, I see the benefit in special
> > > for imx8mp, that you can get all infos you need for signing the image
> > > from within the image. No need to save some log output from U-Boot
> > > build and parse this output ...
> > >
> >
> > (+cc Simon)
> >
> > Heiko,
> >
> > And what are the pros from binman in general? I've read over
> > tools/binman/binman.rst so I'm assuming you mean what is described
> > there as benefits.
> >
> > How do you get all the details needed for signing the image from binman?
> >
> > If I make imx8mm_evk_defconfig which produces via binman flash.bin and
> > u-boot.itb I get the following:
> >
> > $ ./tools/binman/binman ls -i flash.bin
> > binman: Cannot find FDT map in image
> > $ ./tools/binman/binman ls -i u-boot.itb
> > binman: Cannot find FDT map in image
>
> As the message says, you need an 'fdtmap' in the image:
>
>    fdtmap {
>    }:
>

Simon,

Sorry I still don't quite understand:

diff --git a/arch/arm/dts/imx8mm-evk-u-boot.dtsi
b/arch/arm/dts/imx8mm-evk-u-boot.dtsi
index f200afac9f..c6d8932fa4 100644
--- a/arch/arm/dts/imx8mm-evk-u-boot.dtsi
+++ b/arch/arm/dts/imx8mm-evk-u-boot.dtsi
@@ -163,6 +163,9 @@
        itb {
                filename = "u-boot.itb";

+               fdtmap {
+               };
+
                fit {
                        description = "Configuration to load ATF before U-Boot";
                        #address-cells = <1>;


$ make imx8mm_evk_defconfig
$ make
$ ./tools/binman/binman ls -i u-boot.itb
Name          Image-pos  Size    Entry-type  Offset  Uncomp-size
------------------------------------------------------------------
main-section          0   a3875  section          0
  fdtmap              0     48d  fdtmap           0
  fit               48d   a33e8  fit            48d

For signing we need the loadaddr/offset/size of the components within
the FIT image. Since binman is calling mkimage to create FIT images it
seems outside the scope of binman to be able to dump details on the
actual FIT image. Perhaps mkimage or another tool is to be used for
that detail?

> >
> > I would very much like to understand how to use binman to get the
> > various offsets needed for signing an IMX image for use with HAB.
>
> You should be able to add signing support to binman for your use case.
> See for example how vblock.py works.

I see... so your saying instead of using an external tool to generate
a txt template with the offset/size values for the various blobs
instead we need to implement for example a habv4.py to add a habv4
entry and the python class would have access to the content handles to
determine the addr/size in order to create the text template file fed
to the NXP code signing tool?

Regards,

Tim