Hi Tom, On 2 October 2016 at 21:26, Simon Glass <s...@chromium.org> wrote: > Hi Tom, > > On 1 October 2016 at 18:46, Tom Rini <tr...@konsulko.com> wrote: >> On Sat, Oct 01, 2016 at 06:29:42PM -0600, Simon Glass wrote: >>> Hi Tom, >>> >>> On 1 October 2016 at 18:15, Tom Rini <tr...@konsulko.com> wrote: >>> > On Wed, Sep 28, 2016 at 09:46:25AM -0600, Simon Glass wrote: >>> >> Hi Tom, >>> >> >>> >> On 27 September 2016 at 19:55, Tom Rini <tr...@konsulko.com> wrote: >>> >> > On Sun, Sep 25, 2016 at 03:52:27PM -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. >>> >> >> >>> >> >> This is for example only. >>> >> >> >>> >> >> Signed-off-by: Simon Glass <s...@chromium.org> >>> >> >> --- >>> >> >> >>> >> >> Changes in v2: None >>> >> >> >>> >> >> Makefile | 4 +--- >>> >> >> arch/arm/dts/sun7i-a20-pcduino3.dts | 12 ++++++++++++ >>> >> > >>> >> > I think this shows the big problem with using binman today. For the >>> >> > common case of ARM, where we sync in the dts* files from upstream, this >>> >> > will add hunks that must not be overwritten each time. >>> >> > >>> >> > Looking at scripts/Makefile.lib::cmd_fdt I wonder if we couldn't come >>> >> > up >>> >> > with some wildcard rule and check if, somewhere CONFIG'd ? $(BOARDDIR)/ >>> >> > ? u-boot.dtsi exists add in -include that/file.dtsi to the CPP rule so >>> >> > that we can keep the parts that will never get upstream separate. >>> >> >>> >> We can do that, but I have found that most boards with the same SoC >>> >> are the same, or similar. So for x86 [1] I put it in a separate patch >>> >> with just an #include in the .dts file. >>> >> >>> >> We could have binman be a bit smarter about where it looks - e.g. if >>> >> there is no binman node, it could look in the same directory for a >>> >> file that matches the board name, or part of it? >>> > >>> > I'd really like to try and better solve the generic problem we have tho >>> > too while we're at it. ie the u-boot,dm-pre-reloc tag on various nodes >>> > could also go into this file. >>> >>> What sort of solution are you thinking of? A U-Boot .dtsi include that >>> is #included at the top of all files? >> >> Something like: >> ifneq ($(wildcard >> $(srctree)/arch/$(CONFIG_SYS_ARCH)/cpu/$(CONFIG_SYS_CPU)/$(CONFIG_SYS_SOC)/u-boot.dtsi),) >> dtc_cpp_flags += -include >> $(srctree)/arch/$(CONFIG_SYS_ARCH)/cpu/$(CONFIG_SYS_CPU)/$(CONFIG_SYS_SOC)/u-boot.dtsi >> endif >> >> And maybe a few other wildcards, I'm not sure, so that for everything >> rockchip related, ie what binman needs, what nodes need to be pre-reloc, >> etc, can end up in that one file. And we use -include to get it so that >> arch/arm/dts/ can be unmodified from upstream. > > OK, I was worried that's what you might mean :-) > > I'll take a look.
I've sent v3 with something along these lines. I could not use -include because I need to avoid having the .dts version header appear twice. So it has a little 'sed' in it... Regards, Simon _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot