[PATCH 1/1] arm: dts: Enable device-tree overlay support for sun8i-h3 pi devices

[PATCH 1/1] arm: dts: Enable device-tree overlay support for sun8i-h3 pi devices

[Felix Moessbauer]

Add the '-@' DTC option for the sun8i-h3 pi-class devices. This option
populates the '__symbols__' node that contains all the necessary symbols
for supporting device-tree overlays (for instance from the firmware or
the bootloader) on these devices.

These devices allow various modules to be connected and this enables
users to create out-of-tree device-tree overlays for these modules.

Please note that this change does increase the size of the resulting DTB
by ~30%. For example, with v6.4 increase in size is as follows:

22909 -> 29564 sun8i-h3-orangepi-lite.dtb
24214 -> 30935 sun8i-h3-bananapi-m2-plus.dtb
23915 -> 30664 sun8i-h3-nanopi-m1-plus.dtb
22969 -> 29537 sun8i-h3-nanopi-m1.dtb
24157 -> 30836 sun8i-h3-nanopi-duo2.dtb
24110 -> 30845 sun8i-h3-orangepi-plus2e.dtb
23472 -> 30037 sun8i-h3-orangepi-one.dtb
24600 -> 31410 sun8i-h3-orangepi-plus.dtb
23618 -> 30230 sun8i-h3-orangepi-2.dtb
22170 -> 28548 sun8i-h3-orangepi-zero-plus2.dtb
23258 -> 29795 sun8i-h3-nanopi-neo-air.dtb
23113 -> 29699 sun8i-h3-zeropi.dtb
22803 -> 29270 sun8i-h3-nanopi-neo.dtb
24674 -> 31318 sun8i-h3-nanopi-r1.dtb
23477 -> 30038 sun8i-h3-orangepi-pc.dtb
24622 -> 31380 sun8i-h3-bananapi-m2-plus-v1.2.dtb
23750 -> 30366 sun8i-h3-orangepi-pc-plus.dtb

Signed-off-by: Felix Moessbauer <felix.moessbauer@siemens.com>
---
Please note that I only tested the overlay on the sun8i-h3-nanopi-neo
device. However, the devices are quite similar and in general the
change to add symbols should be pretty safe. Similar patches have been
applied to various other devices in the past without any negative
effect (except for the increased size).

Felix Moessbauer
Siemens AG

 arch/arm/boot/dts/allwinner/Makefile | 19 +++++++++++++++++++
 1 file changed, 19 insertions(+)

diff --git a/arch/arm/boot/dts/allwinner/Makefile b/arch/arm/boot/dts/allwinner/Makefile
index 589a1ce1120a..eebb5a0c873a 100644
--- a/arch/arm/boot/dts/allwinner/Makefile
+++ b/arch/arm/boot/dts/allwinner/Makefile
@@ -179,6 +179,25 @@ dtb-$(CONFIG_MACH_SUN7I) += \
 	sun7i-a20-pcduino3-nano.dtb \
 	sun7i-a20-wexler-tab7200.dtb \
 	sun7i-a20-wits-pro-a20-dkt.dtb
+
+# Enables support for device-tree overlays for all pis
+DTC_FLAGS_sun8i-h3-orangepi-lite := -@
+DTC_FLAGS_sun8i-h3-bananapi-m2-plus := -@
+DTC_FLAGS_sun8i-h3-nanopi-m1-plus := -@
+DTC_FLAGS_sun8i-h3-nanopi-m1 := -@
+DTC_FLAGS_sun8i-h3-nanopi-duo2 := -@
+DTC_FLAGS_sun8i-h3-orangepi-plus2e := -@
+DTC_FLAGS_sun8i-h3-orangepi-one := -@
+DTC_FLAGS_sun8i-h3-orangepi-plus := -@
+DTC_FLAGS_sun8i-h3-orangepi-2 := -@
+DTC_FLAGS_sun8i-h3-orangepi-zero-plus2 := -@
+DTC_FLAGS_sun8i-h3-nanopi-neo-air := -@
+DTC_FLAGS_sun8i-h3-zeropi := -@
+DTC_FLAGS_sun8i-h3-nanopi-neo := -@
+DTC_FLAGS_sun8i-h3-nanopi-r1 := -@
+DTC_FLAGS_sun8i-h3-orangepi-pc := -@
+DTC_FLAGS_sun8i-h3-bananapi-m2-plus-v1.2 := -@
+DTC_FLAGS_sun8i-h3-orangepi-pc-plus := -@
 dtb-$(CONFIG_MACH_SUN8I) += \
 	sun8i-a23-evb.dtb \
 	sun8i-a23-gt90h-v4.dtb \
-- 
2.39.2

Re: [PATCH 1/1] arm: dts: Enable device-tree overlay support for sun8i-h3 pi devices

[Jernej Škrabec]

Dne torek, 27. junij 2023 ob 15:37:03 CEST je Felix Moessbauer napisal(a):
> Add the '-@' DTC option for the sun8i-h3 pi-class devices. This option
> populates the '__symbols__' node that contains all the necessary symbols
> for supporting device-tree overlays (for instance from the firmware or
> the bootloader) on these devices.
> 
> These devices allow various modules to be connected and this enables
> users to create out-of-tree device-tree overlays for these modules.
> 
> Please note that this change does increase the size of the resulting DTB
> by ~30%. For example, with v6.4 increase in size is as follows:
> 
> 22909 -> 29564 sun8i-h3-orangepi-lite.dtb
> 24214 -> 30935 sun8i-h3-bananapi-m2-plus.dtb
> 23915 -> 30664 sun8i-h3-nanopi-m1-plus.dtb
> 22969 -> 29537 sun8i-h3-nanopi-m1.dtb
> 24157 -> 30836 sun8i-h3-nanopi-duo2.dtb
> 24110 -> 30845 sun8i-h3-orangepi-plus2e.dtb
> 23472 -> 30037 sun8i-h3-orangepi-one.dtb
> 24600 -> 31410 sun8i-h3-orangepi-plus.dtb
> 23618 -> 30230 sun8i-h3-orangepi-2.dtb
> 22170 -> 28548 sun8i-h3-orangepi-zero-plus2.dtb
> 23258 -> 29795 sun8i-h3-nanopi-neo-air.dtb
> 23113 -> 29699 sun8i-h3-zeropi.dtb
> 22803 -> 29270 sun8i-h3-nanopi-neo.dtb
> 24674 -> 31318 sun8i-h3-nanopi-r1.dtb
> 23477 -> 30038 sun8i-h3-orangepi-pc.dtb
> 24622 -> 31380 sun8i-h3-bananapi-m2-plus-v1.2.dtb
> 23750 -> 30366 sun8i-h3-orangepi-pc-plus.dtb
> 
> Signed-off-by: Felix Moessbauer <felix.moessbauer@siemens.com>
> ---
> Please note that I only tested the overlay on the sun8i-h3-nanopi-neo
> device. However, the devices are quite similar and in general the
> change to add symbols should be pretty safe. Similar patches have been
> applied to various other devices in the past without any negative
> effect (except for the increased size).

I'm not a fan of this approach. What's wrong with letting kernel builders 
specify this flag on their own at compile time? That way size is still 
completely in domain of builder.

Best regards,
Jernej

> 
> Felix Moessbauer
> Siemens AG
> 
>  arch/arm/boot/dts/allwinner/Makefile | 19 +++++++++++++++++++
>  1 file changed, 19 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/allwinner/Makefile
> b/arch/arm/boot/dts/allwinner/Makefile index 589a1ce1120a..eebb5a0c873a
> 100644
> --- a/arch/arm/boot/dts/allwinner/Makefile
> +++ b/arch/arm/boot/dts/allwinner/Makefile
> @@ -179,6 +179,25 @@ dtb-$(CONFIG_MACH_SUN7I) += \
>  	sun7i-a20-pcduino3-nano.dtb \
>  	sun7i-a20-wexler-tab7200.dtb \
>  	sun7i-a20-wits-pro-a20-dkt.dtb
> +
> +# Enables support for device-tree overlays for all pis
> +DTC_FLAGS_sun8i-h3-orangepi-lite := -@
> +DTC_FLAGS_sun8i-h3-bananapi-m2-plus := -@
> +DTC_FLAGS_sun8i-h3-nanopi-m1-plus := -@
> +DTC_FLAGS_sun8i-h3-nanopi-m1 := -@
> +DTC_FLAGS_sun8i-h3-nanopi-duo2 := -@
> +DTC_FLAGS_sun8i-h3-orangepi-plus2e := -@
> +DTC_FLAGS_sun8i-h3-orangepi-one := -@
> +DTC_FLAGS_sun8i-h3-orangepi-plus := -@
> +DTC_FLAGS_sun8i-h3-orangepi-2 := -@
> +DTC_FLAGS_sun8i-h3-orangepi-zero-plus2 := -@
> +DTC_FLAGS_sun8i-h3-nanopi-neo-air := -@
> +DTC_FLAGS_sun8i-h3-zeropi := -@
> +DTC_FLAGS_sun8i-h3-nanopi-neo := -@
> +DTC_FLAGS_sun8i-h3-nanopi-r1 := -@
> +DTC_FLAGS_sun8i-h3-orangepi-pc := -@
> +DTC_FLAGS_sun8i-h3-bananapi-m2-plus-v1.2 := -@
> +DTC_FLAGS_sun8i-h3-orangepi-pc-plus := -@
>  dtb-$(CONFIG_MACH_SUN8I) += \
>  	sun8i-a23-evb.dtb \
>  	sun8i-a23-gt90h-v4.dtb \

Re: [PATCH 1/1] arm: dts: Enable device-tree overlay support for sun8i-h3 pi devices

[Moessbauer Felix]

On Tue, 2023-07-11 at 21:42 +0200, Jernej Škrabec wrote:
> Dne torek, 27. junij 2023 ob 15:37:03 CEST je Felix Moessbauer
> napisal(a):
> > Add the '-@' DTC option for the sun8i-h3 pi-class devices. This
> > option
> > populates the '__symbols__' node that contains all the necessary
> > symbols
> > for supporting device-tree overlays (for instance from the firmware
> > or
> > the bootloader) on these devices.
> > 
> > These devices allow various modules to be connected and this
> > enables
> > users to create out-of-tree device-tree overlays for these modules.
> > 
> > Please note that this change does increase the size of the
> > resulting DTB
> > by ~30%. For example, with v6.4 increase in size is as follows:
> > 
> > 22909 -> 29564 sun8i-h3-orangepi-lite.dtb
> > 24214 -> 30935 sun8i-h3-bananapi-m2-plus.dtb
> > 23915 -> 30664 sun8i-h3-nanopi-m1-plus.dtb
> > 22969 -> 29537 sun8i-h3-nanopi-m1.dtb
> > 24157 -> 30836 sun8i-h3-nanopi-duo2.dtb
> > 24110 -> 30845 sun8i-h3-orangepi-plus2e.dtb
> > 23472 -> 30037 sun8i-h3-orangepi-one.dtb
> > 24600 -> 31410 sun8i-h3-orangepi-plus.dtb
> > 23618 -> 30230 sun8i-h3-orangepi-2.dtb
> > 22170 -> 28548 sun8i-h3-orangepi-zero-plus2.dtb
> > 23258 -> 29795 sun8i-h3-nanopi-neo-air.dtb
> > 23113 -> 29699 sun8i-h3-zeropi.dtb
> > 22803 -> 29270 sun8i-h3-nanopi-neo.dtb
> > 24674 -> 31318 sun8i-h3-nanopi-r1.dtb
> > 23477 -> 30038 sun8i-h3-orangepi-pc.dtb
> > 24622 -> 31380 sun8i-h3-bananapi-m2-plus-v1.2.dtb
> > 23750 -> 30366 sun8i-h3-orangepi-pc-plus.dtb
> > 
> > Signed-off-by: Felix Moessbauer <felix.moessbauer@siemens.com>
> > ---
> > Please note that I only tested the overlay on the sun8i-h3-nanopi-
> > neo
> > device. However, the devices are quite similar and in general the
> > change to add symbols should be pretty safe. Similar patches have
> > been
> > applied to various other devices in the past without any negative
> > effect (except for the increased size).
> 
> I'm not a fan of this approach. What's wrong with letting kernel
> builders 
> specify this flag on their own at compile time? That way size is
> still 
> completely in domain of builder.

That's easier said than done. These symbols are only needed for some
targets (that are commonly used with overlays). But how should a
general purpose kernel builder like Debian know which DT to build with
symbols and which without? In Yocto the overlays are not really needed,
as often the original dts is just patched directly.

There has been a discussion in 2017 to improve the situation in
general, but without any final decision or implementation [1]. By that,
these patches got more and more common. I recently sent a very similar
patch for a riscv board that got accepted [2].

IMHO it is better to have these patches in the kernel instead of
carrying different variants of this in each Linux distro. IMHO, the
board vendors themselves should add this when they add a board.

[1]
https://lore.kernel.org/lkml/1502831736-28282-1-git-send-email-trini@konsulko.com/
[2]
https://lore.kernel.org/linux-devicetree/20230627080620.329873-1-felix.moessbauer@siemens.com/

Best regards,
Felix

> 
> Best regards,
> Jernej
> 
> > 
> > Felix Moessbauer
> > Siemens AG
> > 
> >  arch/arm/boot/dts/allwinner/Makefile | 19 +++++++++++++++++++
> >  1 file changed, 19 insertions(+)
> > 
> > diff --git a/arch/arm/boot/dts/allwinner/Makefile
> > b/arch/arm/boot/dts/allwinner/Makefile index
> > 589a1ce1120a..eebb5a0c873a
> > 100644
> > --- a/arch/arm/boot/dts/allwinner/Makefile
> > +++ b/arch/arm/boot/dts/allwinner/Makefile
> > @@ -179,6 +179,25 @@ dtb-$(CONFIG_MACH_SUN7I) += \
> >         sun7i-a20-pcduino3-nano.dtb \
> >         sun7i-a20-wexler-tab7200.dtb \
> >         sun7i-a20-wits-pro-a20-dkt.dtb
> > +
> > +# Enables support for device-tree overlays for all pis
> > +DTC_FLAGS_sun8i-h3-orangepi-lite := -@
> > +DTC_FLAGS_sun8i-h3-bananapi-m2-plus := -@
> > +DTC_FLAGS_sun8i-h3-nanopi-m1-plus := -@
> > +DTC_FLAGS_sun8i-h3-nanopi-m1 := -@
> > +DTC_FLAGS_sun8i-h3-nanopi-duo2 := -@
> > +DTC_FLAGS_sun8i-h3-orangepi-plus2e := -@
> > +DTC_FLAGS_sun8i-h3-orangepi-one := -@
> > +DTC_FLAGS_sun8i-h3-orangepi-plus := -@
> > +DTC_FLAGS_sun8i-h3-orangepi-2 := -@
> > +DTC_FLAGS_sun8i-h3-orangepi-zero-plus2 := -@
> > +DTC_FLAGS_sun8i-h3-nanopi-neo-air := -@
> > +DTC_FLAGS_sun8i-h3-zeropi := -@
> > +DTC_FLAGS_sun8i-h3-nanopi-neo := -@
> > +DTC_FLAGS_sun8i-h3-nanopi-r1 := -@
> > +DTC_FLAGS_sun8i-h3-orangepi-pc := -@
> > +DTC_FLAGS_sun8i-h3-bananapi-m2-plus-v1.2 := -@
> > +DTC_FLAGS_sun8i-h3-orangepi-pc-plus := -@
> >  dtb-$(CONFIG_MACH_SUN8I) += \
> >         sun8i-a23-evb.dtb \
> >         sun8i-a23-gt90h-v4.dtb \
> 
> 
> 
> 

Re: [PATCH 1/1] arm: dts: Enable device-tree overlay support for sun8i-h3 pi devices

[Jernej Škrabec]

Dne sreda, 19. julij 2023 ob 14:26:13 CEST je Moessbauer Felix napisal(a):
> On Tue, 2023-07-11 at 21:42 +0200, Jernej Škrabec wrote:
> > Dne torek, 27. junij 2023 ob 15:37:03 CEST je Felix Moessbauer
> > 
> > napisal(a):
> > > Add the '-@' DTC option for the sun8i-h3 pi-class devices. This
> > > option
> > > populates the '__symbols__' node that contains all the necessary
> > > symbols
> > > for supporting device-tree overlays (for instance from the firmware
> > > or
> > > the bootloader) on these devices.
> > > 
> > > These devices allow various modules to be connected and this
> > > enables
> > > users to create out-of-tree device-tree overlays for these modules.
> > > 
> > > Please note that this change does increase the size of the
> > > resulting DTB
> > > by ~30%. For example, with v6.4 increase in size is as follows:
> > > 
> > > 22909 -> 29564 sun8i-h3-orangepi-lite.dtb
> > > 24214 -> 30935 sun8i-h3-bananapi-m2-plus.dtb
> > > 23915 -> 30664 sun8i-h3-nanopi-m1-plus.dtb
> > > 22969 -> 29537 sun8i-h3-nanopi-m1.dtb
> > > 24157 -> 30836 sun8i-h3-nanopi-duo2.dtb
> > > 24110 -> 30845 sun8i-h3-orangepi-plus2e.dtb
> > > 23472 -> 30037 sun8i-h3-orangepi-one.dtb
> > > 24600 -> 31410 sun8i-h3-orangepi-plus.dtb
> > > 23618 -> 30230 sun8i-h3-orangepi-2.dtb
> > > 22170 -> 28548 sun8i-h3-orangepi-zero-plus2.dtb
> > > 23258 -> 29795 sun8i-h3-nanopi-neo-air.dtb
> > > 23113 -> 29699 sun8i-h3-zeropi.dtb
> > > 22803 -> 29270 sun8i-h3-nanopi-neo.dtb
> > > 24674 -> 31318 sun8i-h3-nanopi-r1.dtb
> > > 23477 -> 30038 sun8i-h3-orangepi-pc.dtb
> > > 24622 -> 31380 sun8i-h3-bananapi-m2-plus-v1.2.dtb
> > > 23750 -> 30366 sun8i-h3-orangepi-pc-plus.dtb
> > > 
> > > Signed-off-by: Felix Moessbauer <felix.moessbauer@siemens.com>
> > > ---
> > > Please note that I only tested the overlay on the sun8i-h3-nanopi-
> > > neo
> > > device. However, the devices are quite similar and in general the
> > > change to add symbols should be pretty safe. Similar patches have
> > > been
> > > applied to various other devices in the past without any negative
> > > effect (except for the increased size).
> > 
> > I'm not a fan of this approach. What's wrong with letting kernel
> > builders
> > specify this flag on their own at compile time? That way size is
> > still
> > completely in domain of builder.
> 
> That's easier said than done. These symbols are only needed for some
> targets (that are commonly used with overlays). But how should a
> general purpose kernel builder like Debian know which DT to build with
> symbols and which without? In Yocto the overlays are not really needed,
> as often the original dts is just patched directly.

LibreELEC (distro I help with) has support for DT overlays for some time and 
it was easy to enable symbols for all DTs with simple "DTC_FLAGS=-@" addition 
to build command [1]. Do you see any downside except knowing you have to 
include it? On the upside, there is no need to patch each and every file and 
kernel builder has a choice if overlays should be supported or not. Note that 
in some cases overlays can be needed even in the case when board doesn't have 
expansion ports.

Best regards,
Jernej

[1] https://github.com/LibreELEC/LibreELEC.tv/blob/master/packages/linux/
package.mk#L213

> 
> There has been a discussion in 2017 to improve the situation in
> general, but without any final decision or implementation [1]. By that,
> these patches got more and more common. I recently sent a very similar
> patch for a riscv board that got accepted [2].
> 
> IMHO it is better to have these patches in the kernel instead of
> carrying different variants of this in each Linux distro. IMHO, the
> board vendors themselves should add this when they add a board.
> 
> [1]
> https://lore.kernel.org/lkml/1502831736-28282-1-git-send-email-trini@konsulk
> o.com/ [2]
> https://lore.kernel.org/linux-devicetree/20230627080620.329873-1-felix.moess
> bauer@siemens.com/
> 
> Best regards,
> Felix
> 
> > Best regards,
> > Jernej
> > 
> > > Felix Moessbauer
> > > Siemens AG
> > > 
> > >  arch/arm/boot/dts/allwinner/Makefile | 19 +++++++++++++++++++
> > >  1 file changed, 19 insertions(+)
> > > 
> > > diff --git a/arch/arm/boot/dts/allwinner/Makefile
> > > b/arch/arm/boot/dts/allwinner/Makefile index
> > > 589a1ce1120a..eebb5a0c873a
> > > 100644
> > > --- a/arch/arm/boot/dts/allwinner/Makefile
> > > +++ b/arch/arm/boot/dts/allwinner/Makefile
> > > @@ -179,6 +179,25 @@ dtb-$(CONFIG_MACH_SUN7I) += \
> > >         sun7i-a20-pcduino3-nano.dtb \
> > >         sun7i-a20-wexler-tab7200.dtb \
> > >         sun7i-a20-wits-pro-a20-dkt.dtb
> > > +
> > > +# Enables support for device-tree overlays for all pis
> > > +DTC_FLAGS_sun8i-h3-orangepi-lite := -@
> > > +DTC_FLAGS_sun8i-h3-bananapi-m2-plus := -@
> > > +DTC_FLAGS_sun8i-h3-nanopi-m1-plus := -@
> > > +DTC_FLAGS_sun8i-h3-nanopi-m1 := -@
> > > +DTC_FLAGS_sun8i-h3-nanopi-duo2 := -@
> > > +DTC_FLAGS_sun8i-h3-orangepi-plus2e := -@
> > > +DTC_FLAGS_sun8i-h3-orangepi-one := -@
> > > +DTC_FLAGS_sun8i-h3-orangepi-plus := -@
> > > +DTC_FLAGS_sun8i-h3-orangepi-2 := -@
> > > +DTC_FLAGS_sun8i-h3-orangepi-zero-plus2 := -@
> > > +DTC_FLAGS_sun8i-h3-nanopi-neo-air := -@
> > > +DTC_FLAGS_sun8i-h3-zeropi := -@
> > > +DTC_FLAGS_sun8i-h3-nanopi-neo := -@
> > > +DTC_FLAGS_sun8i-h3-nanopi-r1 := -@
> > > +DTC_FLAGS_sun8i-h3-orangepi-pc := -@
> > > +DTC_FLAGS_sun8i-h3-bananapi-m2-plus-v1.2 := -@
> > > +DTC_FLAGS_sun8i-h3-orangepi-pc-plus := -@
> > >  dtb-$(CONFIG_MACH_SUN8I) += \
> > >         sun8i-a23-evb.dtb \
> > >         sun8i-a23-gt90h-v4.dtb \

Re: [PATCH 1/1] arm: dts: Enable device-tree overlay support for sun8i-h3 pi devices

[MOESSBAUER, Felix]

On Mon, 2023-07-31 at 00:12 +0200, Jernej Škrabec wrote:
> Dne sreda, 19. julij 2023 ob 14:26:13 CEST je Moessbauer Felix
> napisal(a):
> > On Tue, 2023-07-11 at 21:42 +0200, Jernej Škrabec wrote:
> > > Dne torek, 27. junij 2023 ob 15:37:03 CEST je Felix Moessbauer
> > > 
> > > napisal(a):
> > > > Add the '-@' DTC option for the sun8i-h3 pi-class devices. This
> > > > option
> > > > populates the '__symbols__' node that contains all the
> > > > necessary
> > > > symbols
> > > > for supporting device-tree overlays (for instance from the
> > > > firmware
> > > > or
> > > > the bootloader) on these devices.
> > > > 
> > > > These devices allow various modules to be connected and this
> > > > enables
> > > > users to create out-of-tree device-tree overlays for these
> > > > modules.
> > > > 
> > > > Please note that this change does increase the size of the
> > > > resulting DTB
> > > > by ~30%. For example, with v6.4 increase in size is as follows:
> > > > 
> > > > 22909 -> 29564 sun8i-h3-orangepi-lite.dtb
> > > > 24214 -> 30935 sun8i-h3-bananapi-m2-plus.dtb
> > > > 23915 -> 30664 sun8i-h3-nanopi-m1-plus.dtb
> > > > 22969 -> 29537 sun8i-h3-nanopi-m1.dtb
> > > > 24157 -> 30836 sun8i-h3-nanopi-duo2.dtb
> > > > 24110 -> 30845 sun8i-h3-orangepi-plus2e.dtb
> > > > 23472 -> 30037 sun8i-h3-orangepi-one.dtb
> > > > 24600 -> 31410 sun8i-h3-orangepi-plus.dtb
> > > > 23618 -> 30230 sun8i-h3-orangepi-2.dtb
> > > > 22170 -> 28548 sun8i-h3-orangepi-zero-plus2.dtb
> > > > 23258 -> 29795 sun8i-h3-nanopi-neo-air.dtb
> > > > 23113 -> 29699 sun8i-h3-zeropi.dtb
> > > > 22803 -> 29270 sun8i-h3-nanopi-neo.dtb
> > > > 24674 -> 31318 sun8i-h3-nanopi-r1.dtb
> > > > 23477 -> 30038 sun8i-h3-orangepi-pc.dtb
> > > > 24622 -> 31380 sun8i-h3-bananapi-m2-plus-v1.2.dtb
> > > > 23750 -> 30366 sun8i-h3-orangepi-pc-plus.dtb
> > > > 
> > > > Signed-off-by: Felix Moessbauer <felix.moessbauer@siemens.com>
> > > > ---
> > > > Please note that I only tested the overlay on the sun8i-h3-
> > > > nanopi-
> > > > neo
> > > > device. However, the devices are quite similar and in general
> > > > the
> > > > change to add symbols should be pretty safe. Similar patches
> > > > have
> > > > been
> > > > applied to various other devices in the past without any
> > > > negative
> > > > effect (except for the increased size).
> > > 
> > > I'm not a fan of this approach. What's wrong with letting kernel
> > > builders
> > > specify this flag on their own at compile time? That way size is
> > > still
> > > completely in domain of builder.
> > 
> > That's easier said than done. These symbols are only needed for
> > some
> > targets (that are commonly used with overlays). But how should a
> > general purpose kernel builder like Debian know which DT to build
> > with
> > symbols and which without? In Yocto the overlays are not really
> > needed,
> > as often the original dts is just patched directly.
> 
> LibreELEC (distro I help with) has support for DT overlays for some
> time and 
> it was easy to enable symbols for all DTs with simple "DTC_FLAGS=-@"
> addition 

Thanks for the pointer. If this would be a kconfig option, I would
agree. There's a patch to add this option, but this did not get
accepted [3]. Just manually adding some "magic" options does not feel
correct.

> to build command [1]. Do you see any downside except knowing you have
> to 
> include it? On the upside, there is no need to patch each and every
> file and 
> kernel builder has a choice if overlays should be supported or not.

There is a similar feature request for Debian, but without a decision
yet [4]. I just cross-referenced it to this thread.

> Note that 
> in some cases overlays can be needed even in the case when board
> doesn't have 
> expansion ports.

If that is the case, why can't we at least add the patch from [3] and
provide the distros an easy option to enable overlays? Once integrated,
we can eventually get rid of all the per-device patches in the kernel.

Best regards,
Felix

[3] https://www.spinics.net/lists/kernel/msg4252361.html
[4] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=910727

> 
> Best regards,
> Jernej
> 
> [1]
> https://github.com/LibreELEC/LibreELEC.tv/blob/master/packages/linux/
> package.mk#L213
> 
> > 
> > There has been a discussion in 2017 to improve the situation in
> > general, but without any final decision or implementation [1]. By
> > that,
> > these patches got more and more common. I recently sent a very
> > similar
> > patch for a riscv board that got accepted [2].
> > 
> > IMHO it is better to have these patches in the kernel instead of
> > carrying different variants of this in each Linux distro. IMHO, the
> > board vendors themselves should add this when they add a board.
> > 
> > [1]
> > https://lore.kernel.org/lkml/1502831736-28282-1-git-send-email-trini@konsulk
> > o.com/ [2]
> > https://lore.kernel.org/linux-devicetree/20230627080620.329873-1-felix.moess
> > bauer@siemens.com/
> > 
> > Best regards,
> > Felix
> > 
> > > Best regards,
> > > Jernej
> > > 
> > > > Felix Moessbauer
> > > > Siemens AG
> > > > 
> > > >  arch/arm/boot/dts/allwinner/Makefile | 19 +++++++++++++++++++
> > > >  1 file changed, 19 insertions(+)
> > > > 
> > > > diff --git a/arch/arm/boot/dts/allwinner/Makefile
> > > > b/arch/arm/boot/dts/allwinner/Makefile index
> > > > 589a1ce1120a..eebb5a0c873a
> > > > 100644
> > > > --- a/arch/arm/boot/dts/allwinner/Makefile
> > > > +++ b/arch/arm/boot/dts/allwinner/Makefile
> > > > @@ -179,6 +179,25 @@ dtb-$(CONFIG_MACH_SUN7I) += \
> > > >         sun7i-a20-pcduino3-nano.dtb \
> > > >         sun7i-a20-wexler-tab7200.dtb \
> > > >         sun7i-a20-wits-pro-a20-dkt.dtb
> > > > +
> > > > +# Enables support for device-tree overlays for all pis
> > > > +DTC_FLAGS_sun8i-h3-orangepi-lite := -@
> > > > +DTC_FLAGS_sun8i-h3-bananapi-m2-plus := -@
> > > > +DTC_FLAGS_sun8i-h3-nanopi-m1-plus := -@
> > > > +DTC_FLAGS_sun8i-h3-nanopi-m1 := -@
> > > > +DTC_FLAGS_sun8i-h3-nanopi-duo2 := -@
> > > > +DTC_FLAGS_sun8i-h3-orangepi-plus2e := -@
> > > > +DTC_FLAGS_sun8i-h3-orangepi-one := -@
> > > > +DTC_FLAGS_sun8i-h3-orangepi-plus := -@
> > > > +DTC_FLAGS_sun8i-h3-orangepi-2 := -@
> > > > +DTC_FLAGS_sun8i-h3-orangepi-zero-plus2 := -@
> > > > +DTC_FLAGS_sun8i-h3-nanopi-neo-air := -@
> > > > +DTC_FLAGS_sun8i-h3-zeropi := -@
> > > > +DTC_FLAGS_sun8i-h3-nanopi-neo := -@
> > > > +DTC_FLAGS_sun8i-h3-nanopi-r1 := -@
> > > > +DTC_FLAGS_sun8i-h3-orangepi-pc := -@
> > > > +DTC_FLAGS_sun8i-h3-bananapi-m2-plus-v1.2 := -@
> > > > +DTC_FLAGS_sun8i-h3-orangepi-pc-plus := -@
> > > >  dtb-$(CONFIG_MACH_SUN8I) += \
> > > >         sun8i-a23-evb.dtb \
> > > >         sun8i-a23-gt90h-v4.dtb \
> 
> 
> 
> 

Re: [PATCH 1/1] arm: dts: Enable device-tree overlay support for sun8i-h3 pi devices

[Andre Przywara]

Hi,

On 31/07/2023 03:46, MOESSBAUER, Felix wrote:
> On Mon, 2023-07-31 at 00:12 +0200, Jernej Škrabec wrote:
>> Dne sreda, 19. julij 2023 ob 14:26:13 CEST je Moessbauer Felix
>> napisal(a):
>>> On Tue, 2023-07-11 at 21:42 +0200, Jernej Škrabec wrote:
>>>> Dne torek, 27. junij 2023 ob 15:37:03 CEST je Felix Moessbauer
>>>>
>>>> napisal(a):
>>>>> Add the '-@' DTC option for the sun8i-h3 pi-class devices. This
>>>>> option
>>>>> populates the '__symbols__' node that contains all the
>>>>> necessary
>>>>> symbols
>>>>> for supporting device-tree overlays (for instance from the
>>>>> firmware
>>>>> or
>>>>> the bootloader) on these devices.
>>>>>
>>>>> These devices allow various modules to be connected and this
>>>>> enables
>>>>> users to create out-of-tree device-tree overlays for these
>>>>> modules.
>>>>>
>>>>> Please note that this change does increase the size of the
>>>>> resulting DTB
>>>>> by ~30%. For example, with v6.4 increase in size is as follows:
>>>>>
>>>>> 22909 -> 29564 sun8i-h3-orangepi-lite.dtb
>>>>> 24214 -> 30935 sun8i-h3-bananapi-m2-plus.dtb
>>>>> 23915 -> 30664 sun8i-h3-nanopi-m1-plus.dtb
>>>>> 22969 -> 29537 sun8i-h3-nanopi-m1.dtb
>>>>> 24157 -> 30836 sun8i-h3-nanopi-duo2.dtb
>>>>> 24110 -> 30845 sun8i-h3-orangepi-plus2e.dtb
>>>>> 23472 -> 30037 sun8i-h3-orangepi-one.dtb
>>>>> 24600 -> 31410 sun8i-h3-orangepi-plus.dtb
>>>>> 23618 -> 30230 sun8i-h3-orangepi-2.dtb
>>>>> 22170 -> 28548 sun8i-h3-orangepi-zero-plus2.dtb
>>>>> 23258 -> 29795 sun8i-h3-nanopi-neo-air.dtb
>>>>> 23113 -> 29699 sun8i-h3-zeropi.dtb
>>>>> 22803 -> 29270 sun8i-h3-nanopi-neo.dtb
>>>>> 24674 -> 31318 sun8i-h3-nanopi-r1.dtb
>>>>> 23477 -> 30038 sun8i-h3-orangepi-pc.dtb
>>>>> 24622 -> 31380 sun8i-h3-bananapi-m2-plus-v1.2.dtb
>>>>> 23750 -> 30366 sun8i-h3-orangepi-pc-plus.dtb
>>>>>
>>>>> Signed-off-by: Felix Moessbauer <felix.moessbauer@siemens.com>
>>>>> ---
>>>>> Please note that I only tested the overlay on the sun8i-h3-
>>>>> nanopi-
>>>>> neo
>>>>> device. However, the devices are quite similar and in general
>>>>> the
>>>>> change to add symbols should be pretty safe. Similar patches
>>>>> have
>>>>> been
>>>>> applied to various other devices in the past without any
>>>>> negative
>>>>> effect (except for the increased size).
>>>>
>>>> I'm not a fan of this approach. What's wrong with letting kernel
>>>> builders
>>>> specify this flag on their own at compile time? That way size is
>>>> still
>>>> completely in domain of builder.
>>>
>>> That's easier said than done. These symbols are only needed for
>>> some
>>> targets (that are commonly used with overlays). But how should a
>>> general purpose kernel builder like Debian know which DT to build
>>> with
>>> symbols and which without? In Yocto the overlays are not really
>>> needed,
>>> as often the original dts is just patched directly.
>>
>> LibreELEC (distro I help with) has support for DT overlays for some
>> time and
>> it was easy to enable symbols for all DTs with simple "DTC_FLAGS=-@"
>> addition

So why don't you use the U-Boot provided copy of the DTB? We sync the 
DTs regularly from the kernel repo to the U-Boot repo, and the U-Boot 
build system builds all DTBs with overlay support already.
This also saves you from the hassle to actually find and load the right 
DTB, as it automatically comes as part of the U-Boot binary.
On the U-Boot prompt (or rather in a script) you would then do:
=> fdt move $fdtcontroladdr $fdt_addr_r
=> load <source> $fdtoverlay_addr_r <your_overlay>.dtbo
=> fdt apply $fdtoverlay_addr_r

You could also chime in on this U-Boot patch of mine, that loads and 
applies all .dtbo files found in a given directory:
https://lore.kernel.org/u-boot/20230210110213.2531190-1-andre.przywara@arm.com/

Cheers,
Andre

> 
> Thanks for the pointer. If this would be a kconfig option, I would
> agree. There's a patch to add this option, but this did not get
> accepted [3]. Just manually adding some "magic" options does not feel
> correct.
> 
>> to build command [1]. Do you see any downside except knowing you have
>> to
>> include it? On the upside, there is no need to patch each and every
>> file and
>> kernel builder has a choice if overlays should be supported or not.
> 
> There is a similar feature request for Debian, but without a decision
> yet [4]. I just cross-referenced it to this thread.
> 
>> Note that
>> in some cases overlays can be needed even in the case when board
>> doesn't have
>> expansion ports.
> 
> If that is the case, why can't we at least add the patch from [3] and
> provide the distros an easy option to enable overlays? Once integrated,
> we can eventually get rid of all the per-device patches in the kernel.
> 
> Best regards,
> Felix
> 
> [3] https://www.spinics.net/lists/kernel/msg4252361.html
> [4] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=910727
> 
>>
>> Best regards,
>> Jernej
>>
>> [1]
>> https://github.com/LibreELEC/LibreELEC.tv/blob/master/packages/linux/
>> package.mk#L213
>>
>>>
>>> There has been a discussion in 2017 to improve the situation in
>>> general, but without any final decision or implementation [1]. By
>>> that,
>>> these patches got more and more common. I recently sent a very
>>> similar
>>> patch for a riscv board that got accepted [2].
>>>
>>> IMHO it is better to have these patches in the kernel instead of
>>> carrying different variants of this in each Linux distro. IMHO, the
>>> board vendors themselves should add this when they add a board.
>>>
>>> [1]
>>> https://lore.kernel.org/lkml/1502831736-28282-1-git-send-email-trini@konsulk
>>> o.com/ [2]
>>> https://lore.kernel.org/linux-devicetree/20230627080620.329873-1-felix.moess
>>> bauer@siemens.com/
>>>
>>> Best regards,
>>> Felix
>>>
>>>> Best regards,
>>>> Jernej
>>>>
>>>>> Felix Moessbauer
>>>>> Siemens AG
>>>>>
>>>>>   arch/arm/boot/dts/allwinner/Makefile | 19 +++++++++++++++++++
>>>>>   1 file changed, 19 insertions(+)
>>>>>
>>>>> diff --git a/arch/arm/boot/dts/allwinner/Makefile
>>>>> b/arch/arm/boot/dts/allwinner/Makefile index
>>>>> 589a1ce1120a..eebb5a0c873a
>>>>> 100644
>>>>> --- a/arch/arm/boot/dts/allwinner/Makefile
>>>>> +++ b/arch/arm/boot/dts/allwinner/Makefile
>>>>> @@ -179,6 +179,25 @@ dtb-$(CONFIG_MACH_SUN7I) += \
>>>>>          sun7i-a20-pcduino3-nano.dtb \
>>>>>          sun7i-a20-wexler-tab7200.dtb \
>>>>>          sun7i-a20-wits-pro-a20-dkt.dtb
>>>>> +
>>>>> +# Enables support for device-tree overlays for all pis
>>>>> +DTC_FLAGS_sun8i-h3-orangepi-lite := -@
>>>>> +DTC_FLAGS_sun8i-h3-bananapi-m2-plus := -@
>>>>> +DTC_FLAGS_sun8i-h3-nanopi-m1-plus := -@
>>>>> +DTC_FLAGS_sun8i-h3-nanopi-m1 := -@
>>>>> +DTC_FLAGS_sun8i-h3-nanopi-duo2 := -@
>>>>> +DTC_FLAGS_sun8i-h3-orangepi-plus2e := -@
>>>>> +DTC_FLAGS_sun8i-h3-orangepi-one := -@
>>>>> +DTC_FLAGS_sun8i-h3-orangepi-plus := -@
>>>>> +DTC_FLAGS_sun8i-h3-orangepi-2 := -@
>>>>> +DTC_FLAGS_sun8i-h3-orangepi-zero-plus2 := -@
>>>>> +DTC_FLAGS_sun8i-h3-nanopi-neo-air := -@
>>>>> +DTC_FLAGS_sun8i-h3-zeropi := -@
>>>>> +DTC_FLAGS_sun8i-h3-nanopi-neo := -@
>>>>> +DTC_FLAGS_sun8i-h3-nanopi-r1 := -@
>>>>> +DTC_FLAGS_sun8i-h3-orangepi-pc := -@
>>>>> +DTC_FLAGS_sun8i-h3-bananapi-m2-plus-v1.2 := -@
>>>>> +DTC_FLAGS_sun8i-h3-orangepi-pc-plus := -@
>>>>>   dtb-$(CONFIG_MACH_SUN8I) += \
>>>>>          sun8i-a23-evb.dtb \
>>>>>          sun8i-a23-gt90h-v4.dtb \
>>
>>
>>
>>
> 

Re: [PATCH 1/1] arm: dts: Enable device-tree overlay support for sun8i-h3 pi devices

[MOESSBAUER, Felix]

On Mon, 2023-07-31 at 10:53 +0100, Andre Przywara wrote:
> Hi,
> 
> On 31/07/2023 03:46, MOESSBAUER, Felix wrote:
> > On Mon, 2023-07-31 at 00:12 +0200, Jernej Škrabec wrote:
> > > Dne sreda, 19. julij 2023 ob 14:26:13 CEST je Moessbauer Felix
> > > napisal(a):
> > > > On Tue, 2023-07-11 at 21:42 +0200, Jernej Škrabec wrote:
> > > > > Dne torek, 27. junij 2023 ob 15:37:03 CEST je Felix
> > > > > Moessbauer
> > > > > 
> > > > > napisal(a):
> > > > > > Add the '-@' DTC option for the sun8i-h3 pi-class devices.
> > > > > > This
> > > > > > option
> > > > > > populates the '__symbols__' node that contains all the
> > > > > > necessary
> > > > > > symbols
> > > > > > for supporting device-tree overlays (for instance from the
> > > > > > firmware
> > > > > > or
> > > > > > the bootloader) on these devices.
> > > > > > 
> > > > > > These devices allow various modules to be connected and
> > > > > > this
> > > > > > enables
> > > > > > users to create out-of-tree device-tree overlays for these
> > > > > > modules.
> > > > > > 
> > > > > > Please note that this change does increase the size of the
> > > > > > resulting DTB
> > > > > > by ~30%. For example, with v6.4 increase in size is as
> > > > > > follows:
> > > > > > 
> > > > > > 22909 -> 29564 sun8i-h3-orangepi-lite.dtb
> > > > > > 24214 -> 30935 sun8i-h3-bananapi-m2-plus.dtb
> > > > > > 23915 -> 30664 sun8i-h3-nanopi-m1-plus.dtb
> > > > > > 22969 -> 29537 sun8i-h3-nanopi-m1.dtb
> > > > > > 24157 -> 30836 sun8i-h3-nanopi-duo2.dtb
> > > > > > 24110 -> 30845 sun8i-h3-orangepi-plus2e.dtb
> > > > > > 23472 -> 30037 sun8i-h3-orangepi-one.dtb
> > > > > > 24600 -> 31410 sun8i-h3-orangepi-plus.dtb
> > > > > > 23618 -> 30230 sun8i-h3-orangepi-2.dtb
> > > > > > 22170 -> 28548 sun8i-h3-orangepi-zero-plus2.dtb
> > > > > > 23258 -> 29795 sun8i-h3-nanopi-neo-air.dtb
> > > > > > 23113 -> 29699 sun8i-h3-zeropi.dtb
> > > > > > 22803 -> 29270 sun8i-h3-nanopi-neo.dtb
> > > > > > 24674 -> 31318 sun8i-h3-nanopi-r1.dtb
> > > > > > 23477 -> 30038 sun8i-h3-orangepi-pc.dtb
> > > > > > 24622 -> 31380 sun8i-h3-bananapi-m2-plus-v1.2.dtb
> > > > > > 23750 -> 30366 sun8i-h3-orangepi-pc-plus.dtb
> > > > > > 
> > > > > > Signed-off-by: Felix Moessbauer
> > > > > > <felix.moessbauer@siemens.com>
> > > > > > ---
> > > > > > Please note that I only tested the overlay on the sun8i-h3-
> > > > > > nanopi-
> > > > > > neo
> > > > > > device. However, the devices are quite similar and in
> > > > > > general
> > > > > > the
> > > > > > change to add symbols should be pretty safe. Similar
> > > > > > patches
> > > > > > have
> > > > > > been
> > > > > > applied to various other devices in the past without any
> > > > > > negative
> > > > > > effect (except for the increased size).
> > > > > 
> > > > > I'm not a fan of this approach. What's wrong with letting
> > > > > kernel
> > > > > builders
> > > > > specify this flag on their own at compile time? That way size
> > > > > is
> > > > > still
> > > > > completely in domain of builder.

At least the Debian maintainers decided to NOT include the -@ for all
targets, but purely rely on what the kernel offers [5]. They motivate
this with a similar decision made in the Kernel. This brings us back to
my patch which enables the -@ for particular boards in the Kernel
itself.

[5] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=910727#28

> > > > 
> > > > That's easier said than done. These symbols are only needed for
> > > > some
> > > > targets (that are commonly used with overlays). But how should
> > > > a
> > > > general purpose kernel builder like Debian know which DT to
> > > > build
> > > > with
> > > > symbols and which without? In Yocto the overlays are not really
> > > > needed,
> > > > as often the original dts is just patched directly.
> > > 
> > > LibreELEC (distro I help with) has support for DT overlays for
> > > some
> > > time and
> > > it was easy to enable symbols for all DTs with simple
> > > "DTC_FLAGS=-@"
> > > addition
> 
> So why don't you use the U-Boot provided copy of the DTB? We sync the
> DTs regularly from the kernel repo to the U-Boot repo, and the U-Boot
> build system builds all DTBs with overlay support already.
> This also saves you from the hassle to actually find and load the
> right 
> DTB, as it automatically comes as part of the U-Boot binary.
> On the U-Boot prompt (or rather in a script) you would then do:
> => fdt move $fdtcontroladdr $fdt_addr_r
> => load <source> $fdtoverlay_addr_r <your_overlay>.dtbo
> => fdt apply $fdtoverlay_addr_r

For systems that use u-boot this is a very convenient option. Thanks
for bringing this up. However, there are other boot-chains where this
is not an option. Also, with this argument no target in the Kernel
would need to be compiled with -@.

My understanding was that adding the -@ is generally accepted if it is
only done on a per-device basis (which this patch does), but not
accepted for whole architectures. By that, I expect to see many similar
patches in the future.

Cheers,
Felix

> 
> You could also chime in on this U-Boot patch of mine, that loads and 
> applies all .dtbo files found in a given directory:
> https://lore.kernel.org/u-boot/20230210110213.2531190-1-andre.przywara@arm.com/
> 
> Cheers,
> Andre
> 
> > 
> > Thanks for the pointer. If this would be a kconfig option, I would
> > agree. There's a patch to add this option, but this did not get
> > accepted [3]. Just manually adding some "magic" options does not
> > feel
> > correct.
> > 
> > > to build command [1]. Do you see any downside except knowing you
> > > have
> > > to
> > > include it? On the upside, there is no need to patch each and
> > > every
> > > file and
> > > kernel builder has a choice if overlays should be supported or
> > > not.
> > 
> > There is a similar feature request for Debian, but without a
> > decision
> > yet [4]. I just cross-referenced it to this thread.
> > 
> > > Note that
> > > in some cases overlays can be needed even in the case when board
> > > doesn't have
> > > expansion ports.
> > 
> > If that is the case, why can't we at least add the patch from [3]
> > and
> > provide the distros an easy option to enable overlays? Once
> > integrated,
> > we can eventually get rid of all the per-device patches in the
> > kernel.
> > 
> > Best regards,
> > Felix
> > 
> > [3] https://www.spinics.net/lists/kernel/msg4252361.html
> > [4] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=910727
> > 
> > > 
> > > Best regards,
> > > Jernej
> > > 
> > > [1]
> > > https://github.com/LibreELEC/LibreELEC.tv/blob/master/packages/linux/
> > > package.mk#L213
> > > 
> > > > 
> > > > There has been a discussion in 2017 to improve the situation in
> > > > general, but without any final decision or implementation [1].
> > > > By
> > > > that,
> > > > these patches got more and more common. I recently sent a very
> > > > similar
> > > > patch for a riscv board that got accepted [2].
> > > > 
> > > > IMHO it is better to have these patches in the kernel instead
> > > > of
> > > > carrying different variants of this in each Linux distro. IMHO,
> > > > the
> > > > board vendors themselves should add this when they add a board.
> > > > 
> > > > [1]
> > > > https://lore.kernel.org/lkml/1502831736-28282-1-git-send-email-trini@konsulk
> > > > o.com/ [2]
> > > > https://lore.kernel.org/linux-devicetree/20230627080620.329873-1-felix.moess
> > > > bauer@siemens.com/
> > > > 
> > > > Best regards,
> > > > Felix
> > > > 
> > > > > Best regards,
> > > > > Jernej
> > > > > 
> > > > > > Felix Moessbauer
> > > > > > Siemens AG
> > > > > > 
> > > > > >   arch/arm/boot/dts/allwinner/Makefile | 19
> > > > > > +++++++++++++++++++
> > > > > >   1 file changed, 19 insertions(+)
> > > > > > 
> > > > > > diff --git a/arch/arm/boot/dts/allwinner/Makefile
> > > > > > b/arch/arm/boot/dts/allwinner/Makefile index
> > > > > > 589a1ce1120a..eebb5a0c873a
> > > > > > 100644
> > > > > > --- a/arch/arm/boot/dts/allwinner/Makefile
> > > > > > +++ b/arch/arm/boot/dts/allwinner/Makefile
> > > > > > @@ -179,6 +179,25 @@ dtb-$(CONFIG_MACH_SUN7I) += \
> > > > > >          sun7i-a20-pcduino3-nano.dtb \
> > > > > >          sun7i-a20-wexler-tab7200.dtb \
> > > > > >          sun7i-a20-wits-pro-a20-dkt.dtb
> > > > > > +
> > > > > > +# Enables support for device-tree overlays for all pis
> > > > > > +DTC_FLAGS_sun8i-h3-orangepi-lite := -@
> > > > > > +DTC_FLAGS_sun8i-h3-bananapi-m2-plus := -@
> > > > > > +DTC_FLAGS_sun8i-h3-nanopi-m1-plus := -@
> > > > > > +DTC_FLAGS_sun8i-h3-nanopi-m1 := -@
> > > > > > +DTC_FLAGS_sun8i-h3-nanopi-duo2 := -@
> > > > > > +DTC_FLAGS_sun8i-h3-orangepi-plus2e := -@
> > > > > > +DTC_FLAGS_sun8i-h3-orangepi-one := -@
> > > > > > +DTC_FLAGS_sun8i-h3-orangepi-plus := -@
> > > > > > +DTC_FLAGS_sun8i-h3-orangepi-2 := -@
> > > > > > +DTC_FLAGS_sun8i-h3-orangepi-zero-plus2 := -@
> > > > > > +DTC_FLAGS_sun8i-h3-nanopi-neo-air := -@
> > > > > > +DTC_FLAGS_sun8i-h3-zeropi := -@
> > > > > > +DTC_FLAGS_sun8i-h3-nanopi-neo := -@
> > > > > > +DTC_FLAGS_sun8i-h3-nanopi-r1 := -@
> > > > > > +DTC_FLAGS_sun8i-h3-orangepi-pc := -@
> > > > > > +DTC_FLAGS_sun8i-h3-bananapi-m2-plus-v1.2 := -@
> > > > > > +DTC_FLAGS_sun8i-h3-orangepi-pc-plus := -@
> > > > > >   dtb-$(CONFIG_MACH_SUN8I) += \
> > > > > >          sun8i-a23-evb.dtb \
> > > > > >          sun8i-a23-gt90h-v4.dtb \
> > > 
> > > 
> > > 
> > > 
> > 

Re: [PATCH 1/1] arm: dts: Enable device-tree overlay support for sun8i-h3 pi devices

[Jernej Škrabec]

Dne torek, 01. avgust 2023 ob 13:59:49 CEST je MOESSBAUER, Felix napisal(a):
> On Mon, 2023-07-31 at 10:53 +0100, Andre Przywara wrote:
> 
> > Hi,
> > 
> > On 31/07/2023 03:46, MOESSBAUER, Felix wrote:
> > 
> > > On Mon, 2023-07-31 at 00:12 +0200, Jernej Škrabec wrote:
> > > 
> > > > Dne sreda, 19. julij 2023 ob 14:26:13 CEST je Moessbauer Felix
> > > > napisal(a):
> > > > 
> > > > > On Tue, 2023-07-11 at 21:42 +0200, Jernej Škrabec wrote:
> > > > > 
> > > > > > Dne torek, 27. junij 2023 ob 15:37:03 CEST je Felix
> > > > > > Moessbauer
> > > > > > 
> > > > > > napisal(a):
> > > > > > 
> > > > > > > Add the '-@' DTC option for the sun8i-h3 pi-class devices.
> > > > > > > This
> > > > > > > option
> > > > > > > populates the '__symbols__' node that contains all the
> > > > > > > necessary
> > > > > > > symbols
> > > > > > > for supporting device-tree overlays (for instance from the
> > > > > > > firmware
> > > > > > > or
> > > > > > > the bootloader) on these devices.
> > > > > > > 
> > > > > > > These devices allow various modules to be connected and
> > > > > > > this
> > > > > > > enables
> > > > > > > users to create out-of-tree device-tree overlays for these
> > > > > > > modules.
> > > > > > > 
> > > > > > > Please note that this change does increase the size of the
> > > > > > > resulting DTB
> > > > > > > by ~30%. For example, with v6.4 increase in size is as
> > > > > > > follows:
> > > > > > > 
> > > > > > > 22909 -> 29564 sun8i-h3-orangepi-lite.dtb
> > > > > > > 24214 -> 30935 sun8i-h3-bananapi-m2-plus.dtb
> > > > > > > 23915 -> 30664 sun8i-h3-nanopi-m1-plus.dtb
> > > > > > > 22969 -> 29537 sun8i-h3-nanopi-m1.dtb
> > > > > > > 24157 -> 30836 sun8i-h3-nanopi-duo2.dtb
> > > > > > > 24110 -> 30845 sun8i-h3-orangepi-plus2e.dtb
> > > > > > > 23472 -> 30037 sun8i-h3-orangepi-one.dtb
> > > > > > > 24600 -> 31410 sun8i-h3-orangepi-plus.dtb
> > > > > > > 23618 -> 30230 sun8i-h3-orangepi-2.dtb
> > > > > > > 22170 -> 28548 sun8i-h3-orangepi-zero-plus2.dtb
> > > > > > > 23258 -> 29795 sun8i-h3-nanopi-neo-air.dtb
> > > > > > > 23113 -> 29699 sun8i-h3-zeropi.dtb
> > > > > > > 22803 -> 29270 sun8i-h3-nanopi-neo.dtb
> > > > > > > 24674 -> 31318 sun8i-h3-nanopi-r1.dtb
> > > > > > > 23477 -> 30038 sun8i-h3-orangepi-pc.dtb
> > > > > > > 24622 -> 31380 sun8i-h3-bananapi-m2-plus-v1.2.dtb
> > > > > > > 23750 -> 30366 sun8i-h3-orangepi-pc-plus.dtb
> > > > > > > 
> > > > > > > Signed-off-by: Felix Moessbauer
> > > > > > > <felix.moessbauer@siemens.com>
> > > > > > > ---
> > > > > > > Please note that I only tested the overlay on the sun8i-h3-
> > > > > > > nanopi-
> > > > > > > neo
> > > > > > > device. However, the devices are quite similar and in
> > > > > > > general
> > > > > > > the
> > > > > > > change to add symbols should be pretty safe. Similar
> > > > > > > patches
> > > > > > > have
> > > > > > > been
> > > > > > > applied to various other devices in the past without any
> > > > > > > negative
> > > > > > > effect (except for the increased size).
> > > > > > 
> > > > > > 
> > > > > > I'm not a fan of this approach. What's wrong with letting
> > > > > > kernel
> > > > > > builders
> > > > > > specify this flag on their own at compile time? That way size
> > > > > > is
> > > > > > still
> > > > > > completely in domain of builder.
> 
> 
> At least the Debian maintainers decided to NOT include the -@ for all
> targets, but purely rely on what the kernel offers [5]. They motivate
> this with a similar decision made in the Kernel. This brings us back to
> my patch which enables the -@ for particular boards in the Kernel
> itself.
> 
> [5] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=910727#28
> 
> 
> > > > > 
> > > > > That's easier said than done. These symbols are only needed for
> > > > > some
> > > > > targets (that are commonly used with overlays). But how should
> > > > > a
> > > > > general purpose kernel builder like Debian know which DT to
> > > > > build
> > > > > with
> > > > > symbols and which without? In Yocto the overlays are not really
> > > > > needed,
> > > > > as often the original dts is just patched directly.
> > > > 
> > > > 
> > > > LibreELEC (distro I help with) has support for DT overlays for
> > > > some
> > > > time and
> > > > it was easy to enable symbols for all DTs with simple
> > > > "DTC_FLAGS=-@"
> > > > addition
> > 
> > 
> > So why don't you use the U-Boot provided copy of the DTB? We sync the
> > DTs regularly from the kernel repo to the U-Boot repo, and the U-Boot
> > build system builds all DTBs with overlay support already.
> > This also saves you from the hassle to actually find and load the
> > right 
> > DTB, as it automatically comes as part of the U-Boot binary.
> > On the U-Boot prompt (or rather in a script) you would then do:
> > => fdt move $fdtcontroladdr $fdt_addr_r
> > => load <source> $fdtoverlay_addr_r <your_overlay>.dtbo
> > => fdt apply $fdtoverlay_addr_r
> 
> 
> For systems that use u-boot this is a very convenient option. Thanks
> for bringing this up. However, there are other boot-chains where this
> is not an option. Also, with this argument no target in the Kernel
> would need to be compiled with -@.
> 
> My understanding was that adding the -@ is generally accepted if it is
> only done on a per-device basis (which this patch does), but not
> accepted for whole architectures. By that, I expect to see many similar
> patches in the future.

I don't necessarly agree with this approach, but since other ways are 
rejected, I'll merge this one if there are no further complaints.

Acked-by: Jernej Skrabec <jernej.skrabec@gmail.com>

Best regards,
Jernej

> 
> Cheers,
> Felix
> 
> 
> > 
> > You could also chime in on this U-Boot patch of mine, that loads and 
> > applies all .dtbo files found in a given directory:
> > https://lore.kernel.org/u-boot/20230210110213.2531190-1-andre.przywara@arm
> > .com/
 
> > Cheers,
> > Andre
> > 
> > 
> > > 
> > > Thanks for the pointer. If this would be a kconfig option, I would
> > > agree. There's a patch to add this option, but this did not get
> > > accepted [3]. Just manually adding some "magic" options does not
> > > feel
> > > correct.
> > > 
> > > 
> > > > to build command [1]. Do you see any downside except knowing you
> > > > have
> > > > to
> > > > include it? On the upside, there is no need to patch each and
> > > > every
> > > > file and
> > > > kernel builder has a choice if overlays should be supported or
> > > > not.
> > > 
> > > 
> > > There is a similar feature request for Debian, but without a
> > > decision
> > > yet [4]. I just cross-referenced it to this thread.
> > > 
> > > 
> > > > Note that
> > > > in some cases overlays can be needed even in the case when board
> > > > doesn't have
> > > > expansion ports.
> > > 
> > > 
> > > If that is the case, why can't we at least add the patch from [3]
> > > and
> > > provide the distros an easy option to enable overlays? Once
> > > integrated,
> > > we can eventually get rid of all the per-device patches in the
> > > kernel.
> > > 
> > > Best regards,
> > > Felix
> > > 
> > > [3] https://www.spinics.net/lists/kernel/msg4252361.html
> > > [4] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=910727
> > > 
> > > 
> > > > 
> > > > Best regards,
> > > > Jernej
> > > > 
> > > > [1]
> > > > https://github.com/LibreELEC/LibreELEC.tv/blob/master/packages/linux/
> > > > package.mk#L213
> > > > 
> > > > 
> > > > > 
> > > > > There has been a discussion in 2017 to improve the situation in
> > > > > general, but without any final decision or implementation [1].
> > > > > By
> > > > > that,
> > > > > these patches got more and more common. I recently sent a very
> > > > > similar
> > > > > patch for a riscv board that got accepted [2].
> > > > > 
> > > > > IMHO it is better to have these patches in the kernel instead
> > > > > of
> > > > > carrying different variants of this in each Linux distro. IMHO,
> > > > > the
> > > > > board vendors themselves should add this when they add a board.
> > > > > 
> > > > > [1]
> > > > > https://lore.kernel.org/lkml/1502831736-28282-1-git-send-email-trini
> > > > > @konsulk
 o.com/ [2]
> > > > > https://lore.kernel.org/linux-devicetree/20230627080620.329873-1-fel
> > > > > ix.moess
 bauer@siemens.com/
> > > > > 
> > > > > Best regards,
> > > > > Felix
> > > > > 
> > > > > 
> > > > > > Best regards,
> > > > > > Jernej
> > > > > > 
> > > > > > 
> > > > > > > Felix Moessbauer
> > > > > > > Siemens AG
> > > > > > > 
> > > > > > >   arch/arm/boot/dts/allwinner/Makefile | 19
> > > > > > > +++++++++++++++++++
> > > > > > >   1 file changed, 19 insertions(+)
> > > > > > > 
> > > > > > > diff --git a/arch/arm/boot/dts/allwinner/Makefile
> > > > > > > b/arch/arm/boot/dts/allwinner/Makefile index
> > > > > > > 589a1ce1120a..eebb5a0c873a
> > > > > > > 100644
> > > > > > > --- a/arch/arm/boot/dts/allwinner/Makefile
> > > > > > > +++ b/arch/arm/boot/dts/allwinner/Makefile
> > > > > > > @@ -179,6 +179,25 @@ dtb-$(CONFIG_MACH_SUN7I) += \
> > > > > > >          sun7i-a20-pcduino3-nano.dtb \
> > > > > > >          sun7i-a20-wexler-tab7200.dtb \
> > > > > > >          sun7i-a20-wits-pro-a20-dkt.dtb
> > > > > > > +
> > > > > > > +# Enables support for device-tree overlays for all pis
> > > > > > > +DTC_FLAGS_sun8i-h3-orangepi-lite := -@
> > > > > > > +DTC_FLAGS_sun8i-h3-bananapi-m2-plus := -@
> > > > > > > +DTC_FLAGS_sun8i-h3-nanopi-m1-plus := -@
> > > > > > > +DTC_FLAGS_sun8i-h3-nanopi-m1 := -@
> > > > > > > +DTC_FLAGS_sun8i-h3-nanopi-duo2 := -@
> > > > > > > +DTC_FLAGS_sun8i-h3-orangepi-plus2e := -@
> > > > > > > +DTC_FLAGS_sun8i-h3-orangepi-one := -@
> > > > > > > +DTC_FLAGS_sun8i-h3-orangepi-plus := -@
> > > > > > > +DTC_FLAGS_sun8i-h3-orangepi-2 := -@
> > > > > > > +DTC_FLAGS_sun8i-h3-orangepi-zero-plus2 := -@
> > > > > > > +DTC_FLAGS_sun8i-h3-nanopi-neo-air := -@
> > > > > > > +DTC_FLAGS_sun8i-h3-zeropi := -@
> > > > > > > +DTC_FLAGS_sun8i-h3-nanopi-neo := -@
> > > > > > > +DTC_FLAGS_sun8i-h3-nanopi-r1 := -@
> > > > > > > +DTC_FLAGS_sun8i-h3-orangepi-pc := -@
> > > > > > > +DTC_FLAGS_sun8i-h3-bananapi-m2-plus-v1.2 := -@
> > > > > > > +DTC_FLAGS_sun8i-h3-orangepi-pc-plus := -@
> > > > > > >   dtb-$(CONFIG_MACH_SUN8I) += \
> > > > > > >          sun8i-a23-evb.dtb \
> > > > > > >          sun8i-a23-gt90h-v4.dtb \
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > 
> > > 
> 
> 

Re: [PATCH 1/1] arm: dts: Enable device-tree overlay support for sun8i-h3 pi devices

[Andre Przywara]

On Thu, 03 Aug 2023 23:26:28 +0200
Jernej Škrabec <jernej.skrabec@gmail.com> wrote:

Hi,

> Dne torek, 01. avgust 2023 ob 13:59:49 CEST je MOESSBAUER, Felix napisal(a):
> > On Mon, 2023-07-31 at 10:53 +0100, Andre Przywara wrote:
> >   
> > > Hi,
> > > 
> > > On 31/07/2023 03:46, MOESSBAUER, Felix wrote:
> > >   
> > > > On Mon, 2023-07-31 at 00:12 +0200, Jernej Škrabec wrote:
> > > >   
> > > > > Dne sreda, 19. julij 2023 ob 14:26:13 CEST je Moessbauer Felix
> > > > > napisal(a):
> > > > >   
> > > > > > On Tue, 2023-07-11 at 21:42 +0200, Jernej Škrabec wrote:
> > > > > >   
> > > > > > > Dne torek, 27. junij 2023 ob 15:37:03 CEST je Felix
> > > > > > > Moessbauer
> > > > > > > 
> > > > > > > napisal(a):
> > > > > > >   
> > > > > > > > Add the '-@' DTC option for the sun8i-h3 pi-class devices.
> > > > > > > > This
> > > > > > > > option
> > > > > > > > populates the '__symbols__' node that contains all the
> > > > > > > > necessary
> > > > > > > > symbols
> > > > > > > > for supporting device-tree overlays (for instance from the
> > > > > > > > firmware
> > > > > > > > or
> > > > > > > > the bootloader) on these devices.
> > > > > > > > 
> > > > > > > > These devices allow various modules to be connected and
> > > > > > > > this
> > > > > > > > enables
> > > > > > > > users to create out-of-tree device-tree overlays for these
> > > > > > > > modules.
> > > > > > > > 
> > > > > > > > Please note that this change does increase the size of the
> > > > > > > > resulting DTB
> > > > > > > > by ~30%. For example, with v6.4 increase in size is as
> > > > > > > > follows:
> > > > > > > > 
> > > > > > > > 22909 -> 29564 sun8i-h3-orangepi-lite.dtb
> > > > > > > > 24214 -> 30935 sun8i-h3-bananapi-m2-plus.dtb
> > > > > > > > 23915 -> 30664 sun8i-h3-nanopi-m1-plus.dtb
> > > > > > > > 22969 -> 29537 sun8i-h3-nanopi-m1.dtb
> > > > > > > > 24157 -> 30836 sun8i-h3-nanopi-duo2.dtb
> > > > > > > > 24110 -> 30845 sun8i-h3-orangepi-plus2e.dtb
> > > > > > > > 23472 -> 30037 sun8i-h3-orangepi-one.dtb
> > > > > > > > 24600 -> 31410 sun8i-h3-orangepi-plus.dtb
> > > > > > > > 23618 -> 30230 sun8i-h3-orangepi-2.dtb
> > > > > > > > 22170 -> 28548 sun8i-h3-orangepi-zero-plus2.dtb
> > > > > > > > 23258 -> 29795 sun8i-h3-nanopi-neo-air.dtb
> > > > > > > > 23113 -> 29699 sun8i-h3-zeropi.dtb
> > > > > > > > 22803 -> 29270 sun8i-h3-nanopi-neo.dtb
> > > > > > > > 24674 -> 31318 sun8i-h3-nanopi-r1.dtb
> > > > > > > > 23477 -> 30038 sun8i-h3-orangepi-pc.dtb
> > > > > > > > 24622 -> 31380 sun8i-h3-bananapi-m2-plus-v1.2.dtb
> > > > > > > > 23750 -> 30366 sun8i-h3-orangepi-pc-plus.dtb
> > > > > > > > 
> > > > > > > > Signed-off-by: Felix Moessbauer
> > > > > > > > <felix.moessbauer@siemens.com>
> > > > > > > > ---
> > > > > > > > Please note that I only tested the overlay on the sun8i-h3-
> > > > > > > > nanopi-
> > > > > > > > neo
> > > > > > > > device. However, the devices are quite similar and in
> > > > > > > > general
> > > > > > > > the
> > > > > > > > change to add symbols should be pretty safe. Similar
> > > > > > > > patches
> > > > > > > > have
> > > > > > > > been
> > > > > > > > applied to various other devices in the past without any
> > > > > > > > negative
> > > > > > > > effect (except for the increased size).  
> > > > > > > 
> > > > > > > 
> > > > > > > I'm not a fan of this approach. What's wrong with letting
> > > > > > > kernel
> > > > > > > builders
> > > > > > > specify this flag on their own at compile time? That way size
> > > > > > > is
> > > > > > > still
> > > > > > > completely in domain of builder.  
> > 
> > 
> > At least the Debian maintainers decided to NOT include the -@ for all
> > targets, but purely rely on what the kernel offers [5]. They motivate
> > this with a similar decision made in the Kernel. This brings us back to
> > my patch which enables the -@ for particular boards in the Kernel
> > itself.
> > 
> > [5] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=910727#28
> > 
> >   
> > > > > > 
> > > > > > That's easier said than done. These symbols are only needed for
> > > > > > some
> > > > > > targets (that are commonly used with overlays). But how should
> > > > > > a
> > > > > > general purpose kernel builder like Debian know which DT to
> > > > > > build
> > > > > > with
> > > > > > symbols and which without? In Yocto the overlays are not really
> > > > > > needed,
> > > > > > as often the original dts is just patched directly.  
> > > > > 
> > > > > 
> > > > > LibreELEC (distro I help with) has support for DT overlays for
> > > > > some
> > > > > time and
> > > > > it was easy to enable symbols for all DTs with simple
> > > > > "DTC_FLAGS=-@"
> > > > > addition  
> > > 
> > > 
> > > So why don't you use the U-Boot provided copy of the DTB? We sync the
> > > DTs regularly from the kernel repo to the U-Boot repo, and the U-Boot
> > > build system builds all DTBs with overlay support already.
> > > This also saves you from the hassle to actually find and load the
> > > right 
> > > DTB, as it automatically comes as part of the U-Boot binary.
> > > On the U-Boot prompt (or rather in a script) you would then do:  
> > > => fdt move $fdtcontroladdr $fdt_addr_r
> > > => load <source> $fdtoverlay_addr_r <your_overlay>.dtbo
> > > => fdt apply $fdtoverlay_addr_r  
> > 
> > 
> > For systems that use u-boot this is a very convenient option. Thanks
> > for bringing this up. However, there are other boot-chains where this
> > is not an option.

What other firmware / bootloader would those boards use then? And how would
the overlays be applied then? Can't the DTs then not be built with overlay
support in this other firmware build process?

> Also, with this argument no target in the Kernel
> > would need to be compiled with -@.
> > 
> > My understanding was that adding the -@ is generally accepted if it is
> > only done on a per-device basis (which this patch does), but not
> > accepted for whole architectures. By that, I expect to see many similar
> > patches in the future.  
> 
> I don't necessarly agree with this approach, but since other ways are 
> rejected, I'll merge this one if there are no further complaints.

Well, I don't really mind too much, but I don't think this is sustainable:
- The requirement to apply overlays is not really confined to just a few
named boards, because anyone could find a reason why they would need to
change something. So what about the
sun8i-h3-emlid-neutis-n5h3-devboard.dts, for instance?

- I understand that this might sound like a broken record, but I still
consider the whole idea of building DTBs through the *kernel* build
system, then somehow deploying them along with the kernel and letting the
board's firmware load them again as somewhat bonkers to begin with.
Although by now it apparently became so ubiquitous that most people seem
to accept this as a given.

As the devicetree describes the device, it should be considered part of
the firmware, so just integrating it into the firmware (SPL/bootloader) is
the natural choice. And in this process you can choose to build with
overlay support - which is exactly what U-Boot does.

I consider the Linux kernel repository just the canonical place to store
the DT files, although more for historic than for really good reasons.
So building them using the kernel build system is more a matter of build
testing and validation than something really to be used.

Cheers,
Andre.

> 
> Acked-by: Jernej Skrabec <jernej.skrabec@gmail.com>
> 
> Best regards,
> Jernej
> 
> > 
> > Cheers,
> > Felix
> > 
> >   
> > > 
> > > You could also chime in on this U-Boot patch of mine, that loads and 
> > > applies all .dtbo files found in a given directory:
> > > https://lore.kernel.org/u-boot/20230210110213.2531190-1-andre.przywara@arm
> > > .com/  
>  
> > > Cheers,
> > > Andre
> > > 
> > >   
> > > > 
> > > > Thanks for the pointer. If this would be a kconfig option, I would
> > > > agree. There's a patch to add this option, but this did not get
> > > > accepted [3]. Just manually adding some "magic" options does not
> > > > feel
> > > > correct.
> > > > 
> > > >   
> > > > > to build command [1]. Do you see any downside except knowing you
> > > > > have
> > > > > to
> > > > > include it? On the upside, there is no need to patch each and
> > > > > every
> > > > > file and
> > > > > kernel builder has a choice if overlays should be supported or
> > > > > not.  
> > > > 
> > > > 
> > > > There is a similar feature request for Debian, but without a
> > > > decision
> > > > yet [4]. I just cross-referenced it to this thread.
> > > > 
> > > >   
> > > > > Note that
> > > > > in some cases overlays can be needed even in the case when board
> > > > > doesn't have
> > > > > expansion ports.  
> > > > 
> > > > 
> > > > If that is the case, why can't we at least add the patch from [3]
> > > > and
> > > > provide the distros an easy option to enable overlays? Once
> > > > integrated,
> > > > we can eventually get rid of all the per-device patches in the
> > > > kernel.
> > > > 
> > > > Best regards,
> > > > Felix
> > > > 
> > > > [3] https://www.spinics.net/lists/kernel/msg4252361.html
> > > > [4] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=910727
> > > > 
> > > >   
> > > > > 
> > > > > Best regards,
> > > > > Jernej
> > > > > 
> > > > > [1]
> > > > > https://github.com/LibreELEC/LibreELEC.tv/blob/master/packages/linux/
> > > > > package.mk#L213
> > > > > 
> > > > >   
> > > > > > 
> > > > > > There has been a discussion in 2017 to improve the situation in
> > > > > > general, but without any final decision or implementation [1].
> > > > > > By
> > > > > > that,
> > > > > > these patches got more and more common. I recently sent a very
> > > > > > similar
> > > > > > patch for a riscv board that got accepted [2].
> > > > > > 
> > > > > > IMHO it is better to have these patches in the kernel instead
> > > > > > of
> > > > > > carrying different variants of this in each Linux distro. IMHO,
> > > > > > the
> > > > > > board vendors themselves should add this when they add a board.
> > > > > > 
> > > > > > [1]
> > > > > > https://lore.kernel.org/lkml/1502831736-28282-1-git-send-email-trini
> > > > > > @konsulk  
>  o.com/ [2]
> > > > > > https://lore.kernel.org/linux-devicetree/20230627080620.329873-1-fel
> > > > > > ix.moess  
>  bauer@siemens.com/
> > > > > > 
> > > > > > Best regards,
> > > > > > Felix
> > > > > > 
> > > > > >   
> > > > > > > Best regards,
> > > > > > > Jernej
> > > > > > > 
> > > > > > >   
> > > > > > > > Felix Moessbauer
> > > > > > > > Siemens AG
> > > > > > > > 
> > > > > > > >   arch/arm/boot/dts/allwinner/Makefile | 19
> > > > > > > > +++++++++++++++++++
> > > > > > > >   1 file changed, 19 insertions(+)
> > > > > > > > 
> > > > > > > > diff --git a/arch/arm/boot/dts/allwinner/Makefile
> > > > > > > > b/arch/arm/boot/dts/allwinner/Makefile index
> > > > > > > > 589a1ce1120a..eebb5a0c873a
> > > > > > > > 100644
> > > > > > > > --- a/arch/arm/boot/dts/allwinner/Makefile
> > > > > > > > +++ b/arch/arm/boot/dts/allwinner/Makefile
> > > > > > > > @@ -179,6 +179,25 @@ dtb-$(CONFIG_MACH_SUN7I) += \
> > > > > > > >          sun7i-a20-pcduino3-nano.dtb \
> > > > > > > >          sun7i-a20-wexler-tab7200.dtb \
> > > > > > > >          sun7i-a20-wits-pro-a20-dkt.dtb
> > > > > > > > +
> > > > > > > > +# Enables support for device-tree overlays for all pis
> > > > > > > > +DTC_FLAGS_sun8i-h3-orangepi-lite := -@
> > > > > > > > +DTC_FLAGS_sun8i-h3-bananapi-m2-plus := -@
> > > > > > > > +DTC_FLAGS_sun8i-h3-nanopi-m1-plus := -@
> > > > > > > > +DTC_FLAGS_sun8i-h3-nanopi-m1 := -@
> > > > > > > > +DTC_FLAGS_sun8i-h3-nanopi-duo2 := -@
> > > > > > > > +DTC_FLAGS_sun8i-h3-orangepi-plus2e := -@
> > > > > > > > +DTC_FLAGS_sun8i-h3-orangepi-one := -@
> > > > > > > > +DTC_FLAGS_sun8i-h3-orangepi-plus := -@
> > > > > > > > +DTC_FLAGS_sun8i-h3-orangepi-2 := -@
> > > > > > > > +DTC_FLAGS_sun8i-h3-orangepi-zero-plus2 := -@
> > > > > > > > +DTC_FLAGS_sun8i-h3-nanopi-neo-air := -@
> > > > > > > > +DTC_FLAGS_sun8i-h3-zeropi := -@
> > > > > > > > +DTC_FLAGS_sun8i-h3-nanopi-neo := -@
> > > > > > > > +DTC_FLAGS_sun8i-h3-nanopi-r1 := -@
> > > > > > > > +DTC_FLAGS_sun8i-h3-orangepi-pc := -@
> > > > > > > > +DTC_FLAGS_sun8i-h3-bananapi-m2-plus-v1.2 := -@
> > > > > > > > +DTC_FLAGS_sun8i-h3-orangepi-pc-plus := -@
> > > > > > > >   dtb-$(CONFIG_MACH_SUN8I) += \
> > > > > > > >          sun8i-a23-evb.dtb \
> > > > > > > >          sun8i-a23-gt90h-v4.dtb \  
> > > > > 
> > > > > 
> > > > > 
> > > > > 
> > > > >   
> > > > 
> > > >   
> > 
> >   
> 
> 
> 
> 

Re: [PATCH 1/1] arm: dts: Enable device-tree overlay support for sun8i-h3 pi devices

[Jernej Škrabec]

Dne petek, 04. avgust 2023 ob 16:30:29 CEST je Andre Przywara napisal(a):
> On Thu, 03 Aug 2023 23:26:28 +0200
> Jernej Škrabec <jernej.skrabec@gmail.com> wrote:
> 
> Hi,
> 
> > Dne torek, 01. avgust 2023 ob 13:59:49 CEST je MOESSBAUER, Felix 
napisal(a):
> > > On Mon, 2023-07-31 at 10:53 +0100, Andre Przywara wrote:
> > > > Hi,
> > > > 
> > > > On 31/07/2023 03:46, MOESSBAUER, Felix wrote:
> > > > > On Mon, 2023-07-31 at 00:12 +0200, Jernej Škrabec wrote:
> > > > > > Dne sreda, 19. julij 2023 ob 14:26:13 CEST je Moessbauer Felix
> > > > > > 
> > > > > > napisal(a):
> > > > > > > On Tue, 2023-07-11 at 21:42 +0200, Jernej Škrabec wrote:
> > > > > > > > Dne torek, 27. junij 2023 ob 15:37:03 CEST je Felix
> > > > > > > > Moessbauer
> > > > > > > > 
> > > > > > > > napisal(a):
> > > > > > > > > Add the '-@' DTC option for the sun8i-h3 pi-class devices.
> > > > > > > > > This
> > > > > > > > > option
> > > > > > > > > populates the '__symbols__' node that contains all the
> > > > > > > > > necessary
> > > > > > > > > symbols
> > > > > > > > > for supporting device-tree overlays (for instance from the
> > > > > > > > > firmware
> > > > > > > > > or
> > > > > > > > > the bootloader) on these devices.
> > > > > > > > > 
> > > > > > > > > These devices allow various modules to be connected and
> > > > > > > > > this
> > > > > > > > > enables
> > > > > > > > > users to create out-of-tree device-tree overlays for these
> > > > > > > > > modules.
> > > > > > > > > 
> > > > > > > > > Please note that this change does increase the size of the
> > > > > > > > > resulting DTB
> > > > > > > > > by ~30%. For example, with v6.4 increase in size is as
> > > > > > > > > follows:
> > > > > > > > > 
> > > > > > > > > 22909 -> 29564 sun8i-h3-orangepi-lite.dtb
> > > > > > > > > 24214 -> 30935 sun8i-h3-bananapi-m2-plus.dtb
> > > > > > > > > 23915 -> 30664 sun8i-h3-nanopi-m1-plus.dtb
> > > > > > > > > 22969 -> 29537 sun8i-h3-nanopi-m1.dtb
> > > > > > > > > 24157 -> 30836 sun8i-h3-nanopi-duo2.dtb
> > > > > > > > > 24110 -> 30845 sun8i-h3-orangepi-plus2e.dtb
> > > > > > > > > 23472 -> 30037 sun8i-h3-orangepi-one.dtb
> > > > > > > > > 24600 -> 31410 sun8i-h3-orangepi-plus.dtb
> > > > > > > > > 23618 -> 30230 sun8i-h3-orangepi-2.dtb
> > > > > > > > > 22170 -> 28548 sun8i-h3-orangepi-zero-plus2.dtb
> > > > > > > > > 23258 -> 29795 sun8i-h3-nanopi-neo-air.dtb
> > > > > > > > > 23113 -> 29699 sun8i-h3-zeropi.dtb
> > > > > > > > > 22803 -> 29270 sun8i-h3-nanopi-neo.dtb
> > > > > > > > > 24674 -> 31318 sun8i-h3-nanopi-r1.dtb
> > > > > > > > > 23477 -> 30038 sun8i-h3-orangepi-pc.dtb
> > > > > > > > > 24622 -> 31380 sun8i-h3-bananapi-m2-plus-v1.2.dtb
> > > > > > > > > 23750 -> 30366 sun8i-h3-orangepi-pc-plus.dtb
> > > > > > > > > 
> > > > > > > > > Signed-off-by: Felix Moessbauer
> > > > > > > > > <felix.moessbauer@siemens.com>
> > > > > > > > > ---
> > > > > > > > > Please note that I only tested the overlay on the sun8i-h3-
> > > > > > > > > nanopi-
> > > > > > > > > neo
> > > > > > > > > device. However, the devices are quite similar and in
> > > > > > > > > general
> > > > > > > > > the
> > > > > > > > > change to add symbols should be pretty safe. Similar
> > > > > > > > > patches
> > > > > > > > > have
> > > > > > > > > been
> > > > > > > > > applied to various other devices in the past without any
> > > > > > > > > negative
> > > > > > > > > effect (except for the increased size).
> > > > > > > > 
> > > > > > > > I'm not a fan of this approach. What's wrong with letting
> > > > > > > > kernel
> > > > > > > > builders
> > > > > > > > specify this flag on their own at compile time? That way size
> > > > > > > > is
> > > > > > > > still
> > > > > > > > completely in domain of builder.
> > > 
> > > At least the Debian maintainers decided to NOT include the -@ for all
> > > targets, but purely rely on what the kernel offers [5]. They motivate
> > > this with a similar decision made in the Kernel. This brings us back to
> > > my patch which enables the -@ for particular boards in the Kernel
> > > itself.
> > > 
> > > [5] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=910727#28
> > > 
> > > > > > > That's easier said than done. These symbols are only needed for
> > > > > > > some
> > > > > > > targets (that are commonly used with overlays). But how should
> > > > > > > a
> > > > > > > general purpose kernel builder like Debian know which DT to
> > > > > > > build
> > > > > > > with
> > > > > > > symbols and which without? In Yocto the overlays are not really
> > > > > > > needed,
> > > > > > > as often the original dts is just patched directly.
> > > > > > 
> > > > > > LibreELEC (distro I help with) has support for DT overlays for
> > > > > > some
> > > > > > time and
> > > > > > it was easy to enable symbols for all DTs with simple
> > > > > > "DTC_FLAGS=-@"
> > > > > > addition
> > > > 
> > > > So why don't you use the U-Boot provided copy of the DTB? We sync the
> > > > DTs regularly from the kernel repo to the U-Boot repo, and the U-Boot
> > > > build system builds all DTBs with overlay support already.
> > > > This also saves you from the hassle to actually find and load the
> > > > right
> > > > DTB, as it automatically comes as part of the U-Boot binary.
> > > > On the U-Boot prompt (or rather in a script) you would then do:
> > > > => fdt move $fdtcontroladdr $fdt_addr_r
> > > > => load <source> $fdtoverlay_addr_r <your_overlay>.dtbo
> > > > => fdt apply $fdtoverlay_addr_r
> > > 
> > > For systems that use u-boot this is a very convenient option. Thanks
> > > for bringing this up. However, there are other boot-chains where this
> > > is not an option.
> 
> What other firmware / bootloader would those boards use then? And how would
> the overlays be applied then? Can't the DTs then not be built with overlay
> support in this other firmware build process?
> 
> > Also, with this argument no target in the Kernel
> > 
> > > would need to be compiled with -@.
> > > 
> > > My understanding was that adding the -@ is generally accepted if it is
> > > only done on a per-device basis (which this patch does), but not
> > > accepted for whole architectures. By that, I expect to see many similar
> > > patches in the future.
> > 
> > I don't necessarly agree with this approach, but since other ways are
> > rejected, I'll merge this one if there are no further complaints.
> 
> Well, I don't really mind too much, but I don't think this is sustainable:
> - The requirement to apply overlays is not really confined to just a few
> named boards, because anyone could find a reason why they would need to
> change something. So what about the
> sun8i-h3-emlid-neutis-n5h3-devboard.dts, for instance?

I completely agree with you on "not sustainable", but unfortunately catch all 
solution with kernel config was rejected. I don't see any other option.

Best regards,
Jernej 

> 
> - I understand that this might sound like a broken record, but I still
> consider the whole idea of building DTBs through the *kernel* build
> system, then somehow deploying them along with the kernel and letting the
> board's firmware load them again as somewhat bonkers to begin with.
> Although by now it apparently became so ubiquitous that most people seem
> to accept this as a given.
> 
> As the devicetree describes the device, it should be considered part of
> the firmware, so just integrating it into the firmware (SPL/bootloader) is
> the natural choice. And in this process you can choose to build with
> overlay support - which is exactly what U-Boot does.
> 
> I consider the Linux kernel repository just the canonical place to store
> the DT files, although more for historic than for really good reasons.
> So building them using the kernel build system is more a matter of build
> testing and validation than something really to be used.
> 
> Cheers,
> Andre.
> 
> > Acked-by: Jernej Skrabec <jernej.skrabec@gmail.com>
> > 
> > Best regards,
> > Jernej
> > 
> > > Cheers,
> > > Felix
> > > 
> > > > You could also chime in on this U-Boot patch of mine, that loads and
> > > > applies all .dtbo files found in a given directory:
> > > > https://lore.kernel.org/u-boot/20230210110213.2531190-1-andre.przywara
> > > > @arm
> > > > .com/
> > > > 
> > > > Cheers,
> > > > Andre
> > > > 
> > > > > Thanks for the pointer. If this would be a kconfig option, I would
> > > > > agree. There's a patch to add this option, but this did not get
> > > > > accepted [3]. Just manually adding some "magic" options does not
> > > > > feel
> > > > > correct.
> > > > > 
> > > > > > to build command [1]. Do you see any downside except knowing you
> > > > > > have
> > > > > > to
> > > > > > include it? On the upside, there is no need to patch each and
> > > > > > every
> > > > > > file and
> > > > > > kernel builder has a choice if overlays should be supported or
> > > > > > not.
> > > > > 
> > > > > There is a similar feature request for Debian, but without a
> > > > > decision
> > > > > yet [4]. I just cross-referenced it to this thread.
> > > > > 
> > > > > > Note that
> > > > > > in some cases overlays can be needed even in the case when board
> > > > > > doesn't have
> > > > > > expansion ports.
> > > > > 
> > > > > If that is the case, why can't we at least add the patch from [3]
> > > > > and
> > > > > provide the distros an easy option to enable overlays? Once
> > > > > integrated,
> > > > > we can eventually get rid of all the per-device patches in the
> > > > > kernel.
> > > > > 
> > > > > Best regards,
> > > > > Felix
> > > > > 
> > > > > [3] https://www.spinics.net/lists/kernel/msg4252361.html
> > > > > [4] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=910727
> > > > > 
> > > > > > Best regards,
> > > > > > Jernej
> > > > > > 
> > > > > > [1]
> > > > > > https://github.com/LibreELEC/LibreELEC.tv/blob/master/packages/lin
> > > > > > ux/
> > > > > > package.mk#L213
> > > > > > 
> > > > > > > There has been a discussion in 2017 to improve the situation in
> > > > > > > general, but without any final decision or implementation [1].
> > > > > > > By
> > > > > > > that,
> > > > > > > these patches got more and more common. I recently sent a very
> > > > > > > similar
> > > > > > > patch for a riscv board that got accepted [2].
> > > > > > > 
> > > > > > > IMHO it is better to have these patches in the kernel instead
> > > > > > > of
> > > > > > > carrying different variants of this in each Linux distro. IMHO,
> > > > > > > the
> > > > > > > board vendors themselves should add this when they add a board.
> > > > > > > 
> > > > > > > [1]
> > > > > > > https://lore.kernel.org/lkml/1502831736-28282-1-git-send-email-t
> > > > > > > rini
> > > > > > > @konsulk
> >  
> >  o.com/ [2]
> >  
> > > > > > > https://lore.kernel.org/linux-devicetree/20230627080620.329873-1
> > > > > > > -fel
> > > > > > > ix.moess
> >  
> >  bauer@siemens.com/
> >  
> > > > > > > Best regards,
> > > > > > > Felix
> > > > > > > 
> > > > > > > > Best regards,
> > > > > > > > Jernej
> > > > > > > > 
> > > > > > > > > Felix Moessbauer
> > > > > > > > > Siemens AG
> > > > > > > > > 
> > > > > > > > >   arch/arm/boot/dts/allwinner/Makefile | 19
> > > > > > > > > 
> > > > > > > > > +++++++++++++++++++
> > > > > > > > > 
> > > > > > > > >   1 file changed, 19 insertions(+)
> > > > > > > > > 
> > > > > > > > > diff --git a/arch/arm/boot/dts/allwinner/Makefile
> > > > > > > > > b/arch/arm/boot/dts/allwinner/Makefile index
> > > > > > > > > 589a1ce1120a..eebb5a0c873a
> > > > > > > > > 100644
> > > > > > > > > --- a/arch/arm/boot/dts/allwinner/Makefile
> > > > > > > > > +++ b/arch/arm/boot/dts/allwinner/Makefile
> > > > > > > > > @@ -179,6 +179,25 @@ dtb-$(CONFIG_MACH_SUN7I) += \
> > > > > > > > > 
> > > > > > > > >          sun7i-a20-pcduino3-nano.dtb \
> > > > > > > > >          sun7i-a20-wexler-tab7200.dtb \
> > > > > > > > >          sun7i-a20-wits-pro-a20-dkt.dtb
> > > > > > > > > 
> > > > > > > > > +
> > > > > > > > > +# Enables support for device-tree overlays for all pis
> > > > > > > > > +DTC_FLAGS_sun8i-h3-orangepi-lite := -@
> > > > > > > > > +DTC_FLAGS_sun8i-h3-bananapi-m2-plus := -@
> > > > > > > > > +DTC_FLAGS_sun8i-h3-nanopi-m1-plus := -@
> > > > > > > > > +DTC_FLAGS_sun8i-h3-nanopi-m1 := -@
> > > > > > > > > +DTC_FLAGS_sun8i-h3-nanopi-duo2 := -@
> > > > > > > > > +DTC_FLAGS_sun8i-h3-orangepi-plus2e := -@
> > > > > > > > > +DTC_FLAGS_sun8i-h3-orangepi-one := -@
> > > > > > > > > +DTC_FLAGS_sun8i-h3-orangepi-plus := -@
> > > > > > > > > +DTC_FLAGS_sun8i-h3-orangepi-2 := -@
> > > > > > > > > +DTC_FLAGS_sun8i-h3-orangepi-zero-plus2 := -@
> > > > > > > > > +DTC_FLAGS_sun8i-h3-nanopi-neo-air := -@
> > > > > > > > > +DTC_FLAGS_sun8i-h3-zeropi := -@
> > > > > > > > > +DTC_FLAGS_sun8i-h3-nanopi-neo := -@
> > > > > > > > > +DTC_FLAGS_sun8i-h3-nanopi-r1 := -@
> > > > > > > > > +DTC_FLAGS_sun8i-h3-orangepi-pc := -@
> > > > > > > > > +DTC_FLAGS_sun8i-h3-bananapi-m2-plus-v1.2 := -@
> > > > > > > > > +DTC_FLAGS_sun8i-h3-orangepi-pc-plus := -@
> > > > > > > > > 
> > > > > > > > >   dtb-$(CONFIG_MACH_SUN8I) += \
> > > > > > > > >   
> > > > > > > > >          sun8i-a23-evb.dtb \
> > > > > > > > >          sun8i-a23-gt90h-v4.dtb \

Re: [PATCH 1/1] arm: dts: Enable device-tree overlay support for sun8i-h3 pi devices

[Jernej Škrabec]

Dne torek, 27. junij 2023 ob 15:37:03 CEST je Felix Moessbauer napisal(a):
> Add the '-@' DTC option for the sun8i-h3 pi-class devices. This option
> populates the '__symbols__' node that contains all the necessary symbols
> for supporting device-tree overlays (for instance from the firmware or
> the bootloader) on these devices.
> 
> These devices allow various modules to be connected and this enables
> users to create out-of-tree device-tree overlays for these modules.
> 
> Please note that this change does increase the size of the resulting DTB
> by ~30%. For example, with v6.4 increase in size is as follows:
> 
> 22909 -> 29564 sun8i-h3-orangepi-lite.dtb
> 24214 -> 30935 sun8i-h3-bananapi-m2-plus.dtb
> 23915 -> 30664 sun8i-h3-nanopi-m1-plus.dtb
> 22969 -> 29537 sun8i-h3-nanopi-m1.dtb
> 24157 -> 30836 sun8i-h3-nanopi-duo2.dtb
> 24110 -> 30845 sun8i-h3-orangepi-plus2e.dtb
> 23472 -> 30037 sun8i-h3-orangepi-one.dtb
> 24600 -> 31410 sun8i-h3-orangepi-plus.dtb
> 23618 -> 30230 sun8i-h3-orangepi-2.dtb
> 22170 -> 28548 sun8i-h3-orangepi-zero-plus2.dtb
> 23258 -> 29795 sun8i-h3-nanopi-neo-air.dtb
> 23113 -> 29699 sun8i-h3-zeropi.dtb
> 22803 -> 29270 sun8i-h3-nanopi-neo.dtb
> 24674 -> 31318 sun8i-h3-nanopi-r1.dtb
> 23477 -> 30038 sun8i-h3-orangepi-pc.dtb
> 24622 -> 31380 sun8i-h3-bananapi-m2-plus-v1.2.dtb
> 23750 -> 30366 sun8i-h3-orangepi-pc-plus.dtb
> 
> Signed-off-by: Felix Moessbauer <felix.moessbauer@siemens.com>

Applied, thanks!

Best regards,
Jernej