OF_UPSTREAM vs. additional dtbs
Jonas Karlman
jonas at kwiboo.se
Mon Aug 26 14:21:03 CEST 2024
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.
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.
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