On Mon, 26 Aug 2024 at 17:51, Jonas Karlman <jo...@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 <jo...@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.kis...@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.kis...@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 > >>>> > >> >