[PATCH 1/2] global: Clean up arch/*/dts/Makefile

[Simon Glass]

Hi Tom,

On Sun, 19 Nov 2023 at 13:28, Tom Rini <trini at konsulko.com> wrote:
>
> On Sun, Nov 19, 2023 at 12:09:07PM -0700, Simon Glass wrote:
> > Hi Tom,
> >
> > On Fri, 17 Nov 2023 at 15:52, Tom Rini <trini at konsulko.com> wrote:
> > >
> > > With commit 3609e1dc ("dts: automatically build necessary .dtb files")
> > > we now have logic that will ensure that all device trees needed in the
> > > binary are built automatically. Any device tree that the developer needs
> > > while working can still be built normally via make arch/.../foo.dtb so
> > > we can simply drop the rest of this logic.
> > >
> > > Suggested-by: Rasmus Villemoes <rasmus.villemoes at prevas.dk>
> > > Signed-off-by: Tom Rini <trini at konsulko.com>
> > > ---
> > >  arch/arc/dts/Makefile        |    8 -
> > >  arch/arm/dts/Makefile        | 1436 +---------------------------------
> > >  arch/m68k/dts/Makefile       |   18 -
> > >  arch/microblaze/dts/Makefile |    2 -
> > >  arch/mips/dts/Makefile       |   37 -
> > >  arch/nios2/dts/Makefile      |    2 -
> > >  arch/powerpc/dts/Makefile    |   32 -
> > >  arch/riscv/dts/Makefile      |    9 -
> > >  arch/sandbox/dts/Makefile    |    5 -
> > >  arch/sh/dts/Makefile         |    2 +-
> > >  arch/x86/dts/Makefile        |   22 -
> > >  arch/xtensa/dts/Makefile     |    2 -
> > >  configs/iot2050_defconfig    |    1 +
> > >  13 files changed, 6 insertions(+), 1570 deletions(-)
> >
> > I can see the motivation for this, but it ends up moving us away from
> > driver model and devicetree, IMO. For example, rk3399 and other
> > rockchip boards use DT for their init so the same U-Boot can be used
> > for all, mostly. Ideally that is the way all boards would be, as they
> > are in Linux.
> >
> > But here I have to manually add all the rk3399 boards to OF_LIST for
> > each board and enable SPL_LOAD_FIT (and SPL_FRAMEWORK but that is
> > fine) to make this work.
>
> How are you doing this today on N rk3399 boards if you aren't tweaking a
> CONFIG option to get the correct dtb in to the final binary? That I
> think is where we go back-and-forth on stuff like this.

Basically without SPL_FIT_LOAD it works by stuffing the correct DT
into the final image just before it is flashed. But I do imagine in a
world where (say) TPL is different for each board but SPL, TF-A,
OP-TEE and U-Boot proper are the same for each board.

But really we need to encourage these complex SoCs to use runtime
configuration from go to whoa. Where DT cannot be used (e.g. TPL) we
can do the Zephyr trick or perhaps create a little SoC-specific config
block which is provided separately and tacked onto the generic TPL
image. Having said that, TPL images are small, so the impact of having
one per board is not great.

> If there's
> deconfigs that can support N boards, but only list a, or only a few, dtb
> files in the right CONFIG variable how do you get it to run on the
> others? I know you noted some Exynos platforms it's a simple concat to
> make another platform work instead. But I really don't know how common
> that is in theory, and even less so in practice. Picking up rk3399, you
> need bl31 and op-tee and you can only get those so generic too.

I understand that they are 100% generic for rk3399. E.g. for TF-A you
use PLAT=rk3399 and that is that.

>
> And part of the issue is that with Linux, the "do board specific things"
> just gets pushed down a layer, to us. We have to just know X/Y/Z at
> build time so that someone else can know it at run time.

Sure, and naturally that gets pushed down from U-Boot proper (which I
think is becoming quite generic) to SPL, TPL, etc.

If it would help, I could try out (say) rockpro64-rk3399 and
firefly-rk3399 to show how this works?

I know it is tempting to build everything individually, but it won't
be nice. Binman knows what is needed for each board and can be used
(one day) to create update files for an SoC without duplication. As
soon as you give up on the commonality, everything just explodes in
size, complexity and user confusion.

Regards,
Simon