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

[Tom Rini]

On Mon, Nov 20, 2023 at 07:16:12PM -0700, Simon Glass wrote:
> 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.

I guess with all of what you said I still don't understand why we need
the sometimes wrong and not really used lists of dtb files in
arch/*/dts/Makefile. A rockpro64-rk3399-tpl-only_defconfig still needs
to say CONFIG_DEFAULT_DEVICETREE="rk3399-rockpro64" so that you build
the tree so that it's available to binman. We have configs today that
build and support N boards, and so use SPL_LOAD_FIT and are as generic
as they can be. The only thing that this patch here changes is that
you're relying on an implicit CONFIG symbol to list whatever device
trees you want to be built and this patch says that you need to use one
of the explicit CONFIG symbols instead.

If you want to try and demonstrate a more generic way of doing things,
sunxi is probably the best bet for that because there's no TARGET
configs there, everything is SoC + device tree. But it's not making any
use of the lists that get removed here.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20231121/9859c9a6/attachment.sig>