OF_UPSTREAM vs. additional dtbs
Jonas Karlman
jonas at kwiboo.se
Tue Aug 27 14:00:43 CEST 2024
Hi Sumit,
On 2024-08-27 09:11, Sumit Garg wrote:
> 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.
The runtime check is stable, at least for current hw revisions, however
the vendor is known to make minor revision changes. End-users may change
Kconfig options or future U-Boot changes may break the runtime detection.
Also there is history that wrong U-Boot vendor image has been used by
end-users and that has resulted in damage to Ethernet, so for mainline I
specifically wanted to avoid such issue by using a single U-Boot target
and play it safe if the runtime detection for whatever reason is not
fully working.
>
>>
>> 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.
Providing different firmware images for each hw revission can be an
option for other bootloaders, or they can provide similar runtime
detection as U-Boot.
So I still see a valid need for having U-Boot only DT together with main
DTs from dts/upstream. It can also be protected behind a new Kconfig
symbol, e.g. OF_UPSTREAM_MIXED or similar.
Regards,
Jonas
>
> -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