[U-Boot] [PATCH 29/30] RFC: Use binman for a sunxi board

[Simon Glass]

Hi Ian,

On 26 July 2016 at 07:35, Ian Campbell <ijc at hellion.org.uk> wrote:
> (adding Hans)
>
> On Mon, 2016-07-25 at 18:59 -0600, Simon Glass wrote:
>> Add an example usage of binman for a sunxi board. This involves adding the
>> > image definition to the device tree and using it in the Makefile.
>
> My concern with this approach is that the *.dts(i) files used for sunxi
> are sync'd unmodified from the upstream repo. I think this is a
> valuable property to retain in terms of maintenance burden for us
> (resync is trivial only if there are no local changes).

Thanks for looking at it.

One option is to put the local changes in an #include file. We have a
similar problem with "u-boot,dm-pre-reloc". We really should be able
to push these sorts of things upstream....

>
> The conflict is then whether the device tree people would consider this
> new block to be "describing the hardware" or not and therefore whether
> these changes would be welcomed/allowed upstream. I'm not sure which
> way it would go TBH.

Me neither. Although there is a flash map / partition map device tree
binding and this is similar.

The binman description lays out what the boot ROM needs in many cases,
which is pretty close to being the 'hardware'.

>
> There is also an issue with duplication, since this stanza is going to
> be the same for all the dozens of sunxi platforms. I suppose this can
> be addressed by putting it in a suitable .dtsi file, but that does sort
> of start to suggest that this information belongs outside the per-board
> .dts in a per-platform file (at which point I would have have to ask if
> .dts is the best/most convenient syntax?).

Yes I think we could use the same thing for large groups of boards,
but we already have an soc-specific .dtsi in most cases, so that
should work quite nicely.

The nice things about device tree are:

- people understand it
- it can be accessed at run-time (e.g. so we know where to find the
next image to load)
- we have robust tools for dealing with device tree source and binaries

Regards,
Simon