diff mbox series

[v3,4/8] dts: Add alternative location for upstream DTB builds

Message ID 20231228115804.3626579-5-sumit.garg@linaro.org
State Superseded
Headers show
Series An effort to bring DT bindings compliance within U-Boot | expand

Commit Message

Sumit Garg Dec. 28, 2023, 11:58 a.m. UTC 
Allow platform owners to mirror devicetree files from devitree-rebasing
directory into dts/arch/$(ARCH) (special case for dts/arch/arm64). Then
build then along with any *-u-boot.dtsi file present in arch/$(ARCH)/dts
directory. Also add a new Makefile for arm64.

This will help easy migration for platforms which currently are compliant
with upstream Linux kernel devicetree files.

Signed-off-by: Sumit Garg <sumit.garg@linaro.org>
---

Changes in v3:
--------------
- Minor commit message update

Changes in v2:
--------------
- s/DEVICE_TREE_LOC/dt_dir/ and s/U-boot/U-Boot/

 dts/Kconfig             | 11 +++++++++++
 dts/Makefile            | 17 ++++++++++++++---
 dts/arch/arm64/Makefile | 14 ++++++++++++++
 3 files changed, 39 insertions(+), 3 deletions(-)
 create mode 100644 dts/arch/arm64/Makefile

Comments

Simon Glass Dec. 28, 2023, 1:37 p.m. UTC | #1 
Hi Sumit,

On Thu, Dec 28, 2023 at 11:58 AM Sumit Garg <sumit.garg@linaro.org> wrote:
>
> Allow platform owners to mirror devicetree files from devitree-rebasing
> directory into dts/arch/$(ARCH) (special case for dts/arch/arm64). Then
> build then along with any *-u-boot.dtsi file present in arch/$(ARCH)/dts
> directory. Also add a new Makefile for arm64.
>
> This will help easy migration for platforms which currently are compliant
> with upstream Linux kernel devicetree files.
>
> Signed-off-by: Sumit Garg <sumit.garg@linaro.org>
> ---
>
> Changes in v3:
> --------------
> - Minor commit message update
>
> Changes in v2:
> --------------
> - s/DEVICE_TREE_LOC/dt_dir/ and s/U-boot/U-Boot/
>
>  dts/Kconfig             | 11 +++++++++++
>  dts/Makefile            | 17 ++++++++++++++---
>  dts/arch/arm64/Makefile | 14 ++++++++++++++
>  3 files changed, 39 insertions(+), 3 deletions(-)
>  create mode 100644 dts/arch/arm64/Makefile
>
> diff --git a/dts/Kconfig b/dts/Kconfig
> index 00c0aeff893..e58c1c6f2ab 100644
> --- a/dts/Kconfig
> +++ b/dts/Kconfig
> @@ -85,6 +85,17 @@ config OF_LIVE
>           enables a live tree which is available after relocation,
>           and can be adjusted as needed.
>
> +config OF_UPSTREAM
> +       bool "Enable use of devicetree imported from Linux kernel release"
> +       help
> +         Traditionally, U-Boot platforms used to have their custom devicetree
> +         files or copy devicetree files from Linux kernel which are hard to
> +         maintain and can usually get out-of-sync from Linux kernel. This
> +         option enables platforms to migrate to devicetree-rebasing repo where
> +         a regular sync will be maintained every major Linux kernel release
> +         cycle. However, platforms can still have some custom u-boot specific
> +         bits maintained as part of *-u-boot.dtsi files.

My only other suggestion here is to mention that this should be set in
Kconfig, for the SoC as a whole. So I believe that means that it
should be hidden, with no string for the 'bool':

      bool  # Enable use of devicetree imported from Linux kernel release

Also, this doesn't seem to work for me. Before this series I get these
files when building firefly-rk3399:

rk3399-eaidk-610.dtb            rk3399-khadas-edge-v.dtb
rk3399-orangepi.dtb        rk3399-rock-pi-4a.dtb
rk3399-evb.dtb                  rk3399-leez-p710.dtb
rk3399-pinebook-pro.dtb    rk3399-rock-pi-4c.dtb
rk3399-ficus.dtb                rk3399-nanopc-t4.dtb
rk3399-pinephone-pro.dtb   rk3399-rockpro64.dtb
rk3399-firefly.dtb              rk3399-nanopi-m4-2gb.dtb
rk3399pro-rock-pi-n10.dtb  rk3399-roc-pc.dtb
rk3399-gru-bob.dtb              rk3399-nanopi-m4b.dtb
rk3399-puma-haikou.dtb     rk3399-roc-pc-mezzanine.dtb
rk3399-gru-kevin.dtb            rk3399-nanopi-m4.dtb
rk3399-rock-4c-plus.dtb
rk3399-khadas-edge-captain.dtb  rk3399-nanopi-neo4.dtb    rk3399-rock-4se.dtb
rk3399-khadas-edge.dtb          rk3399-nanopi-r4s.dtb     rk3399-rock960.dtb

Afterwards I get this:

make[3]: *** No rule to make target
'dts/arch/arm64/rk3399-firefly.dtb', needed by 'dtbs'.  Stop.

So I set this manually for that one board:

CONFIG_DEFAULT_DEVICE_TREE="rockchip/rk3399-firefly"

and get:

make[3]: *** No rule to make target
'dts/arch/arm64/rockchip/rk3399-firefly.dtb', needed by 'dtbs'.  Stop.

I am not sure how to fix this, nor how this can be made to build all
the DTs for rk3399, as it does today.

> +
>  choice
>         prompt "Provider of DTB for DT control"
>         depends on OF_CONTROL
> diff --git a/dts/Makefile b/dts/Makefile
> index 3437e54033d..68daaf45ec7 100644
> --- a/dts/Makefile
> +++ b/dts/Makefile
> @@ -10,10 +10,20 @@ ifeq ($(DEVICE_TREE),)
>  DEVICE_TREE := unset
>  endif
>
> +ifeq ($(CONFIG_OF_UPSTREAM),y)
> +ifeq ($(CONFIG_ARM64),y)
> +dt_dir := dts/arch/arm64
> +else
> +dt_dir := dts/arch/$(ARCH)
> +endif
> +else
> +dt_dir := arch/$(ARCH)/dts
> +endif
> +
>  ifneq ($(EXT_DTB),)
>  DTB := $(EXT_DTB)
>  else
> -DTB := arch/$(ARCH)/dts/$(DEVICE_TREE).dtb
> +DTB := $(dt_dir)/$(DEVICE_TREE).dtb
>  endif
>
>  $(obj)/dt-$(SPL_NAME).dtb: dts/dt.dtb $(objtree)/tools/fdtgrep FORCE
> @@ -41,7 +51,7 @@ $(DTB): arch-dtbs
>
>  PHONY += arch-dtbs
>  arch-dtbs:
> -       $(Q)$(MAKE) $(build)=arch/$(ARCH)/dts dtbs
> +       $(Q)$(MAKE) $(build)=$(dt_dir) dtbs
>
>  ifeq ($(CONFIG_SPL_BUILD),y)
>  obj-$(CONFIG_OF_EMBED) := dt-spl.dtb.o
> @@ -65,4 +75,5 @@ clean-files := dt.dtb.S
>  # Let clean descend into dts directories
>  subdir- += ../arch/arc/dts ../arch/arm/dts ../arch/m68k/dts ../arch/microblaze/dts     \
>            ../arch/mips/dts ../arch/nios2/dts ../arch/powerpc/dts ../arch/riscv/dts     \
> -          ../arch/sandbox/dts ../arch/sh/dts ../arch/x86/dts ../arch/xtensa/dts
> +          ../arch/sandbox/dts ../arch/sh/dts ../arch/x86/dts ../arch/xtensa/dts        \
> +          ./arch/arm64 ./arch/$(ARCH)
> diff --git a/dts/arch/arm64/Makefile b/dts/arch/arm64/Makefile
> new file mode 100644
> index 00000000000..16e9fea622d
> --- /dev/null
> +++ b/dts/arch/arm64/Makefile
> @@ -0,0 +1,14 @@
> +# SPDX-License-Identifier: GPL-2.0+
> +
> +include $(srctree)/scripts/Makefile.dts
> +
> +targets += $(dtb-y)
> +
> +# Add any required device tree compiler flags here
> +DTC_FLAGS += -a 0x8
> +
> +PHONY += dtbs
> +dtbs: $(addprefix $(obj)/, $(dtb-y))
> +       @:
> +
> +clean-files := */*.dtb */*.dtbo */*_HS

What is _HS for?

> --
> 2.34.1
>

Regards,
Simon
Tom Rini Dec. 28, 2023, 2:03 p.m. UTC | #2 
On Thu, Dec 28, 2023 at 01:37:26PM +0000, Simon Glass wrote:
> Hi Sumit,
> 
> On Thu, Dec 28, 2023 at 11:58 AM Sumit Garg <sumit.garg@linaro.org> wrote:
> >
> > Allow platform owners to mirror devicetree files from devitree-rebasing
> > directory into dts/arch/$(ARCH) (special case for dts/arch/arm64). Then
> > build then along with any *-u-boot.dtsi file present in arch/$(ARCH)/dts
> > directory. Also add a new Makefile for arm64.
> >
> > This will help easy migration for platforms which currently are compliant
> > with upstream Linux kernel devicetree files.
> >
> > Signed-off-by: Sumit Garg <sumit.garg@linaro.org>
> > ---
> >
> > Changes in v3:
> > --------------
> > - Minor commit message update
> >
> > Changes in v2:
> > --------------
> > - s/DEVICE_TREE_LOC/dt_dir/ and s/U-boot/U-Boot/
> >
> >  dts/Kconfig             | 11 +++++++++++
> >  dts/Makefile            | 17 ++++++++++++++---
> >  dts/arch/arm64/Makefile | 14 ++++++++++++++
> >  3 files changed, 39 insertions(+), 3 deletions(-)
> >  create mode 100644 dts/arch/arm64/Makefile
> >
> > diff --git a/dts/Kconfig b/dts/Kconfig
> > index 00c0aeff893..e58c1c6f2ab 100644
> > --- a/dts/Kconfig
> > +++ b/dts/Kconfig
> > @@ -85,6 +85,17 @@ config OF_LIVE
> >           enables a live tree which is available after relocation,
> >           and can be adjusted as needed.
> >
> > +config OF_UPSTREAM
> > +       bool "Enable use of devicetree imported from Linux kernel release"
> > +       help
> > +         Traditionally, U-Boot platforms used to have their custom devicetree
> > +         files or copy devicetree files from Linux kernel which are hard to
> > +         maintain and can usually get out-of-sync from Linux kernel. This
> > +         option enables platforms to migrate to devicetree-rebasing repo where
> > +         a regular sync will be maintained every major Linux kernel release
> > +         cycle. However, platforms can still have some custom u-boot specific
> > +         bits maintained as part of *-u-boot.dtsi files.
> 
> My only other suggestion here is to mention that this should be set in
> Kconfig, for the SoC as a whole. So I believe that means that it
> should be hidden, with no string for the 'bool':
> 
>       bool  # Enable use of devicetree imported from Linux kernel release

I think we can just keep prompting for it now, to make the transition
easier, before this option just goes away in time, hopefully.

> Also, this doesn't seem to work for me. Before this series I get these
> files when building firefly-rk3399:
> 
> rk3399-eaidk-610.dtb            rk3399-khadas-edge-v.dtb
> rk3399-orangepi.dtb        rk3399-rock-pi-4a.dtb
> rk3399-evb.dtb                  rk3399-leez-p710.dtb
> rk3399-pinebook-pro.dtb    rk3399-rock-pi-4c.dtb
> rk3399-ficus.dtb                rk3399-nanopc-t4.dtb
> rk3399-pinephone-pro.dtb   rk3399-rockpro64.dtb
> rk3399-firefly.dtb              rk3399-nanopi-m4-2gb.dtb
> rk3399pro-rock-pi-n10.dtb  rk3399-roc-pc.dtb
> rk3399-gru-bob.dtb              rk3399-nanopi-m4b.dtb
> rk3399-puma-haikou.dtb     rk3399-roc-pc-mezzanine.dtb
> rk3399-gru-kevin.dtb            rk3399-nanopi-m4.dtb
> rk3399-rock-4c-plus.dtb
> rk3399-khadas-edge-captain.dtb  rk3399-nanopi-neo4.dtb    rk3399-rock-4se.dtb
> rk3399-khadas-edge.dtb          rk3399-nanopi-r4s.dtb     rk3399-rock960.dtb
> 
> Afterwards I get this:
> 
> make[3]: *** No rule to make target
> 'dts/arch/arm64/rk3399-firefly.dtb', needed by 'dtbs'.  Stop.
> 
> So I set this manually for that one board:
> 
> CONFIG_DEFAULT_DEVICE_TREE="rockchip/rk3399-firefly"
> 
> and get:
> 
> make[3]: *** No rule to make target
> 'dts/arch/arm64/rockchip/rk3399-firefly.dtb', needed by 'dtbs'.  Stop.
> 
> I am not sure how to fix this, nor how this can be made to build all
> the DTs for rk3399, as it does today.

Looking at the patch for amlogic boards, you need to make the link to
devicetree-rebasing inside dts/...

> > diff --git a/dts/arch/arm64/Makefile b/dts/arch/arm64/Makefile
> > new file mode 100644
> > index 00000000000..16e9fea622d
> > --- /dev/null
> > +++ b/dts/arch/arm64/Makefile
> > @@ -0,0 +1,14 @@
> > +# SPDX-License-Identifier: GPL-2.0+
> > +
> > +include $(srctree)/scripts/Makefile.dts
> > +
> > +targets += $(dtb-y)
> > +
> > +# Add any required device tree compiler flags here
> > +DTC_FLAGS += -a 0x8
> > +
> > +PHONY += dtbs
> > +dtbs: $(addprefix $(obj)/, $(dtb-y))
> > +       @:
> > +
> > +clean-files := */*.dtb */*.dtbo */*_HS
> 
> What is _HS for?

Should we even need the clean-files part here? I think this is fixed
with:
https://patchwork.ozlabs.org/project/uboot/patch/20231226154619.5071-9-maxim.uvarov@linaro.org/
Simon Glass Dec. 28, 2023, 3:09 p.m. UTC | #3 
Hi Tom, Sumit,

On Thu, Dec 28, 2023 at 2:03 PM Tom Rini <trini@konsulko.com> wrote:
>
> On Thu, Dec 28, 2023 at 01:37:26PM +0000, Simon Glass wrote:
> > Hi Sumit,
> >
> > On Thu, Dec 28, 2023 at 11:58 AM Sumit Garg <sumit.garg@linaro.org> wrote:
> > >
> > > Allow platform owners to mirror devicetree files from devitree-rebasing
> > > directory into dts/arch/$(ARCH) (special case for dts/arch/arm64). Then
> > > build then along with any *-u-boot.dtsi file present in arch/$(ARCH)/dts
> > > directory. Also add a new Makefile for arm64.
> > >
> > > This will help easy migration for platforms which currently are compliant
> > > with upstream Linux kernel devicetree files.
> > >
> > > Signed-off-by: Sumit Garg <sumit.garg@linaro.org>
> > > ---
> > >
> > > Changes in v3:
> > > --------------
> > > - Minor commit message update
> > >
> > > Changes in v2:
> > > --------------
> > > - s/DEVICE_TREE_LOC/dt_dir/ and s/U-boot/U-Boot/
> > >
> > >  dts/Kconfig             | 11 +++++++++++
> > >  dts/Makefile            | 17 ++++++++++++++---
> > >  dts/arch/arm64/Makefile | 14 ++++++++++++++
> > >  3 files changed, 39 insertions(+), 3 deletions(-)
> > >  create mode 100644 dts/arch/arm64/Makefile
> > >
> > > diff --git a/dts/Kconfig b/dts/Kconfig
> > > index 00c0aeff893..e58c1c6f2ab 100644
> > > --- a/dts/Kconfig
> > > +++ b/dts/Kconfig
> > > @@ -85,6 +85,17 @@ config OF_LIVE
> > >           enables a live tree which is available after relocation,
> > >           and can be adjusted as needed.
> > >
> > > +config OF_UPSTREAM
> > > +       bool "Enable use of devicetree imported from Linux kernel release"
> > > +       help
> > > +         Traditionally, U-Boot platforms used to have their custom devicetree
> > > +         files or copy devicetree files from Linux kernel which are hard to
> > > +         maintain and can usually get out-of-sync from Linux kernel. This
> > > +         option enables platforms to migrate to devicetree-rebasing repo where
> > > +         a regular sync will be maintained every major Linux kernel release
> > > +         cycle. However, platforms can still have some custom u-boot specific
> > > +         bits maintained as part of *-u-boot.dtsi files.
> >
> > My only other suggestion here is to mention that this should be set in
> > Kconfig, for the SoC as a whole. So I believe that means that it
> > should be hidden, with no string for the 'bool':
> >
> >       bool  # Enable use of devicetree imported from Linux kernel release
>
> I think we can just keep prompting for it now, to make the transition
> easier, before this option just goes away in time, hopefully.
>
> > Also, this doesn't seem to work for me. Before this series I get these
> > files when building firefly-rk3399:
> >
> > rk3399-eaidk-610.dtb            rk3399-khadas-edge-v.dtb
> > rk3399-orangepi.dtb        rk3399-rock-pi-4a.dtb
> > rk3399-evb.dtb                  rk3399-leez-p710.dtb
> > rk3399-pinebook-pro.dtb    rk3399-rock-pi-4c.dtb
> > rk3399-ficus.dtb                rk3399-nanopc-t4.dtb
> > rk3399-pinephone-pro.dtb   rk3399-rockpro64.dtb
> > rk3399-firefly.dtb              rk3399-nanopi-m4-2gb.dtb
> > rk3399pro-rock-pi-n10.dtb  rk3399-roc-pc.dtb
> > rk3399-gru-bob.dtb              rk3399-nanopi-m4b.dtb
> > rk3399-puma-haikou.dtb     rk3399-roc-pc-mezzanine.dtb
> > rk3399-gru-kevin.dtb            rk3399-nanopi-m4.dtb
> > rk3399-rock-4c-plus.dtb
> > rk3399-khadas-edge-captain.dtb  rk3399-nanopi-neo4.dtb    rk3399-rock-4se.dtb
> > rk3399-khadas-edge.dtb          rk3399-nanopi-r4s.dtb     rk3399-rock960.dtb
> >
> > Afterwards I get this:
> >
> > make[3]: *** No rule to make target
> > 'dts/arch/arm64/rk3399-firefly.dtb', needed by 'dtbs'.  Stop.
> >
> > So I set this manually for that one board:
> >
> > CONFIG_DEFAULT_DEVICE_TREE="rockchip/rk3399-firefly"
> >
> > and get:
> >
> > make[3]: *** No rule to make target
> > 'dts/arch/arm64/rockchip/rk3399-firefly.dtb', needed by 'dtbs'.  Stop.
> >
> > I am not sure how to fix this, nor how this can be made to build all
> > the DTs for rk3399, as it does today.
>
> Looking at the patch for amlogic boards, you need to make the link to
> devicetree-rebasing inside dts/...

OK, let me give up on rk3399 for now...that doesn't seem to work even
with the link.

Using odroid-c2 with -next I see:

$ ls /tmp/b/odroid-c2/arch/arm/dts/
meson-a1-ad401.dtb                 meson-g12b-odroid-n2l.dtb
    meson-gxl-s905x-libretech-cc.dtb
meson-axg-jethome-jethub-j100.dtb  meson-g12b-odroid-n2-plus.dtb
    meson-gxl-s905x-libretech-cc-v2.dtb
meson-axg-s400.dtb                 meson-g12b-radxa-zero2.dtb
    meson-gxl-s905x-p212.dtb
meson-g12a-radxa-zero.dtb          meson-gxbb-kii-pro.dtb
    meson-gxm-gt1-ultimate.dtb
meson-g12a-sei510.dtb              meson-gxbb-nanopi-k2.dtb
    meson-gxm-khadas-vim2.dtb
meson-g12a-u200.dtb                meson-gxbb-odroidc2.dtb
    meson-gxm-s912-libretech-pc.dtb
meson-g12b-a311d-bananapi-m2s.dtb  meson-gxbb-p200.dtb
    meson-gxm-wetek-core2.dtb
meson-g12b-a311d-khadas-vim3.dtb   meson-gxbb-p201.dtb
    meson-sm1-bananapi-m2-pro.dtb
meson-g12b-bananapi-cm4-cm4io.dtb  meson-gxbb-wetek-hub.dtb
    meson-sm1-bananapi-m5.dtb
meson-g12b-gsking-x.dtb            meson-gxbb-wetek-play2.dtb
    meson-sm1-khadas-vim3l.dtb
meson-g12b-gtking.dtb              meson-gxl-s805x-libretech-ac.dtb
    meson-sm1-odroid-c4.dtb
meson-g12b-gtking-pro.dtb          meson-gxl-s905d-libretech-pc.dtb
    meson-sm1-odroid-hc4.dtb
meson-g12b-odroid-go-ultra.dtb
meson-gxl-s905w-jethome-jethub-j80.dtb  meson-sm1-sei610.dtb
meson-g12b-odroid-n2.dtb           meson-gxl-s905x-khadas-vim.dtb
$
With this series (sort of, since I am really not sure how to
cherry-pick the commits from the PR) I see nothing:

$ ls /tmp/b/odroid-c2/arch/arm/dts/
$

This shows some of the files:

$ find /tmp/b/odroid-c2/ -name "*.dtb"
/tmp/b/odroid-c2/dts/dt.dtb
/tmp/b/odroid-c2/dts/arch/arm64/amlogic/meson-gxbb-odroidc2.dtb
/tmp/b/odroid-c2/dts/arch/arm64/amlogic/meson-gxbb-nanopi-k2.dtb
/tmp/b/odroid-c2/dts/arch/arm64/amlogic/meson-gxbb-wetek-play2.dtb
/tmp/b/odroid-c2/dts/arch/arm64/amlogic/meson-gxbb-kii-pro.dtb
/tmp/b/odroid-c2/dts/arch/arm64/amlogic/meson-gxbb-p200.dtb
/tmp/b/odroid-c2/dts/arch/arm64/amlogic/meson-gxbb-p201.dtb
/tmp/b/odroid-c2/dts/arch/arm64/amlogic/meson-gxbb-wetek-hub.dtb
/tmp/b/odroid-c2/u-boot.dtb

but where are the rest? Also, is it possible to put the output .dtb
files into the same directory? Otherwise we may have some pain with
binman.

[..]

Regards,
Simon
Tom Rini Dec. 28, 2023, 3:54 p.m. UTC | #4 
On Thu, Dec 28, 2023 at 03:09:12PM +0000, Simon Glass wrote:
> Hi Tom, Sumit,
> 
> On Thu, Dec 28, 2023 at 2:03 PM Tom Rini <trini@konsulko.com> wrote:
> >
> > On Thu, Dec 28, 2023 at 01:37:26PM +0000, Simon Glass wrote:
> > > Hi Sumit,
> > >
> > > On Thu, Dec 28, 2023 at 11:58 AM Sumit Garg <sumit.garg@linaro.org> wrote:
> > > >
> > > > Allow platform owners to mirror devicetree files from devitree-rebasing
> > > > directory into dts/arch/$(ARCH) (special case for dts/arch/arm64). Then
> > > > build then along with any *-u-boot.dtsi file present in arch/$(ARCH)/dts
> > > > directory. Also add a new Makefile for arm64.
> > > >
> > > > This will help easy migration for platforms which currently are compliant
> > > > with upstream Linux kernel devicetree files.
> > > >
> > > > Signed-off-by: Sumit Garg <sumit.garg@linaro.org>
> > > > ---
> > > >
> > > > Changes in v3:
> > > > --------------
> > > > - Minor commit message update
> > > >
> > > > Changes in v2:
> > > > --------------
> > > > - s/DEVICE_TREE_LOC/dt_dir/ and s/U-boot/U-Boot/
> > > >
> > > >  dts/Kconfig             | 11 +++++++++++
> > > >  dts/Makefile            | 17 ++++++++++++++---
> > > >  dts/arch/arm64/Makefile | 14 ++++++++++++++
> > > >  3 files changed, 39 insertions(+), 3 deletions(-)
> > > >  create mode 100644 dts/arch/arm64/Makefile
> > > >
> > > > diff --git a/dts/Kconfig b/dts/Kconfig
> > > > index 00c0aeff893..e58c1c6f2ab 100644
> > > > --- a/dts/Kconfig
> > > > +++ b/dts/Kconfig
> > > > @@ -85,6 +85,17 @@ config OF_LIVE
> > > >           enables a live tree which is available after relocation,
> > > >           and can be adjusted as needed.
> > > >
> > > > +config OF_UPSTREAM
> > > > +       bool "Enable use of devicetree imported from Linux kernel release"
> > > > +       help
> > > > +         Traditionally, U-Boot platforms used to have their custom devicetree
> > > > +         files or copy devicetree files from Linux kernel which are hard to
> > > > +         maintain and can usually get out-of-sync from Linux kernel. This
> > > > +         option enables platforms to migrate to devicetree-rebasing repo where
> > > > +         a regular sync will be maintained every major Linux kernel release
> > > > +         cycle. However, platforms can still have some custom u-boot specific
> > > > +         bits maintained as part of *-u-boot.dtsi files.
> > >
> > > My only other suggestion here is to mention that this should be set in
> > > Kconfig, for the SoC as a whole. So I believe that means that it
> > > should be hidden, with no string for the 'bool':
> > >
> > >       bool  # Enable use of devicetree imported from Linux kernel release
> >
> > I think we can just keep prompting for it now, to make the transition
> > easier, before this option just goes away in time, hopefully.
> >
> > > Also, this doesn't seem to work for me. Before this series I get these
> > > files when building firefly-rk3399:
> > >
> > > rk3399-eaidk-610.dtb            rk3399-khadas-edge-v.dtb
> > > rk3399-orangepi.dtb        rk3399-rock-pi-4a.dtb
> > > rk3399-evb.dtb                  rk3399-leez-p710.dtb
> > > rk3399-pinebook-pro.dtb    rk3399-rock-pi-4c.dtb
> > > rk3399-ficus.dtb                rk3399-nanopc-t4.dtb
> > > rk3399-pinephone-pro.dtb   rk3399-rockpro64.dtb
> > > rk3399-firefly.dtb              rk3399-nanopi-m4-2gb.dtb
> > > rk3399pro-rock-pi-n10.dtb  rk3399-roc-pc.dtb
> > > rk3399-gru-bob.dtb              rk3399-nanopi-m4b.dtb
> > > rk3399-puma-haikou.dtb     rk3399-roc-pc-mezzanine.dtb
> > > rk3399-gru-kevin.dtb            rk3399-nanopi-m4.dtb
> > > rk3399-rock-4c-plus.dtb
> > > rk3399-khadas-edge-captain.dtb  rk3399-nanopi-neo4.dtb    rk3399-rock-4se.dtb
> > > rk3399-khadas-edge.dtb          rk3399-nanopi-r4s.dtb     rk3399-rock960.dtb
> > >
> > > Afterwards I get this:
> > >
> > > make[3]: *** No rule to make target
> > > 'dts/arch/arm64/rk3399-firefly.dtb', needed by 'dtbs'.  Stop.
> > >
> > > So I set this manually for that one board:
> > >
> > > CONFIG_DEFAULT_DEVICE_TREE="rockchip/rk3399-firefly"
> > >
> > > and get:
> > >
> > > make[3]: *** No rule to make target
> > > 'dts/arch/arm64/rockchip/rk3399-firefly.dtb', needed by 'dtbs'.  Stop.
> > >
> > > I am not sure how to fix this, nor how this can be made to build all
> > > the DTs for rk3399, as it does today.
> >
> > Looking at the patch for amlogic boards, you need to make the link to
> > devicetree-rebasing inside dts/...
> 
> OK, let me give up on rk3399 for now...that doesn't seem to work even
> with the link.
> 
> Using odroid-c2 with -next I see:
> 
> $ ls /tmp/b/odroid-c2/arch/arm/dts/
> meson-a1-ad401.dtb                 meson-g12b-odroid-n2l.dtb
>     meson-gxl-s905x-libretech-cc.dtb
> meson-axg-jethome-jethub-j100.dtb  meson-g12b-odroid-n2-plus.dtb
>     meson-gxl-s905x-libretech-cc-v2.dtb
> meson-axg-s400.dtb                 meson-g12b-radxa-zero2.dtb
>     meson-gxl-s905x-p212.dtb
> meson-g12a-radxa-zero.dtb          meson-gxbb-kii-pro.dtb
>     meson-gxm-gt1-ultimate.dtb
> meson-g12a-sei510.dtb              meson-gxbb-nanopi-k2.dtb
>     meson-gxm-khadas-vim2.dtb
> meson-g12a-u200.dtb                meson-gxbb-odroidc2.dtb
>     meson-gxm-s912-libretech-pc.dtb
> meson-g12b-a311d-bananapi-m2s.dtb  meson-gxbb-p200.dtb
>     meson-gxm-wetek-core2.dtb
> meson-g12b-a311d-khadas-vim3.dtb   meson-gxbb-p201.dtb
>     meson-sm1-bananapi-m2-pro.dtb
> meson-g12b-bananapi-cm4-cm4io.dtb  meson-gxbb-wetek-hub.dtb
>     meson-sm1-bananapi-m5.dtb
> meson-g12b-gsking-x.dtb            meson-gxbb-wetek-play2.dtb
>     meson-sm1-khadas-vim3l.dtb
> meson-g12b-gtking.dtb              meson-gxl-s805x-libretech-ac.dtb
>     meson-sm1-odroid-c4.dtb
> meson-g12b-gtking-pro.dtb          meson-gxl-s905d-libretech-pc.dtb
>     meson-sm1-odroid-hc4.dtb
> meson-g12b-odroid-go-ultra.dtb
> meson-gxl-s905w-jethome-jethub-j80.dtb  meson-sm1-sei610.dtb
> meson-g12b-odroid-n2.dtb           meson-gxl-s905x-khadas-vim.dtb
> $
> With this series (sort of, since I am really not sure how to
> cherry-pick the commits from the PR) I see nothing:
> 
> $ ls /tmp/b/odroid-c2/arch/arm/dts/
> $
> 
> This shows some of the files:
> 
> $ find /tmp/b/odroid-c2/ -name "*.dtb"
> /tmp/b/odroid-c2/dts/dt.dtb
> /tmp/b/odroid-c2/dts/arch/arm64/amlogic/meson-gxbb-odroidc2.dtb
> /tmp/b/odroid-c2/dts/arch/arm64/amlogic/meson-gxbb-nanopi-k2.dtb
> /tmp/b/odroid-c2/dts/arch/arm64/amlogic/meson-gxbb-wetek-play2.dtb
> /tmp/b/odroid-c2/dts/arch/arm64/amlogic/meson-gxbb-kii-pro.dtb
> /tmp/b/odroid-c2/dts/arch/arm64/amlogic/meson-gxbb-p200.dtb
> /tmp/b/odroid-c2/dts/arch/arm64/amlogic/meson-gxbb-p201.dtb
> /tmp/b/odroid-c2/dts/arch/arm64/amlogic/meson-gxbb-wetek-hub.dtb
> /tmp/b/odroid-c2/u-boot.dtb
> 
> but where are the rest? Also, is it possible to put the output .dtb
> files into the same directory? Otherwise we may have some pain with
> binman.

What do you mean by same directory? But maybe also, what's an example of
a board you think might end up having problems? Converting that in a
follow-up series is likely a good idea, to highlight and address these
issues sooner rather than later.
Simon Glass Dec. 28, 2023, 7:48 p.m. UTC | #5 
Hi Tom,

On Thu, Dec 28, 2023 at 3:54 PM Tom Rini <trini@konsulko.com> wrote:
>
> On Thu, Dec 28, 2023 at 03:09:12PM +0000, Simon Glass wrote:
> > Hi Tom, Sumit,
> >
> > On Thu, Dec 28, 2023 at 2:03 PM Tom Rini <trini@konsulko.com> wrote:
> > >
> > > On Thu, Dec 28, 2023 at 01:37:26PM +0000, Simon Glass wrote:
> > > > Hi Sumit,
> > > >
> > > > On Thu, Dec 28, 2023 at 11:58 AM Sumit Garg <sumit.garg@linaro.org> wrote:
> > > > >
> > > > > Allow platform owners to mirror devicetree files from devitree-rebasing
> > > > > directory into dts/arch/$(ARCH) (special case for dts/arch/arm64). Then
> > > > > build then along with any *-u-boot.dtsi file present in arch/$(ARCH)/dts
> > > > > directory. Also add a new Makefile for arm64.
> > > > >
> > > > > This will help easy migration for platforms which currently are compliant
> > > > > with upstream Linux kernel devicetree files.
> > > > >
> > > > > Signed-off-by: Sumit Garg <sumit.garg@linaro.org>
> > > > > ---
> > > > >
> > > > > Changes in v3:
> > > > > --------------
> > > > > - Minor commit message update
> > > > >
> > > > > Changes in v2:
> > > > > --------------
> > > > > - s/DEVICE_TREE_LOC/dt_dir/ and s/U-boot/U-Boot/
> > > > >
> > > > >  dts/Kconfig             | 11 +++++++++++
> > > > >  dts/Makefile            | 17 ++++++++++++++---
> > > > >  dts/arch/arm64/Makefile | 14 ++++++++++++++
> > > > >  3 files changed, 39 insertions(+), 3 deletions(-)
> > > > >  create mode 100644 dts/arch/arm64/Makefile
> > > > >
> > > > > diff --git a/dts/Kconfig b/dts/Kconfig
> > > > > index 00c0aeff893..e58c1c6f2ab 100644
> > > > > --- a/dts/Kconfig
> > > > > +++ b/dts/Kconfig
> > > > > @@ -85,6 +85,17 @@ config OF_LIVE
> > > > >           enables a live tree which is available after relocation,
> > > > >           and can be adjusted as needed.
> > > > >
> > > > > +config OF_UPSTREAM
> > > > > +       bool "Enable use of devicetree imported from Linux kernel release"
> > > > > +       help
> > > > > +         Traditionally, U-Boot platforms used to have their custom devicetree
> > > > > +         files or copy devicetree files from Linux kernel which are hard to
> > > > > +         maintain and can usually get out-of-sync from Linux kernel. This
> > > > > +         option enables platforms to migrate to devicetree-rebasing repo where
> > > > > +         a regular sync will be maintained every major Linux kernel release
> > > > > +         cycle. However, platforms can still have some custom u-boot specific
> > > > > +         bits maintained as part of *-u-boot.dtsi files.
> > > >
> > > > My only other suggestion here is to mention that this should be set in
> > > > Kconfig, for the SoC as a whole. So I believe that means that it
> > > > should be hidden, with no string for the 'bool':
> > > >
> > > >       bool  # Enable use of devicetree imported from Linux kernel release
> > >
> > > I think we can just keep prompting for it now, to make the transition
> > > easier, before this option just goes away in time, hopefully.
> > >
> > > > Also, this doesn't seem to work for me. Before this series I get these
> > > > files when building firefly-rk3399:
> > > >
> > > > rk3399-eaidk-610.dtb            rk3399-khadas-edge-v.dtb
> > > > rk3399-orangepi.dtb        rk3399-rock-pi-4a.dtb
> > > > rk3399-evb.dtb                  rk3399-leez-p710.dtb
> > > > rk3399-pinebook-pro.dtb    rk3399-rock-pi-4c.dtb
> > > > rk3399-ficus.dtb                rk3399-nanopc-t4.dtb
> > > > rk3399-pinephone-pro.dtb   rk3399-rockpro64.dtb
> > > > rk3399-firefly.dtb              rk3399-nanopi-m4-2gb.dtb
> > > > rk3399pro-rock-pi-n10.dtb  rk3399-roc-pc.dtb
> > > > rk3399-gru-bob.dtb              rk3399-nanopi-m4b.dtb
> > > > rk3399-puma-haikou.dtb     rk3399-roc-pc-mezzanine.dtb
> > > > rk3399-gru-kevin.dtb            rk3399-nanopi-m4.dtb
> > > > rk3399-rock-4c-plus.dtb
> > > > rk3399-khadas-edge-captain.dtb  rk3399-nanopi-neo4.dtb    rk3399-rock-4se.dtb
> > > > rk3399-khadas-edge.dtb          rk3399-nanopi-r4s.dtb     rk3399-rock960.dtb
> > > >
> > > > Afterwards I get this:
> > > >
> > > > make[3]: *** No rule to make target
> > > > 'dts/arch/arm64/rk3399-firefly.dtb', needed by 'dtbs'.  Stop.
> > > >
> > > > So I set this manually for that one board:
> > > >
> > > > CONFIG_DEFAULT_DEVICE_TREE="rockchip/rk3399-firefly"
> > > >
> > > > and get:
> > > >
> > > > make[3]: *** No rule to make target
> > > > 'dts/arch/arm64/rockchip/rk3399-firefly.dtb', needed by 'dtbs'.  Stop.
> > > >
> > > > I am not sure how to fix this, nor how this can be made to build all
> > > > the DTs for rk3399, as it does today.
> > >
> > > Looking at the patch for amlogic boards, you need to make the link to
> > > devicetree-rebasing inside dts/...
> >
> > OK, let me give up on rk3399 for now...that doesn't seem to work even
> > with the link.
> >
> > Using odroid-c2 with -next I see:
> >
> > $ ls /tmp/b/odroid-c2/arch/arm/dts/
> > meson-a1-ad401.dtb                 meson-g12b-odroid-n2l.dtb
> >     meson-gxl-s905x-libretech-cc.dtb
> > meson-axg-jethome-jethub-j100.dtb  meson-g12b-odroid-n2-plus.dtb
> >     meson-gxl-s905x-libretech-cc-v2.dtb
> > meson-axg-s400.dtb                 meson-g12b-radxa-zero2.dtb
> >     meson-gxl-s905x-p212.dtb
> > meson-g12a-radxa-zero.dtb          meson-gxbb-kii-pro.dtb
> >     meson-gxm-gt1-ultimate.dtb
> > meson-g12a-sei510.dtb              meson-gxbb-nanopi-k2.dtb
> >     meson-gxm-khadas-vim2.dtb
> > meson-g12a-u200.dtb                meson-gxbb-odroidc2.dtb
> >     meson-gxm-s912-libretech-pc.dtb
> > meson-g12b-a311d-bananapi-m2s.dtb  meson-gxbb-p200.dtb
> >     meson-gxm-wetek-core2.dtb
> > meson-g12b-a311d-khadas-vim3.dtb   meson-gxbb-p201.dtb
> >     meson-sm1-bananapi-m2-pro.dtb
> > meson-g12b-bananapi-cm4-cm4io.dtb  meson-gxbb-wetek-hub.dtb
> >     meson-sm1-bananapi-m5.dtb
> > meson-g12b-gsking-x.dtb            meson-gxbb-wetek-play2.dtb
> >     meson-sm1-khadas-vim3l.dtb
> > meson-g12b-gtking.dtb              meson-gxl-s805x-libretech-ac.dtb
> >     meson-sm1-odroid-c4.dtb
> > meson-g12b-gtking-pro.dtb          meson-gxl-s905d-libretech-pc.dtb
> >     meson-sm1-odroid-hc4.dtb
> > meson-g12b-odroid-go-ultra.dtb
> > meson-gxl-s905w-jethome-jethub-j80.dtb  meson-sm1-sei610.dtb
> > meson-g12b-odroid-n2.dtb           meson-gxl-s905x-khadas-vim.dtb
> > $
> > With this series (sort of, since I am really not sure how to
> > cherry-pick the commits from the PR) I see nothing:
> >
> > $ ls /tmp/b/odroid-c2/arch/arm/dts/
> > $
> >
> > This shows some of the files:
> >
> > $ find /tmp/b/odroid-c2/ -name "*.dtb"
> > /tmp/b/odroid-c2/dts/dt.dtb
> > /tmp/b/odroid-c2/dts/arch/arm64/amlogic/meson-gxbb-odroidc2.dtb
> > /tmp/b/odroid-c2/dts/arch/arm64/amlogic/meson-gxbb-nanopi-k2.dtb
> > /tmp/b/odroid-c2/dts/arch/arm64/amlogic/meson-gxbb-wetek-play2.dtb
> > /tmp/b/odroid-c2/dts/arch/arm64/amlogic/meson-gxbb-kii-pro.dtb
> > /tmp/b/odroid-c2/dts/arch/arm64/amlogic/meson-gxbb-p200.dtb
> > /tmp/b/odroid-c2/dts/arch/arm64/amlogic/meson-gxbb-p201.dtb
> > /tmp/b/odroid-c2/dts/arch/arm64/amlogic/meson-gxbb-wetek-hub.dtb
> > /tmp/b/odroid-c2/u-boot.dtb
> >
> > but where are the rest? Also, is it possible to put the output .dtb
> > files into the same directory? Otherwise we may have some pain with
> > binman.
>
> What do you mean by same directory? But maybe also, what's an example of
> a board you think might end up having problems? Converting that in a
> follow-up series is likely a good idea, to highlight and address these
> issues sooner rather than later.#

Today the .dtb files go into arch/arm/dts - so it would be easier if
this series could do the same.

The problem I have described above applied to meson, so I believe it
is clear enough with that. I wasn't able to get rk3399 going, but I am
sure it would have the same problem.

The fundamental question is (I believe) whether to:

1. Build only a single DT for a board
2. Build all DTs for the SoC the board uses

This series seems to head towards (1), which worries me. We are
currently mostly at (2).

Regards,
Simon
Tom Rini Dec. 28, 2023, 8:31 p.m. UTC | #6 
On Thu, Dec 28, 2023 at 07:48:06PM +0000, Simon Glass wrote:
> Hi Tom,
> 
> On Thu, Dec 28, 2023 at 3:54 PM Tom Rini <trini@konsulko.com> wrote:
> >
> > On Thu, Dec 28, 2023 at 03:09:12PM +0000, Simon Glass wrote:
> > > Hi Tom, Sumit,
> > >
> > > On Thu, Dec 28, 2023 at 2:03 PM Tom Rini <trini@konsulko.com> wrote:
> > > >
> > > > On Thu, Dec 28, 2023 at 01:37:26PM +0000, Simon Glass wrote:
> > > > > Hi Sumit,
> > > > >
> > > > > On Thu, Dec 28, 2023 at 11:58 AM Sumit Garg <sumit.garg@linaro.org> wrote:
> > > > > >
> > > > > > Allow platform owners to mirror devicetree files from devitree-rebasing
> > > > > > directory into dts/arch/$(ARCH) (special case for dts/arch/arm64). Then
> > > > > > build then along with any *-u-boot.dtsi file present in arch/$(ARCH)/dts
> > > > > > directory. Also add a new Makefile for arm64.
> > > > > >
> > > > > > This will help easy migration for platforms which currently are compliant
> > > > > > with upstream Linux kernel devicetree files.
> > > > > >
> > > > > > Signed-off-by: Sumit Garg <sumit.garg@linaro.org>
> > > > > > ---
> > > > > >
> > > > > > Changes in v3:
> > > > > > --------------
> > > > > > - Minor commit message update
> > > > > >
> > > > > > Changes in v2:
> > > > > > --------------
> > > > > > - s/DEVICE_TREE_LOC/dt_dir/ and s/U-boot/U-Boot/
> > > > > >
> > > > > >  dts/Kconfig             | 11 +++++++++++
> > > > > >  dts/Makefile            | 17 ++++++++++++++---
> > > > > >  dts/arch/arm64/Makefile | 14 ++++++++++++++
> > > > > >  3 files changed, 39 insertions(+), 3 deletions(-)
> > > > > >  create mode 100644 dts/arch/arm64/Makefile
> > > > > >
> > > > > > diff --git a/dts/Kconfig b/dts/Kconfig
> > > > > > index 00c0aeff893..e58c1c6f2ab 100644
> > > > > > --- a/dts/Kconfig
> > > > > > +++ b/dts/Kconfig
> > > > > > @@ -85,6 +85,17 @@ config OF_LIVE
> > > > > >           enables a live tree which is available after relocation,
> > > > > >           and can be adjusted as needed.
> > > > > >
> > > > > > +config OF_UPSTREAM
> > > > > > +       bool "Enable use of devicetree imported from Linux kernel release"
> > > > > > +       help
> > > > > > +         Traditionally, U-Boot platforms used to have their custom devicetree
> > > > > > +         files or copy devicetree files from Linux kernel which are hard to
> > > > > > +         maintain and can usually get out-of-sync from Linux kernel. This
> > > > > > +         option enables platforms to migrate to devicetree-rebasing repo where
> > > > > > +         a regular sync will be maintained every major Linux kernel release
> > > > > > +         cycle. However, platforms can still have some custom u-boot specific
> > > > > > +         bits maintained as part of *-u-boot.dtsi files.
> > > > >
> > > > > My only other suggestion here is to mention that this should be set in
> > > > > Kconfig, for the SoC as a whole. So I believe that means that it
> > > > > should be hidden, with no string for the 'bool':
> > > > >
> > > > >       bool  # Enable use of devicetree imported from Linux kernel release
> > > >
> > > > I think we can just keep prompting for it now, to make the transition
> > > > easier, before this option just goes away in time, hopefully.
> > > >
> > > > > Also, this doesn't seem to work for me. Before this series I get these
> > > > > files when building firefly-rk3399:
> > > > >
> > > > > rk3399-eaidk-610.dtb            rk3399-khadas-edge-v.dtb
> > > > > rk3399-orangepi.dtb        rk3399-rock-pi-4a.dtb
> > > > > rk3399-evb.dtb                  rk3399-leez-p710.dtb
> > > > > rk3399-pinebook-pro.dtb    rk3399-rock-pi-4c.dtb
> > > > > rk3399-ficus.dtb                rk3399-nanopc-t4.dtb
> > > > > rk3399-pinephone-pro.dtb   rk3399-rockpro64.dtb
> > > > > rk3399-firefly.dtb              rk3399-nanopi-m4-2gb.dtb
> > > > > rk3399pro-rock-pi-n10.dtb  rk3399-roc-pc.dtb
> > > > > rk3399-gru-bob.dtb              rk3399-nanopi-m4b.dtb
> > > > > rk3399-puma-haikou.dtb     rk3399-roc-pc-mezzanine.dtb
> > > > > rk3399-gru-kevin.dtb            rk3399-nanopi-m4.dtb
> > > > > rk3399-rock-4c-plus.dtb
> > > > > rk3399-khadas-edge-captain.dtb  rk3399-nanopi-neo4.dtb    rk3399-rock-4se.dtb
> > > > > rk3399-khadas-edge.dtb          rk3399-nanopi-r4s.dtb     rk3399-rock960.dtb
> > > > >
> > > > > Afterwards I get this:
> > > > >
> > > > > make[3]: *** No rule to make target
> > > > > 'dts/arch/arm64/rk3399-firefly.dtb', needed by 'dtbs'.  Stop.
> > > > >
> > > > > So I set this manually for that one board:
> > > > >
> > > > > CONFIG_DEFAULT_DEVICE_TREE="rockchip/rk3399-firefly"
> > > > >
> > > > > and get:
> > > > >
> > > > > make[3]: *** No rule to make target
> > > > > 'dts/arch/arm64/rockchip/rk3399-firefly.dtb', needed by 'dtbs'.  Stop.
> > > > >
> > > > > I am not sure how to fix this, nor how this can be made to build all
> > > > > the DTs for rk3399, as it does today.
> > > >
> > > > Looking at the patch for amlogic boards, you need to make the link to
> > > > devicetree-rebasing inside dts/...
> > >
> > > OK, let me give up on rk3399 for now...that doesn't seem to work even
> > > with the link.
> > >
> > > Using odroid-c2 with -next I see:
> > >
> > > $ ls /tmp/b/odroid-c2/arch/arm/dts/
> > > meson-a1-ad401.dtb                 meson-g12b-odroid-n2l.dtb
> > >     meson-gxl-s905x-libretech-cc.dtb
> > > meson-axg-jethome-jethub-j100.dtb  meson-g12b-odroid-n2-plus.dtb
> > >     meson-gxl-s905x-libretech-cc-v2.dtb
> > > meson-axg-s400.dtb                 meson-g12b-radxa-zero2.dtb
> > >     meson-gxl-s905x-p212.dtb
> > > meson-g12a-radxa-zero.dtb          meson-gxbb-kii-pro.dtb
> > >     meson-gxm-gt1-ultimate.dtb
> > > meson-g12a-sei510.dtb              meson-gxbb-nanopi-k2.dtb
> > >     meson-gxm-khadas-vim2.dtb
> > > meson-g12a-u200.dtb                meson-gxbb-odroidc2.dtb
> > >     meson-gxm-s912-libretech-pc.dtb
> > > meson-g12b-a311d-bananapi-m2s.dtb  meson-gxbb-p200.dtb
> > >     meson-gxm-wetek-core2.dtb
> > > meson-g12b-a311d-khadas-vim3.dtb   meson-gxbb-p201.dtb
> > >     meson-sm1-bananapi-m2-pro.dtb
> > > meson-g12b-bananapi-cm4-cm4io.dtb  meson-gxbb-wetek-hub.dtb
> > >     meson-sm1-bananapi-m5.dtb
> > > meson-g12b-gsking-x.dtb            meson-gxbb-wetek-play2.dtb
> > >     meson-sm1-khadas-vim3l.dtb
> > > meson-g12b-gtking.dtb              meson-gxl-s805x-libretech-ac.dtb
> > >     meson-sm1-odroid-c4.dtb
> > > meson-g12b-gtking-pro.dtb          meson-gxl-s905d-libretech-pc.dtb
> > >     meson-sm1-odroid-hc4.dtb
> > > meson-g12b-odroid-go-ultra.dtb
> > > meson-gxl-s905w-jethome-jethub-j80.dtb  meson-sm1-sei610.dtb
> > > meson-g12b-odroid-n2.dtb           meson-gxl-s905x-khadas-vim.dtb
> > > $
> > > With this series (sort of, since I am really not sure how to
> > > cherry-pick the commits from the PR) I see nothing:
> > >
> > > $ ls /tmp/b/odroid-c2/arch/arm/dts/
> > > $
> > >
> > > This shows some of the files:
> > >
> > > $ find /tmp/b/odroid-c2/ -name "*.dtb"
> > > /tmp/b/odroid-c2/dts/dt.dtb
> > > /tmp/b/odroid-c2/dts/arch/arm64/amlogic/meson-gxbb-odroidc2.dtb
> > > /tmp/b/odroid-c2/dts/arch/arm64/amlogic/meson-gxbb-nanopi-k2.dtb
> > > /tmp/b/odroid-c2/dts/arch/arm64/amlogic/meson-gxbb-wetek-play2.dtb
> > > /tmp/b/odroid-c2/dts/arch/arm64/amlogic/meson-gxbb-kii-pro.dtb
> > > /tmp/b/odroid-c2/dts/arch/arm64/amlogic/meson-gxbb-p200.dtb
> > > /tmp/b/odroid-c2/dts/arch/arm64/amlogic/meson-gxbb-p201.dtb
> > > /tmp/b/odroid-c2/dts/arch/arm64/amlogic/meson-gxbb-wetek-hub.dtb
> > > /tmp/b/odroid-c2/u-boot.dtb
> > >
> > > but where are the rest? Also, is it possible to put the output .dtb
> > > files into the same directory? Otherwise we may have some pain with
> > > binman.
> >
> > What do you mean by same directory? But maybe also, what's an example of
> > a board you think might end up having problems? Converting that in a
> > follow-up series is likely a good idea, to highlight and address these
> > issues sooner rather than later.#
> 
> Today the .dtb files go into arch/arm/dts - so it would be easier if
> this series could do the same.

But that's just an artifact of not having vendor directories. I don't
really think we can sanely put the new object files in there, that's not
what anyone is going to expect.

> The problem I have described above applied to meson, so I believe it
> is clear enough with that. I wasn't able to get rk3399 going, but I am
> sure it would have the same problem.

I don't think meson has the problem I was asking about, which is what
problem binman will have, because the series to make binman replace the
vendor tools didn't complete? That's what I'm getting at, for which
platform is binman going to have a problem today, so that we can look at
what to do about it and evaluate solutions with an example in hand.

> The fundamental question is (I believe) whether to:
> 
> 1. Build only a single DT for a board
> 2. Build all DTs for the SoC the board uses
> 
> This series seems to head towards (1), which worries me. We are
> currently mostly at (2).

It's explicitly at (1) with the notion we'll deal with (2) down the
road once there's a use case for it.  Possibly once someone updates
exynos platforms, based on what you had said previously?
Sumit Garg Dec. 29, 2023, 3:30 p.m. UTC | #7 
On Fri, 29 Dec 2023 at 01:18, Simon Glass <sjg@chromium.org> wrote:
>
> Hi Tom,
>
> On Thu, Dec 28, 2023 at 3:54 PM Tom Rini <trini@konsulko.com> wrote:
> >
> > On Thu, Dec 28, 2023 at 03:09:12PM +0000, Simon Glass wrote:
> > > Hi Tom, Sumit,
> > >
> > > On Thu, Dec 28, 2023 at 2:03 PM Tom Rini <trini@konsulko.com> wrote:
> > > >
> > > > On Thu, Dec 28, 2023 at 01:37:26PM +0000, Simon Glass wrote:
> > > > > Hi Sumit,
> > > > >
> > > > > On Thu, Dec 28, 2023 at 11:58 AM Sumit Garg <sumit.garg@linaro.org> wrote:
> > > > > >
> > > > > > Allow platform owners to mirror devicetree files from devitree-rebasing
> > > > > > directory into dts/arch/$(ARCH) (special case for dts/arch/arm64). Then
> > > > > > build then along with any *-u-boot.dtsi file present in arch/$(ARCH)/dts
> > > > > > directory. Also add a new Makefile for arm64.
> > > > > >
> > > > > > This will help easy migration for platforms which currently are compliant
> > > > > > with upstream Linux kernel devicetree files.
> > > > > >
> > > > > > Signed-off-by: Sumit Garg <sumit.garg@linaro.org>
> > > > > > ---
> > > > > >
> > > > > > Changes in v3:
> > > > > > --------------
> > > > > > - Minor commit message update
> > > > > >
> > > > > > Changes in v2:
> > > > > > --------------
> > > > > > - s/DEVICE_TREE_LOC/dt_dir/ and s/U-boot/U-Boot/
> > > > > >
> > > > > >  dts/Kconfig             | 11 +++++++++++
> > > > > >  dts/Makefile            | 17 ++++++++++++++---
> > > > > >  dts/arch/arm64/Makefile | 14 ++++++++++++++
> > > > > >  3 files changed, 39 insertions(+), 3 deletions(-)
> > > > > >  create mode 100644 dts/arch/arm64/Makefile
> > > > > >
> > > > > > diff --git a/dts/Kconfig b/dts/Kconfig
> > > > > > index 00c0aeff893..e58c1c6f2ab 100644
> > > > > > --- a/dts/Kconfig
> > > > > > +++ b/dts/Kconfig
> > > > > > @@ -85,6 +85,17 @@ config OF_LIVE
> > > > > >           enables a live tree which is available after relocation,
> > > > > >           and can be adjusted as needed.
> > > > > >
> > > > > > +config OF_UPSTREAM
> > > > > > +       bool "Enable use of devicetree imported from Linux kernel release"
> > > > > > +       help
> > > > > > +         Traditionally, U-Boot platforms used to have their custom devicetree
> > > > > > +         files or copy devicetree files from Linux kernel which are hard to
> > > > > > +         maintain and can usually get out-of-sync from Linux kernel. This
> > > > > > +         option enables platforms to migrate to devicetree-rebasing repo where
> > > > > > +         a regular sync will be maintained every major Linux kernel release
> > > > > > +         cycle. However, platforms can still have some custom u-boot specific
> > > > > > +         bits maintained as part of *-u-boot.dtsi files.
> > > > >
> > > > > My only other suggestion here is to mention that this should be set in
> > > > > Kconfig, for the SoC as a whole. So I believe that means that it
> > > > > should be hidden, with no string for the 'bool':
> > > > >
> > > > >       bool  # Enable use of devicetree imported from Linux kernel release
> > > >
> > > > I think we can just keep prompting for it now, to make the transition
> > > > easier, before this option just goes away in time, hopefully.
> > > >
> > > > > Also, this doesn't seem to work for me. Before this series I get these
> > > > > files when building firefly-rk3399:
> > > > >
> > > > > rk3399-eaidk-610.dtb            rk3399-khadas-edge-v.dtb
> > > > > rk3399-orangepi.dtb        rk3399-rock-pi-4a.dtb
> > > > > rk3399-evb.dtb                  rk3399-leez-p710.dtb
> > > > > rk3399-pinebook-pro.dtb    rk3399-rock-pi-4c.dtb
> > > > > rk3399-ficus.dtb                rk3399-nanopc-t4.dtb
> > > > > rk3399-pinephone-pro.dtb   rk3399-rockpro64.dtb
> > > > > rk3399-firefly.dtb              rk3399-nanopi-m4-2gb.dtb
> > > > > rk3399pro-rock-pi-n10.dtb  rk3399-roc-pc.dtb
> > > > > rk3399-gru-bob.dtb              rk3399-nanopi-m4b.dtb
> > > > > rk3399-puma-haikou.dtb     rk3399-roc-pc-mezzanine.dtb
> > > > > rk3399-gru-kevin.dtb            rk3399-nanopi-m4.dtb
> > > > > rk3399-rock-4c-plus.dtb
> > > > > rk3399-khadas-edge-captain.dtb  rk3399-nanopi-neo4.dtb    rk3399-rock-4se.dtb
> > > > > rk3399-khadas-edge.dtb          rk3399-nanopi-r4s.dtb     rk3399-rock960.dtb
> > > > >
> > > > > Afterwards I get this:
> > > > >
> > > > > make[3]: *** No rule to make target
> > > > > 'dts/arch/arm64/rk3399-firefly.dtb', needed by 'dtbs'.  Stop.
> > > > >
> > > > > So I set this manually for that one board:
> > > > >
> > > > > CONFIG_DEFAULT_DEVICE_TREE="rockchip/rk3399-firefly"
> > > > >
> > > > > and get:
> > > > >
> > > > > make[3]: *** No rule to make target
> > > > > 'dts/arch/arm64/rockchip/rk3399-firefly.dtb', needed by 'dtbs'.  Stop.
> > > > >
> > > > > I am not sure how to fix this, nor how this can be made to build all
> > > > > the DTs for rk3399, as it does today.
> > > >
> > > > Looking at the patch for amlogic boards, you need to make the link to
> > > > devicetree-rebasing inside dts/...
> > >
> > > OK, let me give up on rk3399 for now...that doesn't seem to work even
> > > with the link.
> > >
> > > Using odroid-c2 with -next I see:
> > >
> > > $ ls /tmp/b/odroid-c2/arch/arm/dts/
> > > meson-a1-ad401.dtb                 meson-g12b-odroid-n2l.dtb
> > >     meson-gxl-s905x-libretech-cc.dtb
> > > meson-axg-jethome-jethub-j100.dtb  meson-g12b-odroid-n2-plus.dtb
> > >     meson-gxl-s905x-libretech-cc-v2.dtb
> > > meson-axg-s400.dtb                 meson-g12b-radxa-zero2.dtb
> > >     meson-gxl-s905x-p212.dtb
> > > meson-g12a-radxa-zero.dtb          meson-gxbb-kii-pro.dtb
> > >     meson-gxm-gt1-ultimate.dtb
> > > meson-g12a-sei510.dtb              meson-gxbb-nanopi-k2.dtb
> > >     meson-gxm-khadas-vim2.dtb
> > > meson-g12a-u200.dtb                meson-gxbb-odroidc2.dtb
> > >     meson-gxm-s912-libretech-pc.dtb
> > > meson-g12b-a311d-bananapi-m2s.dtb  meson-gxbb-p200.dtb
> > >     meson-gxm-wetek-core2.dtb
> > > meson-g12b-a311d-khadas-vim3.dtb   meson-gxbb-p201.dtb
> > >     meson-sm1-bananapi-m2-pro.dtb
> > > meson-g12b-bananapi-cm4-cm4io.dtb  meson-gxbb-wetek-hub.dtb
> > >     meson-sm1-bananapi-m5.dtb
> > > meson-g12b-gsking-x.dtb            meson-gxbb-wetek-play2.dtb
> > >     meson-sm1-khadas-vim3l.dtb
> > > meson-g12b-gtking.dtb              meson-gxl-s805x-libretech-ac.dtb
> > >     meson-sm1-odroid-c4.dtb
> > > meson-g12b-gtking-pro.dtb          meson-gxl-s905d-libretech-pc.dtb
> > >     meson-sm1-odroid-hc4.dtb
> > > meson-g12b-odroid-go-ultra.dtb
> > > meson-gxl-s905w-jethome-jethub-j80.dtb  meson-sm1-sei610.dtb
> > > meson-g12b-odroid-n2.dtb           meson-gxl-s905x-khadas-vim.dtb
> > > $
> > > With this series (sort of, since I am really not sure how to
> > > cherry-pick the commits from the PR) I see nothing:
> > >
> > > $ ls /tmp/b/odroid-c2/arch/arm/dts/
> > > $
> > >
> > > This shows some of the files:
> > >
> > > $ find /tmp/b/odroid-c2/ -name "*.dtb"
> > > /tmp/b/odroid-c2/dts/dt.dtb
> > > /tmp/b/odroid-c2/dts/arch/arm64/amlogic/meson-gxbb-odroidc2.dtb
> > > /tmp/b/odroid-c2/dts/arch/arm64/amlogic/meson-gxbb-nanopi-k2.dtb
> > > /tmp/b/odroid-c2/dts/arch/arm64/amlogic/meson-gxbb-wetek-play2.dtb
> > > /tmp/b/odroid-c2/dts/arch/arm64/amlogic/meson-gxbb-kii-pro.dtb
> > > /tmp/b/odroid-c2/dts/arch/arm64/amlogic/meson-gxbb-p200.dtb
> > > /tmp/b/odroid-c2/dts/arch/arm64/amlogic/meson-gxbb-p201.dtb
> > > /tmp/b/odroid-c2/dts/arch/arm64/amlogic/meson-gxbb-wetek-hub.dtb
> > > /tmp/b/odroid-c2/u-boot.dtb
> > >
> > > but where are the rest? Also, is it possible to put the output .dtb
> > > files into the same directory? Otherwise we may have some pain with
> > > binman.
> >
> > What do you mean by same directory? But maybe also, what's an example of
> > a board you think might end up having problems? Converting that in a
> > follow-up series is likely a good idea, to highlight and address these
> > issues sooner rather than later.#
>
> Today the .dtb files go into arch/arm/dts - so it would be easier if
> this series could do the same.

The kbuild infrastructure keeps the dtb alongside dts files which is
the preferred way too as otherwise it would be complicated to locate
DT files for the users. Also, we have to move towards Linux DT
directory structure and thereby the tools like binman have to be
adjusted. I will do that when I get to migrating SoCs supporting
binman.

>
> The problem I have described above applied to meson, so I believe it
> is clear enough with that. I wasn't able to get rk3399 going, but I am
> sure it would have the same problem.
>
> The fundamental question is (I believe) whether to:
>
> 1. Build only a single DT for a board
> 2. Build all DTs for the SoC the board uses
>
> This series seems to head towards (1),

v2 of this series had the Makefile rules [1] for meson gxbb SoC but..

[1] https://patchwork.ozlabs.org/project/uboot/patch/20231222061208.3009970-8-sumit.garg@linaro.org/

> which worries me. We are
> currently mostly at (2).

..after discussion with Tom, the Makefile rules are already coming via
Kconfig options like DEFAULT_DEVICE_TREE, OF_LIST etc. So having
redundant rules in Makefile doesn't add any value, so I took them off
in v3.

However, I am very much in favour of having a generalized U-Boot
image. This might become true in some cases like U-Boot acts as a
second stage bootloader for a particular SoC which is a unified image
where the prior stage passes the DT to it. The Qcom effort in this
direction can be an example here. I am not sure at this point how we
can enable different U-Boot features since there are many board
specific bits needed currently not covered by DT.

The other common method is to embed board DT in U-Boot image
especially where U-Boot acts as a first stage bootloader. Once that's
done I don't see how we can call that a generic U-Boot image.

BTW, as Tom said we can very well add those Makefile rules later on a
use case basis if a particular SoC requires a truly generic U-Boot
image and the rules don't come via Kconfig options.

-Sumit

>
> Regards,
> Simon
Simon Glass Dec. 31, 2023, 2:28 p.m. UTC | #8 
Hi Sumit,

On Fri, Dec 29, 2023 at 8:30 AM Sumit Garg <sumit.garg@linaro.org> wrote:
>
> On Fri, 29 Dec 2023 at 01:18, Simon Glass <sjg@chromium.org> wrote:
> >
> > Hi Tom,
> >
> > On Thu, Dec 28, 2023 at 3:54 PM Tom Rini <trini@konsulko.com> wrote:
> > >
> > > On Thu, Dec 28, 2023 at 03:09:12PM +0000, Simon Glass wrote:
> > > > Hi Tom, Sumit,
> > > >
> > > > On Thu, Dec 28, 2023 at 2:03 PM Tom Rini <trini@konsulko.com> wrote:
> > > > >
> > > > > On Thu, Dec 28, 2023 at 01:37:26PM +0000, Simon Glass wrote:
> > > > > > Hi Sumit,
> > > > > >
> > > > > > On Thu, Dec 28, 2023 at 11:58 AM Sumit Garg <sumit.garg@linaro.org> wrote:
> > > > > > >
> > > > > > > Allow platform owners to mirror devicetree files from devitree-rebasing
> > > > > > > directory into dts/arch/$(ARCH) (special case for dts/arch/arm64). Then
> > > > > > > build then along with any *-u-boot.dtsi file present in arch/$(ARCH)/dts
> > > > > > > directory. Also add a new Makefile for arm64.
> > > > > > >
> > > > > > > This will help easy migration for platforms which currently are compliant
> > > > > > > with upstream Linux kernel devicetree files.
> > > > > > >
> > > > > > > Signed-off-by: Sumit Garg <sumit.garg@linaro.org>
> > > > > > > ---
> > > > > > >
> > > > > > > Changes in v3:
> > > > > > > --------------
> > > > > > > - Minor commit message update
> > > > > > >
> > > > > > > Changes in v2:
> > > > > > > --------------
> > > > > > > - s/DEVICE_TREE_LOC/dt_dir/ and s/U-boot/U-Boot/
> > > > > > >
> > > > > > >  dts/Kconfig             | 11 +++++++++++
> > > > > > >  dts/Makefile            | 17 ++++++++++++++---
> > > > > > >  dts/arch/arm64/Makefile | 14 ++++++++++++++
> > > > > > >  3 files changed, 39 insertions(+), 3 deletions(-)
> > > > > > >  create mode 100644 dts/arch/arm64/Makefile
> > > > > > >
> > > > > > > diff --git a/dts/Kconfig b/dts/Kconfig
> > > > > > > index 00c0aeff893..e58c1c6f2ab 100644
> > > > > > > --- a/dts/Kconfig
> > > > > > > +++ b/dts/Kconfig
> > > > > > > @@ -85,6 +85,17 @@ config OF_LIVE
> > > > > > >           enables a live tree which is available after relocation,
> > > > > > >           and can be adjusted as needed.
> > > > > > >
> > > > > > > +config OF_UPSTREAM
> > > > > > > +       bool "Enable use of devicetree imported from Linux kernel release"
> > > > > > > +       help
> > > > > > > +         Traditionally, U-Boot platforms used to have their custom devicetree
> > > > > > > +         files or copy devicetree files from Linux kernel which are hard to
> > > > > > > +         maintain and can usually get out-of-sync from Linux kernel. This
> > > > > > > +         option enables platforms to migrate to devicetree-rebasing repo where
> > > > > > > +         a regular sync will be maintained every major Linux kernel release
> > > > > > > +         cycle. However, platforms can still have some custom u-boot specific
> > > > > > > +         bits maintained as part of *-u-boot.dtsi files.
> > > > > >
> > > > > > My only other suggestion here is to mention that this should be set in
> > > > > > Kconfig, for the SoC as a whole. So I believe that means that it
> > > > > > should be hidden, with no string for the 'bool':
> > > > > >
> > > > > >       bool  # Enable use of devicetree imported from Linux kernel release
> > > > >
> > > > > I think we can just keep prompting for it now, to make the transition
> > > > > easier, before this option just goes away in time, hopefully.
> > > > >
> > > > > > Also, this doesn't seem to work for me. Before this series I get these
> > > > > > files when building firefly-rk3399:
> > > > > >
> > > > > > rk3399-eaidk-610.dtb            rk3399-khadas-edge-v.dtb
> > > > > > rk3399-orangepi.dtb        rk3399-rock-pi-4a.dtb
> > > > > > rk3399-evb.dtb                  rk3399-leez-p710.dtb
> > > > > > rk3399-pinebook-pro.dtb    rk3399-rock-pi-4c.dtb
> > > > > > rk3399-ficus.dtb                rk3399-nanopc-t4.dtb
> > > > > > rk3399-pinephone-pro.dtb   rk3399-rockpro64.dtb
> > > > > > rk3399-firefly.dtb              rk3399-nanopi-m4-2gb.dtb
> > > > > > rk3399pro-rock-pi-n10.dtb  rk3399-roc-pc.dtb
> > > > > > rk3399-gru-bob.dtb              rk3399-nanopi-m4b.dtb
> > > > > > rk3399-puma-haikou.dtb     rk3399-roc-pc-mezzanine.dtb
> > > > > > rk3399-gru-kevin.dtb            rk3399-nanopi-m4.dtb
> > > > > > rk3399-rock-4c-plus.dtb
> > > > > > rk3399-khadas-edge-captain.dtb  rk3399-nanopi-neo4.dtb    rk3399-rock-4se.dtb
> > > > > > rk3399-khadas-edge.dtb          rk3399-nanopi-r4s.dtb     rk3399-rock960.dtb
> > > > > >
> > > > > > Afterwards I get this:
> > > > > >
> > > > > > make[3]: *** No rule to make target
> > > > > > 'dts/arch/arm64/rk3399-firefly.dtb', needed by 'dtbs'.  Stop.
> > > > > >
> > > > > > So I set this manually for that one board:
> > > > > >
> > > > > > CONFIG_DEFAULT_DEVICE_TREE="rockchip/rk3399-firefly"
> > > > > >
> > > > > > and get:
> > > > > >
> > > > > > make[3]: *** No rule to make target
> > > > > > 'dts/arch/arm64/rockchip/rk3399-firefly.dtb', needed by 'dtbs'.  Stop.
> > > > > >
> > > > > > I am not sure how to fix this, nor how this can be made to build all
> > > > > > the DTs for rk3399, as it does today.
> > > > >
> > > > > Looking at the patch for amlogic boards, you need to make the link to
> > > > > devicetree-rebasing inside dts/...
> > > >
> > > > OK, let me give up on rk3399 for now...that doesn't seem to work even
> > > > with the link.
> > > >
> > > > Using odroid-c2 with -next I see:
> > > >
> > > > $ ls /tmp/b/odroid-c2/arch/arm/dts/
> > > > meson-a1-ad401.dtb                 meson-g12b-odroid-n2l.dtb
> > > >     meson-gxl-s905x-libretech-cc.dtb
> > > > meson-axg-jethome-jethub-j100.dtb  meson-g12b-odroid-n2-plus.dtb
> > > >     meson-gxl-s905x-libretech-cc-v2.dtb
> > > > meson-axg-s400.dtb                 meson-g12b-radxa-zero2.dtb
> > > >     meson-gxl-s905x-p212.dtb
> > > > meson-g12a-radxa-zero.dtb          meson-gxbb-kii-pro.dtb
> > > >     meson-gxm-gt1-ultimate.dtb
> > > > meson-g12a-sei510.dtb              meson-gxbb-nanopi-k2.dtb
> > > >     meson-gxm-khadas-vim2.dtb
> > > > meson-g12a-u200.dtb                meson-gxbb-odroidc2.dtb
> > > >     meson-gxm-s912-libretech-pc.dtb
> > > > meson-g12b-a311d-bananapi-m2s.dtb  meson-gxbb-p200.dtb
> > > >     meson-gxm-wetek-core2.dtb
> > > > meson-g12b-a311d-khadas-vim3.dtb   meson-gxbb-p201.dtb
> > > >     meson-sm1-bananapi-m2-pro.dtb
> > > > meson-g12b-bananapi-cm4-cm4io.dtb  meson-gxbb-wetek-hub.dtb
> > > >     meson-sm1-bananapi-m5.dtb
> > > > meson-g12b-gsking-x.dtb            meson-gxbb-wetek-play2.dtb
> > > >     meson-sm1-khadas-vim3l.dtb
> > > > meson-g12b-gtking.dtb              meson-gxl-s805x-libretech-ac.dtb
> > > >     meson-sm1-odroid-c4.dtb
> > > > meson-g12b-gtking-pro.dtb          meson-gxl-s905d-libretech-pc.dtb
> > > >     meson-sm1-odroid-hc4.dtb
> > > > meson-g12b-odroid-go-ultra.dtb
> > > > meson-gxl-s905w-jethome-jethub-j80.dtb  meson-sm1-sei610.dtb
> > > > meson-g12b-odroid-n2.dtb           meson-gxl-s905x-khadas-vim.dtb
> > > > $
> > > > With this series (sort of, since I am really not sure how to
> > > > cherry-pick the commits from the PR) I see nothing:
> > > >
> > > > $ ls /tmp/b/odroid-c2/arch/arm/dts/
> > > > $
> > > >
> > > > This shows some of the files:
> > > >
> > > > $ find /tmp/b/odroid-c2/ -name "*.dtb"
> > > > /tmp/b/odroid-c2/dts/dt.dtb
> > > > /tmp/b/odroid-c2/dts/arch/arm64/amlogic/meson-gxbb-odroidc2.dtb
> > > > /tmp/b/odroid-c2/dts/arch/arm64/amlogic/meson-gxbb-nanopi-k2.dtb
> > > > /tmp/b/odroid-c2/dts/arch/arm64/amlogic/meson-gxbb-wetek-play2.dtb
> > > > /tmp/b/odroid-c2/dts/arch/arm64/amlogic/meson-gxbb-kii-pro.dtb
> > > > /tmp/b/odroid-c2/dts/arch/arm64/amlogic/meson-gxbb-p200.dtb
> > > > /tmp/b/odroid-c2/dts/arch/arm64/amlogic/meson-gxbb-p201.dtb
> > > > /tmp/b/odroid-c2/dts/arch/arm64/amlogic/meson-gxbb-wetek-hub.dtb
> > > > /tmp/b/odroid-c2/u-boot.dtb
> > > >
> > > > but where are the rest? Also, is it possible to put the output .dtb
> > > > files into the same directory? Otherwise we may have some pain with
> > > > binman.
> > >
> > > What do you mean by same directory? But maybe also, what's an example of
> > > a board you think might end up having problems? Converting that in a
> > > follow-up series is likely a good idea, to highlight and address these
> > > issues sooner rather than later.#
> >
> > Today the .dtb files go into arch/arm/dts - so it would be easier if
> > this series could do the same.
>
> The kbuild infrastructure keeps the dtb alongside dts files which is
> the preferred way too as otherwise it would be complicated to locate
> DT files for the users. Also, we have to move towards Linux DT
> directory structure and thereby the tools like binman have to be
> adjusted. I will do that when I get to migrating SoCs supporting
> binman.

OK, I want to stop here and rethink this. This is the path taken so
far, I believe:

1. We want to use devicetree files taken from Linux and
devicetree-rebasing provides these
2. We want to use 'git subtree' to avoid needing a script to do the
sync / create a commit
3. But this leaves us with a directory structure which doesn't match
U-Boot (no script to fix it up)
4. So we deal with that by skipping the build rules and using CONFIG
options to select what is built
5. So now we cannot build all the files for an SoC, just the ones that
are in the CONFIG options
6. Linux doesn't actually use devicetree-rebasing itself, so doesn't
have this problem

So this is heading in the wrong direction. Nor is it clear that this
would just be a temporary problem.

Possible options I see are:

a. Adjust U-Boot's dir structure to match Linux, first (but this might
be painful?)
b. Create a script to sync the files, so we can sync into a dir
structure that matches U-Boot
c. Add build rules to U-Boot's version of the devicetree-rebasing dir
(this seems to be supported)
d. Give up and just live with having boards (not SoCs) specify the
devicetree files they want to build

I would like to do this series properly, maintaining the SoC-specific
build rules, not removing what I see as an important feature. It
should not be that difficult to figure out and I am happy to help with
it.

>
> >
> > The problem I have described above applied to meson, so I believe it
> > is clear enough with that. I wasn't able to get rk3399 going, but I am
> > sure it would have the same problem.
> >
> > The fundamental question is (I believe) whether to:
> >
> > 1. Build only a single DT for a board
> > 2. Build all DTs for the SoC the board uses
> >
> > This series seems to head towards (1),
>
> v2 of this series had the Makefile rules [1] for meson gxbb SoC but..
>
> [1] https://patchwork.ozlabs.org/project/uboot/patch/20231222061208.3009970-8-sumit.garg@linaro.org/
>
> > which worries me. We are
> > currently mostly at (2).
>
> ..after discussion with Tom, the Makefile rules are already coming via
> Kconfig options like DEFAULT_DEVICE_TREE, OF_LIST etc. So having
> redundant rules in Makefile doesn't add any value, so I took them off
> in v3.

Yes, I see that you did that.

This seems to be a fundamental point of disagreement. I would like all
boards for an SoC to have mostly the same defconfig and just use a
devicetree for differences, at least in U-Boot proper. That is what
devicetree is for. In fact, I would like to see a lot more defaults in
U-Boot, so that defconfig files are just a few lines like [2] and
there is no board-specific C code not gated by a compatible string.

>
> However, I am very much in favour of having a generalized U-Boot
> image. This might become true in some cases like U-Boot acts as a
> second stage bootloader for a particular SoC which is a unified image
> where the prior stage passes the DT to it. The Qcom effort in this
> direction can be an example here.

Not relevant to the topic at hand, perhaps, but Qualcomm uses a
closed-source blob to jump to U-Boot and is certainly not an example
we should emulate. But yes, passing a DT to U-Boot proper can be
useful.

>I am not sure at this point how we
> can enable different U-Boot features since there are many board
> specific bits needed currently not covered by DT.

I certainly see many examples of that, but the majority of features
are covered. It was of course the same in Linux until someone put his
foot down.

>
> The other common method is to embed board DT in U-Boot image
> especially where U-Boot acts as a first stage bootloader. Once that's
> done I don't see how we can call that a generic U-Boot image.

If you mean OF_EMBED, then I don't think that is much used. It is just
for using a JTAG debugger and these days, it is barely useful for
that.

We do use fdtgrep to create a smaller FDT for SPL, though. In general,
it will be harder to create a general SPL for an SoC. But it is also
less beneficial, since SPL is small. Also, it is possible, as shown by
rockchip.

>
> BTW, as Tom said we can very well add those Makefile rules later on a
> use case basis if a particular SoC requires a truly generic U-Boot
> image and the rules don't come via Kconfig options.

We mostly have them already, so we should not remove them.

We are setting policy here. The policy should bias towards the
generic, not to make that hard. There are over 900 arm64 devicetree
files in Linux but only a few dozen SoCs and only one build. We should
not have 900 arm64 U-Boots, only a few dozen and perhaps one day in
the dim, distant future, if the tradeoffs make sense, one.

Regards,
Simon

[2] https://patchwork.ozlabs.org/project/uboot/patch/20210619081645.42660-2-mtwget@gmail.com/
Tom Rini Dec. 31, 2023, 8:39 p.m. UTC | #9 
On Sun, Dec 31, 2023 at 07:28:52AM -0700, Simon Glass wrote:
> Hi Sumit,
> 
> On Fri, Dec 29, 2023 at 8:30 AM Sumit Garg <sumit.garg@linaro.org> wrote:
> >
> > On Fri, 29 Dec 2023 at 01:18, Simon Glass <sjg@chromium.org> wrote:
> > >
> > > Hi Tom,
> > >
> > > On Thu, Dec 28, 2023 at 3:54 PM Tom Rini <trini@konsulko.com> wrote:
> > > >
> > > > On Thu, Dec 28, 2023 at 03:09:12PM +0000, Simon Glass wrote:
> > > > > Hi Tom, Sumit,
> > > > >
> > > > > On Thu, Dec 28, 2023 at 2:03 PM Tom Rini <trini@konsulko.com> wrote:
> > > > > >
> > > > > > On Thu, Dec 28, 2023 at 01:37:26PM +0000, Simon Glass wrote:
> > > > > > > Hi Sumit,
> > > > > > >
> > > > > > > On Thu, Dec 28, 2023 at 11:58 AM Sumit Garg <sumit.garg@linaro.org> wrote:
> > > > > > > >
> > > > > > > > Allow platform owners to mirror devicetree files from devitree-rebasing
> > > > > > > > directory into dts/arch/$(ARCH) (special case for dts/arch/arm64). Then
> > > > > > > > build then along with any *-u-boot.dtsi file present in arch/$(ARCH)/dts
> > > > > > > > directory. Also add a new Makefile for arm64.
> > > > > > > >
> > > > > > > > This will help easy migration for platforms which currently are compliant
> > > > > > > > with upstream Linux kernel devicetree files.
> > > > > > > >
> > > > > > > > Signed-off-by: Sumit Garg <sumit.garg@linaro.org>
> > > > > > > > ---
> > > > > > > >
> > > > > > > > Changes in v3:
> > > > > > > > --------------
> > > > > > > > - Minor commit message update
> > > > > > > >
> > > > > > > > Changes in v2:
> > > > > > > > --------------
> > > > > > > > - s/DEVICE_TREE_LOC/dt_dir/ and s/U-boot/U-Boot/
> > > > > > > >
> > > > > > > >  dts/Kconfig             | 11 +++++++++++
> > > > > > > >  dts/Makefile            | 17 ++++++++++++++---
> > > > > > > >  dts/arch/arm64/Makefile | 14 ++++++++++++++
> > > > > > > >  3 files changed, 39 insertions(+), 3 deletions(-)
> > > > > > > >  create mode 100644 dts/arch/arm64/Makefile
> > > > > > > >
> > > > > > > > diff --git a/dts/Kconfig b/dts/Kconfig
> > > > > > > > index 00c0aeff893..e58c1c6f2ab 100644
> > > > > > > > --- a/dts/Kconfig
> > > > > > > > +++ b/dts/Kconfig
> > > > > > > > @@ -85,6 +85,17 @@ config OF_LIVE
> > > > > > > >           enables a live tree which is available after relocation,
> > > > > > > >           and can be adjusted as needed.
> > > > > > > >
> > > > > > > > +config OF_UPSTREAM
> > > > > > > > +       bool "Enable use of devicetree imported from Linux kernel release"
> > > > > > > > +       help
> > > > > > > > +         Traditionally, U-Boot platforms used to have their custom devicetree
> > > > > > > > +         files or copy devicetree files from Linux kernel which are hard to
> > > > > > > > +         maintain and can usually get out-of-sync from Linux kernel. This
> > > > > > > > +         option enables platforms to migrate to devicetree-rebasing repo where
> > > > > > > > +         a regular sync will be maintained every major Linux kernel release
> > > > > > > > +         cycle. However, platforms can still have some custom u-boot specific
> > > > > > > > +         bits maintained as part of *-u-boot.dtsi files.
> > > > > > >
> > > > > > > My only other suggestion here is to mention that this should be set in
> > > > > > > Kconfig, for the SoC as a whole. So I believe that means that it
> > > > > > > should be hidden, with no string for the 'bool':
> > > > > > >
> > > > > > >       bool  # Enable use of devicetree imported from Linux kernel release
> > > > > >
> > > > > > I think we can just keep prompting for it now, to make the transition
> > > > > > easier, before this option just goes away in time, hopefully.
> > > > > >
> > > > > > > Also, this doesn't seem to work for me. Before this series I get these
> > > > > > > files when building firefly-rk3399:
> > > > > > >
> > > > > > > rk3399-eaidk-610.dtb            rk3399-khadas-edge-v.dtb
> > > > > > > rk3399-orangepi.dtb        rk3399-rock-pi-4a.dtb
> > > > > > > rk3399-evb.dtb                  rk3399-leez-p710.dtb
> > > > > > > rk3399-pinebook-pro.dtb    rk3399-rock-pi-4c.dtb
> > > > > > > rk3399-ficus.dtb                rk3399-nanopc-t4.dtb
> > > > > > > rk3399-pinephone-pro.dtb   rk3399-rockpro64.dtb
> > > > > > > rk3399-firefly.dtb              rk3399-nanopi-m4-2gb.dtb
> > > > > > > rk3399pro-rock-pi-n10.dtb  rk3399-roc-pc.dtb
> > > > > > > rk3399-gru-bob.dtb              rk3399-nanopi-m4b.dtb
> > > > > > > rk3399-puma-haikou.dtb     rk3399-roc-pc-mezzanine.dtb
> > > > > > > rk3399-gru-kevin.dtb            rk3399-nanopi-m4.dtb
> > > > > > > rk3399-rock-4c-plus.dtb
> > > > > > > rk3399-khadas-edge-captain.dtb  rk3399-nanopi-neo4.dtb    rk3399-rock-4se.dtb
> > > > > > > rk3399-khadas-edge.dtb          rk3399-nanopi-r4s.dtb     rk3399-rock960.dtb
> > > > > > >
> > > > > > > Afterwards I get this:
> > > > > > >
> > > > > > > make[3]: *** No rule to make target
> > > > > > > 'dts/arch/arm64/rk3399-firefly.dtb', needed by 'dtbs'.  Stop.
> > > > > > >
> > > > > > > So I set this manually for that one board:
> > > > > > >
> > > > > > > CONFIG_DEFAULT_DEVICE_TREE="rockchip/rk3399-firefly"
> > > > > > >
> > > > > > > and get:
> > > > > > >
> > > > > > > make[3]: *** No rule to make target
> > > > > > > 'dts/arch/arm64/rockchip/rk3399-firefly.dtb', needed by 'dtbs'.  Stop.
> > > > > > >
> > > > > > > I am not sure how to fix this, nor how this can be made to build all
> > > > > > > the DTs for rk3399, as it does today.
> > > > > >
> > > > > > Looking at the patch for amlogic boards, you need to make the link to
> > > > > > devicetree-rebasing inside dts/...
> > > > >
> > > > > OK, let me give up on rk3399 for now...that doesn't seem to work even
> > > > > with the link.
> > > > >
> > > > > Using odroid-c2 with -next I see:
> > > > >
> > > > > $ ls /tmp/b/odroid-c2/arch/arm/dts/
> > > > > meson-a1-ad401.dtb                 meson-g12b-odroid-n2l.dtb
> > > > >     meson-gxl-s905x-libretech-cc.dtb
> > > > > meson-axg-jethome-jethub-j100.dtb  meson-g12b-odroid-n2-plus.dtb
> > > > >     meson-gxl-s905x-libretech-cc-v2.dtb
> > > > > meson-axg-s400.dtb                 meson-g12b-radxa-zero2.dtb
> > > > >     meson-gxl-s905x-p212.dtb
> > > > > meson-g12a-radxa-zero.dtb          meson-gxbb-kii-pro.dtb
> > > > >     meson-gxm-gt1-ultimate.dtb
> > > > > meson-g12a-sei510.dtb              meson-gxbb-nanopi-k2.dtb
> > > > >     meson-gxm-khadas-vim2.dtb
> > > > > meson-g12a-u200.dtb                meson-gxbb-odroidc2.dtb
> > > > >     meson-gxm-s912-libretech-pc.dtb
> > > > > meson-g12b-a311d-bananapi-m2s.dtb  meson-gxbb-p200.dtb
> > > > >     meson-gxm-wetek-core2.dtb
> > > > > meson-g12b-a311d-khadas-vim3.dtb   meson-gxbb-p201.dtb
> > > > >     meson-sm1-bananapi-m2-pro.dtb
> > > > > meson-g12b-bananapi-cm4-cm4io.dtb  meson-gxbb-wetek-hub.dtb
> > > > >     meson-sm1-bananapi-m5.dtb
> > > > > meson-g12b-gsking-x.dtb            meson-gxbb-wetek-play2.dtb
> > > > >     meson-sm1-khadas-vim3l.dtb
> > > > > meson-g12b-gtking.dtb              meson-gxl-s805x-libretech-ac.dtb
> > > > >     meson-sm1-odroid-c4.dtb
> > > > > meson-g12b-gtking-pro.dtb          meson-gxl-s905d-libretech-pc.dtb
> > > > >     meson-sm1-odroid-hc4.dtb
> > > > > meson-g12b-odroid-go-ultra.dtb
> > > > > meson-gxl-s905w-jethome-jethub-j80.dtb  meson-sm1-sei610.dtb
> > > > > meson-g12b-odroid-n2.dtb           meson-gxl-s905x-khadas-vim.dtb
> > > > > $
> > > > > With this series (sort of, since I am really not sure how to
> > > > > cherry-pick the commits from the PR) I see nothing:
> > > > >
> > > > > $ ls /tmp/b/odroid-c2/arch/arm/dts/
> > > > > $
> > > > >
> > > > > This shows some of the files:
> > > > >
> > > > > $ find /tmp/b/odroid-c2/ -name "*.dtb"
> > > > > /tmp/b/odroid-c2/dts/dt.dtb
> > > > > /tmp/b/odroid-c2/dts/arch/arm64/amlogic/meson-gxbb-odroidc2.dtb
> > > > > /tmp/b/odroid-c2/dts/arch/arm64/amlogic/meson-gxbb-nanopi-k2.dtb
> > > > > /tmp/b/odroid-c2/dts/arch/arm64/amlogic/meson-gxbb-wetek-play2.dtb
> > > > > /tmp/b/odroid-c2/dts/arch/arm64/amlogic/meson-gxbb-kii-pro.dtb
> > > > > /tmp/b/odroid-c2/dts/arch/arm64/amlogic/meson-gxbb-p200.dtb
> > > > > /tmp/b/odroid-c2/dts/arch/arm64/amlogic/meson-gxbb-p201.dtb
> > > > > /tmp/b/odroid-c2/dts/arch/arm64/amlogic/meson-gxbb-wetek-hub.dtb
> > > > > /tmp/b/odroid-c2/u-boot.dtb
> > > > >
> > > > > but where are the rest? Also, is it possible to put the output .dtb
> > > > > files into the same directory? Otherwise we may have some pain with
> > > > > binman.
> > > >
> > > > What do you mean by same directory? But maybe also, what's an example of
> > > > a board you think might end up having problems? Converting that in a
> > > > follow-up series is likely a good idea, to highlight and address these
> > > > issues sooner rather than later.#
> > >
> > > Today the .dtb files go into arch/arm/dts - so it would be easier if
> > > this series could do the same.
> >
> > The kbuild infrastructure keeps the dtb alongside dts files which is
> > the preferred way too as otherwise it would be complicated to locate
> > DT files for the users. Also, we have to move towards Linux DT
> > directory structure and thereby the tools like binman have to be
> > adjusted. I will do that when I get to migrating SoCs supporting
> > binman.
> 
> OK, I want to stop here and rethink this. This is the path taken so
> far, I believe:
> 
> 1. We want to use devicetree files taken from Linux and
> devicetree-rebasing provides these

Yes.

> 2. We want to use 'git subtree' to avoid needing a script to do the
> sync / create a commit

No. We want to use 'git subtree' to avoid having to use git submodules.

> 3. But this leaves us with a directory structure which doesn't match
> U-Boot (no script to fix it up)

No. We intentionally abandon arch/*/dts because it's so full of
out of date files and never fully re-synced, only re-synced ad-hoc.

> 4. So we deal with that by skipping the build rules and using CONFIG
> options to select what is built
> 5. So now we cannot build all the files for an SoC, just the ones that
> are in the CONFIG options
> 6. Linux doesn't actually use devicetree-rebasing itself, so doesn't
> have this problem

No. devicetree-rebasing skips the Makefiles because they're part of the
kernel. We couldn't re-use them ourselves because we don't have the same
CONFIG names the kernel does. And Sumit has not replicated the logic we
have under arch/*/dts/Makefile today because I've asked him not to, and
we'll figure out what subsets of that logic make sense to add back in as
a second step not a first step.

> So this is heading in the wrong direction. Nor is it clear that this
> would just be a temporary problem.

A previous iteration of this series built all of the dtb files for the
SoC that Sumit has migrated with this series, but then dropped it.

[snip]
> I would like to do this series properly, maintaining the SoC-specific
> build rules, not removing what I see as an important feature. It
> should not be that difficult to figure out and I am happy to help with
> it.

The problem is that the rest of us do not understand the use case you're
describing where a dtb file that would be useful in a build is not
already in the list to build. The only one of those use cases I
understand thus far is the exynos4 (iirc) case you mentioned previously
where yes, really, one defconfig + appending board.dtb is fine, or fine
enough. It's not that far off of the SPL_LOAD_FIT case, but there we
know what to build already.

And I guess trying to tie things up, that's my puzzle. SPL_LOAD_FIT is
how I see the use case you talk about being solved, if a full U-Boot is
generic enough for N boards, SPL_LOAD_FIT does the right thing (in this
non-bloblist DTB, non-reusing-OS-inntended DTB world). I really don't
knnow how many modern SoCs can take a literal concatenated DTB and even
in those cases I don't get why that's the win we want now? 1 build to N
binaries?

But even then, I don't object to adding those rules to the Makefiles. If
it works it works. I object to adding them when they don't work.

> > > The fundamental question is (I believe) whether to:
> > >
> > > 1. Build only a single DT for a board
> > > 2. Build all DTs for the SoC the board uses
> > >
> > > This series seems to head towards (1),
> >
> > v2 of this series had the Makefile rules [1] for meson gxbb SoC but..
> >
> > [1] https://patchwork.ozlabs.org/project/uboot/patch/20231222061208.3009970-8-sumit.garg@linaro.org/
> >
> > > which worries me. We are
> > > currently mostly at (2).
> >
> > ..after discussion with Tom, the Makefile rules are already coming via
> > Kconfig options like DEFAULT_DEVICE_TREE, OF_LIST etc. So having
> > redundant rules in Makefile doesn't add any value, so I took them off
> > in v3.
> 
> Yes, I see that you did that.
> 
> This seems to be a fundamental point of disagreement. I would like all
> boards for an SoC to have mostly the same defconfig and just use a
> devicetree for differences, at least in U-Boot proper. That is what
> devicetree is for. In fact, I would like to see a lot more defaults in
> U-Boot, so that defconfig files are just a few lines like [2] and
> there is no board-specific C code not gated by a compatible string.

That's a nice goal to aim for. Sumit's work doesn't stop that being
aimed for, and by making it easy to keep our device trees modern, it
makes that easier, not harder.

Heck, it's something I've been working with the TI folks with for a few
years now, and this work will make things easier for them because the
dts files will get synced back, for all of the chips, sooner rather than
later, and we can push towards getting rid of most of the -u-boot.dtsi
work, and deal with the hard question of "where do r5 dts files go?".
But that will not get rid of board/siemens/iot2050/ because that's what
a custom hardware design needs and wants. Not "just pass the new DTB".
This is another of the valid use cases that we need to keep in mind and
design around, the explicit and intentional starting point of "don't
just run the EVM binary for custom hardware design production".

> > However, I am very much in favour of having a generalized U-Boot
> > image. This might become true in some cases like U-Boot acts as a
> > second stage bootloader for a particular SoC which is a unified image
> > where the prior stage passes the DT to it. The Qcom effort in this
> > direction can be an example here.
> 
> Not relevant to the topic at hand, perhaps, but Qualcomm uses a
> closed-source blob to jump to U-Boot and is certainly not an example
> we should emulate. But yes, passing a DT to U-Boot proper can be
> useful.

It's a very valid use case we need to continue to support. And to save
Mark from having to repeat himself, again, it's intentionally and not
changing, how the Apple M1/M2/etc platforms boot. I'm pretty sure the
fact that one can use U-Boot this way is part of how engineers get proof
of concept work done to show that if they had U-Boot available then they
could also support X/Y/Z easier. And maybe they'll be able to longer
term push internally to use bloblist to pass things along.

Heck, trying to not go too far off on a tangent, maybe the m1n1 loader
can implement both conventions, as both Linux Kernel[0] and Bloblist[1]
use x0 for device tree, but bloblist has x1 non-zero and Linux does not,
so both could be present here? Or is there some incompatibility I don't
see on quick skimming?
Mark Kettenis Jan. 1, 2024, 12:33 a.m. UTC | #10 
> Date: Sun, 31 Dec 2023 15:39:53 -0500
> From: Tom Rini <trini@konsulko.com>
> 
> On Sun, Dec 31, 2023 at 07:28:52AM -0700, Simon Glass wrote:
> > Hi Sumit,
> > 
> > On Fri, Dec 29, 2023 at 8:30 AM Sumit Garg <sumit.garg@linaro.org> wrote:
> > >
> > > On Fri, 29 Dec 2023 at 01:18, Simon Glass <sjg@chromium.org> wrote:
> > > >
> > > > Hi Tom,
> > > >
> > > > On Thu, Dec 28, 2023 at 3:54 PM Tom Rini <trini@konsulko.com> wrote:
> > > > >
> > > > > On Thu, Dec 28, 2023 at 03:09:12PM +0000, Simon Glass wrote:
> > > > > > Hi Tom, Sumit,
> > > > > >
> > > > > > On Thu, Dec 28, 2023 at 2:03 PM Tom Rini <trini@konsulko.com> wrote:
> > > > > > >
> > > > > > > On Thu, Dec 28, 2023 at 01:37:26PM +0000, Simon Glass wrote:
> > > > > > > > Hi Sumit,
> > > > > > > >
> > > > > > > > On Thu, Dec 28, 2023 at 11:58 AM Sumit Garg <sumit.garg@linaro.org> wrote:
> > > > > > > > >
> > > > > > > > > Allow platform owners to mirror devicetree files from devitree-rebasing
> > > > > > > > > directory into dts/arch/$(ARCH) (special case for dts/arch/arm64). Then
> > > > > > > > > build then along with any *-u-boot.dtsi file present in arch/$(ARCH)/dts
> > > > > > > > > directory. Also add a new Makefile for arm64.
> > > > > > > > >
> > > > > > > > > This will help easy migration for platforms which currently are compliant
> > > > > > > > > with upstream Linux kernel devicetree files.
> > > > > > > > >
> > > > > > > > > Signed-off-by: Sumit Garg <sumit.garg@linaro.org>
> > > > > > > > > ---
> > > > > > > > >
> > > > > > > > > Changes in v3:
> > > > > > > > > --------------
> > > > > > > > > - Minor commit message update
> > > > > > > > >
> > > > > > > > > Changes in v2:
> > > > > > > > > --------------
> > > > > > > > > - s/DEVICE_TREE_LOC/dt_dir/ and s/U-boot/U-Boot/
> > > > > > > > >
> > > > > > > > >  dts/Kconfig             | 11 +++++++++++
> > > > > > > > >  dts/Makefile            | 17 ++++++++++++++---
> > > > > > > > >  dts/arch/arm64/Makefile | 14 ++++++++++++++
> > > > > > > > >  3 files changed, 39 insertions(+), 3 deletions(-)
> > > > > > > > >  create mode 100644 dts/arch/arm64/Makefile
> > > > > > > > >
> > > > > > > > > diff --git a/dts/Kconfig b/dts/Kconfig
> > > > > > > > > index 00c0aeff893..e58c1c6f2ab 100644
> > > > > > > > > --- a/dts/Kconfig
> > > > > > > > > +++ b/dts/Kconfig
> > > > > > > > > @@ -85,6 +85,17 @@ config OF_LIVE
> > > > > > > > >           enables a live tree which is available after relocation,
> > > > > > > > >           and can be adjusted as needed.
> > > > > > > > >
> > > > > > > > > +config OF_UPSTREAM
> > > > > > > > > +       bool "Enable use of devicetree imported from Linux kernel release"
> > > > > > > > > +       help
> > > > > > > > > +         Traditionally, U-Boot platforms used to have their custom devicetree
> > > > > > > > > +         files or copy devicetree files from Linux kernel which are hard to
> > > > > > > > > +         maintain and can usually get out-of-sync from Linux kernel. This
> > > > > > > > > +         option enables platforms to migrate to devicetree-rebasing repo where
> > > > > > > > > +         a regular sync will be maintained every major Linux kernel release
> > > > > > > > > +         cycle. However, platforms can still have some custom u-boot specific
> > > > > > > > > +         bits maintained as part of *-u-boot.dtsi files.
> > > > > > > >
> > > > > > > > My only other suggestion here is to mention that this should be set in
> > > > > > > > Kconfig, for the SoC as a whole. So I believe that means that it
> > > > > > > > should be hidden, with no string for the 'bool':
> > > > > > > >
> > > > > > > >       bool  # Enable use of devicetree imported from Linux kernel release
> > > > > > >
> > > > > > > I think we can just keep prompting for it now, to make the transition
> > > > > > > easier, before this option just goes away in time, hopefully.
> > > > > > >
> > > > > > > > Also, this doesn't seem to work for me. Before this series I get these
> > > > > > > > files when building firefly-rk3399:
> > > > > > > >
> > > > > > > > rk3399-eaidk-610.dtb            rk3399-khadas-edge-v.dtb
> > > > > > > > rk3399-orangepi.dtb        rk3399-rock-pi-4a.dtb
> > > > > > > > rk3399-evb.dtb                  rk3399-leez-p710.dtb
> > > > > > > > rk3399-pinebook-pro.dtb    rk3399-rock-pi-4c.dtb
> > > > > > > > rk3399-ficus.dtb                rk3399-nanopc-t4.dtb
> > > > > > > > rk3399-pinephone-pro.dtb   rk3399-rockpro64.dtb
> > > > > > > > rk3399-firefly.dtb              rk3399-nanopi-m4-2gb.dtb
> > > > > > > > rk3399pro-rock-pi-n10.dtb  rk3399-roc-pc.dtb
> > > > > > > > rk3399-gru-bob.dtb              rk3399-nanopi-m4b.dtb
> > > > > > > > rk3399-puma-haikou.dtb     rk3399-roc-pc-mezzanine.dtb
> > > > > > > > rk3399-gru-kevin.dtb            rk3399-nanopi-m4.dtb
> > > > > > > > rk3399-rock-4c-plus.dtb
> > > > > > > > rk3399-khadas-edge-captain.dtb  rk3399-nanopi-neo4.dtb    rk3399-rock-4se.dtb
> > > > > > > > rk3399-khadas-edge.dtb          rk3399-nanopi-r4s.dtb     rk3399-rock960.dtb
> > > > > > > >
> > > > > > > > Afterwards I get this:
> > > > > > > >
> > > > > > > > make[3]: *** No rule to make target
> > > > > > > > 'dts/arch/arm64/rk3399-firefly.dtb', needed by 'dtbs'.  Stop.
> > > > > > > >
> > > > > > > > So I set this manually for that one board:
> > > > > > > >
> > > > > > > > CONFIG_DEFAULT_DEVICE_TREE="rockchip/rk3399-firefly"
> > > > > > > >
> > > > > > > > and get:
> > > > > > > >
> > > > > > > > make[3]: *** No rule to make target
> > > > > > > > 'dts/arch/arm64/rockchip/rk3399-firefly.dtb', needed by 'dtbs'.  Stop.
> > > > > > > >
> > > > > > > > I am not sure how to fix this, nor how this can be made to build all
> > > > > > > > the DTs for rk3399, as it does today.
> > > > > > >
> > > > > > > Looking at the patch for amlogic boards, you need to make the link to
> > > > > > > devicetree-rebasing inside dts/...
> > > > > >
> > > > > > OK, let me give up on rk3399 for now...that doesn't seem to work even
> > > > > > with the link.
> > > > > >
> > > > > > Using odroid-c2 with -next I see:
> > > > > >
> > > > > > $ ls /tmp/b/odroid-c2/arch/arm/dts/
> > > > > > meson-a1-ad401.dtb                 meson-g12b-odroid-n2l.dtb
> > > > > >     meson-gxl-s905x-libretech-cc.dtb
> > > > > > meson-axg-jethome-jethub-j100.dtb  meson-g12b-odroid-n2-plus.dtb
> > > > > >     meson-gxl-s905x-libretech-cc-v2.dtb
> > > > > > meson-axg-s400.dtb                 meson-g12b-radxa-zero2.dtb
> > > > > >     meson-gxl-s905x-p212.dtb
> > > > > > meson-g12a-radxa-zero.dtb          meson-gxbb-kii-pro.dtb
> > > > > >     meson-gxm-gt1-ultimate.dtb
> > > > > > meson-g12a-sei510.dtb              meson-gxbb-nanopi-k2.dtb
> > > > > >     meson-gxm-khadas-vim2.dtb
> > > > > > meson-g12a-u200.dtb                meson-gxbb-odroidc2.dtb
> > > > > >     meson-gxm-s912-libretech-pc.dtb
> > > > > > meson-g12b-a311d-bananapi-m2s.dtb  meson-gxbb-p200.dtb
> > > > > >     meson-gxm-wetek-core2.dtb
> > > > > > meson-g12b-a311d-khadas-vim3.dtb   meson-gxbb-p201.dtb
> > > > > >     meson-sm1-bananapi-m2-pro.dtb
> > > > > > meson-g12b-bananapi-cm4-cm4io.dtb  meson-gxbb-wetek-hub.dtb
> > > > > >     meson-sm1-bananapi-m5.dtb
> > > > > > meson-g12b-gsking-x.dtb            meson-gxbb-wetek-play2.dtb
> > > > > >     meson-sm1-khadas-vim3l.dtb
> > > > > > meson-g12b-gtking.dtb              meson-gxl-s805x-libretech-ac.dtb
> > > > > >     meson-sm1-odroid-c4.dtb
> > > > > > meson-g12b-gtking-pro.dtb          meson-gxl-s905d-libretech-pc.dtb
> > > > > >     meson-sm1-odroid-hc4.dtb
> > > > > > meson-g12b-odroid-go-ultra.dtb
> > > > > > meson-gxl-s905w-jethome-jethub-j80.dtb  meson-sm1-sei610.dtb
> > > > > > meson-g12b-odroid-n2.dtb           meson-gxl-s905x-khadas-vim.dtb
> > > > > > $
> > > > > > With this series (sort of, since I am really not sure how to
> > > > > > cherry-pick the commits from the PR) I see nothing:
> > > > > >
> > > > > > $ ls /tmp/b/odroid-c2/arch/arm/dts/
> > > > > > $
> > > > > >
> > > > > > This shows some of the files:
> > > > > >
> > > > > > $ find /tmp/b/odroid-c2/ -name "*.dtb"
> > > > > > /tmp/b/odroid-c2/dts/dt.dtb
> > > > > > /tmp/b/odroid-c2/dts/arch/arm64/amlogic/meson-gxbb-odroidc2.dtb
> > > > > > /tmp/b/odroid-c2/dts/arch/arm64/amlogic/meson-gxbb-nanopi-k2.dtb
> > > > > > /tmp/b/odroid-c2/dts/arch/arm64/amlogic/meson-gxbb-wetek-play2.dtb
> > > > > > /tmp/b/odroid-c2/dts/arch/arm64/amlogic/meson-gxbb-kii-pro.dtb
> > > > > > /tmp/b/odroid-c2/dts/arch/arm64/amlogic/meson-gxbb-p200.dtb
> > > > > > /tmp/b/odroid-c2/dts/arch/arm64/amlogic/meson-gxbb-p201.dtb
> > > > > > /tmp/b/odroid-c2/dts/arch/arm64/amlogic/meson-gxbb-wetek-hub.dtb
> > > > > > /tmp/b/odroid-c2/u-boot.dtb
> > > > > >
> > > > > > but where are the rest? Also, is it possible to put the output .dtb
> > > > > > files into the same directory? Otherwise we may have some pain with
> > > > > > binman.
> > > > >
> > > > > What do you mean by same directory? But maybe also, what's an example of
> > > > > a board you think might end up having problems? Converting that in a
> > > > > follow-up series is likely a good idea, to highlight and address these
> > > > > issues sooner rather than later.#
> > > >
> > > > Today the .dtb files go into arch/arm/dts - so it would be easier if
> > > > this series could do the same.
> > >
> > > The kbuild infrastructure keeps the dtb alongside dts files which is
> > > the preferred way too as otherwise it would be complicated to locate
> > > DT files for the users. Also, we have to move towards Linux DT
> > > directory structure and thereby the tools like binman have to be
> > > adjusted. I will do that when I get to migrating SoCs supporting
> > > binman.
> > 
> > OK, I want to stop here and rethink this. This is the path taken so
> > far, I believe:
> > 
> > 1. We want to use devicetree files taken from Linux and
> > devicetree-rebasing provides these
> 
> Yes.
> 
> > 2. We want to use 'git subtree' to avoid needing a script to do the
> > sync / create a commit
> 
> No. We want to use 'git subtree' to avoid having to use git submodules.
> 
> > 3. But this leaves us with a directory structure which doesn't match
> > U-Boot (no script to fix it up)
> 
> No. We intentionally abandon arch/*/dts because it's so full of
> out of date files and never fully re-synced, only re-synced ad-hoc.
> 
> > 4. So we deal with that by skipping the build rules and using CONFIG
> > options to select what is built
> > 5. So now we cannot build all the files for an SoC, just the ones that
> > are in the CONFIG options
> > 6. Linux doesn't actually use devicetree-rebasing itself, so doesn't
> > have this problem
> 
> No. devicetree-rebasing skips the Makefiles because they're part of the
> kernel. We couldn't re-use them ourselves because we don't have the same
> CONFIG names the kernel does. And Sumit has not replicated the logic we
> have under arch/*/dts/Makefile today because I've asked him not to, and
> we'll figure out what subsets of that logic make sense to add back in as
> a second step not a first step.
> 
> > So this is heading in the wrong direction. Nor is it clear that this
> > would just be a temporary problem.
> 
> A previous iteration of this series built all of the dtb files for the
> SoC that Sumit has migrated with this series, but then dropped it.
> 
> [snip]
> > I would like to do this series properly, maintaining the SoC-specific
> > build rules, not removing what I see as an important feature. It
> > should not be that difficult to figure out and I am happy to help with
> > it.
> 
> The problem is that the rest of us do not understand the use case you're
> describing where a dtb file that would be useful in a build is not
> already in the list to build. The only one of those use cases I
> understand thus far is the exynos4 (iirc) case you mentioned previously
> where yes, really, one defconfig + appending board.dtb is fine, or fine
> enough. It's not that far off of the SPL_LOAD_FIT case, but there we
> know what to build already.
> 
> And I guess trying to tie things up, that's my puzzle. SPL_LOAD_FIT is
> how I see the use case you talk about being solved, if a full U-Boot is
> generic enough for N boards, SPL_LOAD_FIT does the right thing (in this
> non-bloblist DTB, non-reusing-OS-inntended DTB world). I really don't
> knnow how many modern SoCs can take a literal concatenated DTB and even
> in those cases I don't get why that's the win we want now? 1 build to N
> binaries?
> 
> But even then, I don't object to adding those rules to the Makefiles. If
> it works it works. I object to adding them when they don't work.
> 
> > > > The fundamental question is (I believe) whether to:
> > > >
> > > > 1. Build only a single DT for a board
> > > > 2. Build all DTs for the SoC the board uses
> > > >
> > > > This series seems to head towards (1),
> > >
> > > v2 of this series had the Makefile rules [1] for meson gxbb SoC but..
> > >
> > > [1] https://patchwork.ozlabs.org/project/uboot/patch/20231222061208.3009970-8-sumit.garg@linaro.org/
> > >
> > > > which worries me. We are
> > > > currently mostly at (2).
> > >
> > > ..after discussion with Tom, the Makefile rules are already coming via
> > > Kconfig options like DEFAULT_DEVICE_TREE, OF_LIST etc. So having
> > > redundant rules in Makefile doesn't add any value, so I took them off
> > > in v3.
> > 
> > Yes, I see that you did that.
> > 
> > This seems to be a fundamental point of disagreement. I would like all
> > boards for an SoC to have mostly the same defconfig and just use a
> > devicetree for differences, at least in U-Boot proper. That is what
> > devicetree is for. In fact, I would like to see a lot more defaults in
> > U-Boot, so that defconfig files are just a few lines like [2] and
> > there is no board-specific C code not gated by a compatible string.
> 
> That's a nice goal to aim for. Sumit's work doesn't stop that being
> aimed for, and by making it easy to keep our device trees modern, it
> makes that easier, not harder.
> 
> Heck, it's something I've been working with the TI folks with for a few
> years now, and this work will make things easier for them because the
> dts files will get synced back, for all of the chips, sooner rather than
> later, and we can push towards getting rid of most of the -u-boot.dtsi
> work, and deal with the hard question of "where do r5 dts files go?".
> But that will not get rid of board/siemens/iot2050/ because that's what
> a custom hardware design needs and wants. Not "just pass the new DTB".
> This is another of the valid use cases that we need to keep in mind and
> design around, the explicit and intentional starting point of "don't
> just run the EVM binary for custom hardware design production".
> 
> > > However, I am very much in favour of having a generalized U-Boot
> > > image. This might become true in some cases like U-Boot acts as a
> > > second stage bootloader for a particular SoC which is a unified image
> > > where the prior stage passes the DT to it. The Qcom effort in this
> > > direction can be an example here.
> > 
> > Not relevant to the topic at hand, perhaps, but Qualcomm uses a
> > closed-source blob to jump to U-Boot and is certainly not an example
> > we should emulate. But yes, passing a DT to U-Boot proper can be
> > useful.
> 
> It's a very valid use case we need to continue to support. And to save
> Mark from having to repeat himself, again, it's intentionally and not
> changing, how the Apple M1/M2/etc platforms boot. I'm pretty sure the
> fact that one can use U-Boot this way is part of how engineers get proof
> of concept work done to show that if they had U-Boot available then they
> could also support X/Y/Z easier. And maybe they'll be able to longer
> term push internally to use bloblist to pass things along.
> 
> Heck, trying to not go too far off on a tangent, maybe the m1n1 loader
> can implement both conventions, as both Linux Kernel[0] and Bloblist[1]
> use x0 for device tree, but bloblist has x1 non-zero and Linux does not,
> so both could be present here? Or is there some incompatibility I don't
> see on quick skimming?

Right.  Some time ago I suggested Simon to lobby the Linux kernel
folks to change the arm64 Linux kernel entry convention to state that
x1 can be non-zero in which case it points at a bloblist.  If that
happened I'd probably do the work to make m1n1 pass a bloblist.  And
it would probably make the folks who want to directly boot a Linux
kernel from TF-A (without going through U-Boot) happy as well.

Cheers,

Mark
Simon Glass Jan. 1, 2024, 10:32 p.m. UTC | #11 
Hi Mark, Tom,

On Sun, Dec 31, 2023 at 5:33 PM Mark Kettenis <mark.kettenis@xs4all.nl> wrote:
>
> > Date: Sun, 31 Dec 2023 15:39:53 -0500
> > From: Tom Rini <trini@konsulko.com>
> >
> > On Sun, Dec 31, 2023 at 07:28:52AM -0700, Simon Glass wrote:
> > > Hi Sumit,
> > >
> > > On Fri, Dec 29, 2023 at 8:30 AM Sumit Garg <sumit.garg@linaro.org> wrote:
> > > >
> > > > On Fri, 29 Dec 2023 at 01:18, Simon Glass <sjg@chromium.org> wrote:
> > > > >
> > > > > Hi Tom,
> > > > >
> > > > > On Thu, Dec 28, 2023 at 3:54 PM Tom Rini <trini@konsulko.com> wrote:
> > > > > >
> > > > > > On Thu, Dec 28, 2023 at 03:09:12PM +0000, Simon Glass wrote:
> > > > > > > Hi Tom, Sumit,
> > > > > > >
> > > > > > > On Thu, Dec 28, 2023 at 2:03 PM Tom Rini <trini@konsulko.com> wrote:
> > > > > > > >
> > > > > > > > On Thu, Dec 28, 2023 at 01:37:26PM +0000, Simon Glass wrote:
> > > > > > > > > Hi Sumit,
> > > > > > > > >
> > > > > > > > > On Thu, Dec 28, 2023 at 11:58 AM Sumit Garg <sumit.garg@linaro.org> wrote:
> > > > > > > > > >
> > > > > > > > > > Allow platform owners to mirror devicetree files from devitree-rebasing
> > > > > > > > > > directory into dts/arch/$(ARCH) (special case for dts/arch/arm64). Then
> > > > > > > > > > build then along with any *-u-boot.dtsi file present in arch/$(ARCH)/dts
> > > > > > > > > > directory. Also add a new Makefile for arm64.
> > > > > > > > > >
> > > > > > > > > > This will help easy migration for platforms which currently are compliant
> > > > > > > > > > with upstream Linux kernel devicetree files.
> > > > > > > > > >
> > > > > > > > > > Signed-off-by: Sumit Garg <sumit.garg@linaro.org>
> > > > > > > > > > ---
> > > > > > > > > >
> > > > > > > > > > Changes in v3:
> > > > > > > > > > --------------
> > > > > > > > > > - Minor commit message update
> > > > > > > > > >
> > > > > > > > > > Changes in v2:
> > > > > > > > > > --------------
> > > > > > > > > > - s/DEVICE_TREE_LOC/dt_dir/ and s/U-boot/U-Boot/
> > > > > > > > > >
> > > > > > > > > >  dts/Kconfig             | 11 +++++++++++
> > > > > > > > > >  dts/Makefile            | 17 ++++++++++++++---
> > > > > > > > > >  dts/arch/arm64/Makefile | 14 ++++++++++++++
> > > > > > > > > >  3 files changed, 39 insertions(+), 3 deletions(-)
> > > > > > > > > >  create mode 100644 dts/arch/arm64/Makefile
> > > > > > > > > >
> > > > > > > > > > diff --git a/dts/Kconfig b/dts/Kconfig
> > > > > > > > > > index 00c0aeff893..e58c1c6f2ab 100644
> > > > > > > > > > --- a/dts/Kconfig
> > > > > > > > > > +++ b/dts/Kconfig
> > > > > > > > > > @@ -85,6 +85,17 @@ config OF_LIVE
> > > > > > > > > >           enables a live tree which is available after relocation,
> > > > > > > > > >           and can be adjusted as needed.
> > > > > > > > > >
> > > > > > > > > > +config OF_UPSTREAM
> > > > > > > > > > +       bool "Enable use of devicetree imported from Linux kernel release"
> > > > > > > > > > +       help
> > > > > > > > > > +         Traditionally, U-Boot platforms used to have their custom devicetree
> > > > > > > > > > +         files or copy devicetree files from Linux kernel which are hard to
> > > > > > > > > > +         maintain and can usually get out-of-sync from Linux kernel. This
> > > > > > > > > > +         option enables platforms to migrate to devicetree-rebasing repo where
> > > > > > > > > > +         a regular sync will be maintained every major Linux kernel release
> > > > > > > > > > +         cycle. However, platforms can still have some custom u-boot specific
> > > > > > > > > > +         bits maintained as part of *-u-boot.dtsi files.
> > > > > > > > >
> > > > > > > > > My only other suggestion here is to mention that this should be set in
> > > > > > > > > Kconfig, for the SoC as a whole. So I believe that means that it
> > > > > > > > > should be hidden, with no string for the 'bool':
> > > > > > > > >
> > > > > > > > >       bool  # Enable use of devicetree imported from Linux kernel release
> > > > > > > >
> > > > > > > > I think we can just keep prompting for it now, to make the transition
> > > > > > > > easier, before this option just goes away in time, hopefully.
> > > > > > > >
> > > > > > > > > Also, this doesn't seem to work for me. Before this series I get these
> > > > > > > > > files when building firefly-rk3399:
> > > > > > > > >
> > > > > > > > > rk3399-eaidk-610.dtb            rk3399-khadas-edge-v.dtb
> > > > > > > > > rk3399-orangepi.dtb        rk3399-rock-pi-4a.dtb
> > > > > > > > > rk3399-evb.dtb                  rk3399-leez-p710.dtb
> > > > > > > > > rk3399-pinebook-pro.dtb    rk3399-rock-pi-4c.dtb
> > > > > > > > > rk3399-ficus.dtb                rk3399-nanopc-t4.dtb
> > > > > > > > > rk3399-pinephone-pro.dtb   rk3399-rockpro64.dtb
> > > > > > > > > rk3399-firefly.dtb              rk3399-nanopi-m4-2gb.dtb
> > > > > > > > > rk3399pro-rock-pi-n10.dtb  rk3399-roc-pc.dtb
> > > > > > > > > rk3399-gru-bob.dtb              rk3399-nanopi-m4b.dtb
> > > > > > > > > rk3399-puma-haikou.dtb     rk3399-roc-pc-mezzanine.dtb
> > > > > > > > > rk3399-gru-kevin.dtb            rk3399-nanopi-m4.dtb
> > > > > > > > > rk3399-rock-4c-plus.dtb
> > > > > > > > > rk3399-khadas-edge-captain.dtb  rk3399-nanopi-neo4.dtb    rk3399-rock-4se.dtb
> > > > > > > > > rk3399-khadas-edge.dtb          rk3399-nanopi-r4s.dtb     rk3399-rock960.dtb
> > > > > > > > >
> > > > > > > > > Afterwards I get this:
> > > > > > > > >
> > > > > > > > > make[3]: *** No rule to make target
> > > > > > > > > 'dts/arch/arm64/rk3399-firefly.dtb', needed by 'dtbs'.  Stop.
> > > > > > > > >
> > > > > > > > > So I set this manually for that one board:
> > > > > > > > >
> > > > > > > > > CONFIG_DEFAULT_DEVICE_TREE="rockchip/rk3399-firefly"
> > > > > > > > >
> > > > > > > > > and get:
> > > > > > > > >
> > > > > > > > > make[3]: *** No rule to make target
> > > > > > > > > 'dts/arch/arm64/rockchip/rk3399-firefly.dtb', needed by 'dtbs'.  Stop.
> > > > > > > > >
> > > > > > > > > I am not sure how to fix this, nor how this can be made to build all
> > > > > > > > > the DTs for rk3399, as it does today.
> > > > > > > >
> > > > > > > > Looking at the patch for amlogic boards, you need to make the link to
> > > > > > > > devicetree-rebasing inside dts/...
> > > > > > >
> > > > > > > OK, let me give up on rk3399 for now...that doesn't seem to work even
> > > > > > > with the link.
> > > > > > >
> > > > > > > Using odroid-c2 with -next I see:
> > > > > > >
> > > > > > > $ ls /tmp/b/odroid-c2/arch/arm/dts/
> > > > > > > meson-a1-ad401.dtb                 meson-g12b-odroid-n2l.dtb
> > > > > > >     meson-gxl-s905x-libretech-cc.dtb
> > > > > > > meson-axg-jethome-jethub-j100.dtb  meson-g12b-odroid-n2-plus.dtb
> > > > > > >     meson-gxl-s905x-libretech-cc-v2.dtb
> > > > > > > meson-axg-s400.dtb                 meson-g12b-radxa-zero2.dtb
> > > > > > >     meson-gxl-s905x-p212.dtb
> > > > > > > meson-g12a-radxa-zero.dtb          meson-gxbb-kii-pro.dtb
> > > > > > >     meson-gxm-gt1-ultimate.dtb
> > > > > > > meson-g12a-sei510.dtb              meson-gxbb-nanopi-k2.dtb
> > > > > > >     meson-gxm-khadas-vim2.dtb
> > > > > > > meson-g12a-u200.dtb                meson-gxbb-odroidc2.dtb
> > > > > > >     meson-gxm-s912-libretech-pc.dtb
> > > > > > > meson-g12b-a311d-bananapi-m2s.dtb  meson-gxbb-p200.dtb
> > > > > > >     meson-gxm-wetek-core2.dtb
> > > > > > > meson-g12b-a311d-khadas-vim3.dtb   meson-gxbb-p201.dtb
> > > > > > >     meson-sm1-bananapi-m2-pro.dtb
> > > > > > > meson-g12b-bananapi-cm4-cm4io.dtb  meson-gxbb-wetek-hub.dtb
> > > > > > >     meson-sm1-bananapi-m5.dtb
> > > > > > > meson-g12b-gsking-x.dtb            meson-gxbb-wetek-play2.dtb
> > > > > > >     meson-sm1-khadas-vim3l.dtb
> > > > > > > meson-g12b-gtking.dtb              meson-gxl-s805x-libretech-ac.dtb
> > > > > > >     meson-sm1-odroid-c4.dtb
> > > > > > > meson-g12b-gtking-pro.dtb          meson-gxl-s905d-libretech-pc.dtb
> > > > > > >     meson-sm1-odroid-hc4.dtb
> > > > > > > meson-g12b-odroid-go-ultra.dtb
> > > > > > > meson-gxl-s905w-jethome-jethub-j80.dtb  meson-sm1-sei610.dtb
> > > > > > > meson-g12b-odroid-n2.dtb           meson-gxl-s905x-khadas-vim.dtb
> > > > > > > $
> > > > > > > With this series (sort of, since I am really not sure how to
> > > > > > > cherry-pick the commits from the PR) I see nothing:
> > > > > > >
> > > > > > > $ ls /tmp/b/odroid-c2/arch/arm/dts/
> > > > > > > $
> > > > > > >
> > > > > > > This shows some of the files:
> > > > > > >
> > > > > > > $ find /tmp/b/odroid-c2/ -name "*.dtb"
> > > > > > > /tmp/b/odroid-c2/dts/dt.dtb
> > > > > > > /tmp/b/odroid-c2/dts/arch/arm64/amlogic/meson-gxbb-odroidc2.dtb
> > > > > > > /tmp/b/odroid-c2/dts/arch/arm64/amlogic/meson-gxbb-nanopi-k2.dtb
> > > > > > > /tmp/b/odroid-c2/dts/arch/arm64/amlogic/meson-gxbb-wetek-play2.dtb
> > > > > > > /tmp/b/odroid-c2/dts/arch/arm64/amlogic/meson-gxbb-kii-pro.dtb
> > > > > > > /tmp/b/odroid-c2/dts/arch/arm64/amlogic/meson-gxbb-p200.dtb
> > > > > > > /tmp/b/odroid-c2/dts/arch/arm64/amlogic/meson-gxbb-p201.dtb
> > > > > > > /tmp/b/odroid-c2/dts/arch/arm64/amlogic/meson-gxbb-wetek-hub.dtb
> > > > > > > /tmp/b/odroid-c2/u-boot.dtb
> > > > > > >
> > > > > > > but where are the rest? Also, is it possible to put the output .dtb
> > > > > > > files into the same directory? Otherwise we may have some pain with
> > > > > > > binman.
> > > > > >
> > > > > > What do you mean by same directory? But maybe also, what's an example of
> > > > > > a board you think might end up having problems? Converting that in a
> > > > > > follow-up series is likely a good idea, to highlight and address these
> > > > > > issues sooner rather than later.#
> > > > >
> > > > > Today the .dtb files go into arch/arm/dts - so it would be easier if
> > > > > this series could do the same.
> > > >
> > > > The kbuild infrastructure keeps the dtb alongside dts files which is
> > > > the preferred way too as otherwise it would be complicated to locate
> > > > DT files for the users. Also, we have to move towards Linux DT
> > > > directory structure and thereby the tools like binman have to be
> > > > adjusted. I will do that when I get to migrating SoCs supporting
> > > > binman.
> > >
> > > OK, I want to stop here and rethink this. This is the path taken so
> > > far, I believe:
> > >
> > > 1. We want to use devicetree files taken from Linux and
> > > devicetree-rebasing provides these
> >
> > Yes.
> >
> > > 2. We want to use 'git subtree' to avoid needing a script to do the
> > > sync / create a commit
> >
> > No. We want to use 'git subtree' to avoid having to use git submodules.

Well that is what I understood from Sumit, when I asked about a
script. I imagine a 100-line Python script could do the same as:

   git subtree pull --prefix devicetree-rebasing
git://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git
<release-tag> --squash

and it could also put the files in the right place for U-Boot.

> >
> > > 3. But this leaves us with a directory structure which doesn't match
> > > U-Boot (no script to fix it up)
> >
> > No. We intentionally abandon arch/*/dts because it's so full of
> > out of date files and never fully re-synced, only re-synced ad-hoc.

I mean that the dir structure doesn't match. I am not worried about
keeping arch/*/dts but I want the same structure somewhere else, e.g.
dtr/arch/*/dts

> >
> > > 4. So we deal with that by skipping the build rules and using CONFIG
> > > options to select what is built
> > > 5. So now we cannot build all the files for an SoC, just the ones that
> > > are in the CONFIG options
> > > 6. Linux doesn't actually use devicetree-rebasing itself, so doesn't
> > > have this problem
> >
> > No. devicetree-rebasing skips the Makefiles because they're part of the
> > kernel. We couldn't re-use them ourselves because we don't have the same
> > CONFIG names the kernel does. And Sumit has not replicated the logic we
> > have under arch/*/dts/Makefile today because I've asked him not to, and
> > we'll figure out what subsets of that logic make sense to add back in as
> > a second step not a first step.

Again, you are missing my point. I am not suggesting using Linux's
build rules, just explaining why Linux doesn't have the problem we
would be creating here.

> >
> > > So this is heading in the wrong direction. Nor is it clear that this
> > > would just be a temporary problem.
> >
> > A previous iteration of this series built all of the dtb files for the
> > SoC that Sumit has migrated with this series, but then dropped it.

Oh.

> >
> > [snip]
> > > I would like to do this series properly, maintaining the SoC-specific
> > > build rules, not removing what I see as an important feature. It
> > > should not be that difficult to figure out and I am happy to help with
> > > it.
> >
> > The problem is that the rest of us do not understand the use case you're
> > describing where a dtb file that would be useful in a build is not
> > already in the list to build. The only one of those use cases I
> > understand thus far is the exynos4 (iirc) case you mentioned previously
> > where yes, really, one defconfig + appending board.dtb is fine, or fine
> > enough. It's not that far off of the SPL_LOAD_FIT case, but there we
> > know what to build already.

Perhaps the problem is that the rest of you think of the build as all
happening in U-Boot, similar to the proposed 'make image.fit' that I
am trying to add to Linux.

But packaging can be (and often is) a separate step from building.
Linux has no packaging mechanism today...it just builds everything
(including all DTs) and stops.

We should be able to pick up whatever .dtb files we want and use them
in an image.

> >
> > And I guess trying to tie things up, that's my puzzle. SPL_LOAD_FIT is
> > how I see the use case you talk about being solved, if a full U-Boot is
> > generic enough for N boards, SPL_LOAD_FIT does the right thing (in this
> > non-bloblist DTB, non-reusing-OS-inntended DTB world). I really don't
> > knnow how many modern SoCs can take a literal concatenated DTB and even
> > in those cases I don't get why that's the win we want now? 1 build to N
> > binaries?

Yes SPL_LOAD_FIT is fine although in practice we will likely need SPL
to use the correct DT as well, so the DT will need to be determined in
TPL, perhaps.

But anyway, this works OK with rk3399, for example. We need to support
this use case.

Also, it is pretty easy. We just need to stick with the dir structure
we have today and copy our existing Makefiles into that dir. Or change
to the kernel dir structure and use that. Or do one, then the other.

> >
> > But even then, I don't object to adding those rules to the Makefiles. If
> > it works it works. I object to adding them when they don't work.

What do you mean by 'work'? With this series as is, it simply isn't
possible to add Makefile rules, as they are ignored. Am I missing
something?

> >
> > > > > The fundamental question is (I believe) whether to:
> > > > >
> > > > > 1. Build only a single DT for a board
> > > > > 2. Build all DTs for the SoC the board uses
> > > > >
> > > > > This series seems to head towards (1),
> > > >
> > > > v2 of this series had the Makefile rules [1] for meson gxbb SoC but..
> > > >
> > > > [1] https://patchwork.ozlabs.org/project/uboot/patch/20231222061208.3009970-8-sumit.garg@linaro.org/
> > > >
> > > > > which worries me. We are
> > > > > currently mostly at (2).
> > > >
> > > > ..after discussion with Tom, the Makefile rules are already coming via
> > > > Kconfig options like DEFAULT_DEVICE_TREE, OF_LIST etc. So having
> > > > redundant rules in Makefile doesn't add any value, so I took them off
> > > > in v3.
> > >
> > > Yes, I see that you did that.
> > >
> > > This seems to be a fundamental point of disagreement. I would like all
> > > boards for an SoC to have mostly the same defconfig and just use a
> > > devicetree for differences, at least in U-Boot proper. That is what
> > > devicetree is for. In fact, I would like to see a lot more defaults in
> > > U-Boot, so that defconfig files are just a few lines like [2] and
> > > there is no board-specific C code not gated by a compatible string.
> >
> > That's a nice goal to aim for. Sumit's work doesn't stop that being
> > aimed for, and by making it easy to keep our device trees modern, it
> > makes that easier, not harder.
> >
> > Heck, it's something I've been working with the TI folks with for a few
> > years now, and this work will make things easier for them because the
> > dts files will get synced back, for all of the chips, sooner rather than
> > later, and we can push towards getting rid of most of the -u-boot.dtsi
> > work, and deal with the hard question of "where do r5 dts files go?".
> > But that will not get rid of board/siemens/iot2050/ because that's what
> > a custom hardware design needs and wants. Not "just pass the new DTB".
> > This is another of the valid use cases that we need to keep in mind and
> > design around, the explicit and intentional starting point of "don't
> > just run the EVM binary for custom hardware design production".

OK.

> >
> > > > However, I am very much in favour of having a generalized U-Boot
> > > > image. This might become true in some cases like U-Boot acts as a
> > > > second stage bootloader for a particular SoC which is a unified image
> > > > where the prior stage passes the DT to it. The Qcom effort in this
> > > > direction can be an example here.
> > >
> > > Not relevant to the topic at hand, perhaps, but Qualcomm uses a
> > > closed-source blob to jump to U-Boot and is certainly not an example
> > > we should emulate. But yes, passing a DT to U-Boot proper can be
> > > useful.
> >
> > It's a very valid use case we need to continue to support. And to save
> > Mark from having to repeat himself, again, it's intentionally and not
> > changing, how the Apple M1/M2/etc platforms boot. I'm pretty sure the
> > fact that one can use U-Boot this way is part of how engineers get proof
> > of concept work done to show that if they had U-Boot available then they
> > could also support X/Y/Z easier. And maybe they'll be able to longer
> > term push internally to use bloblist to pass things along.
> >
> > Heck, trying to not go too far off on a tangent, maybe the m1n1 loader
> > can implement both conventions, as both Linux Kernel[0] and Bloblist[1]
> > use x0 for device tree, but bloblist has x1 non-zero and Linux does not,
> > so both could be present here? Or is there some incompatibility I don't
> > see on quick skimming?
>
> Right.  Some time ago I suggested Simon to lobby the Linux kernel
> folks to change the arm64 Linux kernel entry convention to state that
> x1 can be non-zero in which case it points at a bloblist.  If that
> happened I'd probably do the work to make m1n1 pass a bloblist.  And
> it would probably make the folks who want to directly boot a Linux
> kernel from TF-A (without going through U-Boot) happy as well.

I got a lot of push-back on that. Perhaps there might be some
willingness if it is explained that Linux doesn't need to understand
the bloblist, just tolerate it being there. There are probably other
people who will be more successful at pushing for kernel changes.

As you know, the handoff protocol is designed such that you don't need
to decode the bloblist to find the devicetree. BTW I would like to put
the ACPI/SMBIOS tables in the bloblist as well (with EFI we would
provide pointers into the bloblist for Linux to use)

Regards,
Simon
Tom Rini Jan. 1, 2024, 11:35 p.m. UTC | #12 
On Mon, Jan 01, 2024 at 03:32:41PM -0700, Simon Glass wrote:
> Hi Mark, Tom,
> 
> On Sun, Dec 31, 2023 at 5:33 PM Mark Kettenis <mark.kettenis@xs4all.nl> wrote:
> >
> > > Date: Sun, 31 Dec 2023 15:39:53 -0500
> > > From: Tom Rini <trini@konsulko.com>
> > >
> > > On Sun, Dec 31, 2023 at 07:28:52AM -0700, Simon Glass wrote:
> > > > Hi Sumit,
> > > >
> > > > On Fri, Dec 29, 2023 at 8:30 AM Sumit Garg <sumit.garg@linaro.org> wrote:
> > > > >
> > > > > On Fri, 29 Dec 2023 at 01:18, Simon Glass <sjg@chromium.org> wrote:
> > > > > >
> > > > > > Hi Tom,
> > > > > >
> > > > > > On Thu, Dec 28, 2023 at 3:54 PM Tom Rini <trini@konsulko.com> wrote:
> > > > > > >
> > > > > > > On Thu, Dec 28, 2023 at 03:09:12PM +0000, Simon Glass wrote:
> > > > > > > > Hi Tom, Sumit,
> > > > > > > >
> > > > > > > > On Thu, Dec 28, 2023 at 2:03 PM Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > >
> > > > > > > > > On Thu, Dec 28, 2023 at 01:37:26PM +0000, Simon Glass wrote:
> > > > > > > > > > Hi Sumit,
> > > > > > > > > >
> > > > > > > > > > On Thu, Dec 28, 2023 at 11:58 AM Sumit Garg <sumit.garg@linaro.org> wrote:
> > > > > > > > > > >
> > > > > > > > > > > Allow platform owners to mirror devicetree files from devitree-rebasing
> > > > > > > > > > > directory into dts/arch/$(ARCH) (special case for dts/arch/arm64). Then
> > > > > > > > > > > build then along with any *-u-boot.dtsi file present in arch/$(ARCH)/dts
> > > > > > > > > > > directory. Also add a new Makefile for arm64.
> > > > > > > > > > >
> > > > > > > > > > > This will help easy migration for platforms which currently are compliant
> > > > > > > > > > > with upstream Linux kernel devicetree files.
> > > > > > > > > > >
> > > > > > > > > > > Signed-off-by: Sumit Garg <sumit.garg@linaro.org>
> > > > > > > > > > > ---
> > > > > > > > > > >
> > > > > > > > > > > Changes in v3:
> > > > > > > > > > > --------------
> > > > > > > > > > > - Minor commit message update
> > > > > > > > > > >
> > > > > > > > > > > Changes in v2:
> > > > > > > > > > > --------------
> > > > > > > > > > > - s/DEVICE_TREE_LOC/dt_dir/ and s/U-boot/U-Boot/
> > > > > > > > > > >
> > > > > > > > > > >  dts/Kconfig             | 11 +++++++++++
> > > > > > > > > > >  dts/Makefile            | 17 ++++++++++++++---
> > > > > > > > > > >  dts/arch/arm64/Makefile | 14 ++++++++++++++
> > > > > > > > > > >  3 files changed, 39 insertions(+), 3 deletions(-)
> > > > > > > > > > >  create mode 100644 dts/arch/arm64/Makefile
> > > > > > > > > > >
> > > > > > > > > > > diff --git a/dts/Kconfig b/dts/Kconfig
> > > > > > > > > > > index 00c0aeff893..e58c1c6f2ab 100644
> > > > > > > > > > > --- a/dts/Kconfig
> > > > > > > > > > > +++ b/dts/Kconfig
> > > > > > > > > > > @@ -85,6 +85,17 @@ config OF_LIVE
> > > > > > > > > > >           enables a live tree which is available after relocation,
> > > > > > > > > > >           and can be adjusted as needed.
> > > > > > > > > > >
> > > > > > > > > > > +config OF_UPSTREAM
> > > > > > > > > > > +       bool "Enable use of devicetree imported from Linux kernel release"
> > > > > > > > > > > +       help
> > > > > > > > > > > +         Traditionally, U-Boot platforms used to have their custom devicetree
> > > > > > > > > > > +         files or copy devicetree files from Linux kernel which are hard to
> > > > > > > > > > > +         maintain and can usually get out-of-sync from Linux kernel. This
> > > > > > > > > > > +         option enables platforms to migrate to devicetree-rebasing repo where
> > > > > > > > > > > +         a regular sync will be maintained every major Linux kernel release
> > > > > > > > > > > +         cycle. However, platforms can still have some custom u-boot specific
> > > > > > > > > > > +         bits maintained as part of *-u-boot.dtsi files.
> > > > > > > > > >
> > > > > > > > > > My only other suggestion here is to mention that this should be set in
> > > > > > > > > > Kconfig, for the SoC as a whole. So I believe that means that it
> > > > > > > > > > should be hidden, with no string for the 'bool':
> > > > > > > > > >
> > > > > > > > > >       bool  # Enable use of devicetree imported from Linux kernel release
> > > > > > > > >
> > > > > > > > > I think we can just keep prompting for it now, to make the transition
> > > > > > > > > easier, before this option just goes away in time, hopefully.
> > > > > > > > >
> > > > > > > > > > Also, this doesn't seem to work for me. Before this series I get these
> > > > > > > > > > files when building firefly-rk3399:
> > > > > > > > > >
> > > > > > > > > > rk3399-eaidk-610.dtb            rk3399-khadas-edge-v.dtb
> > > > > > > > > > rk3399-orangepi.dtb        rk3399-rock-pi-4a.dtb
> > > > > > > > > > rk3399-evb.dtb                  rk3399-leez-p710.dtb
> > > > > > > > > > rk3399-pinebook-pro.dtb    rk3399-rock-pi-4c.dtb
> > > > > > > > > > rk3399-ficus.dtb                rk3399-nanopc-t4.dtb
> > > > > > > > > > rk3399-pinephone-pro.dtb   rk3399-rockpro64.dtb
> > > > > > > > > > rk3399-firefly.dtb              rk3399-nanopi-m4-2gb.dtb
> > > > > > > > > > rk3399pro-rock-pi-n10.dtb  rk3399-roc-pc.dtb
> > > > > > > > > > rk3399-gru-bob.dtb              rk3399-nanopi-m4b.dtb
> > > > > > > > > > rk3399-puma-haikou.dtb     rk3399-roc-pc-mezzanine.dtb
> > > > > > > > > > rk3399-gru-kevin.dtb            rk3399-nanopi-m4.dtb
> > > > > > > > > > rk3399-rock-4c-plus.dtb
> > > > > > > > > > rk3399-khadas-edge-captain.dtb  rk3399-nanopi-neo4.dtb    rk3399-rock-4se.dtb
> > > > > > > > > > rk3399-khadas-edge.dtb          rk3399-nanopi-r4s.dtb     rk3399-rock960.dtb
> > > > > > > > > >
> > > > > > > > > > Afterwards I get this:
> > > > > > > > > >
> > > > > > > > > > make[3]: *** No rule to make target
> > > > > > > > > > 'dts/arch/arm64/rk3399-firefly.dtb', needed by 'dtbs'.  Stop.
> > > > > > > > > >
> > > > > > > > > > So I set this manually for that one board:
> > > > > > > > > >
> > > > > > > > > > CONFIG_DEFAULT_DEVICE_TREE="rockchip/rk3399-firefly"
> > > > > > > > > >
> > > > > > > > > > and get:
> > > > > > > > > >
> > > > > > > > > > make[3]: *** No rule to make target
> > > > > > > > > > 'dts/arch/arm64/rockchip/rk3399-firefly.dtb', needed by 'dtbs'.  Stop.
> > > > > > > > > >
> > > > > > > > > > I am not sure how to fix this, nor how this can be made to build all
> > > > > > > > > > the DTs for rk3399, as it does today.
> > > > > > > > >
> > > > > > > > > Looking at the patch for amlogic boards, you need to make the link to
> > > > > > > > > devicetree-rebasing inside dts/...
> > > > > > > >
> > > > > > > > OK, let me give up on rk3399 for now...that doesn't seem to work even
> > > > > > > > with the link.
> > > > > > > >
> > > > > > > > Using odroid-c2 with -next I see:
> > > > > > > >
> > > > > > > > $ ls /tmp/b/odroid-c2/arch/arm/dts/
> > > > > > > > meson-a1-ad401.dtb                 meson-g12b-odroid-n2l.dtb
> > > > > > > >     meson-gxl-s905x-libretech-cc.dtb
> > > > > > > > meson-axg-jethome-jethub-j100.dtb  meson-g12b-odroid-n2-plus.dtb
> > > > > > > >     meson-gxl-s905x-libretech-cc-v2.dtb
> > > > > > > > meson-axg-s400.dtb                 meson-g12b-radxa-zero2.dtb
> > > > > > > >     meson-gxl-s905x-p212.dtb
> > > > > > > > meson-g12a-radxa-zero.dtb          meson-gxbb-kii-pro.dtb
> > > > > > > >     meson-gxm-gt1-ultimate.dtb
> > > > > > > > meson-g12a-sei510.dtb              meson-gxbb-nanopi-k2.dtb
> > > > > > > >     meson-gxm-khadas-vim2.dtb
> > > > > > > > meson-g12a-u200.dtb                meson-gxbb-odroidc2.dtb
> > > > > > > >     meson-gxm-s912-libretech-pc.dtb
> > > > > > > > meson-g12b-a311d-bananapi-m2s.dtb  meson-gxbb-p200.dtb
> > > > > > > >     meson-gxm-wetek-core2.dtb
> > > > > > > > meson-g12b-a311d-khadas-vim3.dtb   meson-gxbb-p201.dtb
> > > > > > > >     meson-sm1-bananapi-m2-pro.dtb
> > > > > > > > meson-g12b-bananapi-cm4-cm4io.dtb  meson-gxbb-wetek-hub.dtb
> > > > > > > >     meson-sm1-bananapi-m5.dtb
> > > > > > > > meson-g12b-gsking-x.dtb            meson-gxbb-wetek-play2.dtb
> > > > > > > >     meson-sm1-khadas-vim3l.dtb
> > > > > > > > meson-g12b-gtking.dtb              meson-gxl-s805x-libretech-ac.dtb
> > > > > > > >     meson-sm1-odroid-c4.dtb
> > > > > > > > meson-g12b-gtking-pro.dtb          meson-gxl-s905d-libretech-pc.dtb
> > > > > > > >     meson-sm1-odroid-hc4.dtb
> > > > > > > > meson-g12b-odroid-go-ultra.dtb
> > > > > > > > meson-gxl-s905w-jethome-jethub-j80.dtb  meson-sm1-sei610.dtb
> > > > > > > > meson-g12b-odroid-n2.dtb           meson-gxl-s905x-khadas-vim.dtb
> > > > > > > > $
> > > > > > > > With this series (sort of, since I am really not sure how to
> > > > > > > > cherry-pick the commits from the PR) I see nothing:
> > > > > > > >
> > > > > > > > $ ls /tmp/b/odroid-c2/arch/arm/dts/
> > > > > > > > $
> > > > > > > >
> > > > > > > > This shows some of the files:
> > > > > > > >
> > > > > > > > $ find /tmp/b/odroid-c2/ -name "*.dtb"
> > > > > > > > /tmp/b/odroid-c2/dts/dt.dtb
> > > > > > > > /tmp/b/odroid-c2/dts/arch/arm64/amlogic/meson-gxbb-odroidc2.dtb
> > > > > > > > /tmp/b/odroid-c2/dts/arch/arm64/amlogic/meson-gxbb-nanopi-k2.dtb
> > > > > > > > /tmp/b/odroid-c2/dts/arch/arm64/amlogic/meson-gxbb-wetek-play2.dtb
> > > > > > > > /tmp/b/odroid-c2/dts/arch/arm64/amlogic/meson-gxbb-kii-pro.dtb
> > > > > > > > /tmp/b/odroid-c2/dts/arch/arm64/amlogic/meson-gxbb-p200.dtb
> > > > > > > > /tmp/b/odroid-c2/dts/arch/arm64/amlogic/meson-gxbb-p201.dtb
> > > > > > > > /tmp/b/odroid-c2/dts/arch/arm64/amlogic/meson-gxbb-wetek-hub.dtb
> > > > > > > > /tmp/b/odroid-c2/u-boot.dtb
> > > > > > > >
> > > > > > > > but where are the rest? Also, is it possible to put the output .dtb
> > > > > > > > files into the same directory? Otherwise we may have some pain with
> > > > > > > > binman.
> > > > > > >
> > > > > > > What do you mean by same directory? But maybe also, what's an example of
> > > > > > > a board you think might end up having problems? Converting that in a
> > > > > > > follow-up series is likely a good idea, to highlight and address these
> > > > > > > issues sooner rather than later.#
> > > > > >
> > > > > > Today the .dtb files go into arch/arm/dts - so it would be easier if
> > > > > > this series could do the same.
> > > > >
> > > > > The kbuild infrastructure keeps the dtb alongside dts files which is
> > > > > the preferred way too as otherwise it would be complicated to locate
> > > > > DT files for the users. Also, we have to move towards Linux DT
> > > > > directory structure and thereby the tools like binman have to be
> > > > > adjusted. I will do that when I get to migrating SoCs supporting
> > > > > binman.
> > > >
> > > > OK, I want to stop here and rethink this. This is the path taken so
> > > > far, I believe:
> > > >
> > > > 1. We want to use devicetree files taken from Linux and
> > > > devicetree-rebasing provides these
> > >
> > > Yes.
> > >
> > > > 2. We want to use 'git subtree' to avoid needing a script to do the
> > > > sync / create a commit
> > >
> > > No. We want to use 'git subtree' to avoid having to use git submodules.
> 
> Well that is what I understood from Sumit, when I asked about a
> script. I imagine a 100-line Python script could do the same as:
> 
>    git subtree pull --prefix devicetree-rebasing
> git://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git
> <release-tag> --squash
> 
> and it could also put the files in the right place for U-Boot.

I've been saying in various places for years that I want to move away
from arch/*/dts being where we have the "just a copy" dts files and have
them somewhere else so they are easier to manage and differentiate our
changes / additions. So arch/*/dts cannot be some hard-coded "right"
path.

> > > > 3. But this leaves us with a directory structure which doesn't match
> > > > U-Boot (no script to fix it up)
> > >
> > > No. We intentionally abandon arch/*/dts because it's so full of
> > > out of date files and never fully re-synced, only re-synced ad-hoc.
> 
> I mean that the dir structure doesn't match. I am not worried about
> keeping arch/*/dts but I want the same structure somewhere else, e.g.
> dtr/arch/*/dts

And what I want here is to match the same structure everyone that's not
U-Boot uses. For better or worse no one else seems to have gone with
"treat aarch64 as just another ARM", and then the vendor directory
structure only makes that more obviously a mismatch. We need to follow
what everyone else uses, and developers familiar with other projects
will expect to see.

> > > > 4. So we deal with that by skipping the build rules and using CONFIG
> > > > options to select what is built
> > > > 5. So now we cannot build all the files for an SoC, just the ones that
> > > > are in the CONFIG options
> > > > 6. Linux doesn't actually use devicetree-rebasing itself, so doesn't
> > > > have this problem
> > >
> > > No. devicetree-rebasing skips the Makefiles because they're part of the
> > > kernel. We couldn't re-use them ourselves because we don't have the same
> > > CONFIG names the kernel does. And Sumit has not replicated the logic we
> > > have under arch/*/dts/Makefile today because I've asked him not to, and
> > > we'll figure out what subsets of that logic make sense to add back in as
> > > a second step not a first step.
> 
> Again, you are missing my point. I am not suggesting using Linux's
> build rules, just explaining why Linux doesn't have the problem we
> would be creating here.
>
> > > > So this is heading in the wrong direction. Nor is it clear that this
> > > > would just be a temporary problem.
> > >
> > > A previous iteration of this series built all of the dtb files for the
> > > SoC that Sumit has migrated with this series, but then dropped it.
> 
> Oh.
> 
> > >
> > > [snip]
> > > > I would like to do this series properly, maintaining the SoC-specific
> > > > build rules, not removing what I see as an important feature. It
> > > > should not be that difficult to figure out and I am happy to help with
> > > > it.
> > >
> > > The problem is that the rest of us do not understand the use case you're
> > > describing where a dtb file that would be useful in a build is not
> > > already in the list to build. The only one of those use cases I
> > > understand thus far is the exynos4 (iirc) case you mentioned previously
> > > where yes, really, one defconfig + appending board.dtb is fine, or fine
> > > enough. It's not that far off of the SPL_LOAD_FIT case, but there we
> > > know what to build already.
> 
> Perhaps the problem is that the rest of you think of the build as all
> happening in U-Boot, similar to the proposed 'make image.fit' that I
> am trying to add to Linux.
> 
> But packaging can be (and often is) a separate step from building.
> Linux has no packaging mechanism today...it just builds everything
> (including all DTs) and stops.
>
> We should be able to pick up whatever .dtb files we want and use them
> in an image.
>
> > > And I guess trying to tie things up, that's my puzzle. SPL_LOAD_FIT is
> > > how I see the use case you talk about being solved, if a full U-Boot is
> > > generic enough for N boards, SPL_LOAD_FIT does the right thing (in this
> > > non-bloblist DTB, non-reusing-OS-inntended DTB world). I really don't
> > > knnow how many modern SoCs can take a literal concatenated DTB and even
> > > in those cases I don't get why that's the win we want now? 1 build to N
> > > binaries?
> 
> Yes SPL_LOAD_FIT is fine although in practice we will likely need SPL
> to use the correct DT as well, so the DT will need to be determined in
> TPL, perhaps.

I mean, SPL_LOAD_FIT still can handle this case, with a call to the
function to re-parse the tree, when needed. I thought we did this today
even, but perhaps I'm confusing my options here.

> But anyway, this works OK with rk3399, for example. We need to support
> this use case.
> 
> Also, it is pretty easy. We just need to stick with the dir structure
> we have today and copy our existing Makefiles into that dir. Or change
> to the kernel dir structure and use that. Or do one, then the other.

I'm sorry, I don't understand what directory structure has to do with
"build more dtbs". For the cases where it makes sense to, yes, we can
build more dtbs, based on the SoC. I'm setting aside entirely the
discussion on what SoCs that works for, for another thread.

Perhaps an issue here is that much like the kernel "install" target, we
need an "install" target too, so that whatever dtbs we build can be
more easily found for external packaging, but whatever tooling it is
that wants it? And perhaps this is part of the problem, tooling that
expects to pull things out of the object directory rather than an
"installed" directory?

> > > But even then, I don't object to adding those rules to the Makefiles. If
> > > it works it works. I object to adding them when they don't work.
> 
> What do you mean by 'work'? With this series as is, it simply isn't
> possible to add Makefile rules, as they are ignored. Am I missing
> something?

Yes, I think you're missing something. Perhaps you need to publish a WIP
tree somewhere so someone can see what you're doing as it sounds like
you're not able to add another SoC of any type on top of Sumit's tree
and have it work.
Caleb Connolly Jan. 2, 2024, 12:50 p.m. UTC | #13 
[snip]
>>>
>>>>> However, I am very much in favour of having a generalized U-Boot
>>>>> image. This might become true in some cases like U-Boot acts as a
>>>>> second stage bootloader for a particular SoC which is a unified image
>>>>> where the prior stage passes the DT to it. The Qcom effort in this
>>>>> direction can be an example here.
>>>>
>>>> Not relevant to the topic at hand, perhaps, but Qualcomm uses a
>>>> closed-source blob to jump to U-Boot and is certainly not an example
>>>> we should emulate. But yes, passing a DT to U-Boot proper can be
>>>> useful.

Just to chime in here, this limitation is true for production Qualcomm 
devices where all of the bootloader blobs are signed by the OEM (true 
for most phones). But for development platforms we can do better. I 
expect this is a topic we will keep on coming back to, so I'd like to 
just take the time to explain some of the technical details on Qualcomm 
platforms, as there is a lot more nuance than you might be aware of.

The modern Qualcomm boot chain is (roughly) PBL (bootrom) -> TZ/el3 -> 
sbl1 (secondary bootloader) -> hypervisor -> XBL_Core (UEFI impl) -> ABL 
(LinuxLoader.efi app) -> Linux

On production devices the best we can do is replace "Linux" with U-Boot, 
and if we're lucky then we can leverage features of ABL to simplify 
things like DTB selection (it supports picking from a bunch of 
concatenated DTBs, but we can just as easily implement some similar 
feature in U-Boot ourselves).

On a development board I have been successful in replacing the 
hypervisor with a stub and replacing XBL_Core with U-Boot - giving us 
EL2 and removing the entire proprietary UEFI stack. There is no reason 
that we can't go further than this.

The Qualcomm Chromebooks all run Coreboot, for sure on those it would be 
possible to use U-Boot much earlier (although there is still the 
proprietary XBL_Sec TZ blob).

The Dragonboard410c (and MSM8916 SoC overall) has been pretty much 
entirely ripped open thanks to Stephan Gerhold and the msm8916-mainline 
project. On these devices it is easily possible to run U-Boot as a 
first-stage bootloader (at least to the same extent one can on the more 
open ARM platforms, or even more open if you wish). Although the 
bootloader of choice for most of these devices is a home-grown fork of lk.

For new SoCs, with the number of Qualcomm devices out there, and 
communities like postmarketOS enabling support on so many of them... My 
hope is that we will quickly see phones being the most common Qualcomm 
devices supported by U-Boot. While it is indeed extremely unfortunate 
that we can't replace the bootloader entirely, using U-Boot as a fresh 
slate is still extremely liberating (EFI! Firmware updates! No need for 
distro hacks to update the kernel! Multi-boot! etc...). I wish we could 
focus more on how U-Boot will make supporting Linux on these devices SO 
SO much easier, and less on how broken the (usually impossible to 
modify) bootloader they shipped with is.

While almost all of the boot chain I explained above is proprietary, the 
ABL source code is publicly available (although most device vendors 
don't publish their modified production version, I suppose for fear of 
embarrassment). The statement "Qualcomm uses a closed-source blob to 
jump to U-Boot" is at the very least an oversimplification.

To be contrarian, here is an example of a phone vendor who do publish 
their ABL source code, here is the code that runs Linux (or U-Boot in 
our case).

https://github.com/SHIFTPHONES/android_bootable_bootloader_edk2/blob/sos-3.x/QcomModulePkg/Library/BootLib/BootLinux.c#L1039

My point is, there is a lot of nuance and complexity here, and we need 
to be careful about what exactly we're referring to.

Kind regards,
Caleb

>>>
>>> It's a very valid use case we need to continue to support. And to save
>>> Mark from having to repeat himself, again, it's intentionally and not
>>> changing, how the Apple M1/M2/etc platforms boot. I'm pretty sure the
>>> fact that one can use U-Boot this way is part of how engineers get proof
>>> of concept work done to show that if they had U-Boot available then they
>>> could also support X/Y/Z easier. And maybe they'll be able to longer
>>> term push internally to use bloblist to pass things along.
>>>
>>> Heck, trying to not go too far off on a tangent, maybe the m1n1 loader
>>> can implement both conventions, as both Linux Kernel[0] and Bloblist[1]
>>> use x0 for device tree, but bloblist has x1 non-zero and Linux does not,
>>> so both could be present here? Or is there some incompatibility I don't
>>> see on quick skimming?
>>
>> Right.  Some time ago I suggested Simon to lobby the Linux kernel
>> folks to change the arm64 Linux kernel entry convention to state that
>> x1 can be non-zero in which case it points at a bloblist.  If that
>> happened I'd probably do the work to make m1n1 pass a bloblist.  And
>> it would probably make the folks who want to directly boot a Linux
>> kernel from TF-A (without going through U-Boot) happy as well.
> 
> I got a lot of push-back on that. Perhaps there might be some
> willingness if it is explained that Linux doesn't need to understand
> the bloblist, just tolerate it being there. There are probably other
> people who will be more successful at pushing for kernel changes.
> 
> As you know, the handoff protocol is designed such that you don't need
> to decode the bloblist to find the devicetree. BTW I would like to put
> the ACPI/SMBIOS tables in the bloblist as well (with EFI we would
> provide pointers into the bloblist for Linux to use)
> 
> Regards,
> Simon
Simon Glass Jan. 2, 2024, 2:06 p.m. UTC | #14 
Hi Caleb,

On Tue, Jan 2, 2024 at 5:51 AM Caleb Connolly <caleb.connolly@linaro.org> wrote:
>
> [snip]
> >>>
> >>>>> However, I am very much in favour of having a generalized U-Boot
> >>>>> image. This might become true in some cases like U-Boot acts as a
> >>>>> second stage bootloader for a particular SoC which is a unified image
> >>>>> where the prior stage passes the DT to it. The Qcom effort in this
> >>>>> direction can be an example here.
> >>>>
> >>>> Not relevant to the topic at hand, perhaps, but Qualcomm uses a
> >>>> closed-source blob to jump to U-Boot and is certainly not an example
> >>>> we should emulate. But yes, passing a DT to U-Boot proper can be
> >>>> useful.
>
> Just to chime in here, this limitation is true for production Qualcomm
> devices where all of the bootloader blobs are signed by the OEM (true
> for most phones). But for development platforms we can do better. I
> expect this is a topic we will keep on coming back to, so I'd like to
> just take the time to explain some of the technical details on Qualcomm
> platforms, as there is a lot more nuance than you might be aware of.
>
> The modern Qualcomm boot chain is (roughly) PBL (bootrom) -> TZ/el3 ->
> sbl1 (secondary bootloader) -> hypervisor -> XBL_Core (UEFI impl) -> ABL
> (LinuxLoader.efi app) -> Linux
>
> On production devices the best we can do is replace "Linux" with U-Boot,
> and if we're lucky then we can leverage features of ABL to simplify
> things like DTB selection (it supports picking from a bunch of
> concatenated DTBs, but we can just as easily implement some similar
> feature in U-Boot ourselves).
>
> On a development board I have been successful in replacing the
> hypervisor with a stub and replacing XBL_Core with U-Boot - giving us
> EL2 and removing the entire proprietary UEFI stack. There is no reason
> that we can't go further than this.
>
> The Qualcomm Chromebooks all run Coreboot, for sure on those it would be
> possible to use U-Boot much earlier (although there is still the
> proprietary XBL_Sec TZ blob).
>
> The Dragonboard410c (and MSM8916 SoC overall) has been pretty much
> entirely ripped open thanks to Stephan Gerhold and the msm8916-mainline
> project. On these devices it is easily possible to run U-Boot as a
> first-stage bootloader (at least to the same extent one can on the more
> open ARM platforms, or even more open if you wish). Although the
> bootloader of choice for most of these devices is a home-grown fork of lk.
>
> For new SoCs, with the number of Qualcomm devices out there, and
> communities like postmarketOS enabling support on so many of them... My
> hope is that we will quickly see phones being the most common Qualcomm
> devices supported by U-Boot. While it is indeed extremely unfortunate
> that we can't replace the bootloader entirely, using U-Boot as a fresh
> slate is still extremely liberating (EFI! Firmware updates! No need for
> distro hacks to update the kernel! Multi-boot! etc...). I wish we could
> focus more on how U-Boot will make supporting Linux on these devices SO
> SO much easier, and less on how broken the (usually impossible to
> modify) bootloader they shipped with is.
>
> While almost all of the boot chain I explained above is proprietary, the
> ABL source code is publicly available (although most device vendors
> don't publish their modified production version, I suppose for fear of
> embarrassment). The statement "Qualcomm uses a closed-source blob to
> jump to U-Boot" is at the very least an oversimplification.
>
> To be contrarian, here is an example of a phone vendor who do publish
> their ABL source code, here is the code that runs Linux (or U-Boot in
> our case).
>
> https://github.com/SHIFTPHONES/android_bootable_bootloader_edk2/blob/sos-3.x/QcomModulePkg/Library/BootLib/BootLinux.c#L1039
>
> My point is, there is a lot of nuance and complexity here, and we need
> to be careful about what exactly we're referring to.

Thank you very much for the information, it is a great read. Yes my
comment was wide of the mark and I am pleased to hear it.

BTW, I would very much like to see Linaro ensuring that new 96boards
have open source firmware before they are released. Before release
seems to be the only time that the vendor can devote time to it.

Regards,
Simon
Simon Glass Jan. 2, 2024, 2:06 p.m. UTC | #15 
Hi Tom,

On Mon, Jan 1, 2024 at 4:35 PM Tom Rini <trini@konsulko.com> wrote:
>
> On Mon, Jan 01, 2024 at 03:32:41PM -0700, Simon Glass wrote:
> > Hi Mark, Tom,
> >
> > On Sun, Dec 31, 2023 at 5:33 PM Mark Kettenis <mark.kettenis@xs4all.nl> wrote:
> > >
> > > > Date: Sun, 31 Dec 2023 15:39:53 -0500
> > > > From: Tom Rini <trini@konsulko.com>
> > > >
> > > > On Sun, Dec 31, 2023 at 07:28:52AM -0700, Simon Glass wrote:
> > > > > Hi Sumit,
> > > > >
> > > > > On Fri, Dec 29, 2023 at 8:30 AM Sumit Garg <sumit.garg@linaro.org> wrote:
> > > > > >
> > > > > > On Fri, 29 Dec 2023 at 01:18, Simon Glass <sjg@chromium.org> wrote:
> > > > > > >
> > > > > > > Hi Tom,
> > > > > > >
> > > > > > > On Thu, Dec 28, 2023 at 3:54 PM Tom Rini <trini@konsulko.com> wrote:
> > > > > > > >
> > > > > > > > On Thu, Dec 28, 2023 at 03:09:12PM +0000, Simon Glass wrote:
> > > > > > > > > Hi Tom, Sumit,
> > > > > > > > >
> > > > > > > > > On Thu, Dec 28, 2023 at 2:03 PM Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > >
> > > > > > > > > > On Thu, Dec 28, 2023 at 01:37:26PM +0000, Simon Glass wrote:
> > > > > > > > > > > Hi Sumit,
> > > > > > > > > > >
> > > > > > > > > > > On Thu, Dec 28, 2023 at 11:58 AM Sumit Garg <sumit.garg@linaro.org> wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > Allow platform owners to mirror devicetree files from devitree-rebasing
> > > > > > > > > > > > directory into dts/arch/$(ARCH) (special case for dts/arch/arm64). Then
> > > > > > > > > > > > build then along with any *-u-boot.dtsi file present in arch/$(ARCH)/dts
> > > > > > > > > > > > directory. Also add a new Makefile for arm64.
> > > > > > > > > > > >
> > > > > > > > > > > > This will help easy migration for platforms which currently are compliant
> > > > > > > > > > > > with upstream Linux kernel devicetree files.
> > > > > > > > > > > >
> > > > > > > > > > > > Signed-off-by: Sumit Garg <sumit.garg@linaro.org>
> > > > > > > > > > > > ---
> > > > > > > > > > > >
> > > > > > > > > > > > Changes in v3:
> > > > > > > > > > > > --------------
> > > > > > > > > > > > - Minor commit message update
> > > > > > > > > > > >
> > > > > > > > > > > > Changes in v2:
> > > > > > > > > > > > --------------
> > > > > > > > > > > > - s/DEVICE_TREE_LOC/dt_dir/ and s/U-boot/U-Boot/
> > > > > > > > > > > >
> > > > > > > > > > > >  dts/Kconfig             | 11 +++++++++++
> > > > > > > > > > > >  dts/Makefile            | 17 ++++++++++++++---
> > > > > > > > > > > >  dts/arch/arm64/Makefile | 14 ++++++++++++++
> > > > > > > > > > > >  3 files changed, 39 insertions(+), 3 deletions(-)
> > > > > > > > > > > >  create mode 100644 dts/arch/arm64/Makefile
> > > > > > > > > > > >
> > > > > > > > > > > > diff --git a/dts/Kconfig b/dts/Kconfig
> > > > > > > > > > > > index 00c0aeff893..e58c1c6f2ab 100644
> > > > > > > > > > > > --- a/dts/Kconfig
> > > > > > > > > > > > +++ b/dts/Kconfig
> > > > > > > > > > > > @@ -85,6 +85,17 @@ config OF_LIVE
> > > > > > > > > > > >           enables a live tree which is available after relocation,
> > > > > > > > > > > >           and can be adjusted as needed.
> > > > > > > > > > > >
> > > > > > > > > > > > +config OF_UPSTREAM
> > > > > > > > > > > > +       bool "Enable use of devicetree imported from Linux kernel release"
> > > > > > > > > > > > +       help
> > > > > > > > > > > > +         Traditionally, U-Boot platforms used to have their custom devicetree
> > > > > > > > > > > > +         files or copy devicetree files from Linux kernel which are hard to
> > > > > > > > > > > > +         maintain and can usually get out-of-sync from Linux kernel. This
> > > > > > > > > > > > +         option enables platforms to migrate to devicetree-rebasing repo where
> > > > > > > > > > > > +         a regular sync will be maintained every major Linux kernel release
> > > > > > > > > > > > +         cycle. However, platforms can still have some custom u-boot specific
> > > > > > > > > > > > +         bits maintained as part of *-u-boot.dtsi files.
> > > > > > > > > > >
> > > > > > > > > > > My only other suggestion here is to mention that this should be set in
> > > > > > > > > > > Kconfig, for the SoC as a whole. So I believe that means that it
> > > > > > > > > > > should be hidden, with no string for the 'bool':
> > > > > > > > > > >
> > > > > > > > > > >       bool  # Enable use of devicetree imported from Linux kernel release
> > > > > > > > > >
> > > > > > > > > > I think we can just keep prompting for it now, to make the transition
> > > > > > > > > > easier, before this option just goes away in time, hopefully.
> > > > > > > > > >
> > > > > > > > > > > Also, this doesn't seem to work for me. Before this series I get these
> > > > > > > > > > > files when building firefly-rk3399:
> > > > > > > > > > >
> > > > > > > > > > > rk3399-eaidk-610.dtb            rk3399-khadas-edge-v.dtb
> > > > > > > > > > > rk3399-orangepi.dtb        rk3399-rock-pi-4a.dtb
> > > > > > > > > > > rk3399-evb.dtb                  rk3399-leez-p710.dtb
> > > > > > > > > > > rk3399-pinebook-pro.dtb    rk3399-rock-pi-4c.dtb
> > > > > > > > > > > rk3399-ficus.dtb                rk3399-nanopc-t4.dtb
> > > > > > > > > > > rk3399-pinephone-pro.dtb   rk3399-rockpro64.dtb
> > > > > > > > > > > rk3399-firefly.dtb              rk3399-nanopi-m4-2gb.dtb
> > > > > > > > > > > rk3399pro-rock-pi-n10.dtb  rk3399-roc-pc.dtb
> > > > > > > > > > > rk3399-gru-bob.dtb              rk3399-nanopi-m4b.dtb
> > > > > > > > > > > rk3399-puma-haikou.dtb     rk3399-roc-pc-mezzanine.dtb
> > > > > > > > > > > rk3399-gru-kevin.dtb            rk3399-nanopi-m4.dtb
> > > > > > > > > > > rk3399-rock-4c-plus.dtb
> > > > > > > > > > > rk3399-khadas-edge-captain.dtb  rk3399-nanopi-neo4.dtb    rk3399-rock-4se.dtb
> > > > > > > > > > > rk3399-khadas-edge.dtb          rk3399-nanopi-r4s.dtb     rk3399-rock960.dtb
> > > > > > > > > > >
> > > > > > > > > > > Afterwards I get this:
> > > > > > > > > > >
> > > > > > > > > > > make[3]: *** No rule to make target
> > > > > > > > > > > 'dts/arch/arm64/rk3399-firefly.dtb', needed by 'dtbs'.  Stop.
> > > > > > > > > > >
> > > > > > > > > > > So I set this manually for that one board:
> > > > > > > > > > >
> > > > > > > > > > > CONFIG_DEFAULT_DEVICE_TREE="rockchip/rk3399-firefly"
> > > > > > > > > > >
> > > > > > > > > > > and get:
> > > > > > > > > > >
> > > > > > > > > > > make[3]: *** No rule to make target
> > > > > > > > > > > 'dts/arch/arm64/rockchip/rk3399-firefly.dtb', needed by 'dtbs'.  Stop.
> > > > > > > > > > >
> > > > > > > > > > > I am not sure how to fix this, nor how this can be made to build all
> > > > > > > > > > > the DTs for rk3399, as it does today.
> > > > > > > > > >
> > > > > > > > > > Looking at the patch for amlogic boards, you need to make the link to
> > > > > > > > > > devicetree-rebasing inside dts/...
> > > > > > > > >
> > > > > > > > > OK, let me give up on rk3399 for now...that doesn't seem to work even
> > > > > > > > > with the link.
> > > > > > > > >
> > > > > > > > > Using odroid-c2 with -next I see:
> > > > > > > > >
> > > > > > > > > $ ls /tmp/b/odroid-c2/arch/arm/dts/
> > > > > > > > > meson-a1-ad401.dtb                 meson-g12b-odroid-n2l.dtb
> > > > > > > > >     meson-gxl-s905x-libretech-cc.dtb
> > > > > > > > > meson-axg-jethome-jethub-j100.dtb  meson-g12b-odroid-n2-plus.dtb
> > > > > > > > >     meson-gxl-s905x-libretech-cc-v2.dtb
> > > > > > > > > meson-axg-s400.dtb                 meson-g12b-radxa-zero2.dtb
> > > > > > > > >     meson-gxl-s905x-p212.dtb
> > > > > > > > > meson-g12a-radxa-zero.dtb          meson-gxbb-kii-pro.dtb
> > > > > > > > >     meson-gxm-gt1-ultimate.dtb
> > > > > > > > > meson-g12a-sei510.dtb              meson-gxbb-nanopi-k2.dtb
> > > > > > > > >     meson-gxm-khadas-vim2.dtb
> > > > > > > > > meson-g12a-u200.dtb                meson-gxbb-odroidc2.dtb
> > > > > > > > >     meson-gxm-s912-libretech-pc.dtb
> > > > > > > > > meson-g12b-a311d-bananapi-m2s.dtb  meson-gxbb-p200.dtb
> > > > > > > > >     meson-gxm-wetek-core2.dtb
> > > > > > > > > meson-g12b-a311d-khadas-vim3.dtb   meson-gxbb-p201.dtb
> > > > > > > > >     meson-sm1-bananapi-m2-pro.dtb
> > > > > > > > > meson-g12b-bananapi-cm4-cm4io.dtb  meson-gxbb-wetek-hub.dtb
> > > > > > > > >     meson-sm1-bananapi-m5.dtb
> > > > > > > > > meson-g12b-gsking-x.dtb            meson-gxbb-wetek-play2.dtb
> > > > > > > > >     meson-sm1-khadas-vim3l.dtb
> > > > > > > > > meson-g12b-gtking.dtb              meson-gxl-s805x-libretech-ac.dtb
> > > > > > > > >     meson-sm1-odroid-c4.dtb
> > > > > > > > > meson-g12b-gtking-pro.dtb          meson-gxl-s905d-libretech-pc.dtb
> > > > > > > > >     meson-sm1-odroid-hc4.dtb
> > > > > > > > > meson-g12b-odroid-go-ultra.dtb
> > > > > > > > > meson-gxl-s905w-jethome-jethub-j80.dtb  meson-sm1-sei610.dtb
> > > > > > > > > meson-g12b-odroid-n2.dtb           meson-gxl-s905x-khadas-vim.dtb
> > > > > > > > > $
> > > > > > > > > With this series (sort of, since I am really not sure how to
> > > > > > > > > cherry-pick the commits from the PR) I see nothing:
> > > > > > > > >
> > > > > > > > > $ ls /tmp/b/odroid-c2/arch/arm/dts/
> > > > > > > > > $
> > > > > > > > >
> > > > > > > > > This shows some of the files:
> > > > > > > > >
> > > > > > > > > $ find /tmp/b/odroid-c2/ -name "*.dtb"
> > > > > > > > > /tmp/b/odroid-c2/dts/dt.dtb
> > > > > > > > > /tmp/b/odroid-c2/dts/arch/arm64/amlogic/meson-gxbb-odroidc2.dtb
> > > > > > > > > /tmp/b/odroid-c2/dts/arch/arm64/amlogic/meson-gxbb-nanopi-k2.dtb
> > > > > > > > > /tmp/b/odroid-c2/dts/arch/arm64/amlogic/meson-gxbb-wetek-play2.dtb
> > > > > > > > > /tmp/b/odroid-c2/dts/arch/arm64/amlogic/meson-gxbb-kii-pro.dtb
> > > > > > > > > /tmp/b/odroid-c2/dts/arch/arm64/amlogic/meson-gxbb-p200.dtb
> > > > > > > > > /tmp/b/odroid-c2/dts/arch/arm64/amlogic/meson-gxbb-p201.dtb
> > > > > > > > > /tmp/b/odroid-c2/dts/arch/arm64/amlogic/meson-gxbb-wetek-hub.dtb
> > > > > > > > > /tmp/b/odroid-c2/u-boot.dtb
> > > > > > > > >
> > > > > > > > > but where are the rest? Also, is it possible to put the output .dtb
> > > > > > > > > files into the same directory? Otherwise we may have some pain with
> > > > > > > > > binman.
> > > > > > > >
> > > > > > > > What do you mean by same directory? But maybe also, what's an example of
> > > > > > > > a board you think might end up having problems? Converting that in a
> > > > > > > > follow-up series is likely a good idea, to highlight and address these
> > > > > > > > issues sooner rather than later.#
> > > > > > >
> > > > > > > Today the .dtb files go into arch/arm/dts - so it would be easier if
> > > > > > > this series could do the same.
> > > > > >
> > > > > > The kbuild infrastructure keeps the dtb alongside dts files which is
> > > > > > the preferred way too as otherwise it would be complicated to locate
> > > > > > DT files for the users. Also, we have to move towards Linux DT
> > > > > > directory structure and thereby the tools like binman have to be
> > > > > > adjusted. I will do that when I get to migrating SoCs supporting
> > > > > > binman.
> > > > >
> > > > > OK, I want to stop here and rethink this. This is the path taken so
> > > > > far, I believe:
> > > > >
> > > > > 1. We want to use devicetree files taken from Linux and
> > > > > devicetree-rebasing provides these
> > > >
> > > > Yes.
> > > >
> > > > > 2. We want to use 'git subtree' to avoid needing a script to do the
> > > > > sync / create a commit
> > > >
> > > > No. We want to use 'git subtree' to avoid having to use git submodules.
> >
> > Well that is what I understood from Sumit, when I asked about a
> > script. I imagine a 100-line Python script could do the same as:
> >
> >    git subtree pull --prefix devicetree-rebasing
> > git://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git
> > <release-tag> --squash
> >
> > and it could also put the files in the right place for U-Boot.
>
> I've been saying in various places for years that I want to move away
> from arch/*/dts being where we have the "just a copy" dts files and have
> them somewhere else so they are easier to manage and differentiate our
> changes / additions. So arch/*/dts cannot be some hard-coded "right"
> path.

OK

>
> > > > > 3. But this leaves us with a directory structure which doesn't match
> > > > > U-Boot (no script to fix it up)
> > > >
> > > > No. We intentionally abandon arch/*/dts because it's so full of
> > > > out of date files and never fully re-synced, only re-synced ad-hoc.
> >
> > I mean that the dir structure doesn't match. I am not worried about
> > keeping arch/*/dts but I want the same structure somewhere else, e.g.
> > dtr/arch/*/dts
>
> And what I want here is to match the same structure everyone that's not
> U-Boot uses. For better or worse no one else seems to have gone with
> "treat aarch64 as just another ARM", and then the vendor directory
> structure only makes that more obviously a mismatch. We need to follow
> what everyone else uses, and developers familiar with other projects
> will expect to see.

So you are saying that U-Boot should move to what Linux uses. I agree
that seems like the best approach, so let's do it.

>
> > > > > 4. So we deal with that by skipping the build rules and using CONFIG
> > > > > options to select what is built
> > > > > 5. So now we cannot build all the files for an SoC, just the ones that
> > > > > are in the CONFIG options
> > > > > 6. Linux doesn't actually use devicetree-rebasing itself, so doesn't
> > > > > have this problem
> > > >
> > > > No. devicetree-rebasing skips the Makefiles because they're part of the
> > > > kernel. We couldn't re-use them ourselves because we don't have the same
> > > > CONFIG names the kernel does. And Sumit has not replicated the logic we
> > > > have under arch/*/dts/Makefile today because I've asked him not to, and
> > > > we'll figure out what subsets of that logic make sense to add back in as
> > > > a second step not a first step.
> >
> > Again, you are missing my point. I am not suggesting using Linux's
> > build rules, just explaining why Linux doesn't have the problem we
> > would be creating here.
> >
> > > > > So this is heading in the wrong direction. Nor is it clear that this
> > > > > would just be a temporary problem.
> > > >
> > > > A previous iteration of this series built all of the dtb files for the
> > > > SoC that Sumit has migrated with this series, but then dropped it.
> >
> > Oh.
> >
> > > >
> > > > [snip]
> > > > > I would like to do this series properly, maintaining the SoC-specific
> > > > > build rules, not removing what I see as an important feature. It
> > > > > should not be that difficult to figure out and I am happy to help with
> > > > > it.
> > > >
> > > > The problem is that the rest of us do not understand the use case you're
> > > > describing where a dtb file that would be useful in a build is not
> > > > already in the list to build. The only one of those use cases I
> > > > understand thus far is the exynos4 (iirc) case you mentioned previously
> > > > where yes, really, one defconfig + appending board.dtb is fine, or fine
> > > > enough. It's not that far off of the SPL_LOAD_FIT case, but there we
> > > > know what to build already.
> >
> > Perhaps the problem is that the rest of you think of the build as all
> > happening in U-Boot, similar to the proposed 'make image.fit' that I
> > am trying to add to Linux.
> >
> > But packaging can be (and often is) a separate step from building.
> > Linux has no packaging mechanism today...it just builds everything
> > (including all DTs) and stops.
> >
> > We should be able to pick up whatever .dtb files we want and use them
> > in an image.
> >
> > > > And I guess trying to tie things up, that's my puzzle. SPL_LOAD_FIT is
> > > > how I see the use case you talk about being solved, if a full U-Boot is
> > > > generic enough for N boards, SPL_LOAD_FIT does the right thing (in this
> > > > non-bloblist DTB, non-reusing-OS-inntended DTB world). I really don't
> > > > knnow how many modern SoCs can take a literal concatenated DTB and even
> > > > in those cases I don't get why that's the win we want now? 1 build to N
> > > > binaries?
> >
> > Yes SPL_LOAD_FIT is fine although in practice we will likely need SPL
> > to use the correct DT as well, so the DT will need to be determined in
> > TPL, perhaps.
>
> I mean, SPL_LOAD_FIT still can handle this case, with a call to the
> function to re-parse the tree, when needed. I thought we did this today
> even, but perhaps I'm confusing my options here.
>
> > But anyway, this works OK with rk3399, for example. We need to support
> > this use case.
> >
> > Also, it is pretty easy. We just need to stick with the dir structure
> > we have today and copy our existing Makefiles into that dir. Or change
> > to the kernel dir structure and use that. Or do one, then the other.
>
> I'm sorry, I don't understand what directory structure has to do with
> "build more dtbs". For the cases where it makes sense to, yes, we can
> build more dtbs, based on the SoC. I'm setting aside entirely the
> discussion on what SoCs that works for, for another thread.

Well you said above that we should switch to the kernel dir structure,
so I believe that issue is resolved.

'build more dtbs' means build all the DTBs for an SoC, not just a
selection that a particular board vendor decided on.

>
> Perhaps an issue here is that much like the kernel "install" target, we
> need an "install" target too, so that whatever dtbs we build can be
> more easily found for external packaging, but whatever tooling it is
> that wants it? And perhaps this is part of the problem, tooling that
> expects to pull things out of the object directory rather than an
> "installed" directory?

This is where binman comes in. It can run as part of U-Boot build, to
build a few default firmware images. Then it can be run *later*,
outside the U-Boot build, with an augmented or more targeted image
definition, with mostly the same input files, to pull together images
for specific uses. As you say, the input files need to be in a defined
location, which they are today, for the most part.

So even if a particular board only uses one DT, all the DTs for that
SoC are built and so can be used in that final-packaging step. Without
that build, there is no way to get the required .dtb files, other than
building every board one by one and then pulling out the .dtb files or
something weird like that.

Note that this works independently of whether OF_LIST is used, etc.

>
> > > > But even then, I don't object to adding those rules to the Makefiles. If
> > > > it works it works. I object to adding them when they don't work.
> >
> > What do you mean by 'work'? With this series as is, it simply isn't
> > possible to add Makefile rules, as they are ignored. Am I missing
> > something?
>
> Yes, I think you're missing something. Perhaps you need to publish a WIP
> tree somewhere so someone can see what you're doing as it sounds like
> you're not able to add another SoC of any type on top of Sumit's tree
> and have it work.

The current -next source builds dtb files based on the SoC, for the
most part. I sent a series to clean that up a bit[1], but it is mostly
there.

From the above it seems like the plan could be:
1. Move arm64 .dts files to arch/arm64/dts/<vendor>/... and adjust
Makefiles accordingly
2. Choose a directory target for devicetree-rebasing. I see that
'barebox' uses 'dts' which seems better to me than
'devicetree-rebasing/src/'. Actually barebox even seems to have
scripts for handling all of this [2]??
3. Adjust the build system to use the dts/ directory for .dts files
when OF_UPSTREAM is enabled

Then it will be easy. People can enable OF_UPSTREAM for an SoC
(without changing DEFAULT_DEVICE_TREE) and will get the same behaviour
as now, just with upstream .dts files. All the .dts files for an SoC
are built, as now, just as Linux does. We can continue cleaning up the
DT build rules as time permits.

Regards,
Simon

[1] http://patchwork.ozlabs.org/project/uboot/list/?series=388154
[2] https://git.pengutronix.de/cgit/barebox/tree/dts
Tom Rini Jan. 2, 2024, 3:10 p.m. UTC | #16 
On Tue, Jan 02, 2024 at 07:06:40AM -0700, Simon Glass wrote:
> Hi Tom,
> 
> On Mon, Jan 1, 2024 at 4:35 PM Tom Rini <trini@konsulko.com> wrote:
> >
> > On Mon, Jan 01, 2024 at 03:32:41PM -0700, Simon Glass wrote:
> > > Hi Mark, Tom,
> > >
> > > On Sun, Dec 31, 2023 at 5:33 PM Mark Kettenis <mark.kettenis@xs4all.nl> wrote:
> > > >
> > > > > Date: Sun, 31 Dec 2023 15:39:53 -0500
> > > > > From: Tom Rini <trini@konsulko.com>
> > > > >
> > > > > On Sun, Dec 31, 2023 at 07:28:52AM -0700, Simon Glass wrote:
> > > > > > Hi Sumit,
> > > > > >
> > > > > > On Fri, Dec 29, 2023 at 8:30 AM Sumit Garg <sumit.garg@linaro.org> wrote:
> > > > > > >
> > > > > > > On Fri, 29 Dec 2023 at 01:18, Simon Glass <sjg@chromium.org> wrote:
> > > > > > > >
> > > > > > > > Hi Tom,
> > > > > > > >
> > > > > > > > On Thu, Dec 28, 2023 at 3:54 PM Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > >
> > > > > > > > > On Thu, Dec 28, 2023 at 03:09:12PM +0000, Simon Glass wrote:
> > > > > > > > > > Hi Tom, Sumit,
> > > > > > > > > >
> > > > > > > > > > On Thu, Dec 28, 2023 at 2:03 PM Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > >
> > > > > > > > > > > On Thu, Dec 28, 2023 at 01:37:26PM +0000, Simon Glass wrote:
> > > > > > > > > > > > Hi Sumit,
> > > > > > > > > > > >
> > > > > > > > > > > > On Thu, Dec 28, 2023 at 11:58 AM Sumit Garg <sumit.garg@linaro.org> wrote:
> > > > > > > > > > > > >
> > > > > > > > > > > > > Allow platform owners to mirror devicetree files from devitree-rebasing
> > > > > > > > > > > > > directory into dts/arch/$(ARCH) (special case for dts/arch/arm64). Then
> > > > > > > > > > > > > build then along with any *-u-boot.dtsi file present in arch/$(ARCH)/dts
> > > > > > > > > > > > > directory. Also add a new Makefile for arm64.
> > > > > > > > > > > > >
> > > > > > > > > > > > > This will help easy migration for platforms which currently are compliant
> > > > > > > > > > > > > with upstream Linux kernel devicetree files.
> > > > > > > > > > > > >
> > > > > > > > > > > > > Signed-off-by: Sumit Garg <sumit.garg@linaro.org>
> > > > > > > > > > > > > ---
> > > > > > > > > > > > >
> > > > > > > > > > > > > Changes in v3:
> > > > > > > > > > > > > --------------
> > > > > > > > > > > > > - Minor commit message update
> > > > > > > > > > > > >
> > > > > > > > > > > > > Changes in v2:
> > > > > > > > > > > > > --------------
> > > > > > > > > > > > > - s/DEVICE_TREE_LOC/dt_dir/ and s/U-boot/U-Boot/
> > > > > > > > > > > > >
> > > > > > > > > > > > >  dts/Kconfig             | 11 +++++++++++
> > > > > > > > > > > > >  dts/Makefile            | 17 ++++++++++++++---
> > > > > > > > > > > > >  dts/arch/arm64/Makefile | 14 ++++++++++++++
> > > > > > > > > > > > >  3 files changed, 39 insertions(+), 3 deletions(-)
> > > > > > > > > > > > >  create mode 100644 dts/arch/arm64/Makefile
> > > > > > > > > > > > >
> > > > > > > > > > > > > diff --git a/dts/Kconfig b/dts/Kconfig
> > > > > > > > > > > > > index 00c0aeff893..e58c1c6f2ab 100644
> > > > > > > > > > > > > --- a/dts/Kconfig
> > > > > > > > > > > > > +++ b/dts/Kconfig
> > > > > > > > > > > > > @@ -85,6 +85,17 @@ config OF_LIVE
> > > > > > > > > > > > >           enables a live tree which is available after relocation,
> > > > > > > > > > > > >           and can be adjusted as needed.
> > > > > > > > > > > > >
> > > > > > > > > > > > > +config OF_UPSTREAM
> > > > > > > > > > > > > +       bool "Enable use of devicetree imported from Linux kernel release"
> > > > > > > > > > > > > +       help
> > > > > > > > > > > > > +         Traditionally, U-Boot platforms used to have their custom devicetree
> > > > > > > > > > > > > +         files or copy devicetree files from Linux kernel which are hard to
> > > > > > > > > > > > > +         maintain and can usually get out-of-sync from Linux kernel. This
> > > > > > > > > > > > > +         option enables platforms to migrate to devicetree-rebasing repo where
> > > > > > > > > > > > > +         a regular sync will be maintained every major Linux kernel release
> > > > > > > > > > > > > +         cycle. However, platforms can still have some custom u-boot specific
> > > > > > > > > > > > > +         bits maintained as part of *-u-boot.dtsi files.
> > > > > > > > > > > >
> > > > > > > > > > > > My only other suggestion here is to mention that this should be set in
> > > > > > > > > > > > Kconfig, for the SoC as a whole. So I believe that means that it
> > > > > > > > > > > > should be hidden, with no string for the 'bool':
> > > > > > > > > > > >
> > > > > > > > > > > >       bool  # Enable use of devicetree imported from Linux kernel release
> > > > > > > > > > >
> > > > > > > > > > > I think we can just keep prompting for it now, to make the transition
> > > > > > > > > > > easier, before this option just goes away in time, hopefully.
> > > > > > > > > > >
> > > > > > > > > > > > Also, this doesn't seem to work for me. Before this series I get these
> > > > > > > > > > > > files when building firefly-rk3399:
> > > > > > > > > > > >
> > > > > > > > > > > > rk3399-eaidk-610.dtb            rk3399-khadas-edge-v.dtb
> > > > > > > > > > > > rk3399-orangepi.dtb        rk3399-rock-pi-4a.dtb
> > > > > > > > > > > > rk3399-evb.dtb                  rk3399-leez-p710.dtb
> > > > > > > > > > > > rk3399-pinebook-pro.dtb    rk3399-rock-pi-4c.dtb
> > > > > > > > > > > > rk3399-ficus.dtb                rk3399-nanopc-t4.dtb
> > > > > > > > > > > > rk3399-pinephone-pro.dtb   rk3399-rockpro64.dtb
> > > > > > > > > > > > rk3399-firefly.dtb              rk3399-nanopi-m4-2gb.dtb
> > > > > > > > > > > > rk3399pro-rock-pi-n10.dtb  rk3399-roc-pc.dtb
> > > > > > > > > > > > rk3399-gru-bob.dtb              rk3399-nanopi-m4b.dtb
> > > > > > > > > > > > rk3399-puma-haikou.dtb     rk3399-roc-pc-mezzanine.dtb
> > > > > > > > > > > > rk3399-gru-kevin.dtb            rk3399-nanopi-m4.dtb
> > > > > > > > > > > > rk3399-rock-4c-plus.dtb
> > > > > > > > > > > > rk3399-khadas-edge-captain.dtb  rk3399-nanopi-neo4.dtb    rk3399-rock-4se.dtb
> > > > > > > > > > > > rk3399-khadas-edge.dtb          rk3399-nanopi-r4s.dtb     rk3399-rock960.dtb
> > > > > > > > > > > >
> > > > > > > > > > > > Afterwards I get this:
> > > > > > > > > > > >
> > > > > > > > > > > > make[3]: *** No rule to make target
> > > > > > > > > > > > 'dts/arch/arm64/rk3399-firefly.dtb', needed by 'dtbs'.  Stop.
> > > > > > > > > > > >
> > > > > > > > > > > > So I set this manually for that one board:
> > > > > > > > > > > >
> > > > > > > > > > > > CONFIG_DEFAULT_DEVICE_TREE="rockchip/rk3399-firefly"
> > > > > > > > > > > >
> > > > > > > > > > > > and get:
> > > > > > > > > > > >
> > > > > > > > > > > > make[3]: *** No rule to make target
> > > > > > > > > > > > 'dts/arch/arm64/rockchip/rk3399-firefly.dtb', needed by 'dtbs'.  Stop.
> > > > > > > > > > > >
> > > > > > > > > > > > I am not sure how to fix this, nor how this can be made to build all
> > > > > > > > > > > > the DTs for rk3399, as it does today.
> > > > > > > > > > >
> > > > > > > > > > > Looking at the patch for amlogic boards, you need to make the link to
> > > > > > > > > > > devicetree-rebasing inside dts/...
> > > > > > > > > >
> > > > > > > > > > OK, let me give up on rk3399 for now...that doesn't seem to work even
> > > > > > > > > > with the link.
> > > > > > > > > >
> > > > > > > > > > Using odroid-c2 with -next I see:
> > > > > > > > > >
> > > > > > > > > > $ ls /tmp/b/odroid-c2/arch/arm/dts/
> > > > > > > > > > meson-a1-ad401.dtb                 meson-g12b-odroid-n2l.dtb
> > > > > > > > > >     meson-gxl-s905x-libretech-cc.dtb
> > > > > > > > > > meson-axg-jethome-jethub-j100.dtb  meson-g12b-odroid-n2-plus.dtb
> > > > > > > > > >     meson-gxl-s905x-libretech-cc-v2.dtb
> > > > > > > > > > meson-axg-s400.dtb                 meson-g12b-radxa-zero2.dtb
> > > > > > > > > >     meson-gxl-s905x-p212.dtb
> > > > > > > > > > meson-g12a-radxa-zero.dtb          meson-gxbb-kii-pro.dtb
> > > > > > > > > >     meson-gxm-gt1-ultimate.dtb
> > > > > > > > > > meson-g12a-sei510.dtb              meson-gxbb-nanopi-k2.dtb
> > > > > > > > > >     meson-gxm-khadas-vim2.dtb
> > > > > > > > > > meson-g12a-u200.dtb                meson-gxbb-odroidc2.dtb
> > > > > > > > > >     meson-gxm-s912-libretech-pc.dtb
> > > > > > > > > > meson-g12b-a311d-bananapi-m2s.dtb  meson-gxbb-p200.dtb
> > > > > > > > > >     meson-gxm-wetek-core2.dtb
> > > > > > > > > > meson-g12b-a311d-khadas-vim3.dtb   meson-gxbb-p201.dtb
> > > > > > > > > >     meson-sm1-bananapi-m2-pro.dtb
> > > > > > > > > > meson-g12b-bananapi-cm4-cm4io.dtb  meson-gxbb-wetek-hub.dtb
> > > > > > > > > >     meson-sm1-bananapi-m5.dtb
> > > > > > > > > > meson-g12b-gsking-x.dtb            meson-gxbb-wetek-play2.dtb
> > > > > > > > > >     meson-sm1-khadas-vim3l.dtb
> > > > > > > > > > meson-g12b-gtking.dtb              meson-gxl-s805x-libretech-ac.dtb
> > > > > > > > > >     meson-sm1-odroid-c4.dtb
> > > > > > > > > > meson-g12b-gtking-pro.dtb          meson-gxl-s905d-libretech-pc.dtb
> > > > > > > > > >     meson-sm1-odroid-hc4.dtb
> > > > > > > > > > meson-g12b-odroid-go-ultra.dtb
> > > > > > > > > > meson-gxl-s905w-jethome-jethub-j80.dtb  meson-sm1-sei610.dtb
> > > > > > > > > > meson-g12b-odroid-n2.dtb           meson-gxl-s905x-khadas-vim.dtb
> > > > > > > > > > $
> > > > > > > > > > With this series (sort of, since I am really not sure how to
> > > > > > > > > > cherry-pick the commits from the PR) I see nothing:
> > > > > > > > > >
> > > > > > > > > > $ ls /tmp/b/odroid-c2/arch/arm/dts/
> > > > > > > > > > $
> > > > > > > > > >
> > > > > > > > > > This shows some of the files:
> > > > > > > > > >
> > > > > > > > > > $ find /tmp/b/odroid-c2/ -name "*.dtb"
> > > > > > > > > > /tmp/b/odroid-c2/dts/dt.dtb
> > > > > > > > > > /tmp/b/odroid-c2/dts/arch/arm64/amlogic/meson-gxbb-odroidc2.dtb
> > > > > > > > > > /tmp/b/odroid-c2/dts/arch/arm64/amlogic/meson-gxbb-nanopi-k2.dtb
> > > > > > > > > > /tmp/b/odroid-c2/dts/arch/arm64/amlogic/meson-gxbb-wetek-play2.dtb
> > > > > > > > > > /tmp/b/odroid-c2/dts/arch/arm64/amlogic/meson-gxbb-kii-pro.dtb
> > > > > > > > > > /tmp/b/odroid-c2/dts/arch/arm64/amlogic/meson-gxbb-p200.dtb
> > > > > > > > > > /tmp/b/odroid-c2/dts/arch/arm64/amlogic/meson-gxbb-p201.dtb
> > > > > > > > > > /tmp/b/odroid-c2/dts/arch/arm64/amlogic/meson-gxbb-wetek-hub.dtb
> > > > > > > > > > /tmp/b/odroid-c2/u-boot.dtb
> > > > > > > > > >
> > > > > > > > > > but where are the rest? Also, is it possible to put the output .dtb
> > > > > > > > > > files into the same directory? Otherwise we may have some pain with
> > > > > > > > > > binman.
> > > > > > > > >
> > > > > > > > > What do you mean by same directory? But maybe also, what's an example of
> > > > > > > > > a board you think might end up having problems? Converting that in a
> > > > > > > > > follow-up series is likely a good idea, to highlight and address these
> > > > > > > > > issues sooner rather than later.#
> > > > > > > >
> > > > > > > > Today the .dtb files go into arch/arm/dts - so it would be easier if
> > > > > > > > this series could do the same.
> > > > > > >
> > > > > > > The kbuild infrastructure keeps the dtb alongside dts files which is
> > > > > > > the preferred way too as otherwise it would be complicated to locate
> > > > > > > DT files for the users. Also, we have to move towards Linux DT
> > > > > > > directory structure and thereby the tools like binman have to be
> > > > > > > adjusted. I will do that when I get to migrating SoCs supporting
> > > > > > > binman.
> > > > > >
> > > > > > OK, I want to stop here and rethink this. This is the path taken so
> > > > > > far, I believe:
> > > > > >
> > > > > > 1. We want to use devicetree files taken from Linux and
> > > > > > devicetree-rebasing provides these
> > > > >
> > > > > Yes.
> > > > >
> > > > > > 2. We want to use 'git subtree' to avoid needing a script to do the
> > > > > > sync / create a commit
> > > > >
> > > > > No. We want to use 'git subtree' to avoid having to use git submodules.
> > >
> > > Well that is what I understood from Sumit, when I asked about a
> > > script. I imagine a 100-line Python script could do the same as:
> > >
> > >    git subtree pull --prefix devicetree-rebasing
> > > git://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git
> > > <release-tag> --squash
> > >
> > > and it could also put the files in the right place for U-Boot.
> >
> > I've been saying in various places for years that I want to move away
> > from arch/*/dts being where we have the "just a copy" dts files and have
> > them somewhere else so they are easier to manage and differentiate our
> > changes / additions. So arch/*/dts cannot be some hard-coded "right"
> > path.
> 
> OK
> 
> >
> > > > > > 3. But this leaves us with a directory structure which doesn't match
> > > > > > U-Boot (no script to fix it up)
> > > > >
> > > > > No. We intentionally abandon arch/*/dts because it's so full of
> > > > > out of date files and never fully re-synced, only re-synced ad-hoc.
> > >
> > > I mean that the dir structure doesn't match. I am not worried about
> > > keeping arch/*/dts but I want the same structure somewhere else, e.g.
> > > dtr/arch/*/dts
> >
> > And what I want here is to match the same structure everyone that's not
> > U-Boot uses. For better or worse no one else seems to have gone with
> > "treat aarch64 as just another ARM", and then the vendor directory
> > structure only makes that more obviously a mismatch. We need to follow
> > what everyone else uses, and developers familiar with other projects
> > will expect to see.
> 
> So you are saying that U-Boot should move to what Linux uses. I agree
> that seems like the best approach, so let's do it.
> 
> >
> > > > > > 4. So we deal with that by skipping the build rules and using CONFIG
> > > > > > options to select what is built
> > > > > > 5. So now we cannot build all the files for an SoC, just the ones that
> > > > > > are in the CONFIG options
> > > > > > 6. Linux doesn't actually use devicetree-rebasing itself, so doesn't
> > > > > > have this problem
> > > > >
> > > > > No. devicetree-rebasing skips the Makefiles because they're part of the
> > > > > kernel. We couldn't re-use them ourselves because we don't have the same
> > > > > CONFIG names the kernel does. And Sumit has not replicated the logic we
> > > > > have under arch/*/dts/Makefile today because I've asked him not to, and
> > > > > we'll figure out what subsets of that logic make sense to add back in as
> > > > > a second step not a first step.
> > >
> > > Again, you are missing my point. I am not suggesting using Linux's
> > > build rules, just explaining why Linux doesn't have the problem we
> > > would be creating here.
> > >
> > > > > > So this is heading in the wrong direction. Nor is it clear that this
> > > > > > would just be a temporary problem.
> > > > >
> > > > > A previous iteration of this series built all of the dtb files for the
> > > > > SoC that Sumit has migrated with this series, but then dropped it.
> > >
> > > Oh.
> > >
> > > > >
> > > > > [snip]
> > > > > > I would like to do this series properly, maintaining the SoC-specific
> > > > > > build rules, not removing what I see as an important feature. It
> > > > > > should not be that difficult to figure out and I am happy to help with
> > > > > > it.
> > > > >
> > > > > The problem is that the rest of us do not understand the use case you're
> > > > > describing where a dtb file that would be useful in a build is not
> > > > > already in the list to build. The only one of those use cases I
> > > > > understand thus far is the exynos4 (iirc) case you mentioned previously
> > > > > where yes, really, one defconfig + appending board.dtb is fine, or fine
> > > > > enough. It's not that far off of the SPL_LOAD_FIT case, but there we
> > > > > know what to build already.
> > >
> > > Perhaps the problem is that the rest of you think of the build as all
> > > happening in U-Boot, similar to the proposed 'make image.fit' that I
> > > am trying to add to Linux.
> > >
> > > But packaging can be (and often is) a separate step from building.
> > > Linux has no packaging mechanism today...it just builds everything
> > > (including all DTs) and stops.
> > >
> > > We should be able to pick up whatever .dtb files we want and use them
> > > in an image.
> > >
> > > > > And I guess trying to tie things up, that's my puzzle. SPL_LOAD_FIT is
> > > > > how I see the use case you talk about being solved, if a full U-Boot is
> > > > > generic enough for N boards, SPL_LOAD_FIT does the right thing (in this
> > > > > non-bloblist DTB, non-reusing-OS-inntended DTB world). I really don't
> > > > > knnow how many modern SoCs can take a literal concatenated DTB and even
> > > > > in those cases I don't get why that's the win we want now? 1 build to N
> > > > > binaries?
> > >
> > > Yes SPL_LOAD_FIT is fine although in practice we will likely need SPL
> > > to use the correct DT as well, so the DT will need to be determined in
> > > TPL, perhaps.
> >
> > I mean, SPL_LOAD_FIT still can handle this case, with a call to the
> > function to re-parse the tree, when needed. I thought we did this today
> > even, but perhaps I'm confusing my options here.
> >
> > > But anyway, this works OK with rk3399, for example. We need to support
> > > this use case.
> > >
> > > Also, it is pretty easy. We just need to stick with the dir structure
> > > we have today and copy our existing Makefiles into that dir. Or change
> > > to the kernel dir structure and use that. Or do one, then the other.
> >
> > I'm sorry, I don't understand what directory structure has to do with
> > "build more dtbs". For the cases where it makes sense to, yes, we can
> > build more dtbs, based on the SoC. I'm setting aside entirely the
> > discussion on what SoCs that works for, for another thread.
> 
> Well you said above that we should switch to the kernel dir structure,
> so I believe that issue is resolved.
> 
> 'build more dtbs' means build all the DTBs for an SoC, not just a
> selection that a particular board vendor decided on.

Yes, what other dtbs to build is the sticking point, in a number of
threads now.

> > Perhaps an issue here is that much like the kernel "install" target, we
> > need an "install" target too, so that whatever dtbs we build can be
> > more easily found for external packaging, but whatever tooling it is
> > that wants it? And perhaps this is part of the problem, tooling that
> > expects to pull things out of the object directory rather than an
> > "installed" directory?
> 
> This is where binman comes in. It can run as part of U-Boot build, to
> build a few default firmware images. Then it can be run *later*,
> outside the U-Boot build, with an augmented or more targeted image
> definition, with mostly the same input files, to pull together images
> for specific uses. As you say, the input files need to be in a defined
> location, which they are today, for the most part.
> 
> So even if a particular board only uses one DT, all the DTs for that
> SoC are built and so can be used in that final-packaging step. Without
> that build, there is no way to get the required .dtb files, other than
> building every board one by one and then pulling out the .dtb files or
> something weird like that.
> 
> Note that this works independently of whether OF_LIST is used, etc.

How about this. When you introduce generic-rk3399_defconfig is when we
can also have dts-$(CONFIG_ROCKCHIP_RK3399) list everything, and insist
it be kept up to date. That to me feels like the right order to go in.
And we can have all of the implementation details be hashed out
elsewhere, not in the thread about fixing our nightmare about dts file
resync.

> > > > > But even then, I don't object to adding those rules to the Makefiles. If
> > > > > it works it works. I object to adding them when they don't work.
> > >
> > > What do you mean by 'work'? With this series as is, it simply isn't
> > > possible to add Makefile rules, as they are ignored. Am I missing
> > > something?
> >
> > Yes, I think you're missing something. Perhaps you need to publish a WIP
> > tree somewhere so someone can see what you're doing as it sounds like
> > you're not able to add another SoC of any type on top of Sumit's tree
> > and have it work.
> 
> The current -next source builds dtb files based on the SoC, for the
> most part. I sent a series to clean that up a bit[1], but it is mostly
> there.

Yes, and that relied on Rasmus' series having been merged ages ago which
fixed up a number of "people just copypasta'd something here,
incorrectly".  Keep that in mind as part of why I have objections here.

> 
> From the above it seems like the plan could be:
> 1. Move arm64 .dts files to arch/arm64/dts/<vendor>/... and adjust
> Makefiles accordingly

Since we're going to move everyone to being from the upstream kernel,
that seems like unneeded churn.

> 2. Choose a directory target for devicetree-rebasing. I see that
> 'barebox' uses 'dts' which seems better to me than
> 'devicetree-rebasing/src/'. Actually barebox even seems to have
> scripts for handling all of this [2]??

They've been doing this since longer than git subtree has existed I
believe. I suspect that much like how Rob would like to move the
in-kernel devicetree compiler sync from a script to git subtree, barebox
will too.

> 3. Adjust the build system to use the dts/ directory for .dts files
> when OF_UPSTREAM is enabled
> 
> Then it will be easy. People can enable OF_UPSTREAM for an SoC
> (without changing DEFAULT_DEVICE_TREE) and will get the same behaviour
> as now, just with upstream .dts files. All the .dts files for an SoC
> are built, as now, just as Linux does. We can continue cleaning up the
> DT build rules as time permits.

Maybe the unasked / unanswered question here is, why don't we put the
subtree in to dts/ ? Just because it would make us more likely to make
changes rather than treat it as read only?
Sumit Garg Jan. 2, 2024, 3:37 p.m. UTC | #17 
On Tue, 2 Jan 2024 at 19:36, Simon Glass <sjg@chromium.org> wrote:
>
> Hi Tom,
>
> On Mon, Jan 1, 2024 at 4:35 PM Tom Rini <trini@konsulko.com> wrote:
> >
> > On Mon, Jan 01, 2024 at 03:32:41PM -0700, Simon Glass wrote:
> > > Hi Mark, Tom,
> > >
> > > On Sun, Dec 31, 2023 at 5:33 PM Mark Kettenis <mark.kettenis@xs4all.nl> wrote:
> > > >
> > > > > Date: Sun, 31 Dec 2023 15:39:53 -0500
> > > > > From: Tom Rini <trini@konsulko.com>
> > > > >
> > > > > On Sun, Dec 31, 2023 at 07:28:52AM -0700, Simon Glass wrote:
> > > > > > Hi Sumit,
> > > > > >
> > > > > > On Fri, Dec 29, 2023 at 8:30 AM Sumit Garg <sumit.garg@linaro.org> wrote:
> > > > > > >
> > > > > > > On Fri, 29 Dec 2023 at 01:18, Simon Glass <sjg@chromium.org> wrote:
> > > > > > > >
> > > > > > > > Hi Tom,
> > > > > > > >
> > > > > > > > On Thu, Dec 28, 2023 at 3:54 PM Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > >
> > > > > > > > > On Thu, Dec 28, 2023 at 03:09:12PM +0000, Simon Glass wrote:
> > > > > > > > > > Hi Tom, Sumit,
> > > > > > > > > >
> > > > > > > > > > On Thu, Dec 28, 2023 at 2:03 PM Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > >
> > > > > > > > > > > On Thu, Dec 28, 2023 at 01:37:26PM +0000, Simon Glass wrote:
> > > > > > > > > > > > Hi Sumit,
> > > > > > > > > > > >
> > > > > > > > > > > > On Thu, Dec 28, 2023 at 11:58 AM Sumit Garg <sumit.garg@linaro.org> wrote:
> > > > > > > > > > > > >
> > > > > > > > > > > > > Allow platform owners to mirror devicetree files from devitree-rebasing
> > > > > > > > > > > > > directory into dts/arch/$(ARCH) (special case for dts/arch/arm64). Then
> > > > > > > > > > > > > build then along with any *-u-boot.dtsi file present in arch/$(ARCH)/dts
> > > > > > > > > > > > > directory. Also add a new Makefile for arm64.
> > > > > > > > > > > > >
> > > > > > > > > > > > > This will help easy migration for platforms which currently are compliant
> > > > > > > > > > > > > with upstream Linux kernel devicetree files.
> > > > > > > > > > > > >
> > > > > > > > > > > > > Signed-off-by: Sumit Garg <sumit.garg@linaro.org>
> > > > > > > > > > > > > ---
> > > > > > > > > > > > >
> > > > > > > > > > > > > Changes in v3:
> > > > > > > > > > > > > --------------
> > > > > > > > > > > > > - Minor commit message update
> > > > > > > > > > > > >
> > > > > > > > > > > > > Changes in v2:
> > > > > > > > > > > > > --------------
> > > > > > > > > > > > > - s/DEVICE_TREE_LOC/dt_dir/ and s/U-boot/U-Boot/
> > > > > > > > > > > > >
> > > > > > > > > > > > >  dts/Kconfig             | 11 +++++++++++
> > > > > > > > > > > > >  dts/Makefile            | 17 ++++++++++++++---
> > > > > > > > > > > > >  dts/arch/arm64/Makefile | 14 ++++++++++++++
> > > > > > > > > > > > >  3 files changed, 39 insertions(+), 3 deletions(-)
> > > > > > > > > > > > >  create mode 100644 dts/arch/arm64/Makefile
> > > > > > > > > > > > >
> > > > > > > > > > > > > diff --git a/dts/Kconfig b/dts/Kconfig
> > > > > > > > > > > > > index 00c0aeff893..e58c1c6f2ab 100644
> > > > > > > > > > > > > --- a/dts/Kconfig
> > > > > > > > > > > > > +++ b/dts/Kconfig
> > > > > > > > > > > > > @@ -85,6 +85,17 @@ config OF_LIVE
> > > > > > > > > > > > >           enables a live tree which is available after relocation,
> > > > > > > > > > > > >           and can be adjusted as needed.
> > > > > > > > > > > > >
> > > > > > > > > > > > > +config OF_UPSTREAM
> > > > > > > > > > > > > +       bool "Enable use of devicetree imported from Linux kernel release"
> > > > > > > > > > > > > +       help
> > > > > > > > > > > > > +         Traditionally, U-Boot platforms used to have their custom devicetree
> > > > > > > > > > > > > +         files or copy devicetree files from Linux kernel which are hard to
> > > > > > > > > > > > > +         maintain and can usually get out-of-sync from Linux kernel. This
> > > > > > > > > > > > > +         option enables platforms to migrate to devicetree-rebasing repo where
> > > > > > > > > > > > > +         a regular sync will be maintained every major Linux kernel release
> > > > > > > > > > > > > +         cycle. However, platforms can still have some custom u-boot specific
> > > > > > > > > > > > > +         bits maintained as part of *-u-boot.dtsi files.
> > > > > > > > > > > >
> > > > > > > > > > > > My only other suggestion here is to mention that this should be set in
> > > > > > > > > > > > Kconfig, for the SoC as a whole. So I believe that means that it
> > > > > > > > > > > > should be hidden, with no string for the 'bool':
> > > > > > > > > > > >
> > > > > > > > > > > >       bool  # Enable use of devicetree imported from Linux kernel release
> > > > > > > > > > >
> > > > > > > > > > > I think we can just keep prompting for it now, to make the transition
> > > > > > > > > > > easier, before this option just goes away in time, hopefully.
> > > > > > > > > > >
> > > > > > > > > > > > Also, this doesn't seem to work for me. Before this series I get these
> > > > > > > > > > > > files when building firefly-rk3399:
> > > > > > > > > > > >
> > > > > > > > > > > > rk3399-eaidk-610.dtb            rk3399-khadas-edge-v.dtb
> > > > > > > > > > > > rk3399-orangepi.dtb        rk3399-rock-pi-4a.dtb
> > > > > > > > > > > > rk3399-evb.dtb                  rk3399-leez-p710.dtb
> > > > > > > > > > > > rk3399-pinebook-pro.dtb    rk3399-rock-pi-4c.dtb
> > > > > > > > > > > > rk3399-ficus.dtb                rk3399-nanopc-t4.dtb
> > > > > > > > > > > > rk3399-pinephone-pro.dtb   rk3399-rockpro64.dtb
> > > > > > > > > > > > rk3399-firefly.dtb              rk3399-nanopi-m4-2gb.dtb
> > > > > > > > > > > > rk3399pro-rock-pi-n10.dtb  rk3399-roc-pc.dtb
> > > > > > > > > > > > rk3399-gru-bob.dtb              rk3399-nanopi-m4b.dtb
> > > > > > > > > > > > rk3399-puma-haikou.dtb     rk3399-roc-pc-mezzanine.dtb
> > > > > > > > > > > > rk3399-gru-kevin.dtb            rk3399-nanopi-m4.dtb
> > > > > > > > > > > > rk3399-rock-4c-plus.dtb
> > > > > > > > > > > > rk3399-khadas-edge-captain.dtb  rk3399-nanopi-neo4.dtb    rk3399-rock-4se.dtb
> > > > > > > > > > > > rk3399-khadas-edge.dtb          rk3399-nanopi-r4s.dtb     rk3399-rock960.dtb
> > > > > > > > > > > >
> > > > > > > > > > > > Afterwards I get this:
> > > > > > > > > > > >
> > > > > > > > > > > > make[3]: *** No rule to make target
> > > > > > > > > > > > 'dts/arch/arm64/rk3399-firefly.dtb', needed by 'dtbs'.  Stop.
> > > > > > > > > > > >
> > > > > > > > > > > > So I set this manually for that one board:
> > > > > > > > > > > >
> > > > > > > > > > > > CONFIG_DEFAULT_DEVICE_TREE="rockchip/rk3399-firefly"
> > > > > > > > > > > >
> > > > > > > > > > > > and get:
> > > > > > > > > > > >
> > > > > > > > > > > > make[3]: *** No rule to make target
> > > > > > > > > > > > 'dts/arch/arm64/rockchip/rk3399-firefly.dtb', needed by 'dtbs'.  Stop.
> > > > > > > > > > > >
> > > > > > > > > > > > I am not sure how to fix this, nor how this can be made to build all
> > > > > > > > > > > > the DTs for rk3399, as it does today.
> > > > > > > > > > >
> > > > > > > > > > > Looking at the patch for amlogic boards, you need to make the link to
> > > > > > > > > > > devicetree-rebasing inside dts/...
> > > > > > > > > >
> > > > > > > > > > OK, let me give up on rk3399 for now...that doesn't seem to work even
> > > > > > > > > > with the link.
> > > > > > > > > >
> > > > > > > > > > Using odroid-c2 with -next I see:
> > > > > > > > > >
> > > > > > > > > > $ ls /tmp/b/odroid-c2/arch/arm/dts/
> > > > > > > > > > meson-a1-ad401.dtb                 meson-g12b-odroid-n2l.dtb
> > > > > > > > > >     meson-gxl-s905x-libretech-cc.dtb
> > > > > > > > > > meson-axg-jethome-jethub-j100.dtb  meson-g12b-odroid-n2-plus.dtb
> > > > > > > > > >     meson-gxl-s905x-libretech-cc-v2.dtb
> > > > > > > > > > meson-axg-s400.dtb                 meson-g12b-radxa-zero2.dtb
> > > > > > > > > >     meson-gxl-s905x-p212.dtb
> > > > > > > > > > meson-g12a-radxa-zero.dtb          meson-gxbb-kii-pro.dtb
> > > > > > > > > >     meson-gxm-gt1-ultimate.dtb
> > > > > > > > > > meson-g12a-sei510.dtb              meson-gxbb-nanopi-k2.dtb
> > > > > > > > > >     meson-gxm-khadas-vim2.dtb
> > > > > > > > > > meson-g12a-u200.dtb                meson-gxbb-odroidc2.dtb
> > > > > > > > > >     meson-gxm-s912-libretech-pc.dtb
> > > > > > > > > > meson-g12b-a311d-bananapi-m2s.dtb  meson-gxbb-p200.dtb
> > > > > > > > > >     meson-gxm-wetek-core2.dtb
> > > > > > > > > > meson-g12b-a311d-khadas-vim3.dtb   meson-gxbb-p201.dtb
> > > > > > > > > >     meson-sm1-bananapi-m2-pro.dtb
> > > > > > > > > > meson-g12b-bananapi-cm4-cm4io.dtb  meson-gxbb-wetek-hub.dtb
> > > > > > > > > >     meson-sm1-bananapi-m5.dtb
> > > > > > > > > > meson-g12b-gsking-x.dtb            meson-gxbb-wetek-play2.dtb
> > > > > > > > > >     meson-sm1-khadas-vim3l.dtb
> > > > > > > > > > meson-g12b-gtking.dtb              meson-gxl-s805x-libretech-ac.dtb
> > > > > > > > > >     meson-sm1-odroid-c4.dtb
> > > > > > > > > > meson-g12b-gtking-pro.dtb          meson-gxl-s905d-libretech-pc.dtb
> > > > > > > > > >     meson-sm1-odroid-hc4.dtb
> > > > > > > > > > meson-g12b-odroid-go-ultra.dtb
> > > > > > > > > > meson-gxl-s905w-jethome-jethub-j80.dtb  meson-sm1-sei610.dtb
> > > > > > > > > > meson-g12b-odroid-n2.dtb           meson-gxl-s905x-khadas-vim.dtb
> > > > > > > > > > $
> > > > > > > > > > With this series (sort of, since I am really not sure how to
> > > > > > > > > > cherry-pick the commits from the PR) I see nothing:
> > > > > > > > > >
> > > > > > > > > > $ ls /tmp/b/odroid-c2/arch/arm/dts/
> > > > > > > > > > $
> > > > > > > > > >
> > > > > > > > > > This shows some of the files:
> > > > > > > > > >
> > > > > > > > > > $ find /tmp/b/odroid-c2/ -name "*.dtb"
> > > > > > > > > > /tmp/b/odroid-c2/dts/dt.dtb
> > > > > > > > > > /tmp/b/odroid-c2/dts/arch/arm64/amlogic/meson-gxbb-odroidc2.dtb
> > > > > > > > > > /tmp/b/odroid-c2/dts/arch/arm64/amlogic/meson-gxbb-nanopi-k2.dtb
> > > > > > > > > > /tmp/b/odroid-c2/dts/arch/arm64/amlogic/meson-gxbb-wetek-play2.dtb
> > > > > > > > > > /tmp/b/odroid-c2/dts/arch/arm64/amlogic/meson-gxbb-kii-pro.dtb
> > > > > > > > > > /tmp/b/odroid-c2/dts/arch/arm64/amlogic/meson-gxbb-p200.dtb
> > > > > > > > > > /tmp/b/odroid-c2/dts/arch/arm64/amlogic/meson-gxbb-p201.dtb
> > > > > > > > > > /tmp/b/odroid-c2/dts/arch/arm64/amlogic/meson-gxbb-wetek-hub.dtb
> > > > > > > > > > /tmp/b/odroid-c2/u-boot.dtb
> > > > > > > > > >
> > > > > > > > > > but where are the rest? Also, is it possible to put the output .dtb
> > > > > > > > > > files into the same directory? Otherwise we may have some pain with
> > > > > > > > > > binman.
> > > > > > > > >
> > > > > > > > > What do you mean by same directory? But maybe also, what's an example of
> > > > > > > > > a board you think might end up having problems? Converting that in a
> > > > > > > > > follow-up series is likely a good idea, to highlight and address these
> > > > > > > > > issues sooner rather than later.#
> > > > > > > >
> > > > > > > > Today the .dtb files go into arch/arm/dts - so it would be easier if
> > > > > > > > this series could do the same.
> > > > > > >
> > > > > > > The kbuild infrastructure keeps the dtb alongside dts files which is
> > > > > > > the preferred way too as otherwise it would be complicated to locate
> > > > > > > DT files for the users. Also, we have to move towards Linux DT
> > > > > > > directory structure and thereby the tools like binman have to be
> > > > > > > adjusted. I will do that when I get to migrating SoCs supporting
> > > > > > > binman.
> > > > > >
> > > > > > OK, I want to stop here and rethink this. This is the path taken so
> > > > > > far, I believe:
> > > > > >
> > > > > > 1. We want to use devicetree files taken from Linux and
> > > > > > devicetree-rebasing provides these
> > > > >
> > > > > Yes.
> > > > >
> > > > > > 2. We want to use 'git subtree' to avoid needing a script to do the
> > > > > > sync / create a commit
> > > > >
> > > > > No. We want to use 'git subtree' to avoid having to use git submodules.
> > >
> > > Well that is what I understood from Sumit, when I asked about a
> > > script. I imagine a 100-line Python script could do the same as:
> > >
> > >    git subtree pull --prefix devicetree-rebasing
> > > git://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git
> > > <release-tag> --squash
> > >
> > > and it could also put the files in the right place for U-Boot.
> >
> > I've been saying in various places for years that I want to move away
> > from arch/*/dts being where we have the "just a copy" dts files and have
> > them somewhere else so they are easier to manage and differentiate our
> > changes / additions. So arch/*/dts cannot be some hard-coded "right"
> > path.
>
> OK
>
> >
> > > > > > 3. But this leaves us with a directory structure which doesn't match
> > > > > > U-Boot (no script to fix it up)
> > > > >
> > > > > No. We intentionally abandon arch/*/dts because it's so full of
> > > > > out of date files and never fully re-synced, only re-synced ad-hoc.
> > >
> > > I mean that the dir structure doesn't match. I am not worried about
> > > keeping arch/*/dts but I want the same structure somewhere else, e.g.
> > > dtr/arch/*/dts
> >
> > And what I want here is to match the same structure everyone that's not
> > U-Boot uses. For better or worse no one else seems to have gone with
> > "treat aarch64 as just another ARM", and then the vendor directory
> > structure only makes that more obviously a mismatch. We need to follow
> > what everyone else uses, and developers familiar with other projects
> > will expect to see.
>
> So you are saying that U-Boot should move to what Linux uses. I agree
> that seems like the best approach, so let's do it.
>
> >
> > > > > > 4. So we deal with that by skipping the build rules and using CONFIG
> > > > > > options to select what is built
> > > > > > 5. So now we cannot build all the files for an SoC, just the ones that
> > > > > > are in the CONFIG options
> > > > > > 6. Linux doesn't actually use devicetree-rebasing itself, so doesn't
> > > > > > have this problem
> > > > >
> > > > > No. devicetree-rebasing skips the Makefiles because they're part of the
> > > > > kernel. We couldn't re-use them ourselves because we don't have the same
> > > > > CONFIG names the kernel does. And Sumit has not replicated the logic we
> > > > > have under arch/*/dts/Makefile today because I've asked him not to, and
> > > > > we'll figure out what subsets of that logic make sense to add back in as
> > > > > a second step not a first step.
> > >
> > > Again, you are missing my point. I am not suggesting using Linux's
> > > build rules, just explaining why Linux doesn't have the problem we
> > > would be creating here.
> > >
> > > > > > So this is heading in the wrong direction. Nor is it clear that this
> > > > > > would just be a temporary problem.
> > > > >
> > > > > A previous iteration of this series built all of the dtb files for the
> > > > > SoC that Sumit has migrated with this series, but then dropped it.
> > >
> > > Oh.
> > >
> > > > >
> > > > > [snip]
> > > > > > I would like to do this series properly, maintaining the SoC-specific
> > > > > > build rules, not removing what I see as an important feature. It
> > > > > > should not be that difficult to figure out and I am happy to help with
> > > > > > it.
> > > > >
> > > > > The problem is that the rest of us do not understand the use case you're
> > > > > describing where a dtb file that would be useful in a build is not
> > > > > already in the list to build. The only one of those use cases I
> > > > > understand thus far is the exynos4 (iirc) case you mentioned previously
> > > > > where yes, really, one defconfig + appending board.dtb is fine, or fine
> > > > > enough. It's not that far off of the SPL_LOAD_FIT case, but there we
> > > > > know what to build already.
> > >
> > > Perhaps the problem is that the rest of you think of the build as all
> > > happening in U-Boot, similar to the proposed 'make image.fit' that I
> > > am trying to add to Linux.
> > >
> > > But packaging can be (and often is) a separate step from building.
> > > Linux has no packaging mechanism today...it just builds everything
> > > (including all DTs) and stops.
> > >
> > > We should be able to pick up whatever .dtb files we want and use them
> > > in an image.
> > >
> > > > > And I guess trying to tie things up, that's my puzzle. SPL_LOAD_FIT is
> > > > > how I see the use case you talk about being solved, if a full U-Boot is
> > > > > generic enough for N boards, SPL_LOAD_FIT does the right thing (in this
> > > > > non-bloblist DTB, non-reusing-OS-inntended DTB world). I really don't
> > > > > knnow how many modern SoCs can take a literal concatenated DTB and even
> > > > > in those cases I don't get why that's the win we want now? 1 build to N
> > > > > binaries?
> > >
> > > Yes SPL_LOAD_FIT is fine although in practice we will likely need SPL
> > > to use the correct DT as well, so the DT will need to be determined in
> > > TPL, perhaps.
> >
> > I mean, SPL_LOAD_FIT still can handle this case, with a call to the
> > function to re-parse the tree, when needed. I thought we did this today
> > even, but perhaps I'm confusing my options here.
> >
> > > But anyway, this works OK with rk3399, for example. We need to support
> > > this use case.
> > >
> > > Also, it is pretty easy. We just need to stick with the dir structure
> > > we have today and copy our existing Makefiles into that dir. Or change
> > > to the kernel dir structure and use that. Or do one, then the other.
> >
> > I'm sorry, I don't understand what directory structure has to do with
> > "build more dtbs". For the cases where it makes sense to, yes, we can
> > build more dtbs, based on the SoC. I'm setting aside entirely the
> > discussion on what SoCs that works for, for another thread.
>
> Well you said above that we should switch to the kernel dir structure,
> so I believe that issue is resolved.
>
> 'build more dtbs' means build all the DTBs for an SoC, not just a
> selection that a particular board vendor decided on.
>
> >
> > Perhaps an issue here is that much like the kernel "install" target, we
> > need an "install" target too, so that whatever dtbs we build can be
> > more easily found for external packaging, but whatever tooling it is
> > that wants it? And perhaps this is part of the problem, tooling that
> > expects to pull things out of the object directory rather than an
> > "installed" directory?
>
> This is where binman comes in. It can run as part of U-Boot build, to
> build a few default firmware images. Then it can be run *later*,
> outside the U-Boot build, with an augmented or more targeted image
> definition, with mostly the same input files, to pull together images
> for specific uses. As you say, the input files need to be in a defined
> location, which they are today, for the most part.
>
> So even if a particular board only uses one DT, all the DTs for that
> SoC are built and so can be used in that final-packaging step. Without
> that build, there is no way to get the required .dtb files, other than
> building every board one by one and then pulling out the .dtb files or
> something weird like that.
>
> Note that this works independently of whether OF_LIST is used, etc.
>
> >
> > > > > But even then, I don't object to adding those rules to the Makefiles. If
> > > > > it works it works. I object to adding them when they don't work.
> > >
> > > What do you mean by 'work'? With this series as is, it simply isn't
> > > possible to add Makefile rules, as they are ignored. Am I missing
> > > something?

That's not correct. Just to demonstrate this I have gone a step
further to switch all Amlogic SoCs to use DT rebasing tree here [1].
As I have said before, the Makefile rules were just dropped based on
Tom's feedback. However, if they really serve the existing tools from
a packaging perspective I am open to migrate them as demonstrated here
[2]. As before it will build all the DTBs corresponding to all the
Amlogic SoCs supported in U-Boot for a single board defconfig.

[1] https://github.com/b49020/u-boot/commits/dt_for_test/
[2] https://github.com/b49020/u-boot/commit/ca5525673cdcafd71b51b48fe33c076f97a287fe

> >
> > Yes, I think you're missing something. Perhaps you need to publish a WIP
> > tree somewhere so someone can see what you're doing as it sounds like
> > you're not able to add another SoC of any type on top of Sumit's tree
> > and have it work.
>
> The current -next source builds dtb files based on the SoC, for the
> most part. I sent a series to clean that up a bit[1], but it is mostly
> there.
>
> From the above it seems like the plan could be:
> 1. Move arm64 .dts files to arch/arm64/dts/<vendor>/... and adjust
> Makefiles accordingly

As I said before it will be a redundant effort when you can just drop
them in favour of dts/arch/arm64/<vendor>/.. We just have to maintain
the *-u-boot.dtsi file in arch/*/dts/.

> 2. Choose a directory target for devicetree-rebasing. I see that
> 'barebox' uses 'dts' which seems better to me than
> 'devicetree-rebasing/src/'.

Actually as part of this patch-set we try to reuse the U-Boot 'dts'
directory (via dts/arch/arm64/<vendor> soft links) since it was
already taken for U-Boot specific DT Makefile. However, I am open to
renaming 'devicetree-rebasing' but to me that sounds more clear that
we maintain a specific subtree within U-Boot.

> Actually barebox even seems to have
> scripts for handling all of this [2]??

That script is just doing the same thing as the DTC import script. git
subtree is just another standardized way to do it.

[1] https://www.barebox.org/doc/latest/devicetree/index.html#barebox-device-trees

> 3. Adjust the build system to use the dts/ directory for .dts files
> when OF_UPSTREAM is enabled
>
> Then it will be easy. People can enable OF_UPSTREAM for an SoC
> (without changing DEFAULT_DEVICE_TREE)

I am still not sure what we will gain via keeping DEFAULT_DEVICE_TREE
the same. However, without a per vendor directory Makefile like:
dts/arch/arm64/<vendor>/Makefile it won't be possible. But to do that
we won't be able to softlink vendor directories from DT rebasing tree
but rather have to softlink every board DTS file which is much more
painful.

> and will get the same behaviour
> as now, just with upstream .dts files. All the .dts files for an SoC
> are built, as now, just as Linux does. We can continue cleaning up the
> DT build rules as time permits.

I will reiterate here, we can decide to add Makefile rules on a case
by case basis. If there is a need (from packaging perspective or a
particular SoC supports a generic U-Boot image) then we should be able
to add them. The cleanup would be automatically part of the process as
we switch SoCs to OF_UPSTREAM.

-Sumit

>
> Regards,
> Simon
>
> [1] http://patchwork.ozlabs.org/project/uboot/list/?series=388154
> [2] https://git.pengutronix.de/cgit/barebox/tree/dts
Tom Rini Jan. 2, 2024, 6:06 p.m. UTC | #18 
On Tue, Jan 02, 2024 at 09:07:48PM +0530, Sumit Garg wrote:
> On Tue, 2 Jan 2024 at 19:36, Simon Glass <sjg@chromium.org> wrote:
[snip]
> > 2. Choose a directory target for devicetree-rebasing. I see that
> > 'barebox' uses 'dts' which seems better to me than
> > 'devicetree-rebasing/src/'.
> 
> Actually as part of this patch-set we try to reuse the U-Boot 'dts'
> directory (via dts/arch/arm64/<vendor> soft links) since it was
> already taken for U-Boot specific DT Makefile. However, I am open to
> renaming 'devicetree-rebasing' but to me that sounds more clear that
> we maintain a specific subtree within U-Boot.

Looking at what little is in dts/ here today could we just use subtree
and pop the contents under there, and basically ignore the
project-provided Makefile? Or is that not really worth it?
Simon Glass Jan. 2, 2024, 11:54 p.m. UTC | #19 
Hi Tom,

On Tue, Jan 2, 2024 at 8:10 AM Tom Rini <trini@konsulko.com> wrote:
>
> On Tue, Jan 02, 2024 at 07:06:40AM -0700, Simon Glass wrote:
> > Hi Tom,
> >
> > On Mon, Jan 1, 2024 at 4:35 PM Tom Rini <trini@konsulko.com> wrote:
> > >
> > > On Mon, Jan 01, 2024 at 03:32:41PM -0700, Simon Glass wrote:
> > > > Hi Mark, Tom,
> > > >
> > > > On Sun, Dec 31, 2023 at 5:33 PM Mark Kettenis <mark.kettenis@xs4all.nl> wrote:
> > > > >
> > > > > > Date: Sun, 31 Dec 2023 15:39:53 -0500
> > > > > > From: Tom Rini <trini@konsulko.com>
> > > > > >
> > > > > > On Sun, Dec 31, 2023 at 07:28:52AM -0700, Simon Glass wrote:
> > > > > > > Hi Sumit,
> > > > > > >
> > > > > > > On Fri, Dec 29, 2023 at 8:30 AM Sumit Garg <sumit.garg@linaro.org> wrote:
> > > > > > > >
> > > > > > > > On Fri, 29 Dec 2023 at 01:18, Simon Glass <sjg@chromium.org> wrote:
> > > > > > > > >
> > > > > > > > > Hi Tom,
> > > > > > > > >
> > > > > > > > > On Thu, Dec 28, 2023 at 3:54 PM Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > >
> > > > > > > > > > On Thu, Dec 28, 2023 at 03:09:12PM +0000, Simon Glass wrote:
> > > > > > > > > > > Hi Tom, Sumit,
> > > > > > > > > > >
> > > > > > > > > > > On Thu, Dec 28, 2023 at 2:03 PM Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > On Thu, Dec 28, 2023 at 01:37:26PM +0000, Simon Glass wrote:
> > > > > > > > > > > > > Hi Sumit,
> > > > > > > > > > > > >
> > > > > > > > > > > > > On Thu, Dec 28, 2023 at 11:58 AM Sumit Garg <sumit.garg@linaro.org> wrote:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Allow platform owners to mirror devicetree files from devitree-rebasing
> > > > > > > > > > > > > > directory into dts/arch/$(ARCH) (special case for dts/arch/arm64). Then
> > > > > > > > > > > > > > build then along with any *-u-boot.dtsi file present in arch/$(ARCH)/dts
> > > > > > > > > > > > > > directory. Also add a new Makefile for arm64.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > This will help easy migration for platforms which currently are compliant
> > > > > > > > > > > > > > with upstream Linux kernel devicetree files.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Signed-off-by: Sumit Garg <sumit.garg@linaro.org>
> > > > > > > > > > > > > > ---
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Changes in v3:
> > > > > > > > > > > > > > --------------
> > > > > > > > > > > > > > - Minor commit message update
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Changes in v2:
> > > > > > > > > > > > > > --------------
> > > > > > > > > > > > > > - s/DEVICE_TREE_LOC/dt_dir/ and s/U-boot/U-Boot/
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >  dts/Kconfig             | 11 +++++++++++
> > > > > > > > > > > > > >  dts/Makefile            | 17 ++++++++++++++---
> > > > > > > > > > > > > >  dts/arch/arm64/Makefile | 14 ++++++++++++++
> > > > > > > > > > > > > >  3 files changed, 39 insertions(+), 3 deletions(-)
> > > > > > > > > > > > > >  create mode 100644 dts/arch/arm64/Makefile
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > diff --git a/dts/Kconfig b/dts/Kconfig
> > > > > > > > > > > > > > index 00c0aeff893..e58c1c6f2ab 100644
> > > > > > > > > > > > > > --- a/dts/Kconfig
> > > > > > > > > > > > > > +++ b/dts/Kconfig
> > > > > > > > > > > > > > @@ -85,6 +85,17 @@ config OF_LIVE
> > > > > > > > > > > > > >           enables a live tree which is available after relocation,
> > > > > > > > > > > > > >           and can be adjusted as needed.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > +config OF_UPSTREAM
> > > > > > > > > > > > > > +       bool "Enable use of devicetree imported from Linux kernel release"
> > > > > > > > > > > > > > +       help
> > > > > > > > > > > > > > +         Traditionally, U-Boot platforms used to have their custom devicetree
> > > > > > > > > > > > > > +         files or copy devicetree files from Linux kernel which are hard to
> > > > > > > > > > > > > > +         maintain and can usually get out-of-sync from Linux kernel. This
> > > > > > > > > > > > > > +         option enables platforms to migrate to devicetree-rebasing repo where
> > > > > > > > > > > > > > +         a regular sync will be maintained every major Linux kernel release
> > > > > > > > > > > > > > +         cycle. However, platforms can still have some custom u-boot specific
> > > > > > > > > > > > > > +         bits maintained as part of *-u-boot.dtsi files.
> > > > > > > > > > > > >
> > > > > > > > > > > > > My only other suggestion here is to mention that this should be set in
> > > > > > > > > > > > > Kconfig, for the SoC as a whole. So I believe that means that it
> > > > > > > > > > > > > should be hidden, with no string for the 'bool':
> > > > > > > > > > > > >
> > > > > > > > > > > > >       bool  # Enable use of devicetree imported from Linux kernel release
> > > > > > > > > > > >
> > > > > > > > > > > > I think we can just keep prompting for it now, to make the transition
> > > > > > > > > > > > easier, before this option just goes away in time, hopefully.
> > > > > > > > > > > >
> > > > > > > > > > > > > Also, this doesn't seem to work for me. Before this series I get these
> > > > > > > > > > > > > files when building firefly-rk3399:
> > > > > > > > > > > > >
> > > > > > > > > > > > > rk3399-eaidk-610.dtb            rk3399-khadas-edge-v.dtb
> > > > > > > > > > > > > rk3399-orangepi.dtb        rk3399-rock-pi-4a.dtb
> > > > > > > > > > > > > rk3399-evb.dtb                  rk3399-leez-p710.dtb
> > > > > > > > > > > > > rk3399-pinebook-pro.dtb    rk3399-rock-pi-4c.dtb
> > > > > > > > > > > > > rk3399-ficus.dtb                rk3399-nanopc-t4.dtb
> > > > > > > > > > > > > rk3399-pinephone-pro.dtb   rk3399-rockpro64.dtb
> > > > > > > > > > > > > rk3399-firefly.dtb              rk3399-nanopi-m4-2gb.dtb
> > > > > > > > > > > > > rk3399pro-rock-pi-n10.dtb  rk3399-roc-pc.dtb
> > > > > > > > > > > > > rk3399-gru-bob.dtb              rk3399-nanopi-m4b.dtb
> > > > > > > > > > > > > rk3399-puma-haikou.dtb     rk3399-roc-pc-mezzanine.dtb
> > > > > > > > > > > > > rk3399-gru-kevin.dtb            rk3399-nanopi-m4.dtb
> > > > > > > > > > > > > rk3399-rock-4c-plus.dtb
> > > > > > > > > > > > > rk3399-khadas-edge-captain.dtb  rk3399-nanopi-neo4.dtb    rk3399-rock-4se.dtb
> > > > > > > > > > > > > rk3399-khadas-edge.dtb          rk3399-nanopi-r4s.dtb     rk3399-rock960.dtb
> > > > > > > > > > > > >
> > > > > > > > > > > > > Afterwards I get this:
> > > > > > > > > > > > >
> > > > > > > > > > > > > make[3]: *** No rule to make target
> > > > > > > > > > > > > 'dts/arch/arm64/rk3399-firefly.dtb', needed by 'dtbs'.  Stop.
> > > > > > > > > > > > >
> > > > > > > > > > > > > So I set this manually for that one board:
> > > > > > > > > > > > >
> > > > > > > > > > > > > CONFIG_DEFAULT_DEVICE_TREE="rockchip/rk3399-firefly"
> > > > > > > > > > > > >
> > > > > > > > > > > > > and get:
> > > > > > > > > > > > >
> > > > > > > > > > > > > make[3]: *** No rule to make target
> > > > > > > > > > > > > 'dts/arch/arm64/rockchip/rk3399-firefly.dtb', needed by 'dtbs'.  Stop.
> > > > > > > > > > > > >
> > > > > > > > > > > > > I am not sure how to fix this, nor how this can be made to build all
> > > > > > > > > > > > > the DTs for rk3399, as it does today.
> > > > > > > > > > > >
> > > > > > > > > > > > Looking at the patch for amlogic boards, you need to make the link to
> > > > > > > > > > > > devicetree-rebasing inside dts/...
> > > > > > > > > > >
> > > > > > > > > > > OK, let me give up on rk3399 for now...that doesn't seem to work even
> > > > > > > > > > > with the link.
> > > > > > > > > > >
> > > > > > > > > > > Using odroid-c2 with -next I see:
> > > > > > > > > > >
> > > > > > > > > > > $ ls /tmp/b/odroid-c2/arch/arm/dts/
> > > > > > > > > > > meson-a1-ad401.dtb                 meson-g12b-odroid-n2l.dtb
> > > > > > > > > > >     meson-gxl-s905x-libretech-cc.dtb
> > > > > > > > > > > meson-axg-jethome-jethub-j100.dtb  meson-g12b-odroid-n2-plus.dtb
> > > > > > > > > > >     meson-gxl-s905x-libretech-cc-v2.dtb
> > > > > > > > > > > meson-axg-s400.dtb                 meson-g12b-radxa-zero2.dtb
> > > > > > > > > > >     meson-gxl-s905x-p212.dtb
> > > > > > > > > > > meson-g12a-radxa-zero.dtb          meson-gxbb-kii-pro.dtb
> > > > > > > > > > >     meson-gxm-gt1-ultimate.dtb
> > > > > > > > > > > meson-g12a-sei510.dtb              meson-gxbb-nanopi-k2.dtb
> > > > > > > > > > >     meson-gxm-khadas-vim2.dtb
> > > > > > > > > > > meson-g12a-u200.dtb                meson-gxbb-odroidc2.dtb
> > > > > > > > > > >     meson-gxm-s912-libretech-pc.dtb
> > > > > > > > > > > meson-g12b-a311d-bananapi-m2s.dtb  meson-gxbb-p200.dtb
> > > > > > > > > > >     meson-gxm-wetek-core2.dtb
> > > > > > > > > > > meson-g12b-a311d-khadas-vim3.dtb   meson-gxbb-p201.dtb
> > > > > > > > > > >     meson-sm1-bananapi-m2-pro.dtb
> > > > > > > > > > > meson-g12b-bananapi-cm4-cm4io.dtb  meson-gxbb-wetek-hub.dtb
> > > > > > > > > > >     meson-sm1-bananapi-m5.dtb
> > > > > > > > > > > meson-g12b-gsking-x.dtb            meson-gxbb-wetek-play2.dtb
> > > > > > > > > > >     meson-sm1-khadas-vim3l.dtb
> > > > > > > > > > > meson-g12b-gtking.dtb              meson-gxl-s805x-libretech-ac.dtb
> > > > > > > > > > >     meson-sm1-odroid-c4.dtb
> > > > > > > > > > > meson-g12b-gtking-pro.dtb          meson-gxl-s905d-libretech-pc.dtb
> > > > > > > > > > >     meson-sm1-odroid-hc4.dtb
> > > > > > > > > > > meson-g12b-odroid-go-ultra.dtb
> > > > > > > > > > > meson-gxl-s905w-jethome-jethub-j80.dtb  meson-sm1-sei610.dtb
> > > > > > > > > > > meson-g12b-odroid-n2.dtb           meson-gxl-s905x-khadas-vim.dtb
> > > > > > > > > > > $
> > > > > > > > > > > With this series (sort of, since I am really not sure how to
> > > > > > > > > > > cherry-pick the commits from the PR) I see nothing:
> > > > > > > > > > >
> > > > > > > > > > > $ ls /tmp/b/odroid-c2/arch/arm/dts/
> > > > > > > > > > > $
> > > > > > > > > > >
> > > > > > > > > > > This shows some of the files:
> > > > > > > > > > >
> > > > > > > > > > > $ find /tmp/b/odroid-c2/ -name "*.dtb"
> > > > > > > > > > > /tmp/b/odroid-c2/dts/dt.dtb
> > > > > > > > > > > /tmp/b/odroid-c2/dts/arch/arm64/amlogic/meson-gxbb-odroidc2.dtb
> > > > > > > > > > > /tmp/b/odroid-c2/dts/arch/arm64/amlogic/meson-gxbb-nanopi-k2.dtb
> > > > > > > > > > > /tmp/b/odroid-c2/dts/arch/arm64/amlogic/meson-gxbb-wetek-play2.dtb
> > > > > > > > > > > /tmp/b/odroid-c2/dts/arch/arm64/amlogic/meson-gxbb-kii-pro.dtb
> > > > > > > > > > > /tmp/b/odroid-c2/dts/arch/arm64/amlogic/meson-gxbb-p200.dtb
> > > > > > > > > > > /tmp/b/odroid-c2/dts/arch/arm64/amlogic/meson-gxbb-p201.dtb
> > > > > > > > > > > /tmp/b/odroid-c2/dts/arch/arm64/amlogic/meson-gxbb-wetek-hub.dtb
> > > > > > > > > > > /tmp/b/odroid-c2/u-boot.dtb
> > > > > > > > > > >
> > > > > > > > > > > but where are the rest? Also, is it possible to put the output .dtb
> > > > > > > > > > > files into the same directory? Otherwise we may have some pain with
> > > > > > > > > > > binman.
> > > > > > > > > >
> > > > > > > > > > What do you mean by same directory? But maybe also, what's an example of
> > > > > > > > > > a board you think might end up having problems? Converting that in a
> > > > > > > > > > follow-up series is likely a good idea, to highlight and address these
> > > > > > > > > > issues sooner rather than later.#
> > > > > > > > >
> > > > > > > > > Today the .dtb files go into arch/arm/dts - so it would be easier if
> > > > > > > > > this series could do the same.
> > > > > > > >
> > > > > > > > The kbuild infrastructure keeps the dtb alongside dts files which is
> > > > > > > > the preferred way too as otherwise it would be complicated to locate
> > > > > > > > DT files for the users. Also, we have to move towards Linux DT
> > > > > > > > directory structure and thereby the tools like binman have to be
> > > > > > > > adjusted. I will do that when I get to migrating SoCs supporting
> > > > > > > > binman.
> > > > > > >
> > > > > > > OK, I want to stop here and rethink this. This is the path taken so
> > > > > > > far, I believe:
> > > > > > >
> > > > > > > 1. We want to use devicetree files taken from Linux and
> > > > > > > devicetree-rebasing provides these
> > > > > >
> > > > > > Yes.
> > > > > >
> > > > > > > 2. We want to use 'git subtree' to avoid needing a script to do the
> > > > > > > sync / create a commit
> > > > > >
> > > > > > No. We want to use 'git subtree' to avoid having to use git submodules.
> > > >
> > > > Well that is what I understood from Sumit, when I asked about a
> > > > script. I imagine a 100-line Python script could do the same as:
> > > >
> > > >    git subtree pull --prefix devicetree-rebasing
> > > > git://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git
> > > > <release-tag> --squash
> > > >
> > > > and it could also put the files in the right place for U-Boot.
> > >
> > > I've been saying in various places for years that I want to move away
> > > from arch/*/dts being where we have the "just a copy" dts files and have
> > > them somewhere else so they are easier to manage and differentiate our
> > > changes / additions. So arch/*/dts cannot be some hard-coded "right"
> > > path.
> >
> > OK
> >
> > >
> > > > > > > 3. But this leaves us with a directory structure which doesn't match
> > > > > > > U-Boot (no script to fix it up)
> > > > > >
> > > > > > No. We intentionally abandon arch/*/dts because it's so full of
> > > > > > out of date files and never fully re-synced, only re-synced ad-hoc.
> > > >
> > > > I mean that the dir structure doesn't match. I am not worried about
> > > > keeping arch/*/dts but I want the same structure somewhere else, e.g.
> > > > dtr/arch/*/dts
> > >
> > > And what I want here is to match the same structure everyone that's not
> > > U-Boot uses. For better or worse no one else seems to have gone with
> > > "treat aarch64 as just another ARM", and then the vendor directory
> > > structure only makes that more obviously a mismatch. We need to follow
> > > what everyone else uses, and developers familiar with other projects
> > > will expect to see.
> >
> > So you are saying that U-Boot should move to what Linux uses. I agree
> > that seems like the best approach, so let's do it.
> >
> > >
> > > > > > > 4. So we deal with that by skipping the build rules and using CONFIG
> > > > > > > options to select what is built
> > > > > > > 5. So now we cannot build all the files for an SoC, just the ones that
> > > > > > > are in the CONFIG options
> > > > > > > 6. Linux doesn't actually use devicetree-rebasing itself, so doesn't
> > > > > > > have this problem
> > > > > >
> > > > > > No. devicetree-rebasing skips the Makefiles because they're part of the
> > > > > > kernel. We couldn't re-use them ourselves because we don't have the same
> > > > > > CONFIG names the kernel does. And Sumit has not replicated the logic we
> > > > > > have under arch/*/dts/Makefile today because I've asked him not to, and
> > > > > > we'll figure out what subsets of that logic make sense to add back in as
> > > > > > a second step not a first step.
> > > >
> > > > Again, you are missing my point. I am not suggesting using Linux's
> > > > build rules, just explaining why Linux doesn't have the problem we
> > > > would be creating here.
> > > >
> > > > > > > So this is heading in the wrong direction. Nor is it clear that this
> > > > > > > would just be a temporary problem.
> > > > > >
> > > > > > A previous iteration of this series built all of the dtb files for the
> > > > > > SoC that Sumit has migrated with this series, but then dropped it.
> > > >
> > > > Oh.
> > > >
> > > > > >
> > > > > > [snip]
> > > > > > > I would like to do this series properly, maintaining the SoC-specific
> > > > > > > build rules, not removing what I see as an important feature. It
> > > > > > > should not be that difficult to figure out and I am happy to help with
> > > > > > > it.
> > > > > >
> > > > > > The problem is that the rest of us do not understand the use case you're
> > > > > > describing where a dtb file that would be useful in a build is not
> > > > > > already in the list to build. The only one of those use cases I
> > > > > > understand thus far is the exynos4 (iirc) case you mentioned previously
> > > > > > where yes, really, one defconfig + appending board.dtb is fine, or fine
> > > > > > enough. It's not that far off of the SPL_LOAD_FIT case, but there we
> > > > > > know what to build already.
> > > >
> > > > Perhaps the problem is that the rest of you think of the build as all
> > > > happening in U-Boot, similar to the proposed 'make image.fit' that I
> > > > am trying to add to Linux.
> > > >
> > > > But packaging can be (and often is) a separate step from building.
> > > > Linux has no packaging mechanism today...it just builds everything
> > > > (including all DTs) and stops.
> > > >
> > > > We should be able to pick up whatever .dtb files we want and use them
> > > > in an image.
> > > >
> > > > > > And I guess trying to tie things up, that's my puzzle. SPL_LOAD_FIT is
> > > > > > how I see the use case you talk about being solved, if a full U-Boot is
> > > > > > generic enough for N boards, SPL_LOAD_FIT does the right thing (in this
> > > > > > non-bloblist DTB, non-reusing-OS-inntended DTB world). I really don't
> > > > > > knnow how many modern SoCs can take a literal concatenated DTB and even
> > > > > > in those cases I don't get why that's the win we want now? 1 build to N
> > > > > > binaries?
> > > >
> > > > Yes SPL_LOAD_FIT is fine although in practice we will likely need SPL
> > > > to use the correct DT as well, so the DT will need to be determined in
> > > > TPL, perhaps.
> > >
> > > I mean, SPL_LOAD_FIT still can handle this case, with a call to the
> > > function to re-parse the tree, when needed. I thought we did this today
> > > even, but perhaps I'm confusing my options here.
> > >
> > > > But anyway, this works OK with rk3399, for example. We need to support
> > > > this use case.
> > > >
> > > > Also, it is pretty easy. We just need to stick with the dir structure
> > > > we have today and copy our existing Makefiles into that dir. Or change
> > > > to the kernel dir structure and use that. Or do one, then the other.
> > >
> > > I'm sorry, I don't understand what directory structure has to do with
> > > "build more dtbs". For the cases where it makes sense to, yes, we can
> > > build more dtbs, based on the SoC. I'm setting aside entirely the
> > > discussion on what SoCs that works for, for another thread.
> >
> > Well you said above that we should switch to the kernel dir structure,
> > so I believe that issue is resolved.
> >
> > 'build more dtbs' means build all the DTBs for an SoC, not just a
> > selection that a particular board vendor decided on.
>
> Yes, what other dtbs to build is the sticking point, in a number of
> threads now.

All of the ones for the SoC.

>
> > > Perhaps an issue here is that much like the kernel "install" target, we
> > > need an "install" target too, so that whatever dtbs we build can be
> > > more easily found for external packaging, but whatever tooling it is
> > > that wants it? And perhaps this is part of the problem, tooling that
> > > expects to pull things out of the object directory rather than an
> > > "installed" directory?
> >
> > This is where binman comes in. It can run as part of U-Boot build, to
> > build a few default firmware images. Then it can be run *later*,
> > outside the U-Boot build, with an augmented or more targeted image
> > definition, with mostly the same input files, to pull together images
> > for specific uses. As you say, the input files need to be in a defined
> > location, which they are today, for the most part.
> >
> > So even if a particular board only uses one DT, all the DTs for that
> > SoC are built and so can be used in that final-packaging step. Without
> > that build, there is no way to get the required .dtb files, other than
> > building every board one by one and then pulling out the .dtb files or
> > something weird like that.
> >
> > Note that this works independently of whether OF_LIST is used, etc.
>
> How about this. When you introduce generic-rk3399_defconfig is when we
> can also have dts-$(CONFIG_ROCKCHIP_RK3399) list everything, and insist
> it be kept up to date. That to me feels like the right order to go in.
> And we can have all of the implementation details be hashed out
> elsewhere, not in the thread about fixing our nightmare about dts file
> resync.

So long as Sumit can put it back so we can use build rules, that's
fine. But removing the build rules is the sticking point for me.

>
> > > > > > But even then, I don't object to adding those rules to the Makefiles. If
> > > > > > it works it works. I object to adding them when they don't work.
> > > >
> > > > What do you mean by 'work'? With this series as is, it simply isn't
> > > > possible to add Makefile rules, as they are ignored. Am I missing
> > > > something?
> > >
> > > Yes, I think you're missing something. Perhaps you need to publish a WIP
> > > tree somewhere so someone can see what you're doing as it sounds like
> > > you're not able to add another SoC of any type on top of Sumit's tree
> > > and have it work.
> >
> > The current -next source builds dtb files based on the SoC, for the
> > most part. I sent a series to clean that up a bit[1], but it is mostly
> > there.
>
> Yes, and that relied on Rasmus' series having been merged ages ago which
> fixed up a number of "people just copypasta'd something here,
> incorrectly".  Keep that in mind as part of why I have objections here.

OK.

>
> >
> > From the above it seems like the plan could be:
> > 1. Move arm64 .dts files to arch/arm64/dts/<vendor>/... and adjust
> > Makefiles accordingly
>
> Since we're going to move everyone to being from the upstream kernel,
> that seems like unneeded churn.

What is the timeline for that move?

We are talking about 1700 lines of Makefies and I already made a good
start on part of it. So if we are going to be a few months with two
different paths, fine, but this is going to drag on for a year, I
would rather clean it up now and have a unified path for both sets of
DTs.

>
> > 2. Choose a directory target for devicetree-rebasing. I see that
> > 'barebox' uses 'dts' which seems better to me than
> > 'devicetree-rebasing/src/'. Actually barebox even seems to have
> > scripts for handling all of this [2]??
>
> They've been doing this since longer than git subtree has existed I
> believe. I suspect that much like how Rob would like to move the
> in-kernel devicetree compiler sync from a script to git subtree, barebox
> will too.

Maybe, although the first barebox dts/ commit was 2014 and subtree is
claimed to come out in 2012...but then devicetree-rebasing might be
newer, which would explain why they have 'git filter-branch' stuff in
the script.

I thought devicetree-rebasing came from Linux. Is it its own repo? So
what is the DT upstream these days??

If subtree does what we want without making U-Boot look like
Franekstein's monster, that's fine. But I don't mind having a script.

>
> > 3. Adjust the build system to use the dts/ directory for .dts files
> > when OF_UPSTREAM is enabled
> >
> > Then it will be easy. People can enable OF_UPSTREAM for an SoC
> > (without changing DEFAULT_DEVICE_TREE) and will get the same behaviour
> > as now, just with upstream .dts files. All the .dts files for an SoC
> > are built, as now, just as Linux does. We can continue cleaning up the
> > DT build rules as time permits.
>
> Maybe the unasked / unanswered question here is, why don't we put the
> subtree in to dts/ ? Just because it would make us more likely to make
> changes rather than treat it as read only?

It is an easy checkpatch check, if that is your only concern.

Regards,
Simon
Tom Rini Jan. 3, 2024, 12:41 a.m. UTC | #20 
On Tue, Jan 02, 2024 at 04:54:15PM -0700, Simon Glass wrote:
> Hi Tom,
> 
> On Tue, Jan 2, 2024 at 8:10 AM Tom Rini <trini@konsulko.com> wrote:
> >
> > On Tue, Jan 02, 2024 at 07:06:40AM -0700, Simon Glass wrote:
> > > Hi Tom,
> > >
> > > On Mon, Jan 1, 2024 at 4:35 PM Tom Rini <trini@konsulko.com> wrote:
> > > >
> > > > On Mon, Jan 01, 2024 at 03:32:41PM -0700, Simon Glass wrote:
> > > > > Hi Mark, Tom,
> > > > >
> > > > > On Sun, Dec 31, 2023 at 5:33 PM Mark Kettenis <mark.kettenis@xs4all.nl> wrote:
> > > > > >
> > > > > > > Date: Sun, 31 Dec 2023 15:39:53 -0500
> > > > > > > From: Tom Rini <trini@konsulko.com>
> > > > > > >
> > > > > > > On Sun, Dec 31, 2023 at 07:28:52AM -0700, Simon Glass wrote:
> > > > > > > > Hi Sumit,
> > > > > > > >
> > > > > > > > On Fri, Dec 29, 2023 at 8:30 AM Sumit Garg <sumit.garg@linaro.org> wrote:
> > > > > > > > >
> > > > > > > > > On Fri, 29 Dec 2023 at 01:18, Simon Glass <sjg@chromium.org> wrote:
> > > > > > > > > >
> > > > > > > > > > Hi Tom,
> > > > > > > > > >
> > > > > > > > > > On Thu, Dec 28, 2023 at 3:54 PM Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > >
> > > > > > > > > > > On Thu, Dec 28, 2023 at 03:09:12PM +0000, Simon Glass wrote:
> > > > > > > > > > > > Hi Tom, Sumit,
> > > > > > > > > > > >
> > > > > > > > > > > > On Thu, Dec 28, 2023 at 2:03 PM Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > > > >
> > > > > > > > > > > > > On Thu, Dec 28, 2023 at 01:37:26PM +0000, Simon Glass wrote:
> > > > > > > > > > > > > > Hi Sumit,
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > On Thu, Dec 28, 2023 at 11:58 AM Sumit Garg <sumit.garg@linaro.org> wrote:
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Allow platform owners to mirror devicetree files from devitree-rebasing
> > > > > > > > > > > > > > > directory into dts/arch/$(ARCH) (special case for dts/arch/arm64). Then
> > > > > > > > > > > > > > > build then along with any *-u-boot.dtsi file present in arch/$(ARCH)/dts
> > > > > > > > > > > > > > > directory. Also add a new Makefile for arm64.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > This will help easy migration for platforms which currently are compliant
> > > > > > > > > > > > > > > with upstream Linux kernel devicetree files.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Signed-off-by: Sumit Garg <sumit.garg@linaro.org>
> > > > > > > > > > > > > > > ---
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Changes in v3:
> > > > > > > > > > > > > > > --------------
> > > > > > > > > > > > > > > - Minor commit message update
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Changes in v2:
> > > > > > > > > > > > > > > --------------
> > > > > > > > > > > > > > > - s/DEVICE_TREE_LOC/dt_dir/ and s/U-boot/U-Boot/
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >  dts/Kconfig             | 11 +++++++++++
> > > > > > > > > > > > > > >  dts/Makefile            | 17 ++++++++++++++---
> > > > > > > > > > > > > > >  dts/arch/arm64/Makefile | 14 ++++++++++++++
> > > > > > > > > > > > > > >  3 files changed, 39 insertions(+), 3 deletions(-)
> > > > > > > > > > > > > > >  create mode 100644 dts/arch/arm64/Makefile
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > diff --git a/dts/Kconfig b/dts/Kconfig
> > > > > > > > > > > > > > > index 00c0aeff893..e58c1c6f2ab 100644
> > > > > > > > > > > > > > > --- a/dts/Kconfig
> > > > > > > > > > > > > > > +++ b/dts/Kconfig
> > > > > > > > > > > > > > > @@ -85,6 +85,17 @@ config OF_LIVE
> > > > > > > > > > > > > > >           enables a live tree which is available after relocation,
> > > > > > > > > > > > > > >           and can be adjusted as needed.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > +config OF_UPSTREAM
> > > > > > > > > > > > > > > +       bool "Enable use of devicetree imported from Linux kernel release"
> > > > > > > > > > > > > > > +       help
> > > > > > > > > > > > > > > +         Traditionally, U-Boot platforms used to have their custom devicetree
> > > > > > > > > > > > > > > +         files or copy devicetree files from Linux kernel which are hard to
> > > > > > > > > > > > > > > +         maintain and can usually get out-of-sync from Linux kernel. This
> > > > > > > > > > > > > > > +         option enables platforms to migrate to devicetree-rebasing repo where
> > > > > > > > > > > > > > > +         a regular sync will be maintained every major Linux kernel release
> > > > > > > > > > > > > > > +         cycle. However, platforms can still have some custom u-boot specific
> > > > > > > > > > > > > > > +         bits maintained as part of *-u-boot.dtsi files.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > My only other suggestion here is to mention that this should be set in
> > > > > > > > > > > > > > Kconfig, for the SoC as a whole. So I believe that means that it
> > > > > > > > > > > > > > should be hidden, with no string for the 'bool':
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >       bool  # Enable use of devicetree imported from Linux kernel release
> > > > > > > > > > > > >
> > > > > > > > > > > > > I think we can just keep prompting for it now, to make the transition
> > > > > > > > > > > > > easier, before this option just goes away in time, hopefully.
> > > > > > > > > > > > >
> > > > > > > > > > > > > > Also, this doesn't seem to work for me. Before this series I get these
> > > > > > > > > > > > > > files when building firefly-rk3399:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > rk3399-eaidk-610.dtb            rk3399-khadas-edge-v.dtb
> > > > > > > > > > > > > > rk3399-orangepi.dtb        rk3399-rock-pi-4a.dtb
> > > > > > > > > > > > > > rk3399-evb.dtb                  rk3399-leez-p710.dtb
> > > > > > > > > > > > > > rk3399-pinebook-pro.dtb    rk3399-rock-pi-4c.dtb
> > > > > > > > > > > > > > rk3399-ficus.dtb                rk3399-nanopc-t4.dtb
> > > > > > > > > > > > > > rk3399-pinephone-pro.dtb   rk3399-rockpro64.dtb
> > > > > > > > > > > > > > rk3399-firefly.dtb              rk3399-nanopi-m4-2gb.dtb
> > > > > > > > > > > > > > rk3399pro-rock-pi-n10.dtb  rk3399-roc-pc.dtb
> > > > > > > > > > > > > > rk3399-gru-bob.dtb              rk3399-nanopi-m4b.dtb
> > > > > > > > > > > > > > rk3399-puma-haikou.dtb     rk3399-roc-pc-mezzanine.dtb
> > > > > > > > > > > > > > rk3399-gru-kevin.dtb            rk3399-nanopi-m4.dtb
> > > > > > > > > > > > > > rk3399-rock-4c-plus.dtb
> > > > > > > > > > > > > > rk3399-khadas-edge-captain.dtb  rk3399-nanopi-neo4.dtb    rk3399-rock-4se.dtb
> > > > > > > > > > > > > > rk3399-khadas-edge.dtb          rk3399-nanopi-r4s.dtb     rk3399-rock960.dtb
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Afterwards I get this:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > make[3]: *** No rule to make target
> > > > > > > > > > > > > > 'dts/arch/arm64/rk3399-firefly.dtb', needed by 'dtbs'.  Stop.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > So I set this manually for that one board:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > CONFIG_DEFAULT_DEVICE_TREE="rockchip/rk3399-firefly"
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > and get:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > make[3]: *** No rule to make target
> > > > > > > > > > > > > > 'dts/arch/arm64/rockchip/rk3399-firefly.dtb', needed by 'dtbs'.  Stop.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > I am not sure how to fix this, nor how this can be made to build all
> > > > > > > > > > > > > > the DTs for rk3399, as it does today.
> > > > > > > > > > > > >
> > > > > > > > > > > > > Looking at the patch for amlogic boards, you need to make the link to
> > > > > > > > > > > > > devicetree-rebasing inside dts/...
> > > > > > > > > > > >
> > > > > > > > > > > > OK, let me give up on rk3399 for now...that doesn't seem to work even
> > > > > > > > > > > > with the link.
> > > > > > > > > > > >
> > > > > > > > > > > > Using odroid-c2 with -next I see:
> > > > > > > > > > > >
> > > > > > > > > > > > $ ls /tmp/b/odroid-c2/arch/arm/dts/
> > > > > > > > > > > > meson-a1-ad401.dtb                 meson-g12b-odroid-n2l.dtb
> > > > > > > > > > > >     meson-gxl-s905x-libretech-cc.dtb
> > > > > > > > > > > > meson-axg-jethome-jethub-j100.dtb  meson-g12b-odroid-n2-plus.dtb
> > > > > > > > > > > >     meson-gxl-s905x-libretech-cc-v2.dtb
> > > > > > > > > > > > meson-axg-s400.dtb                 meson-g12b-radxa-zero2.dtb
> > > > > > > > > > > >     meson-gxl-s905x-p212.dtb
> > > > > > > > > > > > meson-g12a-radxa-zero.dtb          meson-gxbb-kii-pro.dtb
> > > > > > > > > > > >     meson-gxm-gt1-ultimate.dtb
> > > > > > > > > > > > meson-g12a-sei510.dtb              meson-gxbb-nanopi-k2.dtb
> > > > > > > > > > > >     meson-gxm-khadas-vim2.dtb
> > > > > > > > > > > > meson-g12a-u200.dtb                meson-gxbb-odroidc2.dtb
> > > > > > > > > > > >     meson-gxm-s912-libretech-pc.dtb
> > > > > > > > > > > > meson-g12b-a311d-bananapi-m2s.dtb  meson-gxbb-p200.dtb
> > > > > > > > > > > >     meson-gxm-wetek-core2.dtb
> > > > > > > > > > > > meson-g12b-a311d-khadas-vim3.dtb   meson-gxbb-p201.dtb
> > > > > > > > > > > >     meson-sm1-bananapi-m2-pro.dtb
> > > > > > > > > > > > meson-g12b-bananapi-cm4-cm4io.dtb  meson-gxbb-wetek-hub.dtb
> > > > > > > > > > > >     meson-sm1-bananapi-m5.dtb
> > > > > > > > > > > > meson-g12b-gsking-x.dtb            meson-gxbb-wetek-play2.dtb
> > > > > > > > > > > >     meson-sm1-khadas-vim3l.dtb
> > > > > > > > > > > > meson-g12b-gtking.dtb              meson-gxl-s805x-libretech-ac.dtb
> > > > > > > > > > > >     meson-sm1-odroid-c4.dtb
> > > > > > > > > > > > meson-g12b-gtking-pro.dtb          meson-gxl-s905d-libretech-pc.dtb
> > > > > > > > > > > >     meson-sm1-odroid-hc4.dtb
> > > > > > > > > > > > meson-g12b-odroid-go-ultra.dtb
> > > > > > > > > > > > meson-gxl-s905w-jethome-jethub-j80.dtb  meson-sm1-sei610.dtb
> > > > > > > > > > > > meson-g12b-odroid-n2.dtb           meson-gxl-s905x-khadas-vim.dtb
> > > > > > > > > > > > $
> > > > > > > > > > > > With this series (sort of, since I am really not sure how to
> > > > > > > > > > > > cherry-pick the commits from the PR) I see nothing:
> > > > > > > > > > > >
> > > > > > > > > > > > $ ls /tmp/b/odroid-c2/arch/arm/dts/
> > > > > > > > > > > > $
> > > > > > > > > > > >
> > > > > > > > > > > > This shows some of the files:
> > > > > > > > > > > >
> > > > > > > > > > > > $ find /tmp/b/odroid-c2/ -name "*.dtb"
> > > > > > > > > > > > /tmp/b/odroid-c2/dts/dt.dtb
> > > > > > > > > > > > /tmp/b/odroid-c2/dts/arch/arm64/amlogic/meson-gxbb-odroidc2.dtb
> > > > > > > > > > > > /tmp/b/odroid-c2/dts/arch/arm64/amlogic/meson-gxbb-nanopi-k2.dtb
> > > > > > > > > > > > /tmp/b/odroid-c2/dts/arch/arm64/amlogic/meson-gxbb-wetek-play2.dtb
> > > > > > > > > > > > /tmp/b/odroid-c2/dts/arch/arm64/amlogic/meson-gxbb-kii-pro.dtb
> > > > > > > > > > > > /tmp/b/odroid-c2/dts/arch/arm64/amlogic/meson-gxbb-p200.dtb
> > > > > > > > > > > > /tmp/b/odroid-c2/dts/arch/arm64/amlogic/meson-gxbb-p201.dtb
> > > > > > > > > > > > /tmp/b/odroid-c2/dts/arch/arm64/amlogic/meson-gxbb-wetek-hub.dtb
> > > > > > > > > > > > /tmp/b/odroid-c2/u-boot.dtb
> > > > > > > > > > > >
> > > > > > > > > > > > but where are the rest? Also, is it possible to put the output .dtb
> > > > > > > > > > > > files into the same directory? Otherwise we may have some pain with
> > > > > > > > > > > > binman.
> > > > > > > > > > >
> > > > > > > > > > > What do you mean by same directory? But maybe also, what's an example of
> > > > > > > > > > > a board you think might end up having problems? Converting that in a
> > > > > > > > > > > follow-up series is likely a good idea, to highlight and address these
> > > > > > > > > > > issues sooner rather than later.#
> > > > > > > > > >
> > > > > > > > > > Today the .dtb files go into arch/arm/dts - so it would be easier if
> > > > > > > > > > this series could do the same.
> > > > > > > > >
> > > > > > > > > The kbuild infrastructure keeps the dtb alongside dts files which is
> > > > > > > > > the preferred way too as otherwise it would be complicated to locate
> > > > > > > > > DT files for the users. Also, we have to move towards Linux DT
> > > > > > > > > directory structure and thereby the tools like binman have to be
> > > > > > > > > adjusted. I will do that when I get to migrating SoCs supporting
> > > > > > > > > binman.
> > > > > > > >
> > > > > > > > OK, I want to stop here and rethink this. This is the path taken so
> > > > > > > > far, I believe:
> > > > > > > >
> > > > > > > > 1. We want to use devicetree files taken from Linux and
> > > > > > > > devicetree-rebasing provides these
> > > > > > >
> > > > > > > Yes.
> > > > > > >
> > > > > > > > 2. We want to use 'git subtree' to avoid needing a script to do the
> > > > > > > > sync / create a commit
> > > > > > >
> > > > > > > No. We want to use 'git subtree' to avoid having to use git submodules.
> > > > >
> > > > > Well that is what I understood from Sumit, when I asked about a
> > > > > script. I imagine a 100-line Python script could do the same as:
> > > > >
> > > > >    git subtree pull --prefix devicetree-rebasing
> > > > > git://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git
> > > > > <release-tag> --squash
> > > > >
> > > > > and it could also put the files in the right place for U-Boot.
> > > >
> > > > I've been saying in various places for years that I want to move away
> > > > from arch/*/dts being where we have the "just a copy" dts files and have
> > > > them somewhere else so they are easier to manage and differentiate our
> > > > changes / additions. So arch/*/dts cannot be some hard-coded "right"
> > > > path.
> > >
> > > OK
> > >
> > > >
> > > > > > > > 3. But this leaves us with a directory structure which doesn't match
> > > > > > > > U-Boot (no script to fix it up)
> > > > > > >
> > > > > > > No. We intentionally abandon arch/*/dts because it's so full of
> > > > > > > out of date files and never fully re-synced, only re-synced ad-hoc.
> > > > >
> > > > > I mean that the dir structure doesn't match. I am not worried about
> > > > > keeping arch/*/dts but I want the same structure somewhere else, e.g.
> > > > > dtr/arch/*/dts
> > > >
> > > > And what I want here is to match the same structure everyone that's not
> > > > U-Boot uses. For better or worse no one else seems to have gone with
> > > > "treat aarch64 as just another ARM", and then the vendor directory
> > > > structure only makes that more obviously a mismatch. We need to follow
> > > > what everyone else uses, and developers familiar with other projects
> > > > will expect to see.
> > >
> > > So you are saying that U-Boot should move to what Linux uses. I agree
> > > that seems like the best approach, so let's do it.
> > >
> > > >
> > > > > > > > 4. So we deal with that by skipping the build rules and using CONFIG
> > > > > > > > options to select what is built
> > > > > > > > 5. So now we cannot build all the files for an SoC, just the ones that
> > > > > > > > are in the CONFIG options
> > > > > > > > 6. Linux doesn't actually use devicetree-rebasing itself, so doesn't
> > > > > > > > have this problem
> > > > > > >
> > > > > > > No. devicetree-rebasing skips the Makefiles because they're part of the
> > > > > > > kernel. We couldn't re-use them ourselves because we don't have the same
> > > > > > > CONFIG names the kernel does. And Sumit has not replicated the logic we
> > > > > > > have under arch/*/dts/Makefile today because I've asked him not to, and
> > > > > > > we'll figure out what subsets of that logic make sense to add back in as
> > > > > > > a second step not a first step.
> > > > >
> > > > > Again, you are missing my point. I am not suggesting using Linux's
> > > > > build rules, just explaining why Linux doesn't have the problem we
> > > > > would be creating here.
> > > > >
> > > > > > > > So this is heading in the wrong direction. Nor is it clear that this
> > > > > > > > would just be a temporary problem.
> > > > > > >
> > > > > > > A previous iteration of this series built all of the dtb files for the
> > > > > > > SoC that Sumit has migrated with this series, but then dropped it.
> > > > >
> > > > > Oh.
> > > > >
> > > > > > >
> > > > > > > [snip]
> > > > > > > > I would like to do this series properly, maintaining the SoC-specific
> > > > > > > > build rules, not removing what I see as an important feature. It
> > > > > > > > should not be that difficult to figure out and I am happy to help with
> > > > > > > > it.
> > > > > > >
> > > > > > > The problem is that the rest of us do not understand the use case you're
> > > > > > > describing where a dtb file that would be useful in a build is not
> > > > > > > already in the list to build. The only one of those use cases I
> > > > > > > understand thus far is the exynos4 (iirc) case you mentioned previously
> > > > > > > where yes, really, one defconfig + appending board.dtb is fine, or fine
> > > > > > > enough. It's not that far off of the SPL_LOAD_FIT case, but there we
> > > > > > > know what to build already.
> > > > >
> > > > > Perhaps the problem is that the rest of you think of the build as all
> > > > > happening in U-Boot, similar to the proposed 'make image.fit' that I
> > > > > am trying to add to Linux.
> > > > >
> > > > > But packaging can be (and often is) a separate step from building.
> > > > > Linux has no packaging mechanism today...it just builds everything
> > > > > (including all DTs) and stops.
> > > > >
> > > > > We should be able to pick up whatever .dtb files we want and use them
> > > > > in an image.
> > > > >
> > > > > > > And I guess trying to tie things up, that's my puzzle. SPL_LOAD_FIT is
> > > > > > > how I see the use case you talk about being solved, if a full U-Boot is
> > > > > > > generic enough for N boards, SPL_LOAD_FIT does the right thing (in this
> > > > > > > non-bloblist DTB, non-reusing-OS-inntended DTB world). I really don't
> > > > > > > knnow how many modern SoCs can take a literal concatenated DTB and even
> > > > > > > in those cases I don't get why that's the win we want now? 1 build to N
> > > > > > > binaries?
> > > > >
> > > > > Yes SPL_LOAD_FIT is fine although in practice we will likely need SPL
> > > > > to use the correct DT as well, so the DT will need to be determined in
> > > > > TPL, perhaps.
> > > >
> > > > I mean, SPL_LOAD_FIT still can handle this case, with a call to the
> > > > function to re-parse the tree, when needed. I thought we did this today
> > > > even, but perhaps I'm confusing my options here.
> > > >
> > > > > But anyway, this works OK with rk3399, for example. We need to support
> > > > > this use case.
> > > > >
> > > > > Also, it is pretty easy. We just need to stick with the dir structure
> > > > > we have today and copy our existing Makefiles into that dir. Or change
> > > > > to the kernel dir structure and use that. Or do one, then the other.
> > > >
> > > > I'm sorry, I don't understand what directory structure has to do with
> > > > "build more dtbs". For the cases where it makes sense to, yes, we can
> > > > build more dtbs, based on the SoC. I'm setting aside entirely the
> > > > discussion on what SoCs that works for, for another thread.
> > >
> > > Well you said above that we should switch to the kernel dir structure,
> > > so I believe that issue is resolved.
> > >
> > > 'build more dtbs' means build all the DTBs for an SoC, not just a
> > > selection that a particular board vendor decided on.
> >
> > Yes, what other dtbs to build is the sticking point, in a number of
> > threads now.
> 
> All of the ones for the SoC.

Yes, that's your position, and it's not anyone elses position.

> > > > Perhaps an issue here is that much like the kernel "install" target, we
> > > > need an "install" target too, so that whatever dtbs we build can be
> > > > more easily found for external packaging, but whatever tooling it is
> > > > that wants it? And perhaps this is part of the problem, tooling that
> > > > expects to pull things out of the object directory rather than an
> > > > "installed" directory?
> > >
> > > This is where binman comes in. It can run as part of U-Boot build, to
> > > build a few default firmware images. Then it can be run *later*,
> > > outside the U-Boot build, with an augmented or more targeted image
> > > definition, with mostly the same input files, to pull together images
> > > for specific uses. As you say, the input files need to be in a defined
> > > location, which they are today, for the most part.
> > >
> > > So even if a particular board only uses one DT, all the DTs for that
> > > SoC are built and so can be used in that final-packaging step. Without
> > > that build, there is no way to get the required .dtb files, other than
> > > building every board one by one and then pulling out the .dtb files or
> > > something weird like that.
> > >
> > > Note that this works independently of whether OF_LIST is used, etc.
> >
> > How about this. When you introduce generic-rk3399_defconfig is when we
> > can also have dts-$(CONFIG_ROCKCHIP_RK3399) list everything, and insist
> > it be kept up to date. That to me feels like the right order to go in.
> > And we can have all of the implementation details be hashed out
> > elsewhere, not in the thread about fixing our nightmare about dts file
> > resync.
> 
> So long as Sumit can put it back so we can use build rules, that's
> fine. But removing the build rules is the sticking point for me.

But it's not a sticking point for anyone else for the series. Because
no one else gets the point you're trying to make.

> > > > > > > But even then, I don't object to adding those rules to the Makefiles. If
> > > > > > > it works it works. I object to adding them when they don't work.
> > > > >
> > > > > What do you mean by 'work'? With this series as is, it simply isn't
> > > > > possible to add Makefile rules, as they are ignored. Am I missing
> > > > > something?
> > > >
> > > > Yes, I think you're missing something. Perhaps you need to publish a WIP
> > > > tree somewhere so someone can see what you're doing as it sounds like
> > > > you're not able to add another SoC of any type on top of Sumit's tree
> > > > and have it work.
> > >
> > > The current -next source builds dtb files based on the SoC, for the
> > > most part. I sent a series to clean that up a bit[1], but it is mostly
> > > there.
> >
> > Yes, and that relied on Rasmus' series having been merged ages ago which
> > fixed up a number of "people just copypasta'd something here,
> > incorrectly".  Keep that in mind as part of why I have objections here.
> 
> OK.

And since I think you're missing the point I was raising, because no one
else has the "any dtb from the SoC with this binary", we'll just be
getting back to re-introducing those kind of problems with what you're
demanding.

> > > From the above it seems like the plan could be:
> > > 1. Move arm64 .dts files to arch/arm64/dts/<vendor>/... and adjust
> > > Makefiles accordingly
> >
> > Since we're going to move everyone to being from the upstream kernel,
> > that seems like unneeded churn.
> 
> What is the timeline for that move?

It could probably, largely, be done in 2024, for the platforms that
actively sync. For the ones that aren't behaving well right now? I don't
know, it'll depend on when someone shows up being active about them
again.

> We are talking about 1700 lines of Makefies and I already made a good
> start on part of it. So if we are going to be a few months with two
> different paths, fine, but this is going to drag on for a year, I
> would rather clean it up now and have a unified path for both sets of
> DTs.

The sticking point for migration is going to be the testing of the
platforms that are not well in sync at all.

> > > 2. Choose a directory target for devicetree-rebasing. I see that
> > > 'barebox' uses 'dts' which seems better to me than
> > > 'devicetree-rebasing/src/'. Actually barebox even seems to have
> > > scripts for handling all of this [2]??
> >
> > They've been doing this since longer than git subtree has existed I
> > believe. I suspect that much like how Rob would like to move the
> > in-kernel devicetree compiler sync from a script to git subtree, barebox
> > will too.
> 
> Maybe, although the first barebox dts/ commit was 2014 and subtree is
> claimed to come out in 2012...but then devicetree-rebasing might be
> newer, which would explain why they have 'git filter-branch' stuff in
> the script.

Well, it was just a guess on my part. It took a while for subtree to
catch on, and yes, it's taken a while for everything to reach the state
it's in today, for dts sources outside of the linux kernel itself.

> I thought devicetree-rebasing came from Linux. Is it its own repo? So
> what is the DT upstream these days??

I'll let Rob chime in again here if he likes. In short,
devicetree-rebasing is the kernel dts files/bindings copied out and
tagged, matching upstream kernel tags, and with assorted useful bits of
git history available.

> If subtree does what we want without making U-Boot look like
> Franekstein's monster, that's fine. But I don't mind having a script.

Yes, everyone else thus far seems fine with what we get via this series.

> > > 3. Adjust the build system to use the dts/ directory for .dts files
> > > when OF_UPSTREAM is enabled
> > >
> > > Then it will be easy. People can enable OF_UPSTREAM for an SoC
> > > (without changing DEFAULT_DEVICE_TREE) and will get the same behaviour
> > > as now, just with upstream .dts files. All the .dts files for an SoC
> > > are built, as now, just as Linux does. We can continue cleaning up the
> > > DT build rules as time permits.
> >
> > Maybe the unasked / unanswered question here is, why don't we put the
> > subtree in to dts/ ? Just because it would make us more likely to make
> > changes rather than treat it as read only?
> 
> It is an easy checkpatch check, if that is your only concern.

Yeah, checkpatch isn't great for catching and stopping things. I don't
know how many other custodians check their PRs before I get to them. So
if it's not a fatal CI thing, it's not going to always be caught before
I see it, and I don't always catch "ERROR" things in checkpatch in a PR
either. But it might still be more annoying than not to have subtree be
shoved in to "dts". I'm hoping for some feedback from Sumit on this
point since I think he's played around.
Sumit Garg Jan. 3, 2024, 6:57 a.m. UTC | #21 
Hi Tom,

On Tue, 2 Jan 2024 at 23:36, Tom Rini <trini@konsulko.com> wrote:
>
> On Tue, Jan 02, 2024 at 09:07:48PM +0530, Sumit Garg wrote:
> > On Tue, 2 Jan 2024 at 19:36, Simon Glass <sjg@chromium.org> wrote:
> [snip]
> > > 2. Choose a directory target for devicetree-rebasing. I see that
> > > 'barebox' uses 'dts' which seems better to me than
> > > 'devicetree-rebasing/src/'.
> >
> > Actually as part of this patch-set we try to reuse the U-Boot 'dts'
> > directory (via dts/arch/arm64/<vendor> soft links) since it was
> > already taken for U-Boot specific DT Makefile. However, I am open to
> > renaming 'devicetree-rebasing' but to me that sounds more clear that
> > we maintain a specific subtree within U-Boot.
>
> Looking at what little is in dts/ here today could we just use subtree
> and pop the contents under there, and basically ignore the
> project-provided Makefile? Or is that not really worth it?
>

If we really want to avoid soft links then I did try to add the subree
with the prefix as dts/upstream here [1]. It works well with the
downside that we will pollute the subtree source code with U-Boot
specific Makefiles [2]. However, the subtree pull works fine still. If
this sounds better to you and Simon then let me know I will use this
approach for v4.

[1] https://github.com/b49020/u-boot/commits/use_dts_dir/
[2] https://github.com/b49020/u-boot/commit/90eabe614e77bc30a437e7d5559c1ac414ac07b3

-Sumit

> --
> Tom
Sumit Garg Jan. 3, 2024, 7:06 a.m. UTC | #22 
On Tue, 2 Jan 2024 at 21:07, Sumit Garg <sumit.garg@linaro.org> wrote:
>
> On Tue, 2 Jan 2024 at 19:36, Simon Glass <sjg@chromium.org> wrote:
<snip>
>
> > 3. Adjust the build system to use the dts/ directory for .dts files
> > when OF_UPSTREAM is enabled
> >
> > Then it will be easy. People can enable OF_UPSTREAM for an SoC
> > (without changing DEFAULT_DEVICE_TREE)
>
> I am still not sure what we will gain via keeping DEFAULT_DEVICE_TREE
> the same. However, without a per vendor directory Makefile like:
> dts/arch/arm64/<vendor>/Makefile it won't be possible. But to do that
> we won't be able to softlink vendor directories from DT rebasing tree
> but rather have to softlink every board DTS file which is much more
> painful.

Even after this you have to tell <vendor> name via DEFAULT_DEVICE_TREE
because the DTB path is constructed via:

DEVICE_TREE ?= $(CONFIG_DEFAULT_DEVICE_TREE:"%"=%)
ifeq ($(DEVICE_TREE),)
DEVICE_TREE := unset
endif

ifeq ($(CONFIG_OF_UPSTREAM),y)
ifeq ($(CONFIG_ARM64),y)
dt_dir := dts/arch/arm64
else
dt_dir := dts/arch/$(ARCH)
endif
else
dt_dir := arch/$(ARCH)/dts
endif

ifneq ($(EXT_DTB),)
DTB := $(EXT_DTB)
else
DTB := $(dt_dir)/$(DEVICE_TREE).dtb
endif

So with a move to Linux directory structure for dts directory,
DEFAULT_DEVICE_TREE have to specify <vendor>/<name> as DT filename.

-Sumit

>
> > and will get the same behaviour
> > as now, just with upstream .dts files. All the .dts files for an SoC
> > are built, as now, just as Linux does. We can continue cleaning up the
> > DT build rules as time permits.
>
> I will reiterate here, we can decide to add Makefile rules on a case
> by case basis. If there is a need (from packaging perspective or a
> particular SoC supports a generic U-Boot image) then we should be able
> to add them. The cleanup would be automatically part of the process as
> we switch SoCs to OF_UPSTREAM.
>
> -Sumit
>
> >
> > Regards,
> > Simon
> >
> > [1] http://patchwork.ozlabs.org/project/uboot/list/?series=388154
> > [2] https://git.pengutronix.de/cgit/barebox/tree/dts
Tom Rini Jan. 3, 2024, 1:23 p.m. UTC | #23 
On Wed, Jan 03, 2024 at 12:27:24PM +0530, Sumit Garg wrote:
> Hi Tom,
> 
> On Tue, 2 Jan 2024 at 23:36, Tom Rini <trini@konsulko.com> wrote:
> >
> > On Tue, Jan 02, 2024 at 09:07:48PM +0530, Sumit Garg wrote:
> > > On Tue, 2 Jan 2024 at 19:36, Simon Glass <sjg@chromium.org> wrote:
> > [snip]
> > > > 2. Choose a directory target for devicetree-rebasing. I see that
> > > > 'barebox' uses 'dts' which seems better to me than
> > > > 'devicetree-rebasing/src/'.
> > >
> > > Actually as part of this patch-set we try to reuse the U-Boot 'dts'
> > > directory (via dts/arch/arm64/<vendor> soft links) since it was
> > > already taken for U-Boot specific DT Makefile. However, I am open to
> > > renaming 'devicetree-rebasing' but to me that sounds more clear that
> > > we maintain a specific subtree within U-Boot.
> >
> > Looking at what little is in dts/ here today could we just use subtree
> > and pop the contents under there, and basically ignore the
> > project-provided Makefile? Or is that not really worth it?
> >
> 
> If we really want to avoid soft links then I did try to add the subree
> with the prefix as dts/upstream here [1]. It works well with the
> downside that we will pollute the subtree source code with U-Boot
> specific Makefiles [2]. However, the subtree pull works fine still. If
> this sounds better to you and Simon then let me know I will use this
> approach for v4.
> 
> [1] https://github.com/b49020/u-boot/commits/use_dts_dir/
> [2] https://github.com/b49020/u-boot/commit/90eabe614e77bc30a437e7d5559c1ac414ac07b3

I think the symlink stuff was part of what was making it more confusing
to add new SoCs to OF_UPSTREAM so yes this looks good to me, and I
appreciate the demo commit showing an update is still easy. Thanks!
Simon Glass Jan. 4, 2024, 1:42 a.m. UTC | #24 
Hi Tom,

On Tue, Jan 2, 2024 at 5:41 PM Tom Rini <trini@konsulko.com> wrote:
>
> On Tue, Jan 02, 2024 at 04:54:15PM -0700, Simon Glass wrote:
> > Hi Tom,
> >
> > On Tue, Jan 2, 2024 at 8:10 AM Tom Rini <trini@konsulko.com> wrote:
> > >
> > > On Tue, Jan 02, 2024 at 07:06:40AM -0700, Simon Glass wrote:
> > > > Hi Tom,
> > > >
> > > > On Mon, Jan 1, 2024 at 4:35 PM Tom Rini <trini@konsulko.com> wrote:
> > > > >
> > > > > On Mon, Jan 01, 2024 at 03:32:41PM -0700, Simon Glass wrote:
> > > > > > Hi Mark, Tom,
> > > > > >
> > > > > > On Sun, Dec 31, 2023 at 5:33 PM Mark Kettenis <mark.kettenis@xs4all.nl> wrote:
> > > > > > >
> > > > > > > > Date: Sun, 31 Dec 2023 15:39:53 -0500
> > > > > > > > From: Tom Rini <trini@konsulko.com>
> > > > > > > >
> > > > > > > > On Sun, Dec 31, 2023 at 07:28:52AM -0700, Simon Glass wrote:
> > > > > > > > > Hi Sumit,
> > > > > > > > >
> > > > > > > > > On Fri, Dec 29, 2023 at 8:30 AM Sumit Garg <sumit.garg@linaro.org> wrote:
> > > > > > > > > >
> > > > > > > > > > On Fri, 29 Dec 2023 at 01:18, Simon Glass <sjg@chromium.org> wrote:
> > > > > > > > > > >
> > > > > > > > > > > Hi Tom,
> > > > > > > > > > >
> > > > > > > > > > > On Thu, Dec 28, 2023 at 3:54 PM Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > On Thu, Dec 28, 2023 at 03:09:12PM +0000, Simon Glass wrote:
> > > > > > > > > > > > > Hi Tom, Sumit,
> > > > > > > > > > > > >
> > > > > > > > > > > > > On Thu, Dec 28, 2023 at 2:03 PM Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > On Thu, Dec 28, 2023 at 01:37:26PM +0000, Simon Glass wrote:
> > > > > > > > > > > > > > > Hi Sumit,
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > On Thu, Dec 28, 2023 at 11:58 AM Sumit Garg <sumit.garg@linaro.org> wrote:
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Allow platform owners to mirror devicetree files from devitree-rebasing
> > > > > > > > > > > > > > > > directory into dts/arch/$(ARCH) (special case for dts/arch/arm64). Then
> > > > > > > > > > > > > > > > build then along with any *-u-boot.dtsi file present in arch/$(ARCH)/dts
> > > > > > > > > > > > > > > > directory. Also add a new Makefile for arm64.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > This will help easy migration for platforms which currently are compliant
> > > > > > > > > > > > > > > > with upstream Linux kernel devicetree files.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Signed-off-by: Sumit Garg <sumit.garg@linaro.org>
> > > > > > > > > > > > > > > > ---
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Changes in v3:
> > > > > > > > > > > > > > > > --------------
> > > > > > > > > > > > > > > > - Minor commit message update
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Changes in v2:
> > > > > > > > > > > > > > > > --------------
> > > > > > > > > > > > > > > > - s/DEVICE_TREE_LOC/dt_dir/ and s/U-boot/U-Boot/
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >  dts/Kconfig             | 11 +++++++++++
> > > > > > > > > > > > > > > >  dts/Makefile            | 17 ++++++++++++++---
> > > > > > > > > > > > > > > >  dts/arch/arm64/Makefile | 14 ++++++++++++++
> > > > > > > > > > > > > > > >  3 files changed, 39 insertions(+), 3 deletions(-)
> > > > > > > > > > > > > > > >  create mode 100644 dts/arch/arm64/Makefile
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > diff --git a/dts/Kconfig b/dts/Kconfig
> > > > > > > > > > > > > > > > index 00c0aeff893..e58c1c6f2ab 100644
> > > > > > > > > > > > > > > > --- a/dts/Kconfig
> > > > > > > > > > > > > > > > +++ b/dts/Kconfig
> > > > > > > > > > > > > > > > @@ -85,6 +85,17 @@ config OF_LIVE
> > > > > > > > > > > > > > > >           enables a live tree which is available after relocation,
> > > > > > > > > > > > > > > >           and can be adjusted as needed.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > +config OF_UPSTREAM
> > > > > > > > > > > > > > > > +       bool "Enable use of devicetree imported from Linux kernel release"
> > > > > > > > > > > > > > > > +       help
> > > > > > > > > > > > > > > > +         Traditionally, U-Boot platforms used to have their custom devicetree
> > > > > > > > > > > > > > > > +         files or copy devicetree files from Linux kernel which are hard to
> > > > > > > > > > > > > > > > +         maintain and can usually get out-of-sync from Linux kernel. This
> > > > > > > > > > > > > > > > +         option enables platforms to migrate to devicetree-rebasing repo where
> > > > > > > > > > > > > > > > +         a regular sync will be maintained every major Linux kernel release
> > > > > > > > > > > > > > > > +         cycle. However, platforms can still have some custom u-boot specific
> > > > > > > > > > > > > > > > +         bits maintained as part of *-u-boot.dtsi files.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > My only other suggestion here is to mention that this should be set in
> > > > > > > > > > > > > > > Kconfig, for the SoC as a whole. So I believe that means that it
> > > > > > > > > > > > > > > should be hidden, with no string for the 'bool':
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >       bool  # Enable use of devicetree imported from Linux kernel release
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > I think we can just keep prompting for it now, to make the transition
> > > > > > > > > > > > > > easier, before this option just goes away in time, hopefully.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Also, this doesn't seem to work for me. Before this series I get these
> > > > > > > > > > > > > > > files when building firefly-rk3399:
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > rk3399-eaidk-610.dtb            rk3399-khadas-edge-v.dtb
> > > > > > > > > > > > > > > rk3399-orangepi.dtb        rk3399-rock-pi-4a.dtb
> > > > > > > > > > > > > > > rk3399-evb.dtb                  rk3399-leez-p710.dtb
> > > > > > > > > > > > > > > rk3399-pinebook-pro.dtb    rk3399-rock-pi-4c.dtb
> > > > > > > > > > > > > > > rk3399-ficus.dtb                rk3399-nanopc-t4.dtb
> > > > > > > > > > > > > > > rk3399-pinephone-pro.dtb   rk3399-rockpro64.dtb
> > > > > > > > > > > > > > > rk3399-firefly.dtb              rk3399-nanopi-m4-2gb.dtb
> > > > > > > > > > > > > > > rk3399pro-rock-pi-n10.dtb  rk3399-roc-pc.dtb
> > > > > > > > > > > > > > > rk3399-gru-bob.dtb              rk3399-nanopi-m4b.dtb
> > > > > > > > > > > > > > > rk3399-puma-haikou.dtb     rk3399-roc-pc-mezzanine.dtb
> > > > > > > > > > > > > > > rk3399-gru-kevin.dtb            rk3399-nanopi-m4.dtb
> > > > > > > > > > > > > > > rk3399-rock-4c-plus.dtb
> > > > > > > > > > > > > > > rk3399-khadas-edge-captain.dtb  rk3399-nanopi-neo4.dtb    rk3399-rock-4se.dtb
> > > > > > > > > > > > > > > rk3399-khadas-edge.dtb          rk3399-nanopi-r4s.dtb     rk3399-rock960.dtb
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Afterwards I get this:
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > make[3]: *** No rule to make target
> > > > > > > > > > > > > > > 'dts/arch/arm64/rk3399-firefly.dtb', needed by 'dtbs'.  Stop.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > So I set this manually for that one board:
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > CONFIG_DEFAULT_DEVICE_TREE="rockchip/rk3399-firefly"
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > and get:
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > make[3]: *** No rule to make target
> > > > > > > > > > > > > > > 'dts/arch/arm64/rockchip/rk3399-firefly.dtb', needed by 'dtbs'.  Stop.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > I am not sure how to fix this, nor how this can be made to build all
> > > > > > > > > > > > > > > the DTs for rk3399, as it does today.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Looking at the patch for amlogic boards, you need to make the link to
> > > > > > > > > > > > > > devicetree-rebasing inside dts/...
> > > > > > > > > > > > >
> > > > > > > > > > > > > OK, let me give up on rk3399 for now...that doesn't seem to work even
> > > > > > > > > > > > > with the link.
> > > > > > > > > > > > >
> > > > > > > > > > > > > Using odroid-c2 with -next I see:
> > > > > > > > > > > > >
> > > > > > > > > > > > > $ ls /tmp/b/odroid-c2/arch/arm/dts/
> > > > > > > > > > > > > meson-a1-ad401.dtb                 meson-g12b-odroid-n2l.dtb
> > > > > > > > > > > > >     meson-gxl-s905x-libretech-cc.dtb
> > > > > > > > > > > > > meson-axg-jethome-jethub-j100.dtb  meson-g12b-odroid-n2-plus.dtb
> > > > > > > > > > > > >     meson-gxl-s905x-libretech-cc-v2.dtb
> > > > > > > > > > > > > meson-axg-s400.dtb                 meson-g12b-radxa-zero2.dtb
> > > > > > > > > > > > >     meson-gxl-s905x-p212.dtb
> > > > > > > > > > > > > meson-g12a-radxa-zero.dtb          meson-gxbb-kii-pro.dtb
> > > > > > > > > > > > >     meson-gxm-gt1-ultimate.dtb
> > > > > > > > > > > > > meson-g12a-sei510.dtb              meson-gxbb-nanopi-k2.dtb
> > > > > > > > > > > > >     meson-gxm-khadas-vim2.dtb
> > > > > > > > > > > > > meson-g12a-u200.dtb                meson-gxbb-odroidc2.dtb
> > > > > > > > > > > > >     meson-gxm-s912-libretech-pc.dtb
> > > > > > > > > > > > > meson-g12b-a311d-bananapi-m2s.dtb  meson-gxbb-p200.dtb
> > > > > > > > > > > > >     meson-gxm-wetek-core2.dtb
> > > > > > > > > > > > > meson-g12b-a311d-khadas-vim3.dtb   meson-gxbb-p201.dtb
> > > > > > > > > > > > >     meson-sm1-bananapi-m2-pro.dtb
> > > > > > > > > > > > > meson-g12b-bananapi-cm4-cm4io.dtb  meson-gxbb-wetek-hub.dtb
> > > > > > > > > > > > >     meson-sm1-bananapi-m5.dtb
> > > > > > > > > > > > > meson-g12b-gsking-x.dtb            meson-gxbb-wetek-play2.dtb
> > > > > > > > > > > > >     meson-sm1-khadas-vim3l.dtb
> > > > > > > > > > > > > meson-g12b-gtking.dtb              meson-gxl-s805x-libretech-ac.dtb
> > > > > > > > > > > > >     meson-sm1-odroid-c4.dtb
> > > > > > > > > > > > > meson-g12b-gtking-pro.dtb          meson-gxl-s905d-libretech-pc.dtb
> > > > > > > > > > > > >     meson-sm1-odroid-hc4.dtb
> > > > > > > > > > > > > meson-g12b-odroid-go-ultra.dtb
> > > > > > > > > > > > > meson-gxl-s905w-jethome-jethub-j80.dtb  meson-sm1-sei610.dtb
> > > > > > > > > > > > > meson-g12b-odroid-n2.dtb           meson-gxl-s905x-khadas-vim.dtb
> > > > > > > > > > > > > $
> > > > > > > > > > > > > With this series (sort of, since I am really not sure how to
> > > > > > > > > > > > > cherry-pick the commits from the PR) I see nothing:
> > > > > > > > > > > > >
> > > > > > > > > > > > > $ ls /tmp/b/odroid-c2/arch/arm/dts/
> > > > > > > > > > > > > $
> > > > > > > > > > > > >
> > > > > > > > > > > > > This shows some of the files:
> > > > > > > > > > > > >
> > > > > > > > > > > > > $ find /tmp/b/odroid-c2/ -name "*.dtb"
> > > > > > > > > > > > > /tmp/b/odroid-c2/dts/dt.dtb
> > > > > > > > > > > > > /tmp/b/odroid-c2/dts/arch/arm64/amlogic/meson-gxbb-odroidc2.dtb
> > > > > > > > > > > > > /tmp/b/odroid-c2/dts/arch/arm64/amlogic/meson-gxbb-nanopi-k2.dtb
> > > > > > > > > > > > > /tmp/b/odroid-c2/dts/arch/arm64/amlogic/meson-gxbb-wetek-play2.dtb
> > > > > > > > > > > > > /tmp/b/odroid-c2/dts/arch/arm64/amlogic/meson-gxbb-kii-pro.dtb
> > > > > > > > > > > > > /tmp/b/odroid-c2/dts/arch/arm64/amlogic/meson-gxbb-p200.dtb
> > > > > > > > > > > > > /tmp/b/odroid-c2/dts/arch/arm64/amlogic/meson-gxbb-p201.dtb
> > > > > > > > > > > > > /tmp/b/odroid-c2/dts/arch/arm64/amlogic/meson-gxbb-wetek-hub.dtb
> > > > > > > > > > > > > /tmp/b/odroid-c2/u-boot.dtb
> > > > > > > > > > > > >
> > > > > > > > > > > > > but where are the rest? Also, is it possible to put the output .dtb
> > > > > > > > > > > > > files into the same directory? Otherwise we may have some pain with
> > > > > > > > > > > > > binman.
> > > > > > > > > > > >
> > > > > > > > > > > > What do you mean by same directory? But maybe also, what's an example of
> > > > > > > > > > > > a board you think might end up having problems? Converting that in a
> > > > > > > > > > > > follow-up series is likely a good idea, to highlight and address these
> > > > > > > > > > > > issues sooner rather than later.#
> > > > > > > > > > >
> > > > > > > > > > > Today the .dtb files go into arch/arm/dts - so it would be easier if
> > > > > > > > > > > this series could do the same.
> > > > > > > > > >
> > > > > > > > > > The kbuild infrastructure keeps the dtb alongside dts files which is
> > > > > > > > > > the preferred way too as otherwise it would be complicated to locate
> > > > > > > > > > DT files for the users. Also, we have to move towards Linux DT
> > > > > > > > > > directory structure and thereby the tools like binman have to be
> > > > > > > > > > adjusted. I will do that when I get to migrating SoCs supporting
> > > > > > > > > > binman.
> > > > > > > > >
> > > > > > > > > OK, I want to stop here and rethink this. This is the path taken so
> > > > > > > > > far, I believe:
> > > > > > > > >
> > > > > > > > > 1. We want to use devicetree files taken from Linux and
> > > > > > > > > devicetree-rebasing provides these
> > > > > > > >
> > > > > > > > Yes.
> > > > > > > >
> > > > > > > > > 2. We want to use 'git subtree' to avoid needing a script to do the
> > > > > > > > > sync / create a commit
> > > > > > > >
> > > > > > > > No. We want to use 'git subtree' to avoid having to use git submodules.
> > > > > >
> > > > > > Well that is what I understood from Sumit, when I asked about a
> > > > > > script. I imagine a 100-line Python script could do the same as:
> > > > > >
> > > > > >    git subtree pull --prefix devicetree-rebasing
> > > > > > git://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git
> > > > > > <release-tag> --squash
> > > > > >
> > > > > > and it could also put the files in the right place for U-Boot.
> > > > >
> > > > > I've been saying in various places for years that I want to move away
> > > > > from arch/*/dts being where we have the "just a copy" dts files and have
> > > > > them somewhere else so they are easier to manage and differentiate our
> > > > > changes / additions. So arch/*/dts cannot be some hard-coded "right"
> > > > > path.
> > > >
> > > > OK
> > > >
> > > > >
> > > > > > > > > 3. But this leaves us with a directory structure which doesn't match
> > > > > > > > > U-Boot (no script to fix it up)
> > > > > > > >
> > > > > > > > No. We intentionally abandon arch/*/dts because it's so full of
> > > > > > > > out of date files and never fully re-synced, only re-synced ad-hoc.
> > > > > >
> > > > > > I mean that the dir structure doesn't match. I am not worried about
> > > > > > keeping arch/*/dts but I want the same structure somewhere else, e.g.
> > > > > > dtr/arch/*/dts
> > > > >
> > > > > And what I want here is to match the same structure everyone that's not
> > > > > U-Boot uses. For better or worse no one else seems to have gone with
> > > > > "treat aarch64 as just another ARM", and then the vendor directory
> > > > > structure only makes that more obviously a mismatch. We need to follow
> > > > > what everyone else uses, and developers familiar with other projects
> > > > > will expect to see.
> > > >
> > > > So you are saying that U-Boot should move to what Linux uses. I agree
> > > > that seems like the best approach, so let's do it.
> > > >
> > > > >
> > > > > > > > > 4. So we deal with that by skipping the build rules and using CONFIG
> > > > > > > > > options to select what is built
> > > > > > > > > 5. So now we cannot build all the files for an SoC, just the ones that
> > > > > > > > > are in the CONFIG options
> > > > > > > > > 6. Linux doesn't actually use devicetree-rebasing itself, so doesn't
> > > > > > > > > have this problem
> > > > > > > >
> > > > > > > > No. devicetree-rebasing skips the Makefiles because they're part of the
> > > > > > > > kernel. We couldn't re-use them ourselves because we don't have the same
> > > > > > > > CONFIG names the kernel does. And Sumit has not replicated the logic we
> > > > > > > > have under arch/*/dts/Makefile today because I've asked him not to, and
> > > > > > > > we'll figure out what subsets of that logic make sense to add back in as
> > > > > > > > a second step not a first step.
> > > > > >
> > > > > > Again, you are missing my point. I am not suggesting using Linux's
> > > > > > build rules, just explaining why Linux doesn't have the problem we
> > > > > > would be creating here.
> > > > > >
> > > > > > > > > So this is heading in the wrong direction. Nor is it clear that this
> > > > > > > > > would just be a temporary problem.
> > > > > > > >
> > > > > > > > A previous iteration of this series built all of the dtb files for the
> > > > > > > > SoC that Sumit has migrated with this series, but then dropped it.
> > > > > >
> > > > > > Oh.
> > > > > >
> > > > > > > >
> > > > > > > > [snip]
> > > > > > > > > I would like to do this series properly, maintaining the SoC-specific
> > > > > > > > > build rules, not removing what I see as an important feature. It
> > > > > > > > > should not be that difficult to figure out and I am happy to help with
> > > > > > > > > it.
> > > > > > > >
> > > > > > > > The problem is that the rest of us do not understand the use case you're
> > > > > > > > describing where a dtb file that would be useful in a build is not
> > > > > > > > already in the list to build. The only one of those use cases I
> > > > > > > > understand thus far is the exynos4 (iirc) case you mentioned previously
> > > > > > > > where yes, really, one defconfig + appending board.dtb is fine, or fine
> > > > > > > > enough. It's not that far off of the SPL_LOAD_FIT case, but there we
> > > > > > > > know what to build already.
> > > > > >
> > > > > > Perhaps the problem is that the rest of you think of the build as all
> > > > > > happening in U-Boot, similar to the proposed 'make image.fit' that I
> > > > > > am trying to add to Linux.
> > > > > >
> > > > > > But packaging can be (and often is) a separate step from building.
> > > > > > Linux has no packaging mechanism today...it just builds everything
> > > > > > (including all DTs) and stops.
> > > > > >
> > > > > > We should be able to pick up whatever .dtb files we want and use them
> > > > > > in an image.
> > > > > >
> > > > > > > > And I guess trying to tie things up, that's my puzzle. SPL_LOAD_FIT is
> > > > > > > > how I see the use case you talk about being solved, if a full U-Boot is
> > > > > > > > generic enough for N boards, SPL_LOAD_FIT does the right thing (in this
> > > > > > > > non-bloblist DTB, non-reusing-OS-inntended DTB world). I really don't
> > > > > > > > knnow how many modern SoCs can take a literal concatenated DTB and even
> > > > > > > > in those cases I don't get why that's the win we want now? 1 build to N
> > > > > > > > binaries?
> > > > > >
> > > > > > Yes SPL_LOAD_FIT is fine although in practice we will likely need SPL
> > > > > > to use the correct DT as well, so the DT will need to be determined in
> > > > > > TPL, perhaps.
> > > > >
> > > > > I mean, SPL_LOAD_FIT still can handle this case, with a call to the
> > > > > function to re-parse the tree, when needed. I thought we did this today
> > > > > even, but perhaps I'm confusing my options here.
> > > > >
> > > > > > But anyway, this works OK with rk3399, for example. We need to support
> > > > > > this use case.
> > > > > >
> > > > > > Also, it is pretty easy. We just need to stick with the dir structure
> > > > > > we have today and copy our existing Makefiles into that dir. Or change
> > > > > > to the kernel dir structure and use that. Or do one, then the other.
> > > > >
> > > > > I'm sorry, I don't understand what directory structure has to do with
> > > > > "build more dtbs". For the cases where it makes sense to, yes, we can
> > > > > build more dtbs, based on the SoC. I'm setting aside entirely the
> > > > > discussion on what SoCs that works for, for another thread.
> > > >
> > > > Well you said above that we should switch to the kernel dir structure,
> > > > so I believe that issue is resolved.
> > > >
> > > > 'build more dtbs' means build all the DTBs for an SoC, not just a
> > > > selection that a particular board vendor decided on.
> > >
> > > Yes, what other dtbs to build is the sticking point, in a number of
> > > threads now.
> >
> > All of the ones for the SoC.
>
> Yes, that's your position, and it's not anyone elses position.

Indeed, I seem to be in a minority of one.

>
> > > > > Perhaps an issue here is that much like the kernel "install" target, we
> > > > > need an "install" target too, so that whatever dtbs we build can be
> > > > > more easily found for external packaging, but whatever tooling it is
> > > > > that wants it? And perhaps this is part of the problem, tooling that
> > > > > expects to pull things out of the object directory rather than an
> > > > > "installed" directory?
> > > >
> > > > This is where binman comes in. It can run as part of U-Boot build, to
> > > > build a few default firmware images. Then it can be run *later*,
> > > > outside the U-Boot build, with an augmented or more targeted image
> > > > definition, with mostly the same input files, to pull together images
> > > > for specific uses. As you say, the input files need to be in a defined
> > > > location, which they are today, for the most part.
> > > >
> > > > So even if a particular board only uses one DT, all the DTs for that
> > > > SoC are built and so can be used in that final-packaging step. Without
> > > > that build, there is no way to get the required .dtb files, other than
> > > > building every board one by one and then pulling out the .dtb files or
> > > > something weird like that.
> > > >
> > > > Note that this works independently of whether OF_LIST is used, etc.
> > >
> > > How about this. When you introduce generic-rk3399_defconfig is when we
> > > can also have dts-$(CONFIG_ROCKCHIP_RK3399) list everything, and insist
> > > it be kept up to date. That to me feels like the right order to go in.
> > > And we can have all of the implementation details be hashed out
> > > elsewhere, not in the thread about fixing our nightmare about dts file
> > > resync.
> >
> > So long as Sumit can put it back so we can use build rules, that's
> > fine. But removing the build rules is the sticking point for me.
>
> But it's not a sticking point for anyone else for the series. Because
> no one else gets the point you're trying to make.

OK

>
> > > > > > > > But even then, I don't object to adding those rules to the Makefiles. If
> > > > > > > > it works it works. I object to adding them when they don't work.
> > > > > >
> > > > > > What do you mean by 'work'? With this series as is, it simply isn't
> > > > > > possible to add Makefile rules, as they are ignored. Am I missing
> > > > > > something?
> > > > >
> > > > > Yes, I think you're missing something. Perhaps you need to publish a WIP
> > > > > tree somewhere so someone can see what you're doing as it sounds like
> > > > > you're not able to add another SoC of any type on top of Sumit's tree
> > > > > and have it work.
> > > >
> > > > The current -next source builds dtb files based on the SoC, for the
> > > > most part. I sent a series to clean that up a bit[1], but it is mostly
> > > > there.
> > >
> > > Yes, and that relied on Rasmus' series having been merged ages ago which
> > > fixed up a number of "people just copypasta'd something here,
> > > incorrectly".  Keep that in mind as part of why I have objections here.
> >
> > OK.
>
> And since I think you're missing the point I was raising, because no one
> else has the "any dtb from the SoC with this binary", we'll just be
> getting back to re-introducing those kind of problems with what you're
> demanding.
>
> > > > From the above it seems like the plan could be:
> > > > 1. Move arm64 .dts files to arch/arm64/dts/<vendor>/... and adjust
> > > > Makefiles accordingly
> > >
> > > Since we're going to move everyone to being from the upstream kernel,
> > > that seems like unneeded churn.
> >
> > What is the timeline for that move?
>
> It could probably, largely, be done in 2024, for the platforms that
> actively sync. For the ones that aren't behaving well right now? I don't
> know, it'll depend on when someone shows up being active about them
> again.
>
> > We are talking about 1700 lines of Makefies and I already made a good
> > start on part of it. So if we are going to be a few months with two
> > different paths, fine, but this is going to drag on for a year, I
> > would rather clean it up now and have a unified path for both sets of
> > DTs.
>
> The sticking point for migration is going to be the testing of the
> platforms that are not well in sync at all.
>
> > > > 2. Choose a directory target for devicetree-rebasing. I see that
> > > > 'barebox' uses 'dts' which seems better to me than
> > > > 'devicetree-rebasing/src/'. Actually barebox even seems to have
> > > > scripts for handling all of this [2]??
> > >
> > > They've been doing this since longer than git subtree has existed I
> > > believe. I suspect that much like how Rob would like to move the
> > > in-kernel devicetree compiler sync from a script to git subtree, barebox
> > > will too.
> >
> > Maybe, although the first barebox dts/ commit was 2014 and subtree is
> > claimed to come out in 2012...but then devicetree-rebasing might be
> > newer, which would explain why they have 'git filter-branch' stuff in
> > the script.
>
> Well, it was just a guess on my part. It took a while for subtree to
> catch on, and yes, it's taken a while for everything to reach the state
> it's in today, for dts sources outside of the linux kernel itself.
>
> > I thought devicetree-rebasing came from Linux. Is it its own repo? So
> > what is the DT upstream these days??
>
> I'll let Rob chime in again here if he likes. In short,
> devicetree-rebasing is the kernel dts files/bindings copied out and
> tagged, matching upstream kernel tags, and with assorted useful bits of
> git history available.
>
> > If subtree does what we want without making U-Boot look like
> > Franekstein's monster, that's fine. But I don't mind having a script.
>
> Yes, everyone else thus far seems fine with what we get via this series.
>
> > > > 3. Adjust the build system to use the dts/ directory for .dts files
> > > > when OF_UPSTREAM is enabled
> > > >
> > > > Then it will be easy. People can enable OF_UPSTREAM for an SoC
> > > > (without changing DEFAULT_DEVICE_TREE) and will get the same behaviour
> > > > as now, just with upstream .dts files. All the .dts files for an SoC
> > > > are built, as now, just as Linux does. We can continue cleaning up the
> > > > DT build rules as time permits.
> > >
> > > Maybe the unasked / unanswered question here is, why don't we put the
> > > subtree in to dts/ ? Just because it would make us more likely to make
> > > changes rather than treat it as read only?
> >
> > It is an easy checkpatch check, if that is your only concern.
>
> Yeah, checkpatch isn't great for catching and stopping things. I don't
> know how many other custodians check their PRs before I get to them. So
> if it's not a fatal CI thing, it's not going to always be caught before
> I see it, and I don't always catch "ERROR" things in checkpatch in a PR
> either. But it might still be more annoying than not to have subtree be
> shoved in to "dts". I'm hoping for some feedback from Sumit on this
> point since I think he's played around.

It seems to me that the base issue here (in various threads both now
and in previous months) is whether U-Boot should control over the
devicetree it uses, either through managing to get schema upstream, or
by having its own local pieces. That question is relevant both at
build time and at runtime.

Anway, I think I have said my piece. Please go ahead with whatever you
think makes sense.

I would like to continue to clean up the existing Makefile rules though.

Regards,
Simon
Sumit Garg Jan. 4, 2024, 12:23 p.m. UTC | #25 
Hi Simon,

On Thu, 28 Dec 2023 at 20:39, Simon Glass <sjg@chromium.org> wrote:
>
> Hi Tom, Sumit,
>
> On Thu, Dec 28, 2023 at 2:03 PM Tom Rini <trini@konsulko.com> wrote:
> >
> > On Thu, Dec 28, 2023 at 01:37:26PM +0000, Simon Glass wrote:
> > > Hi Sumit,
> > >
> > > On Thu, Dec 28, 2023 at 11:58 AM Sumit Garg <sumit.garg@linaro.org> wrote:
> > > >
> > > > Allow platform owners to mirror devicetree files from devitree-rebasing
> > > > directory into dts/arch/$(ARCH) (special case for dts/arch/arm64). Then
> > > > build then along with any *-u-boot.dtsi file present in arch/$(ARCH)/dts
> > > > directory. Also add a new Makefile for arm64.
> > > >
> > > > This will help easy migration for platforms which currently are compliant
> > > > with upstream Linux kernel devicetree files.
> > > >
> > > > Signed-off-by: Sumit Garg <sumit.garg@linaro.org>
> > > > ---
> > > >
> > > > Changes in v3:
> > > > --------------
> > > > - Minor commit message update
> > > >
> > > > Changes in v2:
> > > > --------------
> > > > - s/DEVICE_TREE_LOC/dt_dir/ and s/U-boot/U-Boot/
> > > >
> > > >  dts/Kconfig             | 11 +++++++++++
> > > >  dts/Makefile            | 17 ++++++++++++++---
> > > >  dts/arch/arm64/Makefile | 14 ++++++++++++++
> > > >  3 files changed, 39 insertions(+), 3 deletions(-)
> > > >  create mode 100644 dts/arch/arm64/Makefile
> > > >
> > > > diff --git a/dts/Kconfig b/dts/Kconfig
> > > > index 00c0aeff893..e58c1c6f2ab 100644
> > > > --- a/dts/Kconfig
> > > > +++ b/dts/Kconfig
> > > > @@ -85,6 +85,17 @@ config OF_LIVE
> > > >           enables a live tree which is available after relocation,
> > > >           and can be adjusted as needed.
> > > >
> > > > +config OF_UPSTREAM
> > > > +       bool "Enable use of devicetree imported from Linux kernel release"
> > > > +       help
> > > > +         Traditionally, U-Boot platforms used to have their custom devicetree
> > > > +         files or copy devicetree files from Linux kernel which are hard to
> > > > +         maintain and can usually get out-of-sync from Linux kernel. This
> > > > +         option enables platforms to migrate to devicetree-rebasing repo where
> > > > +         a regular sync will be maintained every major Linux kernel release
> > > > +         cycle. However, platforms can still have some custom u-boot specific
> > > > +         bits maintained as part of *-u-boot.dtsi files.
> > >
> > > My only other suggestion here is to mention that this should be set in
> > > Kconfig, for the SoC as a whole. So I believe that means that it
> > > should be hidden, with no string for the 'bool':
> > >
> > >       bool  # Enable use of devicetree imported from Linux kernel release
> >
> > I think we can just keep prompting for it now, to make the transition
> > easier, before this option just goes away in time, hopefully.
> >
> > > Also, this doesn't seem to work for me. Before this series I get these
> > > files when building firefly-rk3399:
> > >
> > > rk3399-eaidk-610.dtb            rk3399-khadas-edge-v.dtb
> > > rk3399-orangepi.dtb        rk3399-rock-pi-4a.dtb
> > > rk3399-evb.dtb                  rk3399-leez-p710.dtb
> > > rk3399-pinebook-pro.dtb    rk3399-rock-pi-4c.dtb
> > > rk3399-ficus.dtb                rk3399-nanopc-t4.dtb
> > > rk3399-pinephone-pro.dtb   rk3399-rockpro64.dtb
> > > rk3399-firefly.dtb              rk3399-nanopi-m4-2gb.dtb
> > > rk3399pro-rock-pi-n10.dtb  rk3399-roc-pc.dtb
> > > rk3399-gru-bob.dtb              rk3399-nanopi-m4b.dtb
> > > rk3399-puma-haikou.dtb     rk3399-roc-pc-mezzanine.dtb
> > > rk3399-gru-kevin.dtb            rk3399-nanopi-m4.dtb
> > > rk3399-rock-4c-plus.dtb
> > > rk3399-khadas-edge-captain.dtb  rk3399-nanopi-neo4.dtb    rk3399-rock-4se.dtb
> > > rk3399-khadas-edge.dtb          rk3399-nanopi-r4s.dtb     rk3399-rock960.dtb
> > >
> > > Afterwards I get this:
> > >
> > > make[3]: *** No rule to make target
> > > 'dts/arch/arm64/rk3399-firefly.dtb', needed by 'dtbs'.  Stop.
> > >
> > > So I set this manually for that one board:
> > >
> > > CONFIG_DEFAULT_DEVICE_TREE="rockchip/rk3399-firefly"
> > >
> > > and get:
> > >
> > > make[3]: *** No rule to make target
> > > 'dts/arch/arm64/rockchip/rk3399-firefly.dtb', needed by 'dtbs'.  Stop.
> > >
> > > I am not sure how to fix this, nor how this can be made to build all
> > > the DTs for rk3399, as it does today.
> >
> > Looking at the patch for amlogic boards, you need to make the link to
> > devicetree-rebasing inside dts/...
>
> OK, let me give up on rk3399 for now...that doesn't seem to work even
> with the link.

I went ahead to debug this rk3399 issue. It turned out to be a subtle
Makefile dependency corner case that I missed in v3. Following change
should fix the issue, I will incorporate it in v4. However, while
switching rk3399 to upstream DT I noticed many gaps from upstream DT,
one that occured to me was difference in clk id SCLK_DDRCLK (U-Boot)
vs SCLK_DDRC (upstream DT).

diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib
index bdc1da43e7a..9526eb073f1 100644
--- a/scripts/Makefile.lib
+++ b/scripts/Makefile.lib
@@ -358,7 +359,7 @@ ifdef CONFIG_EFI_CAPSULE_AUTHENTICATE
 dtsi_include_list += $(capsule_esl_dtsi)
 endif

-dtsi_include_list_deps = $(addprefix $(obj)/,$(subst
$(quote),,$(dtsi_include_list)))
+dtsi_include_list_deps = $(addprefix $(u_boot_dtsi_loc)/,$(subst
$(quote),,$(dtsi_include_list)))

 ifneq ($(CHECK_DTBS),)
 DT_CHECKER ?= dt-validate

-Sumit
diff mbox series

Patch

diff --git a/dts/Kconfig b/dts/Kconfig
index 00c0aeff893..e58c1c6f2ab 100644
--- a/dts/Kconfig
+++ b/dts/Kconfig
@@ -85,6 +85,17 @@  config OF_LIVE
 	  enables a live tree which is available after relocation,
 	  and can be adjusted as needed.
 
+config OF_UPSTREAM
+	bool "Enable use of devicetree imported from Linux kernel release"
+	help
+	  Traditionally, U-Boot platforms used to have their custom devicetree
+	  files or copy devicetree files from Linux kernel which are hard to
+	  maintain and can usually get out-of-sync from Linux kernel. This
+	  option enables platforms to migrate to devicetree-rebasing repo where
+	  a regular sync will be maintained every major Linux kernel release
+	  cycle. However, platforms can still have some custom u-boot specific
+	  bits maintained as part of *-u-boot.dtsi files.
+
 choice
 	prompt "Provider of DTB for DT control"
 	depends on OF_CONTROL
diff --git a/dts/Makefile b/dts/Makefile
index 3437e54033d..68daaf45ec7 100644
--- a/dts/Makefile
+++ b/dts/Makefile
@@ -10,10 +10,20 @@  ifeq ($(DEVICE_TREE),)
 DEVICE_TREE := unset
 endif
 
+ifeq ($(CONFIG_OF_UPSTREAM),y)
+ifeq ($(CONFIG_ARM64),y)
+dt_dir := dts/arch/arm64
+else
+dt_dir := dts/arch/$(ARCH)
+endif
+else
+dt_dir := arch/$(ARCH)/dts
+endif
+
 ifneq ($(EXT_DTB),)
 DTB := $(EXT_DTB)
 else
-DTB := arch/$(ARCH)/dts/$(DEVICE_TREE).dtb
+DTB := $(dt_dir)/$(DEVICE_TREE).dtb
 endif
 
 $(obj)/dt-$(SPL_NAME).dtb: dts/dt.dtb $(objtree)/tools/fdtgrep FORCE
@@ -41,7 +51,7 @@  $(DTB): arch-dtbs
 
 PHONY += arch-dtbs
 arch-dtbs:
-	$(Q)$(MAKE) $(build)=arch/$(ARCH)/dts dtbs
+	$(Q)$(MAKE) $(build)=$(dt_dir) dtbs
 
 ifeq ($(CONFIG_SPL_BUILD),y)
 obj-$(CONFIG_OF_EMBED) := dt-spl.dtb.o
@@ -65,4 +75,5 @@  clean-files := dt.dtb.S
 # Let clean descend into dts directories
 subdir- += ../arch/arc/dts ../arch/arm/dts ../arch/m68k/dts ../arch/microblaze/dts	\
 	   ../arch/mips/dts ../arch/nios2/dts ../arch/powerpc/dts ../arch/riscv/dts	\
-	   ../arch/sandbox/dts ../arch/sh/dts ../arch/x86/dts ../arch/xtensa/dts
+	   ../arch/sandbox/dts ../arch/sh/dts ../arch/x86/dts ../arch/xtensa/dts	\
+	   ./arch/arm64 ./arch/$(ARCH)
diff --git a/dts/arch/arm64/Makefile b/dts/arch/arm64/Makefile
new file mode 100644
index 00000000000..16e9fea622d
--- /dev/null
+++ b/dts/arch/arm64/Makefile
@@ -0,0 +1,14 @@ 
+# SPDX-License-Identifier: GPL-2.0+
+
+include $(srctree)/scripts/Makefile.dts
+
+targets += $(dtb-y)
+
+# Add any required device tree compiler flags here
+DTC_FLAGS += -a 0x8
+
+PHONY += dtbs
+dtbs: $(addprefix $(obj)/, $(dtb-y))
+	@:
+
+clean-files := */*.dtb */*.dtbo */*_HS