[U-Boot] Revert "Ensure device tree DTS is compiled"

[Simon Glass]

Hi Masahiro,

On Mon, 11 Mar 2019 at 10:50, Masahiro Yamada
<yamada.masahiro at socionext.com> wrote:
>
> Hi Simon,
>
>
> On Mon, Mar 11, 2019 at 6:59 AM Simon Glass <sjg at chromium.org> wrote:
> >
> > Hi Tom, Masahiro,
> >
> > On Sat, 9 Mar 2019 at 10:42, Tom Rini <trini at konsulko.com> wrote:
> > >
> > > On Sun, Mar 10, 2019 at 01:07:48AM +0900, Masahiro Yamada wrote:
> > > > Hi Tom,
> > > >
> > > >
> > > > On Sat, Mar 9, 2019 at 8:04 AM Tom Rini <trini at konsulko.com> wrote:
> > > > >
> > > > > On Thu, Mar 07, 2019 at 11:13:52PM +0900, Masahiro Yamada wrote:
> > > > >
> > > > > > This reverts commit 27cb7300ffda7a3f1581f0f5a2d3bfe59b97ad67.
> > > > > >
> > > > > > I am not sure if I correctly understood the log of commit 27cb7300ffda
> > > > > > ("Ensure device tree DTS is compiled"), but the code-diff looks like
> > > > > > it was trying to solve the missed re-compilation when .dts was modified.
> > > > > >
> > > > > > Recently, commit 2737dfe096b6 ("kbuild: make arch-dtbs target PHONY")
> > > > > > fixed the issue in a more correct and more complete way.
> > > > > >
> > > > > > Anyway, since the former commit, we see a clumsy log like this:
> > > > > >
> > > > > >   make[2]: 'arch/sandbox/dts/sandbox.dtb' is up to date
> > > > > >
> > > > > > So, let's revert it.
> > > > > >
> > > > > > Signed-off-by: Masahiro Yamada <yamada.masahiro at socionext.com>
> > > > >
> > > > > This causes tons of breakage like:
> > > > >        arm:  +   rpi_0_w
> > > > > +(rpi_0_w)
> > > > > +(rpi_0_w) Device Tree Source is not correctly specified.
> > > > > +(rpi_0_w) Please define 'CONFIG_DEFAULT_DEVICE_TREE'
> > > > > +(rpi_0_w) or build with 'DEVICE_TREE=<device_tree>' argument
> > > > > +(rpi_0_w) make[2]: *** [arch/arm/dts/bcm2835-rpi-zero-w.dtb] Error 1
> > > > > +(rpi_0_w) make[1]: *** [dts] Error 2
> > > > > +(rpi_0_w) make: *** [sub-make] Error 2
> > > > >
> > > >
> > > >
> > > > This is because arch/arm/dts/Makefile
> > > > has no entry for bcm2835-rpi-zero-w.dtb.
> > > >
> > > >
> > > >
> > > >
> > > > The following patch should fix the error
> > > >
> > > >
> > > > diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
> > > > index 2a040b2..5540f1b 100644
> > > > --- a/arch/arm/dts/Makefile
> > > > +++ b/arch/arm/dts/Makefile
> > > > @@ -582,6 +582,7 @@ dtb-$(CONFIG_ARCH_BCM283X) += \
> > > >         bcm2835-rpi-b-plus.dtb \
> > > >         bcm2835-rpi-b-rev2.dtb \
> > > >         bcm2835-rpi-b.dtb \
> > > > +       bcm2835-rpi-zero-w.dtb \
> > > >         bcm2836-rpi-2-b.dtb \
> > > >         bcm2837-rpi-3-b.dtb
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > The reverted commit was hiding the issue.
> > > >
> > > > I believe DTB files should be explicitly associated
> > > > with CONFIG option in Makefile.
> > > > U-Boot used to work that way, and so does Linux.
> > > >
> > > >
> > > > I do not know how may boards are broken now, but
> > > > the right thing to do is to add dtb entries to Makefile,
> > > > the revert the bad commit.
> > >
> > > OK, that sounds good.  But it's a non-trivial number of boards to fix,
> > > so it's a real series to be put on the TODO list then.  Thanks for
> > > explaining!
> >
> > If you are suggesting that we should have a separate CONFIG option for
> > every DT, I don't agree:
>
> I do not mean that.
>
> See my patch.
>
>
> > > > diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
> > > > index 2a040b2..5540f1b 100644
> > > > --- a/arch/arm/dts/Makefile
> > > > +++ b/arch/arm/dts/Makefile
> > > > @@ -582,6 +582,7 @@ dtb-$(CONFIG_ARCH_BCM283X) += \
> > > >         bcm2835-rpi-b-plus.dtb \
> > > >         bcm2835-rpi-b-rev2.dtb \
> > > >         bcm2835-rpi-b.dtb \
> > > > +       bcm2835-rpi-zero-w.dtb \
> > > >         bcm2836-rpi-2-b.dtb \
> > > >         bcm2837-rpi-3-b.dtb
>
>
> I am suggesting to add a missing DTB to the existing CONFIG.
>
> CONFIG_ARCH_BCM283X is a platform CONFIG, not per-board CONFIG.
>
>
> Each platform should have a platform or SoC CONFIG option.

OK I see. Yes, agreed.

>
>
>
>
> > 1. It adds more CONFIGs for no other purpose, or makes use of TARGET
> > configs which we try to avoid using
> > 2. It reduces the testing of DT files for related builds. E.g. you can
> > change something in a common .dtsi file which works fine for one board
> > but breaks another, and you only find out when you build all the
> > boards.
> >
> > Sorry if I have the wrong end of the stick.
> >
> > Regards,
> > Simon

Regards,
Simon