OF_UPSTREAM vs. additional dtbs

Sumit Garg sumit.garg at linaro.org
Tue Aug 27 09:11:31 CEST 2024 

On Mon, 26 Aug 2024 at 17:51, Jonas Karlman <jonas at kwiboo.se> wrote:
>
> Hi Sumit,
>
> On 2024-08-26 13:48, Sumit Garg wrote:
> > Hi Jonas,
> >
> > On Mon, 26 Aug 2024 at 14:27, Jonas Karlman <jonas at kwiboo.se> wrote:
> >>
> >> Hi Sumit,
> >>
> >> On 2024-08-26 08:44, Sumit Garg wrote:
> >>> Hi,
> >>>
> >>> On Wed, 14 Aug 2024 at 22:14, Jan Kiszka <jan.kiszka at siemens.com> wrote:
> >>>>
> >>>> On 14.08.24 11:41, Jan Kiszka wrote:
> >>>>> On 13.08.24 14:52, Nishanth Menon wrote:
> >>>>>> On 11:16-20240813, Jan Kiszka wrote:
> >>>>>>> Hi all,
> >>>>>>>
> >>>>>>> I'm trying to migrate the TI AM65x IOT2050 boards to OF_UPSTREAM but I'm
> >>>>>>> facing issues because I need to still build the u-boot-only overlays. It
> >>>>>>> is also a bit weird (but works) having to specify
> >>>>>>>
> >>>>>>> CONFIG_SPL_OF_LIST="../../../../arch/arm/dts/k3-am65-iot2050-spl"
> >>>>>>>
> >>>>>
> >>>>> Actually, this does NOT work: I just had a long morning debugging SPL
> >>>>> which no longer started because it picked the non-filtered dtb. The
> >>>>> filtered one ended up in a folder outside of the u-boot sources because
> >>>>> of all those ../ and hard-wiring to dts/upstream.
> >>>>>
> >>>>>>> for our spl dtb.
> >>>>>>>
> >>>>>>> Are there means to still build certain dtb[o] files in arch/<arch>/dts?
> >>>>>>> I'm a bit lost in the Makefile forest.
> >>>>>>>
> >>>>>>
> >>>>>> Sumit: Any suggestions?
> >>>>>>
> >>>
> >>> Apologies for the delayed reply. I was a bit busy with other high
> >>> priority stuff.
> >>>
> >>>>>
> >>>>> I would really like to hear some better proposals than my local
> >>>>> workarounds to far. They don't converge although I already patched some
> >>>>> core Makefile (overlays are building now).
> >>>>>
> >>>>
> >>>> OK, I side-stepped the spl issue by using one of our variant DTBs for
> >>>> spl as well - happens to work.
> >>>
> >>> That's good to know.
> >>>
> >>>>
> >>>> For the overlays, I need to add
> >>>>
> >>>> --- a/scripts/Makefile.dts
> >>>> +++ b/scripts/Makefile.dts
> >>>> @@ -1,5 +1,7 @@
> >>>>  # SPDX-License-Identifier: GPL-2.0+
> >>>>
> >>>> +include $(srctree)/config.mk
> >>>> +
> >>>>  dtb-y += $(patsubst %,%.dtb,$(subst ",,$(CONFIG_DEFAULT_DEVICE_TREE) $(CONFIG_OF_LIST) $(CONFIG_SPL_OF_LIST)))
> >>>>
> >>>>  ifeq ($(CONFIG_OF_UPSTREAM_BUILD_VENDOR),y)
> >>>>
> >>>>
> >>>> in order to then be able to do
> >>>>
> >>>> --- a/board/siemens/iot2050/config.mk
> >>>> +++ b/board/siemens/iot2050/config.mk
> >>>> @@ -5,4 +5,12 @@
> >>>>  # Authors:
> >>>>  #   Jan Kiszka <jan.kiszka at siemens.com>
> >>>>
> >>>> +ifneq ($(CONFIG_SPL_BUILD),y)
> >>>> +dtbo-list = \
> >>>> +       k3-am6548-iot2050-advanced-m2-bkey-usb3-overlay \
> >>>> +       k3-am6548-iot2050-advanced-m2-bkey-ekey-pcie-overlay
> >>>> +
> >>>> +dtb-y += $(patsubst %,../../../../arch/arm/dts/%.dtbo,$(dtbo-list))
> >>>> +endif
> >>>> +
> >>>>  flash.bin: all
> >>>>
> >>>>
> >>>> Does that make sense?
> >>>
> >>> A switch to OF_UPSTREAM means that we build all the DT artifacts from
> >>> dts/upstream/src/ directory with the only exception that we include
> >>> U-Boot specific overrides via *-u-boot.dtsi from arch/<arch>/dts. In
> >>> case of overlays, is there any reason for IOT2050 board overlays not
> >>> being pushed into Linux kernel repo? AFAIU, overlays are also
> >>> describing puggable hardware so they shouldn't be referred to as
> >>> "u-boot-only" overlays.
> >>
> >> I have a related issue where I would like to build board DT from
> >> dts/upstream, however there is also a need for a limited U-Boot specific
> >> DT that only is intended for initial boot so that U-Boot at runtime can
> >> determine what hw revision is booting and select correct DT to use for
> >> U-Boot proper and OS.
> >>
> >> For now I have just set the board target to use OF_UPSTREAM=n and
> >> instead created minimal .dts-files in arch/<arch>/dts that include the
> >> full .dts-file from dts/upstream.
> >>
> >> Any suggestion on how we better can support having a U-Boot only
> >> .dts-file together with OF_UPSTREAM=y ?
> >
> > The motivation is rather to avoid any U-Boot specific DT files.
> > Shouldn't you be able to create a DT overlay of v2.1 board over v1.1
> > and push that upstream? The runtime DT choice sounds pretty similar to
> > how you can choose to apply the DT overlay or not with common boot DT.
> > Also, bundling multiple DT within U-Boot proper FIT image can be an
> > alternative too.
>
> Both rk3566-orangepi-3b-v1.1.dts and rk3566-orangepi-3b-v2.1.dts are
> in/from upstream Linux, and they are both included in the same FIT along
> with the default U-Boot specific DT (rk3566-orangepi-3b.dtb):
>
>  CONFIG_OF_LIST="rk3566-orangepi-3b rk3566-orangepi-3b-v1.1 rk3566-orangepi-3b-v2.1"
>
>  Default Configuration: 'config-1'
>  Configuration 0 (config-1)
>   Description:  rk3566-orangepi-3b.dtb
>   Kernel:       unavailable
>   Firmware:     atf-1
>   FDT:          fdt-1
>   Loadables:    u-boot
>                 atf-2
>                 atf-3
>                 atf-4
>                 atf-5
>                 atf-6
>  Configuration 1 (config-2)
>   Description:  rk3566-orangepi-3b-v1.1.dtb
>   Kernel:       unavailable
>   Firmware:     atf-1
>   FDT:          fdt-2
>   Loadables:    u-boot
>                 atf-2
>                 atf-3
>                 atf-4
>                 atf-5
>                 atf-6
>  Configuration 2 (config-3)
>   Description:  rk3566-orangepi-3b-v2.1.dtb
>   Kernel:       unavailable
>   Firmware:     atf-1
>   FDT:          fdt-3
>   Loadables:    u-boot
>                 atf-2
>                 atf-3
>                 atf-4
>                 atf-5
>                 atf-6
>
> Main reason why a U-Boot specific DT is used is because the hw revisions
> use different voltage for Ethernet PHY, and we want to avoid causing
> damage to a board when runtime cannot determine what hw revision is
> running, and thus we use a safe U-Boot specific DT.

Okay so the runtime check for hw revision isn't stable. If that's the
case then I am unsure if we should enable it at all. IIUC in case a
fallback to safe U-Boot DT is made then the ethernet won't be
functional. I would rather favour separate U-Boot images for each
board with corresponding DT to provide a fully functional system.

>
> I do not see any reason to try and upstream this u-boot only DT to Linux,
> since it's only purpose is to assist boot firmware to select correct DT.

I suppose similar functionality would be needed if any other
bootloader/firmware has to be enabled for these boards. So we can't
say it's particularly specific to U-Boot but it is rather a dowsized
DT which can boot on both boards with ethernet non-functional. You can
also rather have a single downsized DT supported upstream with 2
overlays one for each board which can be applied on successful
detection of hw revision.

-Sumit

>
> Regards,
> Jonas
>
> >
> > -Sumit
> >
> >>
> >> Please see following for more details:
> >> https://source.denx.de/u-boot/u-boot/-/commit/a52099b4a2ae9e8cafc79268325249bcad308012
> >> https://source.denx.de/u-boot/u-boot/-/blob/master/arch/arm/dts/rk3566-orangepi-3b.dts
> >> https://source.denx.de/u-boot/u-boot/-/blob/master/arch/arm/dts/rk3566-orangepi-3b-v1.1.dts
> >> https://source.denx.de/u-boot/u-boot/-/blob/master/arch/arm/dts/rk3566-orangepi-3b-v2.1.dts
> >>
> >> Regards,
> >> Jonas
> >>
> >>>
> >>> -Sumit
> >>>
> >>>>
> >>>> Jan
> >>>>
> >>>> --
> >>>> Siemens AG, Technology
> >>>> Linux Expert Center
> >>>>
> >>
>

More information about the U-Boot mailing list