[PATCH v4 0/3] binman: Further updates for FIT support

Simon Glass sjg at chromium.org
Mon Sep 7 15:57:10 CEST 2020


Hi Michal,

On Mon, 7 Sep 2020 at 02:44, Michal Simek <michal.simek at xilinx.com> wrote:
>
> Hi Simon,
>
> On 06. 09. 20 18:39, Simon Glass wrote:
> > This series adds support for help messages when binary blobs are missing,
> > as well as selecting the default FIT configuration.
> >
> > It includes the v3 patches from the earlier series that were not applied.
> >
> > Note: This series is available at u-boot-dm/binman-working and is based
> > on u-boot-dm/next
> >
> > Changes in v4:
> > - Add more documentation for DEFAULT-SEQ
> > - Drop patches previous applied to u-boot-dm/next
> >
> > Changes in v3:
> > - Add a way to show help messages for missing blobs
> > - Rebase on top of earlier binman series
> >
> > Changes in v2:
> > - Add new patch to allow selecting default FIT configuration
> >
> > Simon Glass (3):
> >   binman: Allow selecting default FIT configuration
> >   binman: Support help messages for missing blobs
> >   binman: sunxi: Add help message for missing sunxi ATF BL31
> >
> >  Makefile                                      |  2 +
> >  arch/arm/dts/sunxi-u-boot.dtsi                |  1 +
> >  tools/binman/README                           |  6 ++
> >  tools/binman/README.entries                   |  4 ++
> >  tools/binman/control.py                       | 69 ++++++++++++++++++-
> >  tools/binman/entry.py                         |  9 +++
> >  tools/binman/etype/fit.py                     | 26 +++++++
> >  tools/binman/ftest.py                         | 59 ++++++++++++++--
> >  tools/binman/missing-blob-help                | 15 ++++
> >  tools/binman/test/168_fit_missing_blob.dts    |  9 ++-
> >  .../test/{170_fit_fdt.dts => 172_fit_fdt.dts} |  2 +-
> >  11 files changed, 195 insertions(+), 7 deletions(-)
> >  create mode 100644 tools/binman/missing-blob-help
> >  rename tools/binman/test/{170_fit_fdt.dts => 172_fit_fdt.dts} (95%)
> >
>
> I just spot one thing and will be good to clearify it.
>
> In sunxi this description is used.
> +                                       firmware = "uboot";
> +                                       loadables = "atf";
>
> But is this right way how this should be described?
> I personally use firmware which points to ATF and loadables which points
> to uboot. Not sure what sunxi is doing but also in spl_fit.c there is a
> comment about it.
>         /*
>          * Find the U-Boot image using the following search order:
>          *   - start at 'firmware' (e.g. an ARM Trusted Firmware)
>          *   - fall back 'kernel' (e.g. a Falcon-mode OS boot
>          *   - fall back to using the first 'loadables' entry
>          */

It would be better if this could be made deterministic. I don't really
know which is right, but we should not need fallbacks, etc. We know
when we are in Falcon mode, at least, and we should be able to settle
on which one to use for U-Boot.

Regards,
Simon


More information about the U-Boot mailing list