Re: OF_UPSTREAM vs. additional dtbs
On 10.09.24 14:36, Frank Wunderlich wrote: > Am 10. September 2024 14:08:07 MESZ schrieb Jan Kiszka > : >> On 10.09.24 08:38, Sumit Garg wrote: >>> Hi Jan, >>> >>> On Thu, 5 Sept 2024 at 12:08, Jan Kiszka wrote: >>>> >>>> On 04.09.24 19:29, Frank Wunderlich wrote: >>>>> >>>>> >>>>>> Gesendet: Mittwoch, 04. September 2024 um 19:16 Uhr >>>>>> Von: "Jan Kiszka" >>>>>> OK, our overlay sources are on their way into mainline, will only take >>>>>> until 6.12-rc1 to get them here. >>> >>> Glad to hear that. >>> >>>>>> To accelerate the preparation, I ported >>>>>> that change to a local branch - just to find out that OF_UPSTREAM has no >>>>>> clue about DT overlays so far. And it is not just that there are no >>>>>> build rules for them (that was quickly fixed). It's also that there is >>>>>> no way to trigger their build for your u-boot proper. >>>>>> >>>>>> Are there plans for addressing this? I'm inclined to revive my patch >>>>>> that allows to augment dtb-y from the board's config.mk. Better >>>>>> suggestions? >>>>> >>>>> Hi >>>>> >>>>> i hang also on this part, in my case i build the dtbos for the vendor and >>>>> try to use fdtoverlay to merge base-dt with the defined overlays. >>>>> >>>>> see commits till July 11th >>>>> >>>>> https://github.com/frank-w/u-boot/commits/2024-07-bpi-ofupstream-all/ >>>>> >>>>> this fails because the target for fdtoverlays needs targets for the dtbos >>>>> (have used the fdtoverlay target from linux)... >>>>> but i build then without dedicated target (while building the basedt). >>>>> >>>>> maybe you can help solving the "small" problem in makefile. >>>>> >>>> >>>> This is close but not quite the same scenario because I only need "our" >>>> dtbos, and there is no need to create dtbs with them applied (they will >>>> be used during dt fixup in our case). > > Where do you apply the dtbos? In my case it is > necessary to build the dtb with overlay as we have > no way to detect which overlay needs to be > applied. In our case, during ft_board_setup, thus dynamically: https://source.denx.de/u-boot/u-boot/-/blob/7b2d4ecd7f6593771dd3118c8bab525d727a91e0/board/siemens/iot2050/board.c#L474 > > We have overlays for different mmc (sdmmc/emmc) > and spi (nand/ nor) settings which cannot be probed at runtime (or at least > we have not found > a way to do this). > > > Maybe someone can help getting ftdoverlay target working in uboot with the > dtbo list. Yeah, that would be another path that requires additional work. Sorry, I'm not familiar with those details myself. Jan -- Siemens AG, Technology Linux Expert Center
Re: OF_UPSTREAM vs. additional dtbs
On 10.09.24 08:38, Sumit Garg wrote: > Hi Jan, > > On Thu, 5 Sept 2024 at 12:08, Jan Kiszka wrote: >> >> On 04.09.24 19:29, Frank Wunderlich wrote: >>> >>> >>>> Gesendet: Mittwoch, 04. September 2024 um 19:16 Uhr >>>> Von: "Jan Kiszka" >>>> OK, our overlay sources are on their way into mainline, will only take >>>> until 6.12-rc1 to get them here. > > Glad to hear that. > >>>> To accelerate the preparation, I ported >>>> that change to a local branch - just to find out that OF_UPSTREAM has no >>>> clue about DT overlays so far. And it is not just that there are no >>>> build rules for them (that was quickly fixed). It's also that there is >>>> no way to trigger their build for your u-boot proper. >>>> >>>> Are there plans for addressing this? I'm inclined to revive my patch >>>> that allows to augment dtb-y from the board's config.mk. Better >>>> suggestions? >>> >>> Hi >>> >>> i hang also on this part, in my case i build the dtbos for the vendor and >>> try to use fdtoverlay to merge base-dt with the defined overlays. >>> >>> see commits till July 11th >>> >>> https://github.com/frank-w/u-boot/commits/2024-07-bpi-ofupstream-all/ >>> >>> this fails because the target for fdtoverlays needs targets for the dtbos >>> (have used the fdtoverlay target from linux)... >>> but i build then without dedicated target (while building the basedt). >>> >>> maybe you can help solving the "small" problem in makefile. >>> >> >> This is close but not quite the same scenario because I only need "our" >> dtbos, and there is no need to create dtbs with them applied (they will >> be used during dt fixup in our case). >> >> What I've now done is this: >> >> diff --git a/dts/Kconfig b/dts/Kconfig >> index 569d4be338e..7ea4fd5a79b 100644 >> --- a/dts/Kconfig >> +++ b/dts/Kconfig >> @@ -226,11 +226,11 @@ config OF_LIST >> >> config OF_OVERLAY_LIST >> string "List of device tree overlays to include for DT control" >> - depends on SPL_LOAD_FIT_APPLY_OVERLAY >> help >> This option specifies a list of device tree overlays to use for DT >> control. This option can then be used by a FIT generator to include >> - the overlays in the FIT image. >> + the overlays in the FIT image or by binman when assembling an image >> + that uses overlays during DT fixup. >> >> choice >> prompt "OF LIST compression" >> diff --git a/scripts/Makefile.dts b/scripts/Makefile.dts >> index 790f3c508f1..dc181240a21 100644 >> --- a/scripts/Makefile.dts >> +++ b/scripts/Makefile.dts >> @@ -1,6 +1,7 @@ >> # SPDX-License-Identifier: GPL-2.0+ >> >> dtb-y += $(patsubst %,%.dtb,$(subst ",,$(CONFIG_DEFAULT_DEVICE_TREE) >> $(CONFIG_OF_LIST) $(CONFIG_SPL_OF_LIST))) >> +dtb-y += $(patsubst %,%.dtbo,$(subst ",,$(CONFIG_OF_OVERLAY_LIST))) >> >> ifeq ($(CONFIG_OF_UPSTREAM_BUILD_VENDOR),y) >> ifeq ($(CONFIG_ARM64),y) >> > > Yeah that's all you need to build DT overlays from dts/upstream > subtree. Care to send a proper patch for this? > Can do if you already want this [1]. Our tree [2] where it is currently included still has to wait for upstream 6.12, possibly even 6.13 as we need one more overlay now. >> >> I will also provide a patch to enhance the machinery in dts/upstream >> /Makefile. This apparently plays no role when building U-Boot, but it >> would still be useful for validation purposes to have overlay support >> there. > > As you mentioned we don't use Makefile for U-Boot builds. So it's > better to directly send that patch for inclusion in the DT rebasing > tree. No, this is about our shadow Makefiles, see [3]. Jan [1] https://github.com/siemens/u-boot/commit/2be0393b1718990abf2feb0b13dbaf79629ce692 [2] https://github.com/siemens/u-boot/commits/jan/iot2050 [3] https://github.com/siemens/u-boot/commit/de3df1fed47d2075bb3f9ecccfaa93a368b58924 -- Siemens AG, Technology Linux Expert Center
Re: OF_UPSTREAM vs. additional dtbs
On 04.09.24 19:29, Frank Wunderlich wrote: > > >> Gesendet: Mittwoch, 04. September 2024 um 19:16 Uhr >> Von: "Jan Kiszka" >> OK, our overlay sources are on their way into mainline, will only take >> until 6.12-rc1 to get them here. To accelerate the preparation, I ported >> that change to a local branch - just to find out that OF_UPSTREAM has no >> clue about DT overlays so far. And it is not just that there are no >> build rules for them (that was quickly fixed). It's also that there is >> no way to trigger their build for your u-boot proper. >> >> Are there plans for addressing this? I'm inclined to revive my patch >> that allows to augment dtb-y from the board's config.mk. Better suggestions? > > Hi > > i hang also on this part, in my case i build the dtbos for the vendor and try > to use fdtoverlay to merge base-dt with the defined overlays. > > see commits till July 11th > > https://github.com/frank-w/u-boot/commits/2024-07-bpi-ofupstream-all/ > > this fails because the target for fdtoverlays needs targets for the dtbos > (have used the fdtoverlay target from linux)... > but i build then without dedicated target (while building the basedt). > > maybe you can help solving the "small" problem in makefile. > This is close but not quite the same scenario because I only need "our" dtbos, and there is no need to create dtbs with them applied (they will be used during dt fixup in our case). What I've now done is this: diff --git a/dts/Kconfig b/dts/Kconfig index 569d4be338e..7ea4fd5a79b 100644 --- a/dts/Kconfig +++ b/dts/Kconfig @@ -226,11 +226,11 @@ config OF_LIST config OF_OVERLAY_LIST string "List of device tree overlays to include for DT control" - depends on SPL_LOAD_FIT_APPLY_OVERLAY help This option specifies a list of device tree overlays to use for DT control. This option can then be used by a FIT generator to include - the overlays in the FIT image. + the overlays in the FIT image or by binman when assembling an image + that uses overlays during DT fixup. choice prompt "OF LIST compression" diff --git a/scripts/Makefile.dts b/scripts/Makefile.dts index 790f3c508f1..dc181240a21 100644 --- a/scripts/Makefile.dts +++ b/scripts/Makefile.dts @@ -1,6 +1,7 @@ # SPDX-License-Identifier: GPL-2.0+ dtb-y += $(patsubst %,%.dtb,$(subst ",,$(CONFIG_DEFAULT_DEVICE_TREE) $(CONFIG_OF_LIST) $(CONFIG_SPL_OF_LIST))) +dtb-y += $(patsubst %,%.dtbo,$(subst ",,$(CONFIG_OF_OVERLAY_LIST))) ifeq ($(CONFIG_OF_UPSTREAM_BUILD_VENDOR),y) ifeq ($(CONFIG_ARM64),y) I will also provide a patch to enhance the machinery in dts/upstream /Makefile. This apparently plays no role when building U-Boot, but it would still be useful for validation purposes to have overlay support there. Jan -- Siemens AG, Technology Linux Expert Center
Re: OF_UPSTREAM vs. additional dtbs
On 27.08.24 12:39, Sumit Garg wrote: > On Tue, 27 Aug 2024 at 15:05, Jan Kiszka wrote: >> >> On 27.08.24 09:13, Sumit Garg wrote: >>> On Mon, 26 Aug 2024 at 18:02, Jan Kiszka wrote: >>>> >>>> On 26.08.24 09:10, Sumit Garg wrote: >>>>> On Mon, 26 Aug 2024 at 12:19, Jan Kiszka wrote: >>>>>> >>>>>> On 26.08.24 08:44, Sumit Garg wrote: >>>>>>> Hi, >>>>>>> >>>>>>> On Wed, 14 Aug 2024 at 22:14, Jan Kiszka 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//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 >>>>>>>> >>>>>>>> +ifneq ($(CONFIG_SPL_BUILD),y) >>>>>>>> +dtbo-list = \ >>>>>>>> + k3
Re: OF_UPSTREAM vs. additional dtbs
On 27.08.24 09:13, Sumit Garg wrote: > On Mon, 26 Aug 2024 at 18:02, Jan Kiszka wrote: >> >> On 26.08.24 09:10, Sumit Garg wrote: >>> On Mon, 26 Aug 2024 at 12:19, Jan Kiszka wrote: >>>> >>>> On 26.08.24 08:44, Sumit Garg wrote: >>>>> Hi, >>>>> >>>>> On Wed, 14 Aug 2024 at 22:14, Jan Kiszka 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//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 >>>>>> >>>>>> +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//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. >>>> >>>> We are using the overlay to massage the DT presented to the OS based on >>>> firmware configuration. >>> >>> Agree and more than that I prefer the firmware to own the overall DT >>> and present that to the OS. >>> >>>> So, those two belong to the firmware logically, >>>> but - with some disclaimers, we could also try to upstream them. >>> >>> For historical reasons, Linux kernel source tree has become the >>> defacto upstream repo for DT sources. So it's better to contribute >>> there and sync back in U-Boot. >> >> Will do ASAP, hope to hit at least 6.12 then. >> >> Still, this will delay our next patches for U-Boot by many months. Also >> for that reason, a plan B for U-Boot local DTs should remain, no >> left-or-right policy. > > Yeah, the U-Boot local DTs should be used until the board is fully > supported by the dts/upstream directory. > This is not what I mean and won't help: Given the longer pipeline, it should remain possible to carry also local changes after switching to OF_UPSTREAM and while waiting for upstreaming to be done - if ever. We are missing middle ground. Jan -- Siemens AG, Technology Linux Expert Center
Re: OF_UPSTREAM vs. additional dtbs
On 26.08.24 09:10, Sumit Garg wrote: > On Mon, 26 Aug 2024 at 12:19, Jan Kiszka wrote: >> >> On 26.08.24 08:44, Sumit Garg wrote: >>> Hi, >>> >>> On Wed, 14 Aug 2024 at 22:14, Jan Kiszka 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//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 >>>> >>>> +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//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. >> >> We are using the overlay to massage the DT presented to the OS based on >> firmware configuration. > > Agree and more than that I prefer the firmware to own the overall DT > and present that to the OS. > >> So, those two belong to the firmware logically, >> but - with some disclaimers, we could also try to upstream them. > > For historical reasons, Linux kernel source tree has become the > defacto upstream repo for DT sources. So it's better to contribute > there and sync back in U-Boot. Will do ASAP, hope to hit at least 6.12 then. Still, this will delay our next patches for U-Boot by many months. Also for that reason, a plan B for U-Boot local DTs should remain, no left-or-right policy. Jan -- Siemens AG, Technology Linux Expert Center
Re: OF_UPSTREAM vs. additional dtbs
On 26.08.24 08:44, Sumit Garg wrote: > Hi, > > On Wed, 14 Aug 2024 at 22:14, Jan Kiszka 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//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 >> >> +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//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. We are using the overlay to massage the DT presented to the OS based on firmware configuration. So, those two belong to the firmware logically, but - with some disclaimers, we could also try to upstream them. Jan -- Siemens AG, Technology Linux Expert Center
Re: OF_UPSTREAM vs. additional dtbs
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//dts? >>> I'm a bit lost in the Makefile forest. >>> >> >> Sumit: Any suggestions? >> > > 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. 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 +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? Jan -- Siemens AG, Technology Linux Expert Center
Re: OF_UPSTREAM vs. additional dtbs
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//dts? >> I'm a bit lost in the Makefile forest. >> > > Sumit: Any suggestions? > 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). Jan -- Siemens AG, Technology Linux Expert Center
OF_UPSTREAM vs. additional dtbs
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" for our spl dtb. Are there means to still build certain dtb[o] files in arch//dts? I'm a bit lost in the Makefile forest. Thanks, Jan -- Siemens AG, Technology Linux Expert Center
Re: [PATCH] usb: dwc3-generic: fix CONFIG_DM_REGULATOR-off case
On 08.08.24 16:27, Caleb Connolly wrote: > Hi Jan, > > On 08/08/2024 10:51, Jan Kiszka wrote: >> From: Jan Kiszka >> >> When DM_REGULATOR is disabled, all calls will return -ENOSYS. Account >> for that so that targets like the IOT2050 will work again. >> >> Fixes: de451d5d5b6f ("usb: dwc3-generic: support external vbus >> regulator") >> Signed-off-by: Jan Kiszka >> --- >> drivers/usb/dwc3/dwc3-generic.c | 6 +++--- >> 1 file changed, 3 insertions(+), 3 deletions(-) >> >> diff --git a/drivers/usb/dwc3/dwc3-generic.c >> b/drivers/usb/dwc3/dwc3-generic.c >> index a9ba315463c..2ab41cbae45 100644 >> --- a/drivers/usb/dwc3/dwc3-generic.c >> +++ b/drivers/usb/dwc3/dwc3-generic.c >> @@ -246,12 +246,12 @@ static int dwc3_generic_host_probe(struct >> udevice *dev) >> return rc; >> rc = device_get_supply_regulator(dev, "vbus-supply", >> &priv->vbus_supply); >> - if (rc) >> + if (rc && rc != -ENOSYS) >> debug("%s: No vbus regulator found: %d\n", dev->name, rc); >> - /* Only returns an error if regulator is valid and failed to >> enable due to a driver issue */ >> + /* Does not return an error if regulator is invalid - but does so >> when DM_REGULATOR is disabled */ >> rc = regulator_set_enable_if_allowed(priv->vbus_supply, true); >> - if (rc) >> + if (rc && rc != -ENOSYS) > > regulator_set_enable_if_allowed() will return 0 if the call to > regulator_set_enable() returns -ENOSYS > > Maybe it would make sense to have the stub implementation of > regulator_set_enable_if_allowed() return 0? > Possible. Would that be the only case where a stub should not return ENOSYS? All do so far. > Somewhat confusing to check for -ENOSYS here imo, since it isn't really > obvious when that would be the case. But that would still leave is a with a misleading message, even if it is just a debug output. The absence of a regulator is not per se a bug to my understanding. Jan >> return rc; >> hccr = (struct xhci_hccr *)priv->gen_priv.base; > -- Siemens AG, Technology Linux Expert Center
[PATCH] usb: dwc3-generic: fix CONFIG_DM_REGULATOR-off case
From: Jan Kiszka When DM_REGULATOR is disabled, all calls will return -ENOSYS. Account for that so that targets like the IOT2050 will work again. Fixes: de451d5d5b6f ("usb: dwc3-generic: support external vbus regulator") Signed-off-by: Jan Kiszka --- drivers/usb/dwc3/dwc3-generic.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/usb/dwc3/dwc3-generic.c b/drivers/usb/dwc3/dwc3-generic.c index a9ba315463c..2ab41cbae45 100644 --- a/drivers/usb/dwc3/dwc3-generic.c +++ b/drivers/usb/dwc3/dwc3-generic.c @@ -246,12 +246,12 @@ static int dwc3_generic_host_probe(struct udevice *dev) return rc; rc = device_get_supply_regulator(dev, "vbus-supply", &priv->vbus_supply); - if (rc) + if (rc && rc != -ENOSYS) debug("%s: No vbus regulator found: %d\n", dev->name, rc); - /* Only returns an error if regulator is valid and failed to enable due to a driver issue */ + /* Does not return an error if regulator is invalid - but does so when DM_REGULATOR is disabled */ rc = regulator_set_enable_if_allowed(priv->vbus_supply, true); - if (rc) + if (rc && rc != -ENOSYS) return rc; hccr = (struct xhci_hccr *)priv->gen_priv.base; -- 2.43.0
[PATCH] clk: Fix error message in clk_get_bulk
From: Jan Kiszka Fix a logical inversion of the printed text. Signed-off-by: Jan Kiszka --- drivers/clk/clk-uclass.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/clk/clk-uclass.c b/drivers/clk/clk-uclass.c index ed6e60bc484..78d8ea94c65 100644 --- a/drivers/clk/clk-uclass.c +++ b/drivers/clk/clk-uclass.c @@ -180,7 +180,7 @@ int clk_get_bulk(struct udevice *dev, struct clk_bulk *bulk) bulk_get_err: err = clk_release_all(bulk->clks, bulk->count); if (err) - debug("%s: could release all clocks for %p\n", + debug("%s: could not release all clocks for %p\n", __func__, dev); return ret; -- 2.35.3
Re: [PATCH V6 07/20] configs: am62x_evm_a53_defconfig: Switch to bootstd
On 21.02.24 10:10, Francesco Dolcini wrote: > Hello Jan, > > On Mon, Feb 19, 2024 at 07:37:55PM +0100, Jan Kiszka wrote: >> My personal observation is that continuous integration testings with >> all-upstream components is not really a common thing. I saw that with >> multiple active SoCs from various vendors. > > With some limitation we have this running in Toradex since a couple of > years, we do integrate latest mainline kernel/u-boot and OE master > layers and run all that through our Lava test suite on real hardware. > > It has challenges, even getting the build to succeed is not obvious and > requires continuous care, but we do spot regression on RC releases and > we actively report and/or contribute fixes for it. > > Unfortunately the test results are still not published on some website > and are only internal, but we are working on making this available. > > Looking forward to have more players doing it, starting from the SoC > vendors! This is great to hear an highly welcome! One challenge of this is definitely to get the information to the right people, ideally without requiring too much manual effort (as that is often the most limited resource) while not overloading the target audience with too many false or inaccurate reports. Jan -- Siemens AG, Technology Linux Expert Center
Re: [PATCH V6 07/20] configs: am62x_evm_a53_defconfig: Switch to bootstd
On 19.02.24 19:37, Jan Kiszka wrote: > On 17.02.24 12:36, Alexander Sverdlin wrote: >> Hi Jan! >> >> On Sat, 2024-02-17 at 09:42 +0100, Jan Kiszka wrote: >>>> U-Boot 2024.01 (Feb 15 2024 - 01:43:17 +0100) >>>> >>>> SoC: AM62X SR1.0 HS-FS >>>> Model: Texas Instruments AM625 SK >>>> DRAM: 2 GiB >>>> Core: 56 devices, 23 uclasses, devicetree: separate >>>> MMC: mmc@fa1: 0, mmc@fa0: 1 >>>> Loading Environment from nowhere... OK >>>> In: serial@280 >>>> Out: serial@280 >>>> Err: serial@280 >>>> Net: eth0: ethernet@800port@1 >>>> Hit any key to stop autoboot: 0 >>>> switch to partitions #0, OK >>>> mmc1 is current device >>>> SD/MMC found on device 1 >>>> Failed to load 'uEnv.txt' >>>> Scanning for bootflows in all bootdevs >>>> Seq Method State Uclass Part Name >>>> Filename >>>> --- --- -- >>>> >>>> Scanning global bootmeth 'efi_mgr': >>>> No EFI system partition >>>> No EFI system partition >>>> Failed to persist EFI variables >>>> Scanning bootdev 'mmc@fa0.bootdev': >>>> Scanning bootdev 'mmc@fa1.bootdev': >>>> Unknown uclass 'usb' in label >>>> link up on port 1, speed 100, full duplex >>>> BOOTP broadcast 1 >>>> BOOTP broadcast 2 >>>> BOOTP broadcast 3 >>>> ... >>>> --- >>>> >>>> I suppose TI's BSP has older U-Boot... So it's not providing necessary >>>> script for BOOTSTD, I suppose? >>>> >>> >>> You can make the BeagleBone boot via EFI, but it requires a hybrid >>> partition table (ROM loader want DOS, EFI needs GPT). A Debian >>> integration with this can be found for Isar [1] in this series [2]. It's >>> only using upstream sources (plus still one u-boot patch to get wifi >>> working). >>> >>> If you want legacy script booting, I suspect you need to flip some extra >>> switches explicitly by now. >> >> Thanks for the hints! >> I'm wondering, if this was a deliberate "let's stop booting all the >> pre-existing embedded distros" decision? (buildroot, yocto/meta-ti...) >> > > FWIW, I'm not seeing other boot methods being specifically disabled in > beagleplay in 2024.01 or even newer. I didn't try the result, but this > may actually be some other issue and real bug, nothing obviously intended. > I'm not even sure about this anymore, though there is still a bug, just a different one: ... U-Boot 2024.04-rc2-00040-g3e6f2a94bfc (Feb 20 2024 - 08:42:59 +0100) SoC: AM62X SR1.0 GP Model: BeagleBoard.org BeaglePlay DRAM: 2 GiB Core: 98 devices, 27 uclasses, devicetree: separate MMC: mmc@fa1: 0, mmc@fa0: 1, mmc@fa2: 2 Loading Environment from nowhere... OK In:serial@280 Out: serial@280 Err: serial@280 Net: No ethernet found. Press SPACE to abort autoboot in 2 seconds => print bootmeths bootmeths=script extlinux efi pxe => bootflow scan -l Scanning for bootflows in all bootdevs Seq Method State UclassPart Name Filename --- --- -- Scanning bootdev 'mmc@fa0.bootdev': 0 efi ready mmc 2 mmc@fa0.bootdev.part_ efi/boot/bootaa64.efi Scanning bootdev 'mmc@fa1.bootdev': 1 extlinux ready mmc 1 mmc@fa1.bootdev.part_ /extlinux/extlinux.conf Unknown uclass 'usb' in label "Synchronous Abort" handler, esr 0x8604, far 0x3030303030303840 elr: 3030302fb0bc0840 lr : 3030302fb0bc0840 (reloc) elr: 3030303030303840 lr : 3030303030303840 x0 : ffed x1 : x2 : 0002 x3 : ffb49d30 x4 : fffd4c00 x5 : ffb49d50 x6 : x7 : ffb4e890 x8 : 6924 x9 : ffb1212c x10: 0003 x11: 6914 x12: ffb1221c x13: ffb12b40 x14: ffb12b40 x15: ffb12535 x16: fff8a9d4 x17: x18: ffb23da0 x19: 314074726f70 x20: fffed000 x21: fffef000 x22: x23: fffef000 x24: fffef000 x25: x26: fffc7174 x27: x28: x29: 74656e7265687465 Same with 2024.01 release. Jan -- Siemens AG, Technology Linux Expert Center
Re: [PATCH V6 07/20] configs: am62x_evm_a53_defconfig: Switch to bootstd
On 17.02.24 12:36, Alexander Sverdlin wrote: > Hi Jan! > > On Sat, 2024-02-17 at 09:42 +0100, Jan Kiszka wrote: >>> U-Boot 2024.01 (Feb 15 2024 - 01:43:17 +0100) >>> >>> SoC: AM62X SR1.0 HS-FS >>> Model: Texas Instruments AM625 SK >>> DRAM: 2 GiB >>> Core: 56 devices, 23 uclasses, devicetree: separate >>> MMC: mmc@fa1: 0, mmc@fa0: 1 >>> Loading Environment from nowhere... OK >>> In: serial@280 >>> Out: serial@280 >>> Err: serial@280 >>> Net: eth0: ethernet@800port@1 >>> Hit any key to stop autoboot: 0 >>> switch to partitions #0, OK >>> mmc1 is current device >>> SD/MMC found on device 1 >>> Failed to load 'uEnv.txt' >>> Scanning for bootflows in all bootdevs >>> Seq Method State Uclass Part Name Filename >>> --- --- -- >>> >>> Scanning global bootmeth 'efi_mgr': >>> No EFI system partition >>> No EFI system partition >>> Failed to persist EFI variables >>> Scanning bootdev 'mmc@fa0.bootdev': >>> Scanning bootdev 'mmc@fa1.bootdev': >>> Unknown uclass 'usb' in label >>> link up on port 1, speed 100, full duplex >>> BOOTP broadcast 1 >>> BOOTP broadcast 2 >>> BOOTP broadcast 3 >>> ... >>> --- >>> >>> I suppose TI's BSP has older U-Boot... So it's not providing necessary >>> script for BOOTSTD, I suppose? >>> >> >> You can make the BeagleBone boot via EFI, but it requires a hybrid >> partition table (ROM loader want DOS, EFI needs GPT). A Debian >> integration with this can be found for Isar [1] in this series [2]. It's >> only using upstream sources (plus still one u-boot patch to get wifi >> working). >> >> If you want legacy script booting, I suspect you need to flip some extra >> switches explicitly by now. > > Thanks for the hints! > I'm wondering, if this was a deliberate "let's stop booting all the > pre-existing embedded distros" decision? (buildroot, yocto/meta-ti...) > FWIW, I'm not seeing other boot methods being specifically disabled in beagleplay in 2024.01 or even newer. I didn't try the result, but this may actually be some other issue and real bug, nothing obviously intended. My personal observation is that continuous integration testings with all-upstream components is not really a common thing. I saw that with multiple active SoCs from various vendors. Jan -- Siemens AG, Technology Linux Expert Center
Re: [PATCH V6 07/20] configs: am62x_evm_a53_defconfig: Switch to bootstd
On 17.02.24 04:11, Alexander Sverdlin wrote: > Hello Nishanth, > > On Fri, 2023-08-25 at 13:02 -0500, Nishanth Menon wrote: >> Switch to using bootstd. Note with this change, we will stop using >> distro_bootcmd and instead depend entirely on bootflow method of >> starting the system up. >> >> Suggested-by: Tom Rini >> Suggested-by: Simon Glass >> Reviewed-by: Tom Rini >> Tested-by: Mattijs Korpershoek >> Signed-off-by: Nishanth Menon >> Reviewed-by: Tom Rini >> Reviewed-by: Mattijs Korpershoek >> --- >> No change other than picking up reviews, tested tags along the way. >> V5: https://lore.kernel.org/r/20230824031101.3460411-6...@ti.com >> configs/am62x_evm_a53_defconfig | 5 +++-- >> 1 file changed, 3 insertions(+), 2 deletions(-) >> >> diff --git a/configs/am62x_evm_a53_defconfig >> b/configs/am62x_evm_a53_defconfig >> index d55caabe22c9..1807df8bbee9 100644 >> --- a/configs/am62x_evm_a53_defconfig >> +++ b/configs/am62x_evm_a53_defconfig >> @@ -28,8 +28,9 @@ CONFIG_SPL_SPI=y >> # CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set >> CONFIG_SPL_LOAD_FIT=y >> CONFIG_SPL_LOAD_FIT_ADDRESS=0x8100 >> -CONFIG_DISTRO_DEFAULTS=y >> -CONFIG_BOOTCOMMAND="run envboot; run distro_bootcmd;" >> +CONFIG_BOOTSTD_FULL=y >> +CONFIG_BOOTSTD_DEFAULTS=y >> +CONFIG_BOOTCOMMAND="run envboot; bootflow scan -lb" >> CONFIG_SPL_MAX_SIZE=0x58000 >> CONFIG_SPL_HAS_BSS_LINKER_SECTION=y >> CONFIG_SPL_BSS_START_ADDR=0x80c8 > > could you please suggest which distro have you used for testing? > > After U-Boot update to v2024.01 Buildroot is not booting any more: > > --- > U-Boot 2024.01 (Feb 15 2024 - 01:43:17 +0100) > > SoC: AM62X SR1.0 HS-FS > Model: Texas Instruments AM625 SK > DRAM: 2 GiB > Core: 56 devices, 23 uclasses, devicetree: separate > MMC: mmc@fa1: 0, mmc@fa0: 1 > Loading Environment from nowhere... OK > In:serial@280 > Out: serial@280 > Err: serial@280 > Net: eth0: ethernet@800port@1 > Hit any key to stop autoboot: 0 > switch to partitions #0, OK > mmc1 is current device > SD/MMC found on device 1 > Failed to load 'uEnv.txt' > Scanning for bootflows in all bootdevs > Seq Method State UclassPart Name Filename > --- --- -- > > Scanning global bootmeth 'efi_mgr': > No EFI system partition > No EFI system partition > Failed to persist EFI variables > Scanning bootdev 'mmc@fa0.bootdev': > Scanning bootdev 'mmc@fa1.bootdev': > Unknown uclass 'usb' in label > link up on port 1, speed 100, full duplex > BOOTP broadcast 1 > BOOTP broadcast 2 > BOOTP broadcast 3 > ... > --- > > I suppose TI's BSP has older U-Boot... So it's not providing necessary > script for BOOTSTD, I suppose? > You can make the BeagleBone boot via EFI, but it requires a hybrid partition table (ROM loader want DOS, EFI needs GPT). A Debian integration with this can be found for Isar [1] in this series [2]. It's only using upstream sources (plus still one u-boot patch to get wifi working). If you want legacy script booting, I suspect you need to flip some extra switches explicitly by now. Jan [1] https://github.com/ilbers/isar/ [2] https://patchwork.isar-build.org/project/isar/list/?series=1049 -- Siemens AG, Technology Linux Expert Center
Re: [PATCH 3/6] board: ti: am62x: Add basic initialization for usb voltage, 32k crystal, debounce
On 26.07.23 13:10, Nishanth Menon wrote: > On 00:35-20230726, Francesco Dolcini wrote: > [...] At least the ones we have currently (I am not sure about toradex, phytech etc), seem to operate the vdd_core at 0.85V .. (which is what USB is dependent upon). >>> >>> For Toradex, we do have the equivalent code in our board file, see >>> https://git.toradex.com/cgit/u-boot-toradex.git/tree/board/toradex/verdin-am62/verdin-am62.c?h=toradex_ti-u-boot-2023.04#n92 >>> >>> The 32kHz configuration is just different for us, we do not re-use the >>> same you have here. > > True, you are hitting the bypass control and not powering on the > oscillator control since the 32k is incoming from RTC, in my case, since > I have an actual 32k crystal, I am clearing the powerdown. > > >>> >>> The debounce conf registers I have no idea what they are about, >>> something we should have also on our board? Any additional details? >> >> So, I got curious and checked on the datasheet/TRM on this debounce. If >> I understood correctly this is to have debounce on GPIO and/or EQEP. > > Typically, yes - input signals more useful for eQEP or GPIO. but the > implementation is at pin level which, technically could be used for > other purposes (but I have'nt seen any). > >> >> However to my understanding this would need to have the corresponding >> DEBOUNCE_SEL register written on the pad configuration, and by default it's >> 0. >> >> What's the use case for this debounce configuration you have here? > > TRM was a bit of a crap (internal ticket was filed to improve), but long > story short: > * bootloader configures delays per index > * in the pinmux configuration, we pick which index to use for the pin > > On Beagleplay, for example, the HDMI hot plug detect GPIO benefited from > this[1]. Corresponding pinctrl.h macros were posted in [2]. > > Why do it in the bootloader? since gpio inputs could also used in u-boot > (e.g. MMC/CD) > > > All said, Tom's question is very valid - we'd rather not modify evm.c > for these specific configurations (popcorn as they might be), and we > need to figure out a better option to introduce this kind of variation > cleanly. For now, I will try dropping this patch. > > > [1] > https://git.beagleboard.org/beagleboard/linux/-/blob/v6.1.33-ti-rt-arm64-r6/arch/arm64/boot/dts/ti/k3-am625-beagleplay.dts#L311 > [2] https://lore.kernel.org/all/20230619131620.3286650-1...@ti.com/ > What happened to this? I still need something like this patch (a version that has the CFG register writes correctly ordered) on top of current master in order to get WIFI on the Beagleplay. Jan
[PATCH] arm: dts: iot2050: Fix by syncing from Linux
From: Jan Kiszka This restores support for IOT2050 by widely synchronizing its DT files with the Linux kernel. We additionally need to add the alias restoration that is still waiting for its upstream merge and the not-yet-upstreamed bits needed for watchdog reboot detection. Fixes: 4dbdc84754ea ("arm: dts: k3-am654: pull in dtb update from Linux") Signed-off-by: Jan Kiszka --- Bryan, please don't do partial DT syncing in future anymore! arch/arm/dts/k3-am65-iot2050-common-pg2.dtsi | 2 +- arch/arm/dts/k3-am65-iot2050-common.dtsi | 218 +- .../dts/k3-am6528-iot2050-basic-common.dtsi | 3 +- .../k3-am6548-iot2050-advanced-common.dtsi| 6 +- .../arm/dts/k3-am6548-iot2050-advanced-m2.dts | 28 ++- 5 files changed, 123 insertions(+), 134 deletions(-) diff --git a/arch/arm/dts/k3-am65-iot2050-common-pg2.dtsi b/arch/arm/dts/k3-am65-iot2050-common-pg2.dtsi index e73458ca690..e9419c4fe60 100644 --- a/arch/arm/dts/k3-am65-iot2050-common-pg2.dtsi +++ b/arch/arm/dts/k3-am65-iot2050-common-pg2.dtsi @@ -10,7 +10,7 @@ */ &main_pmx0 { - cp2102n_reset_pin_default: cp2102n-reset-pin-default { + cp2102n_reset_pin_default: cp2102n-reset-default-pins { pinctrl-single,pins = < /* (AF12) GPIO1_24, used as cp2102 reset */ AM65X_IOPAD(0x01e0, PIN_OUTPUT, 7) diff --git a/arch/arm/dts/k3-am65-iot2050-common.dtsi b/arch/arm/dts/k3-am65-iot2050-common.dtsi index b6135b849f1..fa7178144b8 100644 --- a/arch/arm/dts/k3-am65-iot2050-common.dtsi +++ b/arch/arm/dts/k3-am65-iot2050-common.dtsi @@ -14,6 +14,16 @@ / { aliases { + serial0 = &wkup_uart0; + serial1 = &mcu_uart0; + serial2 = &main_uart0; + serial3 = &main_uart1; + i2c0 = &wkup_i2c0; + i2c1 = &mcu_i2c0; + i2c2 = &main_i2c0; + i2c3 = &main_i2c1; + i2c4 = &main_i2c2; + i2c5 = &main_i2c3; spi0 = &mcu_spi0; mmc0 = &sdhci1; mmc1 = &sdhci0; @@ -21,7 +31,6 @@ chosen { stdout-path = "serial3:115200n8"; - bootargs = "earlycon=ns16550a,mmio32,0x0281"; }; reserved-memory { @@ -111,7 +120,7 @@ }; &wkup_pmx0 { - wkup_i2c0_pins_default: wkup-i2c0-pins-default { + wkup_i2c0_pins_default: wkup-i2c0-default-pins { pinctrl-single,pins = < /* (AC7) WKUP_I2C0_SCL */ AM65X_WKUP_IOPAD(0x00e0, PIN_INPUT, 0) @@ -120,7 +129,7 @@ >; }; - mcu_i2c0_pins_default: mcu-i2c0-pins-default { + mcu_i2c0_pins_default: mcu-i2c0-default-pins { pinctrl-single,pins = < /* (AD8) MCU_I2C0_SCL */ AM65X_WKUP_IOPAD(0x00e8, PIN_INPUT, 0) @@ -129,21 +138,21 @@ >; }; - arduino_i2c_aio_switch_pins_default: arduino-i2c-aio-switch-pins-default { + arduino_i2c_aio_switch_pins_default: arduino-i2c-aio-switch-default-pins { pinctrl-single,pins = < /* (R2) WKUP_GPIO0_21 */ AM65X_WKUP_IOPAD(0x0024, PIN_OUTPUT, 7) >; }; - push_button_pins_default: push-button-pins-default { + push_button_pins_default: push-button-default-pins { pinctrl-single,pins = < /* (T1) MCU_OSPI1_CLK.WKUP_GPIO0_25 */ AM65X_WKUP_IOPAD(0x0034, PIN_INPUT, 7) >; }; - arduino_uart_pins_default: arduino-uart-pins-default { + arduino_uart_pins_default: arduino-uart-default-pins { pinctrl-single,pins = < /* (P4) MCU_UART0_RXD */ AM65X_WKUP_IOPAD(0x0044, PIN_INPUT, 4) @@ -152,7 +161,7 @@ >; }; - arduino_io_d2_to_d3_pins_default: arduino-io-d2-to-d3-pins-default { + arduino_io_d2_to_d3_pins_default: arduino-io-d2-to-d3-default-pins { pinctrl-single,pins = < /* (P1) WKUP_GPIO0_31 */ AM65X_WKUP_IOPAD(0x004C, PIN_OUTPUT, 7) @@ -161,7 +170,7 @@ >; }; - arduino_io_oe_pins_default: arduino-io-oe-pins-default { + arduino_io_oe_pins_default: arduino-io-oe-default-pins { pinctrl-single,pins = < /* (N4) WKUP_GPIO0_34 */ AM65X_WKUP_IOPAD(0x0058, PIN_OUTPUT, 7) @@ -176,7 +185,7 @@ >; }; - mcu_fss0_ospi0_pins_default: mcu-fss0-ospi0-pins-default { + mcu_fss0_ospi0_pins_default: mcu-fss0-ospi0-default-pins { pinctrl-singl
Re: [PATCH v2 00/26] sync am65x device tree with Linux v6.7-rc1
On 06.01.24 12:57, Jan Kiszka wrote: > On 29.12.23 18:46, Bryan Brattlof wrote: >> Hello Again Everyone! >> >> This series gets the am65x booting again along with syncing the device >> tree files with v6.7-rc1 Linux. >> >> The bulk of these patches unify the WKUP SPL board file with the arm64 >> files to make future syncs from Linux much easier. In the end the DTBs >> should look a lot like what the DTBs look like for the am64x which >> is fairly similar to the am65x. >> >> For those interested in what UART boot looks like: >>https://paste.sr.ht/~bryanb/7df8a645dc548912cd806abd5ecab967ef3287bc >> >> Changes from v1: [0] >> - fixed multi-line comment format >> - moved wkup_uart0 and mcu_uart0 U-Boot overrides to the r5 board file >> as they are not needed for a53/main domain U-Boot builds >> - corrected a bad wkup_i2c0_pins_default fixup in PATCH 6/26 >> - spelling fix (s/Libux/Linux/) in commit body for PATCH 6/26 >> - added trailers from Tom >> >> Thanks for reviewing and happy holidays >> ~Bryan >> >> [0] https://lore.kernel.org/u-boot/20231221174412.210807-1...@ti.com/ >> >> Bryan Brattlof (26): >> configs: am65x_evm_r5: enable driver for fixed regulators >> configs: am65x_evm_a53: disable CONSOLE_MUX >> arm: dts: k3-am654-r5: Merge board file and U-Boot overlay >> arm: dts: k3-am654: pull in dtb update from Linux >> arm: dts: k3-am654: copy bootph properties to a53 dts >> arm: dts: k3-am654: include a53 board dtb for r5 build >> arm: dts: k3-am654: remove duplicate vtt_supply >> arm: dts: k3-am654: remove duplicate wkup_uart0 >> arm: dts: k3-am654: remove duplicate timer >> arm: dts: k3-am654: remove duplicate mcu_ringacc >> arm: dts: k3-am654: remove duplicate mcu_udmap >> arm: dts: k3-am654: add needed regs to udmap nodes >> arm: dts: k3-am654: remove duplicate mcu_uart0 node >> arm: dts: k3-am654: remove duplicate main_uart0 >> arm: dts: k3-am654: remove duplicate sdhci0 pinmux node >> arm: dts: k3-am654: remove duplicate sdhci1 pinmux node >> arm: dts: k3-am654: remove duplicate wkup_i2c0 >> arm: dts: k3-am654: remove duplicate ospi0 node >> arm: dts: k3-am654: remove usb0 >> arm: dts: k3-am654: remove duplicate mdio >> arm: dts: k3-am654: remove duplicate vtt pinmux >> arm: dts: k3-am654: remove duplicate root properties >> arm: dts: k3-am654: remove un-needed aliases >> arm: dts: k3-am654: move dummy_clock to root node >> arm: dts: k3-am654: remove duplicate mcu secure proxy node >> arm: dts: k3-am654: convert bootph-pre-ram to bootph-all >> >> arch/arm/dts/k3-am65-main.dtsi| 342 +++--- >> arch/arm/dts/k3-am65-mcu.dtsi | 156 +++- >> arch/arm/dts/k3-am65-wakeup.dtsi | 10 +- >> arch/arm/dts/k3-am65.dtsi | 19 +- >> arch/arm/dts/k3-am654-base-board-u-boot.dtsi | 195 +- >> arch/arm/dts/k3-am654-base-board.dts | 301 +-- >> .../dts/k3-am654-r5-base-board-u-boot.dtsi| 208 --- >> arch/arm/dts/k3-am654-r5-base-board.dts | 303 >> arch/arm/dts/k3-am654.dtsi| 7 + >> configs/am65x_evm_a53_defconfig | 1 - >> configs/am65x_evm_r5_defconfig| 2 + >> 11 files changed, 886 insertions(+), 658 deletions(-) >> delete mode 100644 arch/arm/dts/k3-am654-r5-base-board-u-boot.dtsi >> >> >> base-commit: 0a0ceea2269b983e736b80104f03cc800d1a5e2a > > This breaks the IOT2050 boards, probably because it did in incomplete > sync, changing the core dtsi file without updating all affected boards. > But also [1] is missing in upstream already and seem to have an impact. > Bad timing for a sync. > > And the series is not bisectable - already the 3rd patch breaks the build: > > ... > DTC arch/arm/dts/k3-am654-r5-base-board.dtb > Error: arch/arm/dts/.k3-am654-r5-base-board.dtb.pre.tmp:423.27-28 syntax > error > FATAL ERROR: Unable to parse input tree > > Jan > > [1] > https://lore.kernel.org/lkml/1edbc1b56ed4ff2256d7afb7db3cab4b3a423692.1699087938.git.jan.kis...@siemens.com/ > BTW, folks @TI: You have our devices by now. Jan -- Siemens AG, Technology Linux Expert Center
Re: [PATCH v2 00/26] sync am65x device tree with Linux v6.7-rc1
On 29.12.23 18:46, Bryan Brattlof wrote: > Hello Again Everyone! > > This series gets the am65x booting again along with syncing the device > tree files with v6.7-rc1 Linux. > > The bulk of these patches unify the WKUP SPL board file with the arm64 > files to make future syncs from Linux much easier. In the end the DTBs > should look a lot like what the DTBs look like for the am64x which > is fairly similar to the am65x. > > For those interested in what UART boot looks like: >https://paste.sr.ht/~bryanb/7df8a645dc548912cd806abd5ecab967ef3287bc > > Changes from v1: [0] > - fixed multi-line comment format > - moved wkup_uart0 and mcu_uart0 U-Boot overrides to the r5 board file > as they are not needed for a53/main domain U-Boot builds > - corrected a bad wkup_i2c0_pins_default fixup in PATCH 6/26 > - spelling fix (s/Libux/Linux/) in commit body for PATCH 6/26 > - added trailers from Tom > > Thanks for reviewing and happy holidays > ~Bryan > > [0] https://lore.kernel.org/u-boot/20231221174412.210807-1...@ti.com/ > > Bryan Brattlof (26): > configs: am65x_evm_r5: enable driver for fixed regulators > configs: am65x_evm_a53: disable CONSOLE_MUX > arm: dts: k3-am654-r5: Merge board file and U-Boot overlay > arm: dts: k3-am654: pull in dtb update from Linux > arm: dts: k3-am654: copy bootph properties to a53 dts > arm: dts: k3-am654: include a53 board dtb for r5 build > arm: dts: k3-am654: remove duplicate vtt_supply > arm: dts: k3-am654: remove duplicate wkup_uart0 > arm: dts: k3-am654: remove duplicate timer > arm: dts: k3-am654: remove duplicate mcu_ringacc > arm: dts: k3-am654: remove duplicate mcu_udmap > arm: dts: k3-am654: add needed regs to udmap nodes > arm: dts: k3-am654: remove duplicate mcu_uart0 node > arm: dts: k3-am654: remove duplicate main_uart0 > arm: dts: k3-am654: remove duplicate sdhci0 pinmux node > arm: dts: k3-am654: remove duplicate sdhci1 pinmux node > arm: dts: k3-am654: remove duplicate wkup_i2c0 > arm: dts: k3-am654: remove duplicate ospi0 node > arm: dts: k3-am654: remove usb0 > arm: dts: k3-am654: remove duplicate mdio > arm: dts: k3-am654: remove duplicate vtt pinmux > arm: dts: k3-am654: remove duplicate root properties > arm: dts: k3-am654: remove un-needed aliases > arm: dts: k3-am654: move dummy_clock to root node > arm: dts: k3-am654: remove duplicate mcu secure proxy node > arm: dts: k3-am654: convert bootph-pre-ram to bootph-all > > arch/arm/dts/k3-am65-main.dtsi| 342 +++--- > arch/arm/dts/k3-am65-mcu.dtsi | 156 +++- > arch/arm/dts/k3-am65-wakeup.dtsi | 10 +- > arch/arm/dts/k3-am65.dtsi | 19 +- > arch/arm/dts/k3-am654-base-board-u-boot.dtsi | 195 +- > arch/arm/dts/k3-am654-base-board.dts | 301 +-- > .../dts/k3-am654-r5-base-board-u-boot.dtsi| 208 --- > arch/arm/dts/k3-am654-r5-base-board.dts | 303 > arch/arm/dts/k3-am654.dtsi| 7 + > configs/am65x_evm_a53_defconfig | 1 - > configs/am65x_evm_r5_defconfig| 2 + > 11 files changed, 886 insertions(+), 658 deletions(-) > delete mode 100644 arch/arm/dts/k3-am654-r5-base-board-u-boot.dtsi > > > base-commit: 0a0ceea2269b983e736b80104f03cc800d1a5e2a This breaks the IOT2050 boards, probably because it did in incomplete sync, changing the core dtsi file without updating all affected boards. But also [1] is missing in upstream already and seem to have an impact. Bad timing for a sync. And the series is not bisectable - already the 3rd patch breaks the build: ... DTC arch/arm/dts/k3-am654-r5-base-board.dtb Error: arch/arm/dts/.k3-am654-r5-base-board.dtb.pre.tmp:423.27-28 syntax error FATAL ERROR: Unable to parse input tree Jan [1] https://lore.kernel.org/lkml/1edbc1b56ed4ff2256d7afb7db3cab4b3a423692.1699087938.git.jan.kis...@siemens.com/ -- Siemens AG, Technology Linux Expert Center
Re: [PATCH 00/26] sync am65x device tree with Linux v6.7-rc1
On 02.01.24 18:42, Tom Rini wrote: > On Tue, Jan 02, 2024 at 08:27:34AM +0100, Jan Kiszka wrote: >> On 27.12.23 13:39, Nishanth Menon wrote: >>> On 15:00-20231221, Tom Rini wrote: >>>> On Thu, Dec 21, 2023 at 11:43:46AM -0600, Bryan Brattlof wrote: >>>> >>>>> Hello Everyone! >>>>> >>>>> This series gets the am65x booting again along with syncing the device >>>>> tree files with v6.7-rc1 Linux. >>>>> >>>>> The bulk of these patches unify the WKUP SPL board file with the arm64 >>>>> files to make future syncs from Linux much easier. In the end the DTBs >>>>> should look a lot like what the DTBs look like for the am64x which >>>>> is fairly similar to the am65x. >>>>> >>>>> For those interested in what UART boot looks like: >>>>>https://paste.sr.ht/~bryanb/7df8a645dc548912cd806abd5ecab967ef3287bc >>>>> >>>>> Thanks for reviewing and happy holidays >>>>> ~Bryan >>>> >>>> For the series, >>>> Tested-by: Tom Rini >>>> >>>> Nishanth, does this path work for you? >>>> >>> >>> Other than the minor comments provided in the relevant patches, >>> >>> The following files also need sync up with v6.7-rc1. >>> >>> k3-am65-iot2050-common-pg2.dtsi >>> k3-am65-iot2050-common.dtsi >>> k3-am6528-iot2050-basic-common.dtsi >>> k3-am6548-iot2050-advanced-common.dtsi >>> k3-am6548-iot2050-advanced-m2.dts >>> >>> Jan - could you look at syncing those once an update to this series is >>> posted? We could probably have a smoother v6.8-rc1 from then on. >>> >> >> We currently plan to sync once support for the new SM variant is in the >> upstream DT. Do you see other changes that would benefit from an earlier >> sync? > > So this sync is because the ref platforms at least do not boot, is > iot2050 currently booting? It was booting with ~v2024.01-rc4 before Christmas, didn't try latest master yet. Jan -- Siemens AG, Technology Linux Expert Center
Re: [PATCH 00/26] sync am65x device tree with Linux v6.7-rc1
On 27.12.23 13:39, Nishanth Menon wrote: > On 15:00-20231221, Tom Rini wrote: >> On Thu, Dec 21, 2023 at 11:43:46AM -0600, Bryan Brattlof wrote: >> >>> Hello Everyone! >>> >>> This series gets the am65x booting again along with syncing the device >>> tree files with v6.7-rc1 Linux. >>> >>> The bulk of these patches unify the WKUP SPL board file with the arm64 >>> files to make future syncs from Linux much easier. In the end the DTBs >>> should look a lot like what the DTBs look like for the am64x which >>> is fairly similar to the am65x. >>> >>> For those interested in what UART boot looks like: >>>https://paste.sr.ht/~bryanb/7df8a645dc548912cd806abd5ecab967ef3287bc >>> >>> Thanks for reviewing and happy holidays >>> ~Bryan >> >> For the series, >> Tested-by: Tom Rini >> >> Nishanth, does this path work for you? >> > > Other than the minor comments provided in the relevant patches, > > The following files also need sync up with v6.7-rc1. > > k3-am65-iot2050-common-pg2.dtsi > k3-am65-iot2050-common.dtsi > k3-am6528-iot2050-basic-common.dtsi > k3-am6548-iot2050-advanced-common.dtsi > k3-am6548-iot2050-advanced-m2.dts > > Jan - could you look at syncing those once an update to this series is > posted? We could probably have a smoother v6.8-rc1 from then on. > We currently plan to sync once support for the new SM variant is in the upstream DT. Do you see other changes that would benefit from an earlier sync? Jan -- Siemens AG, Technology Linux Expert Center
Re: [PATCH] spi: cadence-quadspi: Fix error message on stuck busy state
On 31.10.23 08:14, Stefan Roese wrote: > On 10/30/23 17:20, Jan Kiszka wrote: >> From: Jan Kiszka >> >> We are not iterating CQSPI_REG_RETRY, we are waiting 'timeout' ms, since >> day 1. >> >> Signed-off-by: Jan Kiszka > > Reviewed-by: Stefan Roese > > Thanks, > Stefan > >> --- >> >> We are unfortunately seeing that message right now, rarely but then >> prominently... >> >> drivers/spi/cadence_qspi_apb.c | 3 +-- >> 1 file changed, 1 insertion(+), 2 deletions(-) >> >> diff --git a/drivers/spi/cadence_qspi_apb.c >> b/drivers/spi/cadence_qspi_apb.c >> index 9ce2c0f254f..d033184aa46 100644 >> --- a/drivers/spi/cadence_qspi_apb.c >> +++ b/drivers/spi/cadence_qspi_apb.c >> @@ -171,8 +171,7 @@ static unsigned int cadence_qspi_wait_idle(void >> *reg_base) >> } >> /* Timeout, still in busy mode. */ >> - printf("QSPI: QSPI is still busy after poll for %d times.\n", >> - CQSPI_REG_RETRY); >> + printf("QSPI: QSPI is still busy after poll for %d ms.\n", timeout); >> return 0; >> } >> > > Viele Grüße, > Stefan Roese > Ping. Jan -- Siemens AG, Technology Linux Expert Center
[PATCH] spi: cadence-quadspi: Fix error message on stuck busy state
From: Jan Kiszka We are not iterating CQSPI_REG_RETRY, we are waiting 'timeout' ms, since day 1. Signed-off-by: Jan Kiszka --- We are unfortunately seeing that message right now, rarely but then prominently... drivers/spi/cadence_qspi_apb.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/spi/cadence_qspi_apb.c b/drivers/spi/cadence_qspi_apb.c index 9ce2c0f254f..d033184aa46 100644 --- a/drivers/spi/cadence_qspi_apb.c +++ b/drivers/spi/cadence_qspi_apb.c @@ -171,8 +171,7 @@ static unsigned int cadence_qspi_wait_idle(void *reg_base) } /* Timeout, still in busy mode. */ - printf("QSPI: QSPI is still busy after poll for %d times.\n", - CQSPI_REG_RETRY); + printf("QSPI: QSPI is still busy after poll for %d ms.\n", timeout); return 0; } -- 2.35.3
[PATCH v2] iot2050: Allow for more than 1 USB storage device
From: Jan Kiszka This was lost in refactoring while some users of the IOT2050 expect it to work: Make sure that up to 3 USB storage devices are probed. Fixes: 53873974a4b0 ("include: armv7: Enable distroboot across all configs") Signed-off-by: Jan Kiszka Reviewed-by: Heinrich Schuchardt --- Changes in v2: - typo fix include/configs/iot2050.h | 9 + 1 file changed, 9 insertions(+) diff --git a/include/configs/iot2050.h b/include/configs/iot2050.h index 4968722d18f..94a9c767882 100644 --- a/include/configs/iot2050.h +++ b/include/configs/iot2050.h @@ -15,6 +15,15 @@ #include +/* allow up to 3 USB storage devices */ +#ifdef CONFIG_CMD_USB +#undef BOOT_TARGET_USB +#define BOOT_TARGET_USB(func) \ + func(USB, usb, 0) \ + func(USB, usb, 1) \ + func(USB, usb, 2) +#endif + /* * This defines all MMC devices, even if the basic variant has no mmc1. * The non-supported device will be removed from the boot targets during -- 2.35.3
[PATCH] iot2050: Allow for more than 1 USB storage device
From: Jan Kiszka This was lost via 53873974a4b0 while some users of the IOT2050 expect it to work: Make sure that up to 3 USB storage devices are probed. Signed-off-by: Jan Kiszka --- include/configs/iot2050.h | 9 + 1 file changed, 9 insertions(+) diff --git a/include/configs/iot2050.h b/include/configs/iot2050.h index 4968722d18f..1d444d02c83 100644 --- a/include/configs/iot2050.h +++ b/include/configs/iot2050.h @@ -15,6 +15,15 @@ #include +/* allow up to 3 USB storage devcies */ +#ifdef CONFIG_CMD_USB +#undef BOOT_TARGET_USB +#define BOOT_TARGET_USB(func) \ + func(USB, usb, 0) \ + func(USB, usb, 1) \ + func(USB, usb, 2) +#endif + /* * This defines all MMC devices, even if the basic variant has no mmc1. * The non-supported device will be removed from the boot targets during -- 2.35.3
[PATCH] board: siemens: iot2050: Fix M.2 detection
From: Jan Kiszka The "simpler" the logic, the higher the probability to not test and get things wrong, again: The absence of a "-PG2" suffix is not sufficient to derive that we are on PG1. There is also "IOT2050-ADVANCED-M2". Finally fix that by exactly matching against the two PG1 device names. While changing this, we can also drop the not really needed check for !board_is_sr1 in board_is_m2 and call the boards by their names ("board_is_pg1"). Reported-and-tested-by: Bao Cheng Su Signed-off-by: Jan Kiszka --- board/siemens/iot2050/board.c | 11 ++- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/board/siemens/iot2050/board.c b/board/siemens/iot2050/board.c index e35e55fb5de..0b0686e2628 100644 --- a/board/siemens/iot2050/board.c +++ b/board/siemens/iot2050/board.c @@ -155,19 +155,20 @@ static bool board_is_advanced(void) strstr((char *)info->name, "IOT2050-ADVANCED") != NULL; } -static bool board_is_sr1(void) +static bool board_is_pg1(void) { struct iot2050_info *info = IOT2050_INFO_DATA; return info->magic == IOT2050_INFO_MAGIC && - strstr((char *)info->name, "-PG2") == NULL; + (strcmp((char *)info->name, "IOT2050-BASIC") == 0 || +strcmp((char *)info->name, "IOT2050-ADVANCED") == 0); } static bool board_is_m2(void) { struct iot2050_info *info = IOT2050_INFO_DATA; - return !board_is_sr1() && info->magic == IOT2050_INFO_MAGIC && + return info->magic == IOT2050_INFO_MAGIC && strcmp((char *)info->name, "IOT2050-ADVANCED-M2") == 0; } @@ -217,14 +218,14 @@ void set_board_info_env(void) } if (board_is_advanced()) { - if (board_is_sr1()) + if (board_is_pg1()) fdtfile = "ti/k3-am6548-iot2050-advanced.dtb"; else if(board_is_m2()) fdtfile = "ti/k3-am6548-iot2050-advanced-m2.dtb"; else fdtfile = "ti/k3-am6548-iot2050-advanced-pg2.dtb"; } else { - if (board_is_sr1()) + if (board_is_pg1()) fdtfile = "ti/k3-am6528-iot2050-basic.dtb"; else fdtfile = "ti/k3-am6528-iot2050-basic-pg2.dtb"; -- 2.35.3
[PATCH] board: siemens: iot2050: Fix logical bug in PG1/PG2 detection
From: Jan Kiszka This caused the wrong fdtfile to be set and was failing to apply M.2 settings. Fixes: badaa1f6a7a9 ("boards: siemens: iot2050: Unify PG1 and PG2/M.2 configurations again") Signed-off-by: Jan Kiszka --- board/siemens/iot2050/board.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/board/siemens/iot2050/board.c b/board/siemens/iot2050/board.c index 15f5310c7bf..e35e55fb5de 100644 --- a/board/siemens/iot2050/board.c +++ b/board/siemens/iot2050/board.c @@ -160,7 +160,7 @@ static bool board_is_sr1(void) struct iot2050_info *info = IOT2050_INFO_DATA; return info->magic == IOT2050_INFO_MAGIC && - strstr((char *)info->name, "-PG2") != NULL; + strstr((char *)info->name, "-PG2") == NULL; } static bool board_is_m2(void) -- 2.35.3
[PATCH] arm: dts: k3-am65-iot2050: Fix boot
From: Jan Kiszka Since commit [1] A53 u-boot proper is broken. This is because nodes marked as 'bootph-pre-ram' are not available at u-boot proper before relocation. To fix this we mark all nodes in u-boot.dtsi as 'bootph-all'. [1] 9e644284ab812 ("dm: core: Report bootph-pre-ram/sram node as pre-reloc after relocation") Signed-off-by: Jan Kiszka --- .../dts/k3-am65-iot2050-common-u-boot.dtsi| 44 +-- 1 file changed, 22 insertions(+), 22 deletions(-) diff --git a/arch/arm/dts/k3-am65-iot2050-common-u-boot.dtsi b/arch/arm/dts/k3-am65-iot2050-common-u-boot.dtsi index 9fd64809a63..30fc7a78d89 100644 --- a/arch/arm/dts/k3-am65-iot2050-common-u-boot.dtsi +++ b/arch/arm/dts/k3-am65-iot2050-common-u-boot.dtsi @@ -37,18 +37,18 @@ }; leds { - bootph-pre-ram; + bootph-all; status-led-red { - bootph-pre-ram; + bootph-all; }; status-led-green { - bootph-pre-ram; + bootph-all; }; }; }; &cbass_mcu { - bootph-pre-ram; + bootph-all; mcu_navss: bus@2838 { ringacc@2b80 { @@ -75,70 +75,70 @@ }; &cbass_wakeup { - bootph-pre-ram; + bootph-all; }; &cbass_main { - bootph-pre-ram; + bootph-all; main_navss: bus@3080 { - bootph-pre-ram; + bootph-all; }; }; &wkup_pmx0 { - bootph-pre-ram; + bootph-all; mcu-fss0-ospi0-pins-default { - bootph-pre-ram; + bootph-all; }; }; &main_pmx0 { - bootph-pre-ram; + bootph-all; main-uart1-pins-default { - bootph-pre-ram; + bootph-all; }; }; &main_uart1 { - bootph-pre-ram; + bootph-all; current-speed = <115200>; }; &wkup_gpio0 { - bootph-pre-ram; + bootph-all; }; &ospi0 { - bootph-pre-ram; + bootph-all; flash@0 { - bootph-pre-ram; + bootph-all; }; }; &secure_proxy_main { - bootph-pre-ram; + bootph-all; }; &dmsc { - bootph-pre-ram; + bootph-all; k3_sysreset: sysreset-controller { compatible = "ti,sci-sysreset"; - bootph-pre-ram; + bootph-all; }; }; &k3_pds { - bootph-pre-ram; + bootph-all; }; &k3_clks { - bootph-pre-ram; + bootph-all; }; &k3_reset { - bootph-pre-ram; + bootph-all; }; &fss { - bootph-pre-ram; + bootph-all; }; -- 2.35.3
Re: [PATCH] arm: dts: k3-am625-beagleplay: Fix boot
On 04.10.23 14:15, Nishanth Menon wrote: > On 22:26-20231003, Jan Kiszka wrote: >> From: Jan Kiszka >> >> Since commit [1] A53 u-boot proper is broken. This is because nodes >> marked as 'bootph-pre-ram' are not available at u-boot proper before >> relocation. >> >> To fix this we mark all nodes as 'bootph-all'. >> >> [1] 9e644284ab812 ("dm: core: Report bootph-pre-ram/sram node as pre-reloc >> after relocation") >> >> Signed-off-by: Jan Kiszka >> --- >> >> This may overshoot, but at least the board boots again. Could it be that >> [1] broke even more boards? > > Jan: > https://lore.kernel.org/all/b1c62a7d-a90e-4212-8972-9b622e147...@kernel.org/ > > I got boot without r5-beagleplay.dts modified. and it is in line with > the changes in linux-next commit 944adefc7f88 ("arm64: dts: ti: > k3-am625-beagleplay: Add boot phase tags marking") > Yeah, no problem, missed that. Meanwhile, I can fix our IOT2050 because I was unfortunatenly right: more havoc in sight. Did anyone tried to look at the fallouts systematically already? Is it only affecting the TI family? Jan -- Siemens AG, Technology Linux Expert Center
[PATCH] arm: dts: k3-am625-beagleplay: Fix boot
From: Jan Kiszka Since commit [1] A53 u-boot proper is broken. This is because nodes marked as 'bootph-pre-ram' are not available at u-boot proper before relocation. To fix this we mark all nodes as 'bootph-all'. [1] 9e644284ab812 ("dm: core: Report bootph-pre-ram/sram node as pre-reloc after relocation") Signed-off-by: Jan Kiszka --- This may overshoot, but at least the board boots again. Could it be that [1] broke even more boards? arch/arm/dts/k3-am625-beagleplay-u-boot.dtsi | 70 ++-- arch/arm/dts/k3-am625-r5-beagleplay.dts | 12 ++-- 2 files changed, 41 insertions(+), 41 deletions(-) diff --git a/arch/arm/dts/k3-am625-beagleplay-u-boot.dtsi b/arch/arm/dts/k3-am625-beagleplay-u-boot.dtsi index f8c04e8a300..d6c6baa5518 100644 --- a/arch/arm/dts/k3-am625-beagleplay-u-boot.dtsi +++ b/arch/arm/dts/k3-am625-beagleplay-u-boot.dtsi @@ -14,143 +14,143 @@ }; memory@8000 { - bootph-pre-ram; + bootph-all; }; /* Keep the LEDs on by default to indicate life */ leds { - bootph-pre-ram; + bootph-all; led-0 { default-state = "on"; - bootph-pre-ram; + bootph-all; }; led-1 { default-state = "on"; - bootph-pre-ram; + bootph-all; }; led-2 { default-state = "on"; - bootph-pre-ram; + bootph-all; }; led-3 { default-state = "on"; - bootph-pre-ram; + bootph-all; }; led-4 { default-state = "on"; - bootph-pre-ram; + bootph-all; }; }; }; &cbass_main { - bootph-pre-ram; + bootph-all; }; &main_timer0 { clock-frequency = <2500>; - bootph-pre-ram; + bootph-all; }; &dmss { - bootph-pre-ram; + bootph-all; }; &secure_proxy_main { - bootph-pre-ram; + bootph-all; }; &dmsc { - bootph-pre-ram; + bootph-all; }; &k3_pds { - bootph-pre-ram; + bootph-all; }; &k3_clks { - bootph-pre-ram; + bootph-all; }; &k3_reset { - bootph-pre-ram; + bootph-all; }; &dmsc { - bootph-pre-ram; + bootph-all; k3_sysreset: sysreset-controller { compatible = "ti,sci-sysreset"; - bootph-pre-ram; + bootph-all; }; }; &wkup_conf { - bootph-pre-ram; + bootph-all; }; &chipid { - bootph-pre-ram; + bootph-all; }; &main_pmx0 { - bootph-pre-ram; + bootph-all; }; &main_uart0 { - bootph-pre-ram; + bootph-all; }; &console_pins_default { - bootph-pre-ram; + bootph-all; }; &cbass_mcu { - bootph-pre-ram; + bootph-all; }; &cbass_wakeup { - bootph-pre-ram; + bootph-all; }; &mcu_pmx0 { - bootph-pre-ram; + bootph-all; }; &main_i2c0 { - bootph-pre-ram; + bootph-all; }; &local_i2c_pins_default { - bootph-pre-ram; + bootph-all; }; &gpio0_pins_default { - bootph-pre-ram; + bootph-all; }; &main_gpio0 { - bootph-pre-ram; + bootph-all; }; &main_gpio1 { - bootph-pre-ram; + bootph-all; }; &sdhci0 { /* EMMC */ - bootph-pre-ram; + bootph-all; }; &emmc_pins_default { - bootph-pre-ram; + bootph-all; }; &sd_pins_default { - bootph-pre-ram; + bootph-all; /* Force to use SDCD card detect pin */ pinctrl-single,pins = < AM62X_IOPAD(0x023c, PIN_INPUT, 0) /* (A21) MMC1_CMD */ @@ -164,11 +164,11 @@ }; &tps65219 { - bootph-pre-ram; + bootph-all; }; &sdhci1 { - bootph-pre-ram; + bootph-all; }; #ifdef CONFIG_TARGET_AM625_A53_EVM diff --git a/arch/arm/dts/k3-am625-r5-beagleplay.dts b/arch/arm/dts/k3-am625-r5-beagleplay.dts index 9c9d0570592..ac5461a32c0 100644 --- a/arch/arm/dts/k3-am625-r5-beagleplay.dts +++ b/arch/arm/dts/k3-am625-r5-beagleplay.dts @@ -31,7 +31,7 @@ ti,sci = <&dmsc>; ti,sci-proc-id = <32>; ti,sci-host-id = <10>; - bootph-pre-ram; + bootph-all; }; dm_tifs: dm-tifs { @@ -41,7 +41,7 @@ mbox-names = "rx", "tx"; mboxes= <&secure_proxy_main 22>, <&a
[PATCH] configs: iot2050: Disable CONFIG_CONSOLE_MUX
From: Jan Kiszka We only have serial as console option, and leaving this on turns on SYS_CONSOLE_IS_IN_ENV which is also not true for these devices, leaving an ugly In:No input devices available! Out: No output devices available! Err: No error devices available! behind. Signed-off-by: Jan Kiszka --- Fix for 2023.10. configs/iot2050_defconfig | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/configs/iot2050_defconfig b/configs/iot2050_defconfig index bc9ca16fac3..3f05f8c38d7 100644 --- a/configs/iot2050_defconfig +++ b/configs/iot2050_defconfig @@ -18,7 +18,6 @@ CONFIG_DM_GPIO=y CONFIG_SPL_DM_SPI=y CONFIG_DEFAULT_DEVICE_TREE="k3-am6528-iot2050-basic" CONFIG_SPL_TEXT_BASE=0x8008 -CONFIG_SYS_PROMPT="IOT2050> " CONFIG_OF_LIBFDT_OVERLAY=y CONFIG_DM_RESET=y CONFIG_SPL_SERIAL=y @@ -41,7 +40,6 @@ CONFIG_AUTOBOOT_FLUSH_STDIN=y CONFIG_AUTOBOOT_PROMPT="Hit SPACE to stop autoboot in %d seconds...\n" CONFIG_AUTOBOOT_STOP_STR=" " CONFIG_BOOTCOMMAND="run start_watchdog; run distro_bootcmd" -CONFIG_CONSOLE_MUX=y # CONFIG_DISPLAY_CPUINFO is not set CONFIG_SPL_MAX_SIZE=0x58000 CONFIG_SPL_HAS_BSS_LINKER_SECTION=y @@ -62,6 +60,7 @@ CONFIG_SPL_POWER_DOMAIN=y CONFIG_SPL_SPI_FLASH_SFDP_SUPPORT=y CONFIG_SPL_SPI_LOAD=y CONFIG_SYS_SPI_U_BOOT_OFFS=0x38 +CONFIG_SYS_PROMPT="IOT2050> " CONFIG_SYS_MAXARGS=64 CONFIG_SYS_PBSIZE=1050 CONFIG_CMD_ASKENV=y -- 2.35.3
[PATCH] tools: iot2050-sign-fw.sh: Make localization of tools dir more robust
From: Jan Kiszka When building in-tree, there is no source link. Signed-off-by: Jan Kiszka --- tools/iot2050-sign-fw.sh | 10 ++ 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/tools/iot2050-sign-fw.sh b/tools/iot2050-sign-fw.sh index 6b426c854c2..75ffd560823 100755 --- a/tools/iot2050-sign-fw.sh +++ b/tools/iot2050-sign-fw.sh @@ -5,6 +5,8 @@ if [ -z "$1" ]; then exit 1 fi +TOOLS_DIR=$(dirname $0) + TEMP_X509=$(mktemp .temp) REVISION=${2:-0} @@ -39,10 +41,10 @@ CERT_X509=$(mktemp .crt) openssl req -new -x509 -key $1 -nodes -outform DER -out $CERT_X509 -config $TEMP_X509 -sha512 cat $CERT_X509 tispl.bin > tispl.bin_signed -source/tools/binman/binman replace -i flash-pg1.bin -f tispl.bin_signed fit@18 -source/tools/binman/binman replace -i flash-pg2.bin -f tispl.bin_signed fit@18 +$TOOLS_DIR/binman/binman replace -i flash-pg1.bin -f tispl.bin_signed fit@18 +$TOOLS_DIR/binman/binman replace -i flash-pg2.bin -f tispl.bin_signed fit@18 rm $TEMP_X509 $CERT_X509 -source/tools/binman/binman sign -i flash-pg1.bin -k $1 -a sha256,rsa4096 fit@38 -source/tools/binman/binman sign -i flash-pg2.bin -k $1 -a sha256,rsa4096 fit@38 +$TOOLS_DIR/binman/binman sign -i flash-pg1.bin -k $1 -a sha256,rsa4096 fit@38 +$TOOLS_DIR/binman/binman sign -i flash-pg2.bin -k $1 -a sha256,rsa4096 fit@38 -- 2.35.3
Re: [PATCH 2/5] iot2050: rename overlay sources to .dtso
On 25.09.23 10:09, Rasmus Villemoes wrote: > Distinguish more clearly between source files meant for producing .dtb > from those meant for producing .dtbo. No functional change, as we > currently have rules for producing a foo.dtbo from either foo.dts or > foo.dtso. > > Note that in the linux tree, all device tree overlay sources have been > renamed to .dtso, and the .dts->.dtbo rule is gone since v6.5 (commit > 81d362732bac). So this is also a step towards staying closer to linux > with respect to both Kbuild and device tree sources. > > Signed-off-by: Rasmus Villemoes > --- > ... => k3-am6548-iot2050-advanced-m2-bkey-ekey-pcie-overlay.dtso} | 0 > ...y.dts => k3-am6548-iot2050-advanced-m2-bkey-usb3-overlay.dtso} | 0 > 2 files changed, 0 insertions(+), 0 deletions(-) > rename > arch/arm/dts/{k3-am6548-iot2050-advanced-m2-bkey-ekey-pcie-overlay.dts => > k3-am6548-iot2050-advanced-m2-bkey-ekey-pcie-overlay.dtso} (100%) > rename arch/arm/dts/{k3-am6548-iot2050-advanced-m2-bkey-usb3-overlay.dts => > k3-am6548-iot2050-advanced-m2-bkey-usb3-overlay.dtso} (100%) > > diff --git > a/arch/arm/dts/k3-am6548-iot2050-advanced-m2-bkey-ekey-pcie-overlay.dts > b/arch/arm/dts/k3-am6548-iot2050-advanced-m2-bkey-ekey-pcie-overlay.dtso > similarity index 100% > rename from > arch/arm/dts/k3-am6548-iot2050-advanced-m2-bkey-ekey-pcie-overlay.dts > rename to > arch/arm/dts/k3-am6548-iot2050-advanced-m2-bkey-ekey-pcie-overlay.dtso > diff --git a/arch/arm/dts/k3-am6548-iot2050-advanced-m2-bkey-usb3-overlay.dts > b/arch/arm/dts/k3-am6548-iot2050-advanced-m2-bkey-usb3-overlay.dtso > similarity index 100% > rename from arch/arm/dts/k3-am6548-iot2050-advanced-m2-bkey-usb3-overlay.dts > rename to arch/arm/dts/k3-am6548-iot2050-advanced-m2-bkey-usb3-overlay.dtso Reviewed-by: Jan Kiszka Jan -- Siemens AG, Technology Linux Expert Center
[PATCH] board: ti: am62x: beagleplay: Disable semi-functional PSCI reset support
From: Jan Kiszka At this point, system shutdown is not supported by the DM firmware that TF-A calls. As we can't de-select only this feature, declare complete PSCI reset support as non-functional so that we don't signal incomplete support to the OS via EFI runtime services. This makes power-off under Linux work again when booting via EFI. Signed-off-by: Jan Kiszka --- board/ti/am62x/beagleplay_a53.config | 2 ++ 1 file changed, 2 insertions(+) diff --git a/board/ti/am62x/beagleplay_a53.config b/board/ti/am62x/beagleplay_a53.config index 967f794446d..8b0f671bc9e 100644 --- a/board/ti/am62x/beagleplay_a53.config +++ b/board/ti/am62x/beagleplay_a53.config @@ -53,3 +53,5 @@ CONFIG_SPI=n CONFIG_SPI_FLASH=n CONFIG_SPL_DM_SPI_FLASH=n CONFIG_SPL_SPI_FLASH_SUPPORT=n +# DM firmware lacks support for shutdown +# CONFIG_PSCI_RESET is not set -- 2.35.3
Re: [PATCH 2/2] configs: Make TI_SECURE_DEVICE default for K3
On 03.08.23 16:54, Andrew Davis wrote: > All K3 boards now are secure by default, instead of setting this in each > defconfig, make it implied by the ARCH config. > > The only exception is IOT2050, which I do not believe will have any > problems with being a TI_SECURE_DEVICE, but for now turn it off to keep > its config the same. The IOT2050 firmware is not using TI_SECURE_DEVICE because it serves non-HS devices by default as well. Secure boot on HS devices can be enabled by applying an extra config fragment like [1]. So it's indeed better to keep this off for the IO2050 to avoid untested side effects. E.g., we would probably lose legacy image booting in non-secure mode. Jan [1] https://github.com/siemens/meta-iot2050/blob/master/recipes-bsp/u-boot/files/secure-boot.cfg > > Signed-off-by: Andrew Davis > --- > arch/arm/Kconfig | 1 + > configs/am62ax_evm_a53_defconfig | 1 - > configs/am62ax_evm_r5_defconfig | 1 - > configs/am62x_evm_a53_defconfig | 1 - > configs/am62x_evm_r5_defconfig | 1 - > configs/am64x_evm_a53_defconfig | 1 - > configs/am64x_evm_r5_defconfig | 1 - > configs/iot2050_defconfig| 1 + > configs/j7200_evm_a72_defconfig | 1 - > configs/j7200_evm_r5_defconfig | 1 - > configs/j721e_evm_a72_defconfig | 1 - > configs/j721e_evm_r5_defconfig | 1 - > configs/j721s2_evm_a72_defconfig | 1 - > configs/j721s2_evm_r5_defconfig | 1 - > 14 files changed, 2 insertions(+), 12 deletions(-) > > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig > index 97c25b4f146..8ad6c5582ce 100644 > --- a/arch/arm/Kconfig > +++ b/arch/arm/Kconfig > @@ -787,6 +787,7 @@ config ARCH_K3 > select FIT > select REGEX > select FIT_SIGNATURE if ARM64 > + imply TI_SECURE_DEVICE > > config ARCH_OMAP2PLUS > bool "TI OMAP2+" > diff --git a/configs/am62ax_evm_a53_defconfig > b/configs/am62ax_evm_a53_defconfig > index 773cf3a591c..d0a34c75505 100644 > --- a/configs/am62ax_evm_a53_defconfig > +++ b/configs/am62ax_evm_a53_defconfig > @@ -1,6 +1,5 @@ > CONFIG_ARM=y > CONFIG_ARCH_K3=y > -CONFIG_TI_SECURE_DEVICE=y > CONFIG_SYS_MALLOC_F_LEN=0x8000 > CONFIG_SPL_LIBCOMMON_SUPPORT=y > CONFIG_SPL_LIBGENERIC_SUPPORT=y > diff --git a/configs/am62ax_evm_r5_defconfig b/configs/am62ax_evm_r5_defconfig > index 05c30cbba19..2c1110d227f 100644 > --- a/configs/am62ax_evm_r5_defconfig > +++ b/configs/am62ax_evm_r5_defconfig > @@ -1,6 +1,5 @@ > CONFIG_ARM=y > CONFIG_ARCH_K3=y > -CONFIG_TI_SECURE_DEVICE=y > CONFIG_SYS_MALLOC_F_LEN=0x9000 > CONFIG_SPL_LIBCOMMON_SUPPORT=y > CONFIG_SPL_LIBGENERIC_SUPPORT=y > diff --git a/configs/am62x_evm_a53_defconfig b/configs/am62x_evm_a53_defconfig > index d55caabe22c..1d05cecbcde 100644 > --- a/configs/am62x_evm_a53_defconfig > +++ b/configs/am62x_evm_a53_defconfig > @@ -1,6 +1,5 @@ > CONFIG_ARM=y > CONFIG_ARCH_K3=y > -CONFIG_TI_SECURE_DEVICE=y > CONFIG_SYS_MALLOC_F_LEN=0x8000 > CONFIG_SPL_LIBCOMMON_SUPPORT=y > CONFIG_SPL_LIBGENERIC_SUPPORT=y > diff --git a/configs/am62x_evm_r5_defconfig b/configs/am62x_evm_r5_defconfig > index 3c5f3672984..9dd2930dc89 100644 > --- a/configs/am62x_evm_r5_defconfig > +++ b/configs/am62x_evm_r5_defconfig > @@ -1,6 +1,5 @@ > CONFIG_ARM=y > CONFIG_ARCH_K3=y > -CONFIG_TI_SECURE_DEVICE=y > CONFIG_SYS_MALLOC_LEN=0x0800 > CONFIG_SYS_MALLOC_F_LEN=0x9000 > CONFIG_SPL_LIBCOMMON_SUPPORT=y > diff --git a/configs/am64x_evm_a53_defconfig b/configs/am64x_evm_a53_defconfig > index 9bdb767f9e6..d1d46c61075 100644 > --- a/configs/am64x_evm_a53_defconfig > +++ b/configs/am64x_evm_a53_defconfig > @@ -1,7 +1,6 @@ > CONFIG_ARM=y > CONFIG_SKIP_LOWLEVEL_INIT=y > CONFIG_ARCH_K3=y > -CONFIG_TI_SECURE_DEVICE=y > CONFIG_SYS_MALLOC_LEN=0x200 > CONFIG_SYS_MALLOC_F_LEN=0x8000 > CONFIG_SPL_GPIO=y > diff --git a/configs/am64x_evm_r5_defconfig b/configs/am64x_evm_r5_defconfig > index 45d32658cff..96cb437b10b 100644 > --- a/configs/am64x_evm_r5_defconfig > +++ b/configs/am64x_evm_r5_defconfig > @@ -1,6 +1,5 @@ > CONFIG_ARM=y > CONFIG_ARCH_K3=y > -CONFIG_TI_SECURE_DEVICE=y > CONFIG_SYS_MALLOC_LEN=0x200 > CONFIG_SYS_MALLOC_F_LEN=0x8 > CONFIG_SPL_GPIO=y > diff --git a/configs/iot2050_defconfig b/configs/iot2050_defconfig > index bcbaa92ee89..ad9217ff86a 100644 > --- a/configs/iot2050_defconfig > +++ b/configs/iot2050_defconfig > @@ -1,6 +1,7 @@ > CONFIG_ARM=y > CONFIG_SKIP_LOWLEVEL_INIT=y > CONFIG_ARCH_K3=y > +# CONFIG_TI_SECURE_DEVICE is not set > CONFIG_SYS_MALLOC_LEN=0x200 > CONFIG_SYS_MALLOC_F_LEN=0x8000 > CONFIG_SPL_GPIO=y > diff --git a/configs/j7200_evm_a72_defconfig b/configs/j7200_evm_a72_defconfig > index c68d52537e5..a9f5d36ffe3 100644 > --- a/configs/j7200_evm_a72_defconfig > +++ b/configs/j7200_evm_a72_defconfig > @@ -1,6 +1,5 @@ > CONFIG_ARM=y > CONFIG_ARCH_K3=y > -CONFIG_TI_SECURE_DEVICE=y > CONFIG_SYS_MALLOC_LEN=0x200 > CONFIG_SYS_MALLOC_F_LEN=0x8000 > CONFIG_SPL_GPIO=y > diff --git a/configs/j7200_evm_r5_defconfig b/configs/j7200_evm_r5_defconfig > index c4dd3
[PATCH 5/5] configs: iot2050: Enabled keyed autoboot
From: Jan Kiszka Only accept SPACE to stop autobooting. This is safer to avoid accidental interruptions on unattended devices. Signed-off-by: Jan Kiszka --- configs/iot2050_defconfig | 4 1 file changed, 4 insertions(+) diff --git a/configs/iot2050_defconfig b/configs/iot2050_defconfig index b5a50d4fa4a..bcbaa92ee89 100644 --- a/configs/iot2050_defconfig +++ b/configs/iot2050_defconfig @@ -36,6 +36,10 @@ CONFIG_DISTRO_DEFAULTS=y CONFIG_BOOTSTAGE=y CONFIG_SHOW_BOOT_PROGRESS=y CONFIG_SPL_SHOW_BOOT_PROGRESS=y +CONFIG_AUTOBOOT_KEYED=y +CONFIG_AUTOBOOT_FLUSH_STDIN=y +CONFIG_AUTOBOOT_PROMPT="Hit SPACE to stop autoboot in %d seconds...\n" +CONFIG_AUTOBOOT_STOP_STR=" " CONFIG_BOOTCOMMAND="run start_watchdog; run distro_bootcmd" CONFIG_CONSOLE_MUX=y # CONFIG_DISPLAY_CPUINFO is not set -- 2.35.3
[PATCH 3/5] boards: siemens: iot2050: Unify PG1 and PG2/M.2 configurations again
From: Jan Kiszka This avoids having to maintain to defconfigs that are 99% equivalent. The approach is to use binman to generate two flash images, flash-pg1.bin and flash-pg2.bin. With the help of a template dtsi, we can avoid duplicating the common binman image definitions. Suggested-by: Andrew Davis Signed-off-by: Jan Kiszka --- CC: Andrew Davis --- arch/arm/dts/k3-am65-iot2050-boot-image.dtsi | 155 +++--- board/siemens/iot2050/Kconfig | 30 +--- board/siemens/iot2050/MAINTAINERS | 3 +- board/siemens/iot2050/board.c | 25 ++- ...ot2050_pg1_defconfig => iot2050_defconfig} | 3 +- configs/iot2050_pg2_defconfig | 151 - doc/board/siemens/iot2050.rst | 27 ++- tools/iot2050-sign-fw.sh | 6 +- 8 files changed, 138 insertions(+), 262 deletions(-) rename configs/{iot2050_pg1_defconfig => iot2050_defconfig} (97%) delete mode 100644 configs/iot2050_pg2_defconfig diff --git a/arch/arm/dts/k3-am65-iot2050-boot-image.dtsi b/arch/arm/dts/k3-am65-iot2050-boot-image.dtsi index 7bfa4eebb90..3ecb461b011 100644 --- a/arch/arm/dts/k3-am65-iot2050-boot-image.dtsi +++ b/arch/arm/dts/k3-am65-iot2050-boot-image.dtsi @@ -1,6 +1,6 @@ // SPDX-License-Identifier: GPL-2.0 /* - * Copyright (c) Siemens AG, 2020-2022 + * Copyright (c) Siemens AG, 2020-2023 * * Authors: * Jan Kiszka @@ -10,23 +10,23 @@ #include / { - binman { - filename = "flash.bin"; + binman: binman { + multiple-images; + }; +}; + +&binman { + common_part: template { pad-byte = <0xff>; size = <0x8c>; allow-repack; - blob-ext@0x00 { + blob-ext@0 { offset = <0x00>; -#ifdef CONFIG_TARGET_IOT2050_A53_PG1 - filename = "seboot_pg1.bin"; -#else - filename = "seboot_pg2.bin"; -#endif missing-msg = "iot2050-seboot"; }; - fit@0x18 { + fit@18 { offset = <0x18>; filename = "tispl.bin"; pad-byte = <0xff>; @@ -104,9 +104,8 @@ }; }; - fit@0x38 { + fit@38 { description = "U-Boot for IOT2050"; - fit,fdt-list = "of-list"; offset = <0x38>; images { u-boot { @@ -134,36 +133,6 @@ }; }; -#ifdef CONFIG_TARGET_IOT2050_A53_PG2 - bkey-usb3-overlay { - description = "M.2-bkey-usb3-overlay"; - type = "blob"; - load = <0x8210>; - arch = "arm64"; - compression = "none"; - blob-ext { - filename = "k3-am6548-iot2050-advanced-m2-bkey-usb3-overlay.dtbo"; - }; - hash { - algo = "sha256"; - }; - }; - - bkey-ekey-pcie-overlay { - description = "M.2-bkey-ekey-pcie-overlay"; - type = "blob"; - load = <0x8211>; - arch = "arm64"; - compression = "none"; - blob-ext { - filename = "k3-am6548-iot2050-advanced-m2-bkey-ekey-pcie-overlay.dtbo"; - }; - hash { - algo = "sha256"; - }; - }; -#endif - #ifdef CONFIG_WDT_K3_RTI_FW_FILE k3-rti-wdt-firmware { type = "firmware"; @@ -182,20 +151,10 @@ }; configurations { - default = "@config-DEFAULT-SEQ"; @config-SEQ {
[PATCH 0/5] iot2050: 2023.10-rc1 fixes and cleanups
[resent, now that the list is working again] Most of this comes late, but primarily as the required binman templating changes were awaited, and the lots of regressions hit this board. I really hope we can not only merge the minimally required patch 1 of this series. Jan CC: Andrew Davis CC: Manorit Chawdhry CC: Simon Glass Jan Kiszka (5): boards: siemens: iot2050: Fix boot configuration iot2050: Use binman in signing script boards: siemens: iot2050: Unify PG1 and PG2/M.2 configurations again doc: board: siemens: iot2050: Update build env vars configs: iot2050: Enabled keyed autoboot arch/arm/dts/k3-am65-iot2050-boot-image.dtsi | 155 +++--- board/siemens/iot2050/Kconfig | 30 +--- board/siemens/iot2050/MAINTAINERS | 3 +- board/siemens/iot2050/board.c | 25 ++- board/siemens/iot2050/iot2050.env | 2 + ...ot2050_pg1_defconfig => iot2050_defconfig} | 8 +- configs/iot2050_pg2_defconfig | 150 - doc/board/siemens/iot2050.rst | 31 ++-- include/configs/iot2050.h | 11 ++ tools/iot2050-sign-fw.sh | 11 +- 10 files changed, 158 insertions(+), 268 deletions(-) rename configs/{iot2050_pg1_defconfig => iot2050_defconfig} (94%) delete mode 100644 configs/iot2050_pg2_defconfig -- 2.35.3
[PATCH 4/5] doc: board: siemens: iot2050: Update build env vars
From: Jan Kiszka ATF is now called BL31, and OP-TEE since 3.21 suggests to use tee-raw.bin instead of (the still identical) tee-pager_v2.bin. Signed-off-by: Jan Kiszka --- doc/board/siemens/iot2050.rst | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/doc/board/siemens/iot2050.rst b/doc/board/siemens/iot2050.rst index 0df11a950a7..ee3c5c95846 100644 --- a/doc/board/siemens/iot2050.rst +++ b/doc/board/siemens/iot2050.rst @@ -66,8 +66,8 @@ U-Boot: .. code-block:: text - $ export ATF=/path/to/bl31.bin - $ export TEE=/path/to/tee-pager_v2.bin + $ export BL31=/path/to/bl31.bin + $ export TEE=/path/to/tee-raw.bin $ make iot2050_defconfig $ make -- 2.35.3
[PATCH 2/5] iot2050: Use binman in signing script
From: Jan Kiszka The underlying issue was fixed in the meantime. Also signing the U-Boot proper fit image now works. Just supporting custom cert templates remains a todo. Signed-off-by: Jan Kiszka --- CC: Simon Glass --- tools/iot2050-sign-fw.sh | 9 ++--- 1 file changed, 2 insertions(+), 7 deletions(-) diff --git a/tools/iot2050-sign-fw.sh b/tools/iot2050-sign-fw.sh index 4d1d79498c2..3f953c09ed9 100755 --- a/tools/iot2050-sign-fw.sh +++ b/tools/iot2050-sign-fw.sh @@ -39,13 +39,8 @@ CERT_X509=$(mktemp .crt) openssl req -new -x509 -key $1 -nodes -outform DER -out $CERT_X509 -config $TEMP_X509 -sha512 cat $CERT_X509 tispl.bin > tispl.bin_signed -# currently broken in upstream -#source/tools/binman/binman replace -i flash.bin -f tispl.bin_signed blob@0x18 -dd if=tispl.bin_signed of=flash.bin bs=$((0x1000)) seek=$((0x18/0x1000)) conv=notrunc +source/tools/binman/binman replace -i flash.bin -f tispl.bin_signed fit@0x18 rm $TEMP_X509 $CERT_X509 -tools/mkimage -G $1 -r -o sha256,rsa4096 -F f...@0x38.fit -# currently broken in upstream -#source/tools/binman/binman replace -i flash.bin -f f...@0x38.fit fit@0x38 -dd if=f...@0x38.fit of=flash.bin bs=$((0x1000)) seek=$((0x38/0x1000)) conv=notrunc +source/tools/binman/binman sign -i flash.bin -k $1 -a sha256,rsa4096 fit@0x38 -- 2.35.3
[PATCH 1/5] boards: siemens: iot2050: Fix boot configuration
From: Jan Kiszka The common env bits now come via ti_armv7_common.env, include it. Futhermore restore the board-specific boot targets and their ordering that is now enforced k3-wide differently. Finally, enable CONFIG_LEGACY_IMAGE_FORMAT explicitly which got lost while turning FIT_SIGNATURE on by default for k3 devices. Fixes: 53873974 ("include: armv7: Enable distroboot across all configs") Fixes: 4ae1a247 ("env: Make common bootcmd across all k3 devices") Fixes: 86fab110 ("Kconfig: Enable FIT_SIGNATURE if ARM64") Signed-off-by: Jan Kiszka --- CC: Manorit Chawdhry --- board/siemens/iot2050/iot2050.env | 2 ++ configs/iot2050_pg1_defconfig | 1 + configs/iot2050_pg2_defconfig | 1 + include/configs/iot2050.h | 11 +++ 4 files changed, 15 insertions(+) diff --git a/board/siemens/iot2050/iot2050.env b/board/siemens/iot2050/iot2050.env index 02958798b49..7fd836e6285 100644 --- a/board/siemens/iot2050/iot2050.env +++ b/board/siemens/iot2050/iot2050.env @@ -6,6 +6,8 @@ * Jan Kiszka */ +#include + usb_pgood_delay=900 watchdog_timeout_ms=CONFIG_WATCHDOG_TIMEOUT_MSECS diff --git a/configs/iot2050_pg1_defconfig b/configs/iot2050_pg1_defconfig index cc1b9673d79..391ab78d366 100644 --- a/configs/iot2050_pg1_defconfig +++ b/configs/iot2050_pg1_defconfig @@ -29,6 +29,7 @@ CONFIG_SPL_SPI=y CONFIG_PCI=y # CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set CONFIG_SPL_LOAD_FIT=y +CONFIG_LEGACY_IMAGE_FORMAT=y CONFIG_OF_BOARD_SETUP=y CONFIG_OF_SYSTEM_SETUP=y CONFIG_DISTRO_DEFAULTS=y diff --git a/configs/iot2050_pg2_defconfig b/configs/iot2050_pg2_defconfig index c5741a4dae4..19c440732aa 100644 --- a/configs/iot2050_pg2_defconfig +++ b/configs/iot2050_pg2_defconfig @@ -29,6 +29,7 @@ CONFIG_SPL_SPI=y CONFIG_PCI=y # CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set CONFIG_SPL_LOAD_FIT=y +CONFIG_LEGACY_IMAGE_FORMAT=y CONFIG_OF_BOARD_SETUP=y CONFIG_OF_SYSTEM_SETUP=y CONFIG_DISTRO_DEFAULTS=y diff --git a/include/configs/iot2050.h b/include/configs/iot2050.h index 2177e0dfe38..4968722d18f 100644 --- a/include/configs/iot2050.h +++ b/include/configs/iot2050.h @@ -15,6 +15,17 @@ #include +/* + * This defines all MMC devices, even if the basic variant has no mmc1. + * The non-supported device will be removed from the boot targets during + * runtime, when that board was detected. + */ +#undef BOOT_TARGET_DEVICES +#define BOOT_TARGET_DEVICES(func) \ + func(MMC, mmc, 1) \ + func(MMC, mmc, 0) \ + BOOT_TARGET_USB(func) + #ifdef CONFIG_ENV_WRITEABLE_LIST #define CFG_ENV_FLAGS_LIST_STATIC \ "board_uuid:sw,board_name:sw,board_serial:sw,board_a5e:sw," \ -- 2.35.3
Re: [PATCH 00/18] K3 HS Support along with fixes
On 26.07.23 09:25, Manorit Chawdhry wrote: > On 12:17-20230726, Manorit Chawdhry wrote: >> Hi Jan, >> >> On 08:42-20230726, Jan Kiszka wrote: >>> On 14.07.23 07:52, Manorit Chawdhry wrote: >>>> The series focuses on fixes for various boards along with moving to >>>> standards and enabling the FIT_SIGNATURE for K3 Platforms towards the >>>> end. >>>> >>>> Dependencies: >>>> https://lore.kernel.org/u-boot/20230712183453.7623-1-n-fran...@ti.com/ >>>> >>>> Signed-off-by: Manorit Chawdhry >>>> --- >>>> Andrew Davis (4): >>>> environment: ti: Prefix ARM64 DTB names with directory >>>> environment: ti: Make get_fdt_mmc common >>>> configs: Enable setexpr command on TI devices >>>> arm: k3: Add regex/gsub command handling >>>> >>>> Kamlesh Gurudasani (3): >>>> board: ti: am64x: am64x.env: set fdtfile env variable >>>> configs: k3: make consistent bootcmd across all k3 socs >>>> configs: am64: Fix booting of fitImage on AM64x >>>> >>>> Manorit Chawdhry (11): >>>> arch: mach-k3: security: fix the check for authentication >>>> Kconfig: j721s2: Fix the scratchpad base >>>> mach-k3: common: correct the calculations for determining firewalls >>>> include: j7*_evm.h: Cleanups to be done >>>> configs: k3: Remove saved environments >>>> env: Make common bootcmd across all k3 devices >>>> include: armv7: Enable distroboot across all configs >>>> board: ti: keys: add .key and .crt for fit signature signing >>>> k3-*-binman: dts: Pack u-boot.dtb instead of soc specific dtb >>>> lib: Kconfig: k3: Enable SHA512 for fit signature >>>> Kconfig: Enable FIT_SIGNATURE if ARM64 >>>> >>>> arch/arm/Kconfig | 2 + >>>> arch/arm/dts/k3-am625-sk-binman.dtsi | 2 +- >>>> arch/arm/dts/k3-am62a-sk-binman.dtsi | 2 +- >>>> arch/arm/dts/k3-am64x-binman.dtsi | 2 +- >>>> arch/arm/dts/k3-am65x-binman.dtsi | 2 +- >>>> arch/arm/dts/k3-j7200-binman.dtsi | 2 +- >>>> arch/arm/dts/k3-j721e-binman.dtsi | 2 +- >>>> arch/arm/dts/k3-j721s2-binman.dtsi | 2 +- >>>> arch/arm/mach-k3/Kconfig | 2 +- >>>> arch/arm/mach-k3/common.c | 3 +- >>>> arch/arm/mach-k3/common.h | 2 +- >>>> arch/arm/mach-k3/security.c| 5 +- >>>> board/ti/am62ax/am62ax.env | 3 +- >>>> board/ti/am62x/am62x.env | 3 +- >>>> board/ti/am64x/am64x.env | 6 +- >>>> board/ti/am65x/am65x.env | 3 +- >>>> board/ti/j721e/j721e.env | 9 +- >>>> board/ti/j721s2/j721s2.env | 7 +- >>>> board/ti/keys/custMpk.crt | 33 ++ >>>> board/ti/keys/custMpk.key | 51 + >>>> boot/Kconfig | 3 +- >>>> configs/am335x_hs_evm_defconfig| 1 - >>>> configs/am43xx_hs_evm_defconfig| 1 - >>>> configs/am43xx_hs_evm_qspi_defconfig | 1 - >>>> configs/am57xx_hs_evm_defconfig| 1 - >>>> configs/am57xx_hs_evm_usb_defconfig| 1 - >>>> configs/am62ax_evm_a53_defconfig | 1 + >>>> configs/am62x_evm_a53_defconfig| 3 +- >>>> configs/am64x_evm_a53_defconfig| 7 +- >>>> configs/am65x_evm_a53_defconfig| 1 - >>>> configs/am65x_hs_evm_a53_defconfig | 1 - >>>> configs/j7200_evm_a72_defconfig| 7 +- >>>> configs/j721e_evm_a72_defconfig| 7 +- >>>> configs/j721s2_evm_a72_defconfig | 6 +- >>>> doc/board/ti/k3.rst| 172 >>>> + >>>> include/configs/am62ax_evm.h | 71 >>>> include/configs/am62x_evm.h| 27 - >>>> include/configs/j721e_evm.h| 32 -- >>>> include/configs/j721s2_evm.h | 5 - >>>> include/configs/ti_armv7_common.h | 50 + >>&
Re: [PATCH 00/18] K3 HS Support along with fixes
On 14.07.23 07:52, Manorit Chawdhry wrote: > The series focuses on fixes for various boards along with moving to > standards and enabling the FIT_SIGNATURE for K3 Platforms towards the > end. > > Dependencies: > https://lore.kernel.org/u-boot/20230712183453.7623-1-n-fran...@ti.com/ > > Signed-off-by: Manorit Chawdhry > --- > Andrew Davis (4): > environment: ti: Prefix ARM64 DTB names with directory > environment: ti: Make get_fdt_mmc common > configs: Enable setexpr command on TI devices > arm: k3: Add regex/gsub command handling > > Kamlesh Gurudasani (3): > board: ti: am64x: am64x.env: set fdtfile env variable > configs: k3: make consistent bootcmd across all k3 socs > configs: am64: Fix booting of fitImage on AM64x > > Manorit Chawdhry (11): > arch: mach-k3: security: fix the check for authentication > Kconfig: j721s2: Fix the scratchpad base > mach-k3: common: correct the calculations for determining firewalls > include: j7*_evm.h: Cleanups to be done > configs: k3: Remove saved environments > env: Make common bootcmd across all k3 devices > include: armv7: Enable distroboot across all configs > board: ti: keys: add .key and .crt for fit signature signing > k3-*-binman: dts: Pack u-boot.dtb instead of soc specific dtb > lib: Kconfig: k3: Enable SHA512 for fit signature > Kconfig: Enable FIT_SIGNATURE if ARM64 > > arch/arm/Kconfig | 2 + > arch/arm/dts/k3-am625-sk-binman.dtsi | 2 +- > arch/arm/dts/k3-am62a-sk-binman.dtsi | 2 +- > arch/arm/dts/k3-am64x-binman.dtsi | 2 +- > arch/arm/dts/k3-am65x-binman.dtsi | 2 +- > arch/arm/dts/k3-j7200-binman.dtsi | 2 +- > arch/arm/dts/k3-j721e-binman.dtsi | 2 +- > arch/arm/dts/k3-j721s2-binman.dtsi | 2 +- > arch/arm/mach-k3/Kconfig | 2 +- > arch/arm/mach-k3/common.c | 3 +- > arch/arm/mach-k3/common.h | 2 +- > arch/arm/mach-k3/security.c| 5 +- > board/ti/am62ax/am62ax.env | 3 +- > board/ti/am62x/am62x.env | 3 +- > board/ti/am64x/am64x.env | 6 +- > board/ti/am65x/am65x.env | 3 +- > board/ti/j721e/j721e.env | 9 +- > board/ti/j721s2/j721s2.env | 7 +- > board/ti/keys/custMpk.crt | 33 ++ > board/ti/keys/custMpk.key | 51 + > boot/Kconfig | 3 +- > configs/am335x_hs_evm_defconfig| 1 - > configs/am43xx_hs_evm_defconfig| 1 - > configs/am43xx_hs_evm_qspi_defconfig | 1 - > configs/am57xx_hs_evm_defconfig| 1 - > configs/am57xx_hs_evm_usb_defconfig| 1 - > configs/am62ax_evm_a53_defconfig | 1 + > configs/am62x_evm_a53_defconfig| 3 +- > configs/am64x_evm_a53_defconfig| 7 +- > configs/am65x_evm_a53_defconfig| 1 - > configs/am65x_hs_evm_a53_defconfig | 1 - > configs/j7200_evm_a72_defconfig| 7 +- > configs/j721e_evm_a72_defconfig| 7 +- > configs/j721s2_evm_a72_defconfig | 6 +- > doc/board/ti/k3.rst| 172 > + > include/configs/am62ax_evm.h | 71 > include/configs/am62x_evm.h| 27 - > include/configs/j721e_evm.h| 32 -- > include/configs/j721s2_evm.h | 5 - > include/configs/ti_armv7_common.h | 50 + > include/environment/ti/mmc.env | 5 +- > include/environment/ti/ti_armv7_common.env | 11 +- > lib/Kconfig| 1 + > 43 files changed, 356 insertions(+), 202 deletions(-) > --- > base-commit: 26bd02c45a97f77cfb6afac4ee4f61fb9c5c7007 > change-id: 20230713-b4-upstream-fit-image-support-9d3c113ebab7 > > Best regards, This series (at least) completely broke IOT2050 booting, specifically by dictating EVM-specific settings on our non-EVM board. Still trying to understand all problems and how to resolve them, either on board level or via making the side-effects optional. Due to that, our own patches missed rc1 :(. Jan -- Siemens AG, Technology Linux Expert Center
Re: [PATCH 2/5] MAINTAINERS: Add some missing defconfig files to existing entries
On 18.07.23 18:20, Tom Rini wrote: > We have a few places where defconfigs were added (or renamed) and not > included in their previously listed MAINTAINERS entry, correct this. > > Signed-off-by: Tom Rini > --- > Cc: Adam Ford > Cc: Chris Packham > Cc: Jan Kiszka > Cc: Neil Armstrong > Cc: Stefan Roese > --- > board/Marvell/db-88f6820-amc/MAINTAINERS | 1 + > board/amlogic/w400/MAINTAINERS | 1 + > board/beacon/imx8mm/MAINTAINERS | 1 + > board/beacon/imx8mn/MAINTAINERS | 1 + > board/siemens/iot2050/MAINTAINERS| 3 ++- > board/solidrun/clearfog/MAINTAINERS | 2 ++ > 6 files changed, 8 insertions(+), 1 deletion(-) > > diff --git a/board/Marvell/db-88f6820-amc/MAINTAINERS > b/board/Marvell/db-88f6820-amc/MAINTAINERS > index abf5b7efdc93..d519eb47b84c 100644 > --- a/board/Marvell/db-88f6820-amc/MAINTAINERS > +++ b/board/Marvell/db-88f6820-amc/MAINTAINERS > @@ -4,3 +4,4 @@ S:Maintained > F: board/Marvell/db-88f6820-amc/ > F: include/configs/db-88f6820-amc.h > F: configs/db-88f6820-amc_defconfig > +F: configs/db-88f6820-amc_nand_defconfig > diff --git a/board/amlogic/w400/MAINTAINERS b/board/amlogic/w400/MAINTAINERS > index 117f79ea047b..19b1f30e6213 100644 > --- a/board/amlogic/w400/MAINTAINERS > +++ b/board/amlogic/w400/MAINTAINERS > @@ -5,6 +5,7 @@ L:u-boot-amlo...@groups.io > F: board/amlogic/w400/ > F: configs/bananapi-cm4-cm4io_defconfig > F: configs/bananapi-m2s_defconfig > +F: configs/odroid-n2l_defconfig > F: configs/radxa-zero2_defconfig > F: doc/board/amlogic/w400.rst > F: doc/board/amlogic/bananapi-cm4io.rst > diff --git a/board/beacon/imx8mm/MAINTAINERS b/board/beacon/imx8mm/MAINTAINERS > index d48ba8605bba..d8a5d0973694 100644 > --- a/board/beacon/imx8mm/MAINTAINERS > +++ b/board/beacon/imx8mm/MAINTAINERS > @@ -5,4 +5,5 @@ S:Maintained > F: board/beacon/imx8mm/ > F: include/configs/imx8mm_beacon.h > F: configs/imx8mm_beacon_defconfig > +F: configs/imx8mm_beacon_fspi_defconfig > F: doc/board/beacon/ > diff --git a/board/beacon/imx8mn/MAINTAINERS b/board/beacon/imx8mn/MAINTAINERS > index 4805cb255cc0..6dcef21a65e9 100644 > --- a/board/beacon/imx8mn/MAINTAINERS > +++ b/board/beacon/imx8mn/MAINTAINERS > @@ -5,3 +5,4 @@ F:board/beacon/imx8mn/ > F: include/configs/imx8mn_beacon.h > F: configs/imx8mn_beacon_defconfig > F: configs/imx8mn_beacon_2g_defconfig > +F: configs/imx8mn_beacon_fspi_defconfig > diff --git a/board/siemens/iot2050/MAINTAINERS > b/board/siemens/iot2050/MAINTAINERS > index 1b525356c2d6..aa21de2099f7 100644 > --- a/board/siemens/iot2050/MAINTAINERS > +++ b/board/siemens/iot2050/MAINTAINERS > @@ -4,6 +4,7 @@ M:Jan Kiszka > S: Maintained > F: board/siemens/iot2050/ > F: include/configs/iot2050.h > -F: configs/iot2050_defconfig > +F: configs/iot2050_pg1_defconfig > +F: configs/iot2050_pg2_defconfig Hehe, I'm sitting on patches to revert that again, but I don't object to fix this first to the current reality. Jan > F: arch/arm/dts/iot2050-* > F: doc/board/siemens/iot2050.rst > diff --git a/board/solidrun/clearfog/MAINTAINERS > b/board/solidrun/clearfog/MAINTAINERS > index 6646d96206bf..55bd1278049a 100644 > --- a/board/solidrun/clearfog/MAINTAINERS > +++ b/board/solidrun/clearfog/MAINTAINERS > @@ -5,3 +5,5 @@ F:board/soldrun/clearfog/ > F: include/configs/clearfog.h > F: configs/clearfog_defconfig > F: configs/clearfog_gt_8k_defconfig > +F: configs/clearfog_sata_defconfig > +F: configs/clearfog_spi_defconfig -- Siemens AG, Technology Competence Center Embedded Linux
Re: [PATCH v6 18/23] arm: k3-am65x-iot2050: Use binman for tispl.bin for iot2050
On 12.07.23 20:34, Neha Malcom Francis wrote: > Move to using binman to generate tispl.bin which is used to generate the > final flash.bin bootloader for iot2050 boards. > > Signed-off-by: Neha Malcom Francis > Cc: Jan Kiszka > Reviewed-by: Simon Glass > --- > arch/arm/dts/k3-am65-iot2050-boot-image.dtsi | 76 +++- > 1 file changed, 74 insertions(+), 2 deletions(-) > > diff --git a/arch/arm/dts/k3-am65-iot2050-boot-image.dtsi > b/arch/arm/dts/k3-am65-iot2050-boot-image.dtsi > index 03ccc54329..9d83898d33 100644 > --- a/arch/arm/dts/k3-am65-iot2050-boot-image.dtsi > +++ b/arch/arm/dts/k3-am65-iot2050-boot-image.dtsi > @@ -26,9 +26,81 @@ > missing-msg = "iot2050-seboot"; > }; > > - blob@0x18 { > + fit@0x18 { > offset = <0x18>; > - filename = "tispl.bin"; > + pad-byte = <0xff>; > + description = "Configuration to load ATF and SPL"; > + > + images { > + atf { > + description = "ARM Trusted Firmware"; > + type = "firmware"; > + arch = "arm64"; > + compression = "none"; > + os = "arm-trusted-firmware"; > + load = ; > + entry = ; > + atf: atf-bl31 { > + }; > + }; > + > + tee { > + description = "OPTEE"; > + type = "tee"; > + arch = "arm64"; > + compression = "none"; > + os = "tee"; > + load = <0x9e80>; > + entry = <0x9e80>; > + tee: tee-os { > + }; > + }; > + > + dm { > + description = "DM binary"; > + type = "firmware"; > + arch = "arm32"; > + compression = "none"; > + os = "DM"; > + load = <0x8900>; > + entry = <0x8900>; > + blob-ext { > + filename = "/dev/null"; > + }; > + }; > + > + spl { > + description = "SPL (64-bit)"; > + type = "standalone"; > + os = "U-Boot"; > + arch = "arm64"; > + compression = "none"; > + load = ; > + entry = ; > + u_boot_spl_nodtb: blob-ext { > + filename = > "spl/u-boot-spl-nodtb.bin"; > + }; > + }; > + > + fdt-0 { > + description = "k3-am65-iot2050-spl.dtb"; > + type = "flat_dt"; > + arch = "arm"; > + compression = "none"; > + spl_am65x_evm_dtb: blob-ext { > + filename = > "spl/dts/k3-am65-iot2050-spl.dtb"; > + }; > + }; > + }; > + > + configurations { > + default = "spl"; > + spl { > + fdt = "fdt-0"; > + firmware = "atf"; > + loadables = "tee", "dm", "spl"; > + }; > + }; > }; > > fit@0x38 { You forgot to update tools/iot2050-sign-fw.sh? Jan -- Siemens AG, Technology Competence Center Embedded Linux
Re: [PATCH v4 00/20] binman: Simple templating feature and mkimage conversion
On 11.07.23 16:59, Simon Glass wrote: > This series converts the mkimage entry type to be a section, i.e. based on > the entry_Section class. This makes it more consistent in its behaviour, > e.g. allowing symbol writing and expanded entries. > > A simple templating feature is also introduced, to reduce duplication > when a set of entries must be used in multiple images. > > In this version the nodes from the template are placed before any other > nodes, meaning that the template sets the node order. This seems more > consistent than other mechanisms. > > This series is available at u-boot-dm/mkim-working > > Changes in v4: > - Avoid copying phandle nodes > - Support copying over properties from each template node > - Make sure phandles are not copied > - Copy over properties from the top-level template node > - Add new patch to reduce state.SetInt and bintool cmd to debug level > > Changes in v3: > - Add new patch for elf to return number of written symbols > - Add new patch with more detail on how ObtainContents() works > - Fix up some tests which now need SPL and TPL > - Avoid calling ObtainContents() when not needed > - Fix 'specific' typo > - Add a new devicetree file especially for node copying > - Correct logic for merging nodes in order > - Tidy up some comments > - Adjust to use the new example file > - Drop duplicate dts-v1 header > - Add new test case for templating in a FIT > - Add new patch to support writing symbols inside a mkimage image > > Changes in v2: > - Drop now-unnecessary methods in mkimage etype > - Correct ordering of template nodes > - Fix 'preseverd' and 'inserter' typos > > Marek Vasut (1): > binman: Convert mkimage to Entry_section > > Simon Glass (19): > binman: Correct coverage gap in control > binman: Init align_default in entry_Section > binman: Use GetEntries() to obtain section contents > binman: Read _multiple_data_files in the correct place > binman: Allow disabling symbol writing > stm32mp15: Avoid writing symbols in SPL > binman: Update elf to return number of written symbols > binman: Add more detail on how ObtainContents() works > binman: Provide a way to specify the fdt-list directly > binman: Drop __bss_size variable in bss_data.c > binman: Correct handling of zero bss size > dtoc: Support copying the contents of a node into another > dtoc: Allow inserting a list of nodes into another > binman: Support simple templates > binman: Support templating with multiple images > binman: Add a test for templating in a FIT > binman: Support templates at any level > binman: Support writing symbols inside a mkimage image > binman: Reduce state.SetInt and bintool cmd to debug level > > arch/arm/dts/stm32mp15-u-boot.dtsi | 1 + > tools/binman/binman.rst| 94 + > tools/binman/bintool.py| 2 +- > tools/binman/control.py| 34 +++- > tools/binman/elf.py| 13 +- > tools/binman/elf_test.py | 13 +- > tools/binman/entries.rst | 6 + > tools/binman/entry.py | 11 +- > tools/binman/etype/blob_phase.py | 5 + > tools/binman/etype/fit.py | 9 + > tools/binman/etype/mkimage.py | 110 --- > tools/binman/etype/section.py | 54 +++-- > tools/binman/etype/u_boot_spl_bss_pad.py | 2 +- > tools/binman/etype/u_boot_tpl_bss_pad.py | 2 +- > tools/binman/etype/u_boot_vpl_bss_pad.py | 2 +- > tools/binman/ftest.py | 218 - > tools/binman/state.py | 4 +- > tools/binman/test/282_symbols_disable.dts | 25 +++ > tools/binman/test/283_mkimage_special.dts | 24 +++ > tools/binman/test/284_fit_fdt_list.dts | 58 ++ > tools/binman/test/285_spl_expand.dts | 13 ++ > tools/binman/test/286_template.dts | 42 > tools/binman/test/287_template_multi.dts | 27 +++ > tools/binman/test/288_template_fit.dts | 37 > tools/binman/test/289_template_section.dts | 52 + > tools/binman/test/290_mkimage_sym.dts | 27 +++ > tools/binman/test/Makefile | 5 +- > tools/binman/test/bss_data.c | 3 +- > tools/binman/test/bss_data_zero.c | 16 ++ > tools/binman/test/bss_data_zero.lds| 15 ++ > tools/binman/test/embed_data.lds | 1 + > tools/dtoc/fdt.py | 141 - > tools/dtoc/test/dtoc_test_copy.dts | 88 + > tools/dtoc/test_fdt.py | 113 +++ > 34 files changed, 1196 insertions(+), 71 deletions(-) > create mode 100644 tools/binman/test/282_symbols_disable.dts > create mode 100644 tools/binman/test/283_mkimage_special.dts > create mode 100644 tools/binman/test/284_fit_fdt_list.dts > create mode 100644 tools/binman/test/285_spl_expand.dts > create mode 100644 tools/binman/te
Re: [PATCH v5 18/23] arm: k3-am65x-iot2050: Use binman for tispl.bin for iot2050
On 10.07.23 09:50, Neha Malcom Francis wrote: > Hi Jan > > On 07/07/23 19:08, Jan Kiszka wrote: >> On 07.07.23 14:34, Neha Malcom Francis wrote: >>> Move to using binman to generate tispl.bin which is used to generate the >>> final flash.bin bootloader for iot2050 boards. >>> >>> Signed-off-by: Neha Malcom Francis >>> Cc: Jan Kiszka >>> --- >>> arch/arm/dts/k3-am65-iot2050-boot-image.dtsi | 76 +++- >>> 1 file changed, 74 insertions(+), 2 deletions(-) >>> >>> diff --git a/arch/arm/dts/k3-am65-iot2050-boot-image.dtsi >>> b/arch/arm/dts/k3-am65-iot2050-boot-image.dtsi >>> index 03ccc54329..9d83898d33 100644 >>> --- a/arch/arm/dts/k3-am65-iot2050-boot-image.dtsi >>> +++ b/arch/arm/dts/k3-am65-iot2050-boot-image.dtsi >>> @@ -26,9 +26,81 @@ >>> missing-msg = "iot2050-seboot"; >>> }; >>> - blob@0x18 { >>> + fit@0x18 { >>> offset = <0x18>; >>> - filename = "tispl.bin"; >>> + pad-byte = <0xff>; >>> + description = "Configuration to load ATF and SPL"; >>> + >>> + images { >>> + atf { >>> + description = "ARM Trusted Firmware"; >>> + type = "firmware"; >>> + arch = "arm64"; >>> + compression = "none"; >>> + os = "arm-trusted-firmware"; >>> + load = ; >>> + entry = ; >>> + atf: atf-bl31 { >>> + }; >>> + }; >>> + >>> + tee { >>> + description = "OPTEE"; >>> + type = "tee"; >>> + arch = "arm64"; >>> + compression = "none"; >>> + os = "tee"; >>> + load = <0x9e80>; >>> + entry = <0x9e80>; >>> + tee: tee-os { >>> + }; >>> + }; >>> + >>> + dm { >>> + description = "DM binary"; >>> + type = "firmware"; >>> + arch = "arm32"; >>> + compression = "none"; >>> + os = "DM"; >>> + load = <0x8900>; >>> + entry = <0x8900>; >>> + blob-ext { >>> + filename = "/dev/null"; >>> + }; >>> + }; >>> + >>> + spl { >>> + description = "SPL (64-bit)"; >>> + type = "standalone"; >>> + os = "U-Boot"; >>> + arch = "arm64"; >>> + compression = "none"; >>> + load = ; >>> + entry = ; >>> + u_boot_spl_nodtb: blob-ext { >>> + filename = "spl/u-boot-spl-nodtb.bin"; >>> + }; >>> + }; >>> + >>> + fdt-0 { >>> + description = "k3-am65-iot2050-spl.dtb"; >>> + type = "flat_dt"; >>> + arch = "arm"; >>> + compression = "none"; >>> + spl_am65x_evm_dtb: blob-ext { >>> + filename = "spl/dts/k3-am65-iot2050-spl.dtb"; >>> + }; >>> + }; >>> + }; >>> + >>> + configurations { >>> + default = "spl"; >>> + spl { >>> + fdt = "fdt-0"; >>> + firmware = "atf"; >>> + loadables = "tee", "dm", "spl"; >>> + }; >>> + }; >>> }; >>>
Re: [PATCH v5 12/23] j721s2: yaml: Add board configs for J721S2
On 07.07.23 14:34, Neha Malcom Francis wrote: > Added YAML configs for J721S2 > > Signed-off-by: Neha Malcom Francis > --- > board/ti/j721s2/board-cfg.yaml | 37 + > board/ti/j721s2/pm-cfg.yaml| 12 + > board/ti/j721s2/rm-cfg.yaml| 2901 > board/ti/j721s2/sec-cfg.yaml | 379 + > 4 files changed, 3329 insertions(+) > create mode 100644 board/ti/j721s2/board-cfg.yaml > create mode 100644 board/ti/j721s2/pm-cfg.yaml > create mode 100644 board/ti/j721s2/rm-cfg.yaml > create mode 100644 board/ti/j721s2/sec-cfg.yaml > > diff --git a/board/ti/j721s2/board-cfg.yaml b/board/ti/j721s2/board-cfg.yaml > new file mode 100644 > index 00..d80f308ca6 > --- /dev/null > +++ b/board/ti/j721s2/board-cfg.yaml > @@ -0,0 +1,37 @@ > +# SPDX-License-Identifier: GPL-2.0+ > +# Copyright (C) 2022 Texas Instruments Incorporated - https://www.ti.com/ > +# > +# Board configuration for J721S2 > +# > + > +--- > + > +board-cfg: > +rev: > +boardcfg_abi_maj : 0x0 > +boardcfg_abi_min : 0x1 > +control: > +subhdr: > +magic: 0xC1D3 > +size: 7 > +main_isolation_enable : 0x5A > +main_isolation_hostid : 0x2 > +secproxy: > +subhdr: > +magic: 0x1207 > +size: 7 > +scaling_factor : 0x1 > +scaling_profile : 0x1 > +disable_main_nav_secure_proxy : 0 > +msmc: > +subhdr: > +magic: 0xA5C3 > +size: 5 > +msmc_cache_size : 0x0 > +debug_cfg: > +subhdr: > +magic: 0x020C > +size: 8 > +trace_dst_enables : 0x00 > +trace_src_enables : 0x00 > + > diff --git a/board/ti/j721s2/pm-cfg.yaml b/board/ti/j721s2/pm-cfg.yaml > new file mode 100644 > index 00..45994e23cc > --- /dev/null > +++ b/board/ti/j721s2/pm-cfg.yaml > @@ -0,0 +1,12 @@ > +# SPDX-License-Identifier: GPL-2.0+ > +# Copyright (C) 2022 Texas Instruments Incorporated - https://www.ti.com/ > +# > +# Power management configuration for J721S2 > +# > + > +--- > + > +pm-cfg: > +rev: > +boardcfg_abi_maj : 0x0 > +boardcfg_abi_min : 0x1 > diff --git a/board/ti/j721s2/rm-cfg.yaml b/board/ti/j721s2/rm-cfg.yaml > new file mode 100644 > index 00..6058f3b35c > --- /dev/null > +++ b/board/ti/j721s2/rm-cfg.yaml > @@ -0,0 +1,2901 @@ > +# SPDX-License-Identifier: GPL-2.0+ > +# Copyright (C) 2022 Texas Instruments Incorporated - https://www.ti.com/ > +# > +# Resource management configuration for J721S2 > +# > + > +--- > + > +rm-cfg: > +rm_boardcfg: > +rev: > +boardcfg_abi_maj : 0x0 > +boardcfg_abi_min : 0x1 > +host_cfg: > +subhdr: > +magic: 0x4C41 > +size : 356 > +host_cfg_entries: > +- #1 > +host_id: 3 > +allowed_atype : 0x2A > +allowed_qos : 0x > +allowed_orderid : 0x > +allowed_priority : 0x > +allowed_sched_priority : 0xAA > +- #2 > +host_id: 5 > +allowed_atype : 0x2A > +allowed_qos : 0x > +allowed_orderid : 0x > +allowed_priority : 0x > +allowed_sched_priority : 0xAA > +- #3 > +host_id: 12 > +allowed_atype : 0x2A > +allowed_qos : 0x > +allowed_orderid : 0x > +allowed_priority : 0x > +allowed_sched_priority : 0xAA > +- #4 > +host_id: 13 > +allowed_atype : 0x2A > +allowed_qos : 0x > +allowed_orderid : 0x > +allowed_priority : 0x > +allowed_sched_priority : 0xAA > +- #5 > +host_id: 21 > +allowed_atype : 0x2A > +allowed_qos : 0x > +allowed_orderid : 0x > +allowed_priority : 0x > +allowed_sched_priority : 0xAA > +- #6 > +host_id: 23 > +allowed_atype : 0x2A > +allowed_qos : 0x > +allowed_orderid : 0x > +allowed_priority : 0x > +allowed_sched_priority : 0xAA > +- #7 > +host_id: 35 > +allowed_atype : 0x2A > +allowed_qos : 0x > +allowed_orderid : 0x > +allowed_priority : 0x > +allowed_sched_priority : 0xAA > +- #8 > +host_id: 37 >
Re: [PATCH v5 10/23] am64x: yaml: Add board configs for AM64x
On 07.07.23 14:34, Neha Malcom Francis wrote: > Added YAML configs for AM64xx > > Signed-off-by: Neha Malcom Francis > --- > board/ti/am64x/board-cfg.yaml | 37 + > board/ti/am64x/pm-cfg.yaml| 12 + > board/ti/am64x/rm-cfg.yaml| 1400 + > board/ti/am64x/sec-cfg.yaml | 380 + > 4 files changed, 1829 insertions(+) > create mode 100644 board/ti/am64x/board-cfg.yaml > create mode 100644 board/ti/am64x/pm-cfg.yaml > create mode 100644 board/ti/am64x/rm-cfg.yaml > create mode 100644 board/ti/am64x/sec-cfg.yaml > > diff --git a/board/ti/am64x/board-cfg.yaml b/board/ti/am64x/board-cfg.yaml > new file mode 100644 > index 00..f1f7c68d50 > --- /dev/null > +++ b/board/ti/am64x/board-cfg.yaml > @@ -0,0 +1,37 @@ > +# SPDX-License-Identifier: GPL-2.0+ > +# Copyright (C) 2022 Texas Instruments Incorporated - https://www.ti.com/ > +# > +# Board configuration for AM64x > +# > + > +--- > + > +board-cfg: > +rev: > +boardcfg_abi_maj : 0x0 > +boardcfg_abi_min : 0x1 > +control: > +subhdr: > +magic: 0xC1D3 > +size: 7 > +main_isolation_enable : 0x5A > +main_isolation_hostid : 0x2 > +secproxy: > +subhdr: > +magic: 0x1207 > +size: 7 > +scaling_factor : 0x1 > +scaling_profile : 0x1 > +disable_main_nav_secure_proxy : 0 > +msmc: > +subhdr: > +magic: 0xA5C3 > +size: 5 > +msmc_cache_size : 0x0 > +debug_cfg: > +subhdr: > +magic: 0x020C > +size: 8 > +trace_dst_enables : 0x00 > +trace_src_enables : 0x00 > + > diff --git a/board/ti/am64x/pm-cfg.yaml b/board/ti/am64x/pm-cfg.yaml > new file mode 100644 > index 00..c97495f482 > --- /dev/null > +++ b/board/ti/am64x/pm-cfg.yaml > @@ -0,0 +1,12 @@ > +# SPDX-License-Identifier: GPL-2.0+ > +# Copyright (C) 2022 Texas Instruments Incorporated - https://www.ti.com/ > +# > +# Power management configuration for AM64x > +# > + > +--- > + > +pm-cfg: > +rev: > +boardcfg_abi_maj : 0x0 > +boardcfg_abi_min : 0x1 > diff --git a/board/ti/am64x/rm-cfg.yaml b/board/ti/am64x/rm-cfg.yaml > new file mode 100644 > index 00..1e6b07aef6 > --- /dev/null > +++ b/board/ti/am64x/rm-cfg.yaml > @@ -0,0 +1,1400 @@ > +# SPDX-License-Identifier: GPL-2.0+ > +# Copyright (C) 2022 Texas Instruments Incorporated - https://www.ti.com/ > +# > +# Resource management configuration for AM64x > +# > + > +--- > + > +rm-cfg: > +rm_boardcfg: > +rev: > +boardcfg_abi_maj : 0x0 > +boardcfg_abi_min : 0x1 > +host_cfg: > +subhdr: > +magic: 0x4C41 > +size : 356 > +host_cfg_entries: > +- #1 > +host_id: 12 > +allowed_atype : 0x2A > +allowed_qos : 0x > +allowed_orderid : 0x > +allowed_priority : 0x > +allowed_sched_priority : 0xAA > +- #2 > +host_id: 30 > +allowed_atype : 0x2A > +allowed_qos : 0x > +allowed_orderid : 0x > +allowed_priority : 0x > +allowed_sched_priority : 0xAA > +- #3 > +host_id: 36 > +allowed_atype : 0x2A > +allowed_qos : 0x > +allowed_orderid : 0x > +allowed_priority : 0x > +allowed_sched_priority : 0xAA > +- #4 > +host_id: 38 > +allowed_atype : 0x2A > +allowed_qos : 0x > +allowed_orderid : 0x > +allowed_priority : 0x > +allowed_sched_priority : 0xAA > +- #5 > +ho
Re: [PATCH v5 01/23] binman: ti-board-config: Add support for TI board config binaries
On 07.07.23 14:34, Neha Malcom Francis wrote: > The ti-board-config entry loads and validates a given YAML config file > against a given schema, and generates the board config binary. K3 > devices require these binaries to be packed into the final system > firmware images. > > Signed-off-by: Neha Malcom Francis > Reviewed-by: Simon Glass > --- > tools/binman/entries.rst | 48 > tools/binman/etype/ti_board_config.py | 259 ++ > tools/binman/ftest.py | 20 ++ > tools/binman/test/277_ti_board_cfg.dts| 14 + > .../binman/test/278_ti_board_cfg_combined.dts | 25 ++ > .../binman/test/279_ti_board_cfg_no_type.dts | 11 + > tools/binman/test/yaml/config.yaml| 19 ++ > tools/binman/test/yaml/schema.yaml| 51 > tools/binman/test/yaml/schema_notype.yaml | 40 +++ > 9 files changed, 487 insertions(+) > create mode 100644 tools/binman/etype/ti_board_config.py > create mode 100644 tools/binman/test/277_ti_board_cfg.dts > create mode 100644 tools/binman/test/278_ti_board_cfg_combined.dts > create mode 100644 tools/binman/test/279_ti_board_cfg_no_type.dts > create mode 100644 tools/binman/test/yaml/config.yaml > create mode 100644 tools/binman/test/yaml/schema.yaml > create mode 100644 tools/binman/test/yaml/schema_notype.yaml > > diff --git a/tools/binman/entries.rst b/tools/binman/entries.rst > index b71af801fd..14a2d03fad 100644 > --- a/tools/binman/entries.rst > +++ b/tools/binman/entries.rst > @@ -1658,6 +1658,54 @@ by setting the size of the entry to something larger > than the text. > > > > +.. _etype_ti_board_config: > + > +Entry: ti-board-config: An entry containing a TI schema validated board > config binary > +- > + > +This etype supports generation of two kinds of board configuration > +binaries: singular board config binary as well as combined board config > +binary. > + > +Properties / Entry arguments: > +- config-file: File containing board configuration data in YAML > +- schema-file: File containing board configuration YAML schema against > + which the config file is validated > + > +Output files: > +- board config binary: File containing board configuration binary > + > +These above parameters are used only when the generated binary is > +intended to be a single board configuration binary. Example:: > + > +my-ti-board-config { > +ti-board-config { > +config = "board-config.yaml"; > +schema = "schema.yaml"; > +}; > +}; > + > +To generate a combined board configuration binary, we pack the > +needed individual binaries into a ti-board-config binary. In this case, > +the available supported subnode names are board-cfg, pm-cfg, sec-cfg and > +rm-cfg. The final binary is prepended with a header containing details about > +the included board config binaries. Example:: > + > +my-combined-ti-board-config { > +ti-board-config { > +board-cfg { > +config = "board-cfg.yaml"; > +schema = "schema.yaml"; > +}; > +sec-cfg { > +config = "sec-cfg.yaml"; > +schema = "schema.yaml"; > +}; > +} > +} > + > + > + > .. _etype_u_boot: > > Entry: u-boot: U-Boot flat binary > diff --git a/tools/binman/etype/ti_board_config.py > b/tools/binman/etype/ti_board_config.py > new file mode 100644 > index 00..0799e5dc59 > --- /dev/null > +++ b/tools/binman/etype/ti_board_config.py > @@ -0,0 +1,259 @@ > +# SPDX-License-Identifier: GPL-2.0+ > +# Copyright (c) 2022 Texas Instruments Incorporated - https://www.ti.com/ > +# Written by Neha Malcom Francis > +# > +# Entry-type module for generating schema validated TI board > +# configuration binary > +# > + > +import os > +import struct > +import yaml > + > +from collections import OrderedDict > +from jsonschema import validate > +from shutil import copyfileobj > + > +from binman.entry import Entry > +from binman.etype.section import Entry_section > +from dtoc import fdt_util > +from u_boot_pylib import tools > + > +BOARDCFG = 0xB > +BOARDCFG_SEC = 0xD > +BOARDCFG_PM = 0xE > +BOARDCFG_RM = 0xC > +BOARDCFG_NUM_ELEMS = 4 > + > +class Entry_ti_board_config(Entry_section): > +"""An entry containing a TI schema validated board config binary > + > +This etype supports generation of two kinds of board configuration > +binaries: singular board config binary as well as combined board config > +binary. > + > +Properties / Entry arguments: > +- config-file: File containing board configuration data in YAML > +- schema-file: File containing board configuration YAML schema > against > + which the config file is validated > + > +Output files: > +- board config binary: File containing board configuration binary > + > +
Re: [PATCH v3 00/19] binman: Simple templating feature and mkimage conversion
On 10.07.23 18:00, Simon Glass wrote: > Hi Jan, > > On Sun, 9 Jul 2023 at 23:21, Jan Kiszka wrote: >> >> On 10.07.23 04:40, Simon Glass wrote: >>> This series converts the mkimage entry type to be a section, i.e. based on >>> the entry_Section class. This makes it more consistent in its behaviour, >>> e.g. allowing symbol writing and expanded entries. >>> >>> A simple templating feature is also introduced, to reduce duplication >>> when a set of entries must be used in multiple images. >>> >>> In this version the nodes from the template are placed before any other >>> nodes, meaning that the template sets the node order. This seems more >>> consistent than other mechanisms. >>> >>> Changes in v3: >>> - Add new patch for elf to return number of written symbols >>> - Add new patch with more detail on how ObtainContents() works >>> - Fix up some tests which now need SPL and TPL >>> - Avoid calling ObtainContents() when not needed >>> - Fix 'specific' typo >>> - Add a new devicetree file especially for node copying >>> - Correct logic for merging nodes in order >>> - Tidy up some comments >>> - Adjust to use the new example file >>> - Drop duplicate dts-v1 header >>> - Add new test case for templating in a FIT >>> - Add new patch to support writing symbols inside a mkimage image >>> >>> Changes in v2: >>> - Drop now-unnecessary methods in mkimage etype >>> - Correct ordering of template nodes >>> - Fix 'preseverd' and 'inserter' typos >>> >>> Marek Vasut (1): >>> binman: Convert mkimage to Entry_section >>> >>> Simon Glass (18): >>> binman: Correct coverage gap in control >>> binman: Init align_default in entry_Section >>> binman: Use GetEntries() to obtain section contents >>> binman: Read _multiple_data_files in the correct place >>> binman: Allow disabling symbol writing >>> stm32mp15: Avoid writing symbols in SPL >>> binman: Update elf to return number of written symbols >>> binman: Add more detail on how ObtainContents() works >>> binman: Provide a way to specify the fdt-list directly >>> binman: Drop __bss_size variable in bss_data.c >>> binman: Correct handling of zero bss size >>> dtoc: Support copying the contents of a node into another >>> dtoc: Allow inserting a list of nodes into another >>> binman: Support simple templates >>> binman: Support templating with multiple images >>> binman: Add a test for templating in a FIT >>> binman: Support templates at any level >>> binman: Support writing symbols inside a mkimage image >>> >>> arch/arm/dts/stm32mp15-u-boot.dtsi | 1 + >>> tools/binman/binman.rst| 89 + >>> tools/binman/control.py| 34 +++- >>> tools/binman/elf.py| 13 +- >>> tools/binman/elf_test.py | 13 +- >>> tools/binman/entries.rst | 6 + >>> tools/binman/entry.py | 11 +- >>> tools/binman/etype/blob_phase.py | 5 + >>> tools/binman/etype/fit.py | 9 + >>> tools/binman/etype/mkimage.py | 110 --- >>> tools/binman/etype/section.py | 54 +++-- >>> tools/binman/etype/u_boot_spl_bss_pad.py | 2 +- >>> tools/binman/etype/u_boot_tpl_bss_pad.py | 2 +- >>> tools/binman/etype/u_boot_vpl_bss_pad.py | 2 +- >>> tools/binman/ftest.py | 218 - >>> tools/binman/test/282_symbols_disable.dts | 25 +++ >>> tools/binman/test/283_mkimage_special.dts | 24 +++ >>> tools/binman/test/284_fit_fdt_list.dts | 58 ++ >>> tools/binman/test/285_spl_expand.dts | 13 ++ >>> tools/binman/test/286_template.dts | 42 >>> tools/binman/test/287_template_multi.dts | 27 +++ >>> tools/binman/test/288_template_fit.dts | 37 >>> tools/binman/test/289_template_section.dts | 52 + >>> tools/binman/test/290_mkimage_sym.dts | 27 +++ >>> tools/binman/test/Makefile | 5 +- >>> tools/binman/test/bss_data.c | 3 +- >>> tools/binman/test/bss_data_zero.c | 16 ++ >>> tools/binman/test/bss_data_zero.lds| 15 ++ >>> tools/binman/test/embed_data.lds
Re: [PATCH v5 11/23] am64x: dts: binman: Package tiboot3.bin, tispl.bin u-boot.img
On 10.07.23 11:12, Neha Malcom Francis wrote: > Hi Simon > > On 07/07/23 23:05, Simon Glass wrote: >> Hi Neha, >> >> On Fri, 7 Jul 2023 at 13:36, Neha Malcom Francis >> wrote: >>> >>> Support added for HS and GP boot binaries for AM64x. >>> >>> HS-SE: >>> * tiboot3-am64x_sr2-hs-evm.bin >>> * tispl.bin >>> * u-boot.img >>> >>> HS-FS: >>> * tiboot3-am64x_sr2-hs-fs-evm.bin >>> * tispl.bin >>> * u-boot.img >>> >>> GP: >>> * tiboot3.bin --> tiboot3-am64x-gp-evm.bin >>> * tispl.bin_unsigned >>> * u-boot.img_unsigned >>> >>> Note that the bootflow followed by AM64x requires: >>> >>> tiboot3.bin: >>> * R5 SPL >>> * R5 SPL dtbs >>> * sysfw >>> * board-cfg >>> * pm-cfg >>> * sec-cfg >>> * rm-cfg >>> >>> tispl.bin: >>> * ATF >>> * OPTEE >>> * A53 SPL >>> * A53 SPL dtbs >>> >>> u-boot.img: >>> * A53 U-Boot >>> * A53 U-Boot dtbs >>> >>> Signed-off-by: Neha Malcom Francis >>> Reviewed-by: Simon Glass >>> [a...@ti.com: changed output binary names appropriately] >>> Signed-off-by: Andrew Davis >>> --- >>> arch/arm/dts/k3-am642-evm-u-boot.dtsi | 2 + >>> arch/arm/dts/k3-am642-r5-evm.dts | 1 + >>> arch/arm/dts/k3-am642-sk-u-boot.dtsi | 2 + >>> arch/arm/dts/k3-am64x-binman.dtsi | 515 ++ >>> board/ti/am64x/Kconfig | 2 + >>> 5 files changed, 522 insertions(+) >>> create mode 100644 arch/arm/dts/k3-am64x-binman.dtsi >> >> It looks like the template feature (see pending patches) might help >> reduce the size of the .dtsi, but we can worry about that later. >> > > Right, I'll have a shot at it once this series is up. Thanks! > I would recommend testing it earlier locally if you are interested - there might be still some edges left, and early feedback already helped to improve it. Jan -- Siemens AG, Technology Competence Center Embedded Linux
Re: [PATCH v3 00/19] binman: Simple templating feature and mkimage conversion
On 10.07.23 04:40, Simon Glass wrote: > This series converts the mkimage entry type to be a section, i.e. based on > the entry_Section class. This makes it more consistent in its behaviour, > e.g. allowing symbol writing and expanded entries. > > A simple templating feature is also introduced, to reduce duplication > when a set of entries must be used in multiple images. > > In this version the nodes from the template are placed before any other > nodes, meaning that the template sets the node order. This seems more > consistent than other mechanisms. > > Changes in v3: > - Add new patch for elf to return number of written symbols > - Add new patch with more detail on how ObtainContents() works > - Fix up some tests which now need SPL and TPL > - Avoid calling ObtainContents() when not needed > - Fix 'specific' typo > - Add a new devicetree file especially for node copying > - Correct logic for merging nodes in order > - Tidy up some comments > - Adjust to use the new example file > - Drop duplicate dts-v1 header > - Add new test case for templating in a FIT > - Add new patch to support writing symbols inside a mkimage image > > Changes in v2: > - Drop now-unnecessary methods in mkimage etype > - Correct ordering of template nodes > - Fix 'preseverd' and 'inserter' typos > > Marek Vasut (1): > binman: Convert mkimage to Entry_section > > Simon Glass (18): > binman: Correct coverage gap in control > binman: Init align_default in entry_Section > binman: Use GetEntries() to obtain section contents > binman: Read _multiple_data_files in the correct place > binman: Allow disabling symbol writing > stm32mp15: Avoid writing symbols in SPL > binman: Update elf to return number of written symbols > binman: Add more detail on how ObtainContents() works > binman: Provide a way to specify the fdt-list directly > binman: Drop __bss_size variable in bss_data.c > binman: Correct handling of zero bss size > dtoc: Support copying the contents of a node into another > dtoc: Allow inserting a list of nodes into another > binman: Support simple templates > binman: Support templating with multiple images > binman: Add a test for templating in a FIT > binman: Support templates at any level > binman: Support writing symbols inside a mkimage image > > arch/arm/dts/stm32mp15-u-boot.dtsi | 1 + > tools/binman/binman.rst| 89 + > tools/binman/control.py| 34 +++- > tools/binman/elf.py| 13 +- > tools/binman/elf_test.py | 13 +- > tools/binman/entries.rst | 6 + > tools/binman/entry.py | 11 +- > tools/binman/etype/blob_phase.py | 5 + > tools/binman/etype/fit.py | 9 + > tools/binman/etype/mkimage.py | 110 --- > tools/binman/etype/section.py | 54 +++-- > tools/binman/etype/u_boot_spl_bss_pad.py | 2 +- > tools/binman/etype/u_boot_tpl_bss_pad.py | 2 +- > tools/binman/etype/u_boot_vpl_bss_pad.py | 2 +- > tools/binman/ftest.py | 218 - > tools/binman/test/282_symbols_disable.dts | 25 +++ > tools/binman/test/283_mkimage_special.dts | 24 +++ > tools/binman/test/284_fit_fdt_list.dts | 58 ++ > tools/binman/test/285_spl_expand.dts | 13 ++ > tools/binman/test/286_template.dts | 42 > tools/binman/test/287_template_multi.dts | 27 +++ > tools/binman/test/288_template_fit.dts | 37 > tools/binman/test/289_template_section.dts | 52 + > tools/binman/test/290_mkimage_sym.dts | 27 +++ > tools/binman/test/Makefile | 5 +- > tools/binman/test/bss_data.c | 3 +- > tools/binman/test/bss_data_zero.c | 16 ++ > tools/binman/test/bss_data_zero.lds| 15 ++ > tools/binman/test/embed_data.lds | 1 + > tools/dtoc/fdt.py | 122 +++- > tools/dtoc/test/dtoc_test_copy.dts | 86 > tools/dtoc/test_fdt.py | 93 + > 32 files changed, 1147 insertions(+), 68 deletions(-) > create mode 100644 tools/binman/test/282_symbols_disable.dts > create mode 100644 tools/binman/test/283_mkimage_special.dts > create mode 100644 tools/binman/test/284_fit_fdt_list.dts > create mode 100644 tools/binman/test/285_spl_expand.dts > create mode 100644 tools/binman/test/286_template.dts > create mode 100644 tools/binman/test/287_template_multi.dts > create mode 100644 tools/binman/test/288_template_fit.dts > create mode 100644 tools/binman/test/289_template_section.dts > create mode 100644 tools/binman/test/290_mkimage_sym.dts > create mode 100644 tools/binman/test/bss_data_zero.c > create mode 100644 tools/binman/test/bss_data_zero.lds > create mode 100644 tools/dtoc/test/dtoc_test_copy.dts > Works much better! What does not work yet: /dts-v1/; / { b
Re: [PATCH 12/12] binman: Support simple templates
On 07.07.23 19:35, Simon Glass wrote: > Hi Jan, > > On Fri, 7 Jul 2023 at 17:03, Jan Kiszka wrote: >> >> On 07.07.23 17:35, Simon Glass wrote: >>> Hi Jan, >>> >>> On Fri, 7 Jul 2023 at 14:56, Jan Kiszka wrote: >>>> >>>> On 07.07.23 14:42, Simon Glass wrote: >>>>> Hi Jan, >>>>> >>>>> On Fri, 7 Jul 2023 at 11:05, Jan Kiszka wrote: >>>>>> >>>>>> On 05.07.23 00:14, Simon Glass wrote: >>>>>>> Hi Jan, >>>>>>> >>>>>>> On Mon, 3 Jul 2023 at 20:34, Jan Kiszka wrote: >>>>>>>> >>>>>>>> Hi Simon, >>>>>>>> >>>>>>>> On 28.06.23 13:41, Simon Glass wrote: >>>>>>>>> Collections can used to collect the contents of other entries into a >>>>>>>>> single entry, but they result in a single entry, with the original >>>>>>>>> entries >>>>>>>>> 'left behind' in their old place. >>>>>>>>> >>>>>>>>> It is useful to be able to specific a set of entries ones and have it >>>>>>>>> used >>>>>>>>> in multiple images, or parts of an image. >>>>>>>>> >>>>>>>>> Implement this mechanism. >>>>>>>>> >>>>>>>>> Signed-off-by: Simon Glass >>>>>>>>> --- >>>>>>>>> >>>>>>>>> tools/binman/binman.rst | 80 >>>>>>>>> >>>>>>>>> tools/binman/control.py | 9 +++ >>>>>>>>> tools/binman/etype/section.py| 3 +- >>>>>>>>> tools/binman/ftest.py| 8 +++ >>>>>>>>> tools/binman/test/286_entry_template.dts | 42 + >>>>>>>>> 5 files changed, 141 insertions(+), 1 deletion(-) >>>>>>>>> create mode 100644 tools/binman/test/286_entry_template.dts >>>>>>>>> >>>>>>>>> diff --git a/tools/binman/binman.rst b/tools/binman/binman.rst >>>>>>>>> index a4b31fe5397b..9be979ae1c5b 100644 >>>>>>>>> --- a/tools/binman/binman.rst >>>>>>>>> +++ b/tools/binman/binman.rst >>>>>>>>> @@ -727,6 +727,13 @@ optional: >>>>>>>>> Note that missing, optional blobs do not produce a non-zero exit >>>>>>>>> code from >>>>>>>>> binman, although it does show a warning about the missing >>>>>>>>> external blob. >>>>>>>>> >>>>>>>>> +insert-template: >>>>>>>>> +This is not strictly speaking an entry property, since it is >>>>>>>>> processed early >>>>>>>>> +in Binman before the entries are read. It is a list of phandles >>>>>>>>> of nodes to >>>>>>>>> +include in the current (target) node. For each node, its >>>>>>>>> subnodes and their >>>>>>>>> +properties are brought into the target node. See Templates_ >>>>>>>>> below for >>>>>>>>> +more information. >>>>>>>>> + >>>>>>>>> The attributes supported for images and sections are described >>>>>>>>> below. Several >>>>>>>>> are similar to those for entries. >>>>>>>>> >>>>>>>>> @@ -1172,6 +1179,79 @@ If you are having trouble figuring out what is >>>>>>>>> going on, you can use >>>>>>>>> arch/arm/dts/u-boot.dtsi ... found: >>>>>>>>> "arch/arm/dts/juno-r2-u-boot.dtsi" >>>>>>>>> >>>>>>>>> >>>>>>>>> +Templates >>>>>>>>> += >>>>>>>>> + >>>>>>>>> +Sometimes multiple images need to be created which have all have a >>>>>>>>> common >>>>>>>>> +part. For example,
Re: [PATCH 12/12] binman: Support simple templates
On 07.07.23 17:35, Simon Glass wrote: > Hi Jan, > > On Fri, 7 Jul 2023 at 14:56, Jan Kiszka wrote: >> >> On 07.07.23 14:42, Simon Glass wrote: >>> Hi Jan, >>> >>> On Fri, 7 Jul 2023 at 11:05, Jan Kiszka wrote: >>>> >>>> On 05.07.23 00:14, Simon Glass wrote: >>>>> Hi Jan, >>>>> >>>>> On Mon, 3 Jul 2023 at 20:34, Jan Kiszka wrote: >>>>>> >>>>>> Hi Simon, >>>>>> >>>>>> On 28.06.23 13:41, Simon Glass wrote: >>>>>>> Collections can used to collect the contents of other entries into a >>>>>>> single entry, but they result in a single entry, with the original >>>>>>> entries >>>>>>> 'left behind' in their old place. >>>>>>> >>>>>>> It is useful to be able to specific a set of entries ones and have it >>>>>>> used >>>>>>> in multiple images, or parts of an image. >>>>>>> >>>>>>> Implement this mechanism. >>>>>>> >>>>>>> Signed-off-by: Simon Glass >>>>>>> --- >>>>>>> >>>>>>> tools/binman/binman.rst | 80 >>>>>>> tools/binman/control.py | 9 +++ >>>>>>> tools/binman/etype/section.py| 3 +- >>>>>>> tools/binman/ftest.py| 8 +++ >>>>>>> tools/binman/test/286_entry_template.dts | 42 + >>>>>>> 5 files changed, 141 insertions(+), 1 deletion(-) >>>>>>> create mode 100644 tools/binman/test/286_entry_template.dts >>>>>>> >>>>>>> diff --git a/tools/binman/binman.rst b/tools/binman/binman.rst >>>>>>> index a4b31fe5397b..9be979ae1c5b 100644 >>>>>>> --- a/tools/binman/binman.rst >>>>>>> +++ b/tools/binman/binman.rst >>>>>>> @@ -727,6 +727,13 @@ optional: >>>>>>> Note that missing, optional blobs do not produce a non-zero exit >>>>>>> code from >>>>>>> binman, although it does show a warning about the missing external >>>>>>> blob. >>>>>>> >>>>>>> +insert-template: >>>>>>> +This is not strictly speaking an entry property, since it is >>>>>>> processed early >>>>>>> +in Binman before the entries are read. It is a list of phandles of >>>>>>> nodes to >>>>>>> +include in the current (target) node. For each node, its subnodes >>>>>>> and their >>>>>>> +properties are brought into the target node. See Templates_ below >>>>>>> for >>>>>>> +more information. >>>>>>> + >>>>>>> The attributes supported for images and sections are described below. >>>>>>> Several >>>>>>> are similar to those for entries. >>>>>>> >>>>>>> @@ -1172,6 +1179,79 @@ If you are having trouble figuring out what is >>>>>>> going on, you can use >>>>>>> arch/arm/dts/u-boot.dtsi ... found: >>>>>>> "arch/arm/dts/juno-r2-u-boot.dtsi" >>>>>>> >>>>>>> >>>>>>> +Templates >>>>>>> += >>>>>>> + >>>>>>> +Sometimes multiple images need to be created which have all have a >>>>>>> common >>>>>>> +part. For example, a board may generate SPI and eMMC images which both >>>>>>> include >>>>>>> +a FIT. Since the FIT includes many entries, it is tedious to repeat >>>>>>> them twice >>>>>>> +in the image description. >>>>>>> + >>>>>>> +Templates provide a simple way to handle this:: >>>>>>> + >>>>>>> +binman { >>>>>>> +multiple-images; >>>>>>> +common_part: template-1 { >>>>>>> +fit { >>>>>>> +... lots of entries in here >>>>>>> +}; >>>>>>&
Re: [PATCH] binman: Support templating with multiple images
On 07.07.23 14:40, Simon Glass wrote: > Allow a template to appear in the top level description when using > multiple images. > > Signed-off-by: Simon Glass > --- > > tools/binman/control.py | 5 ++-- > tools/binman/ftest.py| 12 ++ > tools/binman/test/287_template_multi.dts | 29 > 3 files changed, 44 insertions(+), 2 deletions(-) > create mode 100644 tools/binman/test/287_template_multi.dts > > diff --git a/tools/binman/control.py b/tools/binman/control.py > index 0f98e9904fb1..b334fbc8ac8f 100644 > --- a/tools/binman/control.py > +++ b/tools/binman/control.py > @@ -57,8 +57,9 @@ def _ReadImageDesc(binman_node, use_expanded): > images = OrderedDict() > if 'multiple-images' in binman_node.props: > for node in binman_node.subnodes: > -images[node.name] = Image(node.name, node, > - use_expanded=use_expanded) > +if 'template' not in node.name: > +images[node.name] = Image(node.name, node, > + use_expanded=use_expanded) > else: > images['image'] = Image('image', binman_node, > use_expanded=use_expanded) > return images > diff --git a/tools/binman/ftest.py b/tools/binman/ftest.py > index 389d3906371a..c783424c91da 100644 > --- a/tools/binman/ftest.py > +++ b/tools/binman/ftest.py > @@ -6771,6 +6771,18 @@ fdt fdtmapExtract the > devicetree blob from the fdtmap > second = U_BOOT_DATA + b'#' + VGA_DATA + U_BOOT_DTB_DATA > self.assertEqual(U_BOOT_IMG_DATA + first + second, data) > > +def testEntryTemplateBlobMulti(self): > +"""Test using a template with 'multiple-images' enabled""" > +TestFunctional._MakeInputFile('my-blob.bin', b'blob') > +TestFunctional._MakeInputFile('my-blob2.bin', b'other') > +retcode = self._DoTestFile('287_template_multi.dts') > + > +self.assertEqual(0, retcode) > +image = control.images['image'] > +image_fname = tools.get_output_filename('my-image.bin') > +data = tools.read_file(image_fname) > +self.assertEqual(b'blobother', data) > + > > if __name__ == "__main__": > unittest.main() > diff --git a/tools/binman/test/287_template_multi.dts > b/tools/binman/test/287_template_multi.dts > new file mode 100644 > index ..15bd8701c671 > --- /dev/null > +++ b/tools/binman/test/287_template_multi.dts > @@ -0,0 +1,29 @@ > +// SPDX-License-Identifier: GPL-2.0+ > + > +/dts-v1/; > + > +/dts-v1/; Duplicate. > +/ { > + binman: binman { > + multiple-images; > + > + my_template: template { > + blob-ext@0 { > + filename = "my-blob.bin"; > + offset = <0>; > + }; > + blob-ext@8 { > + offset = <8>; > + }; > + }; > + > + image { > + pad-byte = <0x40>; > + filename = "my-image.bin"; > + insert-template = <&my_template>; > + blob-ext@8 { > + filename = "my-blob2.bin"; > + }; > + }; > + }; > +}; For the sake of context: echo 1234 > my-blob.bin echo 5678 > my-blob2.bin dtc tools/binman/test/287_template_multi.dts -o binman-test.dtb tools/binman/binman build -d binman-test.dtb -O . binman: Node '/binman/image/blob-ext@0': Offset 0x0 (0) overlaps with previous entry '/binman/image/blob-ext@8' ending at 0xd (13) Jan -- Siemens AG, Technology Competence Center Embedded Linux
Re: [PATCH 12/12] binman: Support simple templates
On 07.07.23 14:42, Simon Glass wrote: > Hi Jan, > > On Fri, 7 Jul 2023 at 11:05, Jan Kiszka wrote: >> >> On 05.07.23 00:14, Simon Glass wrote: >>> Hi Jan, >>> >>> On Mon, 3 Jul 2023 at 20:34, Jan Kiszka wrote: >>>> >>>> Hi Simon, >>>> >>>> On 28.06.23 13:41, Simon Glass wrote: >>>>> Collections can used to collect the contents of other entries into a >>>>> single entry, but they result in a single entry, with the original entries >>>>> 'left behind' in their old place. >>>>> >>>>> It is useful to be able to specific a set of entries ones and have it used >>>>> in multiple images, or parts of an image. >>>>> >>>>> Implement this mechanism. >>>>> >>>>> Signed-off-by: Simon Glass >>>>> --- >>>>> >>>>> tools/binman/binman.rst | 80 >>>>> tools/binman/control.py | 9 +++ >>>>> tools/binman/etype/section.py| 3 +- >>>>> tools/binman/ftest.py| 8 +++ >>>>> tools/binman/test/286_entry_template.dts | 42 + >>>>> 5 files changed, 141 insertions(+), 1 deletion(-) >>>>> create mode 100644 tools/binman/test/286_entry_template.dts >>>>> >>>>> diff --git a/tools/binman/binman.rst b/tools/binman/binman.rst >>>>> index a4b31fe5397b..9be979ae1c5b 100644 >>>>> --- a/tools/binman/binman.rst >>>>> +++ b/tools/binman/binman.rst >>>>> @@ -727,6 +727,13 @@ optional: >>>>> Note that missing, optional blobs do not produce a non-zero exit >>>>> code from >>>>> binman, although it does show a warning about the missing external >>>>> blob. >>>>> >>>>> +insert-template: >>>>> +This is not strictly speaking an entry property, since it is >>>>> processed early >>>>> +in Binman before the entries are read. It is a list of phandles of >>>>> nodes to >>>>> +include in the current (target) node. For each node, its subnodes >>>>> and their >>>>> +properties are brought into the target node. See Templates_ below for >>>>> +more information. >>>>> + >>>>> The attributes supported for images and sections are described below. >>>>> Several >>>>> are similar to those for entries. >>>>> >>>>> @@ -1172,6 +1179,79 @@ If you are having trouble figuring out what is >>>>> going on, you can use >>>>> arch/arm/dts/u-boot.dtsi ... found: >>>>> "arch/arm/dts/juno-r2-u-boot.dtsi" >>>>> >>>>> >>>>> +Templates >>>>> += >>>>> + >>>>> +Sometimes multiple images need to be created which have all have a common >>>>> +part. For example, a board may generate SPI and eMMC images which both >>>>> include >>>>> +a FIT. Since the FIT includes many entries, it is tedious to repeat them >>>>> twice >>>>> +in the image description. >>>>> + >>>>> +Templates provide a simple way to handle this:: >>>>> + >>>>> +binman { >>>>> +multiple-images; >>>>> +common_part: template-1 { >>>>> +fit { >>>>> +... lots of entries in here >>>>> +}; >>>>> + >>>>> +text { >>>>> +text = "base image"; >>>>> +}; >>>>> +}; >>>>> + >>>>> +spi-image { >>>>> +filename = "image-spi.bin"; >>>>> +insert-template = <&fit>; >>>>> + >>>>> +/* things specific to SPI follow */ >>>>> +header { >>>>> +]; >>>>> + >>>>> +text { >>>>> +text = "SPI image"; >>>>> +}; >>>>> +}; >>>>> + >>>>> +mmc-image { >>>>> +filename = "image-mmc
Re: [PATCH v5 20/23] doc: board: ti: Update documentation for binman flow
On 07.07.23 15:30, Jerome Forissier wrote: > > > On 7/7/23 14:34, Neha Malcom Francis wrote: >> Earlier documentation specified builds for generating bootloader images >> using an external TI repository k3-image-gen and core-secdev-k3. Modify >> this to using the binman flow so that user understands how to build the >> final boot images. >> >> Signed-off-by: Neha Malcom Francis >> Reviewed-by: Simon Glass >> --- >> doc/board/ti/am62x_sk.rst | 42 - >> doc/board/ti/j721e_evm.rst | 50 +--- >> doc/board/ti/k3.rst| 95 +- >> 3 files changed, 73 insertions(+), 114 deletions(-) >> >> diff --git a/doc/board/ti/am62x_sk.rst b/doc/board/ti/am62x_sk.rst >> index 27d7b527c6..e4d58b4958 100644 >> --- a/doc/board/ti/am62x_sk.rst >> +++ b/doc/board/ti/am62x_sk.rst > [...] >> @@ -139,35 +135,37 @@ Build procedure: >> >> 1. ATF: >> >> -.. code-block:: text >> +.. code-block:: bash >> >> - $ make CROSS_COMPILE=aarch64-none-linux-gnu- ARCH=aarch64 PLAT=k3 >> TARGET_BOARD=lite SPD=opteed >> + $ make CROSS_COMPILE=aarch64-none-linux-gnu- ARCH=aarch64 PLAT=k3 \ >> +TARGET_BOARD=lite SPD=opteed >> >> 2. OPTEE: >> >> -.. code-block:: text >> +.. code-block:: bash >> >> - $ make PLATFORM=k3 CFG_ARM64_core=y >> CROSS_COMPILE=arm-none-linux-gnueabihf- >> CROSS_COMPILE64=aarch64-none-linux-gnu- >> + $ make PLATFORM=k3 CFG_ARM64_core=y >> CROSS_COMPILE=arm-none-linux-gnueabihf- \ >> +CROSS_COMPILE64=aarch64-none-linux-gnu- >> >> 3. U-Boot: >> >> * 3.1 R5: >> >> -.. code-block:: text >> +.. code-block:: bash >> >> - $ make ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabihf- >> am62x_evm_r5_defconfig O=/tmp/r5 >> - $ make ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabihf- O=/tmp/r5 >> - $ cd >> - $ make ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabihf- SOC=am62x >> SBL=/tmp/r5/spl/u-boot-spl.bin SYSFW_PATH=> ti-linux-firmware>/ti-sysfw/ti-fs-firmware-am62x-gp.bin >> - >> -Use the tiboot3.bin generated from last command >> + $ make ARCH=arm am62x_evm_r5_defconfig >> + $ make ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabihf- \ >> +BINMAN_INDIRS= >> >> * 3.2 A53: >> >> -.. code-block:: text >> +.. code-block:: bash >> >> - $ make ARCH=arm CROSS_COMPILE=aarch64-none-linux-gnu- >> am62x_evm_a53_defconfig O=/tmp/a53 >> - $ make ARCH=arm CROSS_COMPILE=aarch64-none-linux-gnu- ATF=> dir>/build/k3/lite/release/bl31.bin TEE=> dir>/out/arm-plat-k3/core/tee-pager_v2.bin DM=> ti-linux-firmware>/ti-dm/am62xx/ipc_echo_testb_mcu1_0_release_strip.xer5f >> O=/tmp/a53 >> + $ make ARCH=arm am62x_evm_a53_defconfig >> + $ make ARCH=arm CROSS_COMPILE=aarch64-none-linux-gnu- \ >> +BL31=/build/k3/lite/release/bl31.bin \ >> +TEE=/out/arm-plat-k3/core/tee-pager_v2.bin \ > > Note that since OP-TEE 3.21.0, tee-raw.bin could/should be used instead of > tee-pager_v2.bin. Indeed when the "pager" feature is not enabled, the two > binaries are identical, and the newer name is hopefully less confusing. > Ah, interesting. That will affect doc/board/siemens/iot2050.rst as well (and our integration recipes). Jan -- Siemens AG, Technology Competence Center Embedded Linux
Re: [PATCH v5 18/23] arm: k3-am65x-iot2050: Use binman for tispl.bin for iot2050
On 07.07.23 14:34, Neha Malcom Francis wrote: > Move to using binman to generate tispl.bin which is used to generate the > final flash.bin bootloader for iot2050 boards. > > Signed-off-by: Neha Malcom Francis > Cc: Jan Kiszka > --- > arch/arm/dts/k3-am65-iot2050-boot-image.dtsi | 76 +++- > 1 file changed, 74 insertions(+), 2 deletions(-) > > diff --git a/arch/arm/dts/k3-am65-iot2050-boot-image.dtsi > b/arch/arm/dts/k3-am65-iot2050-boot-image.dtsi > index 03ccc54329..9d83898d33 100644 > --- a/arch/arm/dts/k3-am65-iot2050-boot-image.dtsi > +++ b/arch/arm/dts/k3-am65-iot2050-boot-image.dtsi > @@ -26,9 +26,81 @@ > missing-msg = "iot2050-seboot"; > }; > > - blob@0x18 { > + fit@0x18 { > offset = <0x18>; > - filename = "tispl.bin"; > + pad-byte = <0xff>; > + description = "Configuration to load ATF and SPL"; > + > + images { > + atf { > + description = "ARM Trusted Firmware"; > + type = "firmware"; > + arch = "arm64"; > + compression = "none"; > + os = "arm-trusted-firmware"; > + load = ; > + entry = ; > + atf: atf-bl31 { > + }; > + }; > + > + tee { > + description = "OPTEE"; > + type = "tee"; > + arch = "arm64"; > + compression = "none"; > + os = "tee"; > + load = <0x9e80>; > + entry = <0x9e80>; > + tee: tee-os { > + }; > + }; > + > + dm { > + description = "DM binary"; > + type = "firmware"; > + arch = "arm32"; > + compression = "none"; > + os = "DM"; > + load = <0x8900>; > + entry = <0x8900>; > + blob-ext { > + filename = "/dev/null"; > + }; > + }; > + > + spl { > + description = "SPL (64-bit)"; > + type = "standalone"; > + os = "U-Boot"; > + arch = "arm64"; > + compression = "none"; > + load = ; > + entry = ; > + u_boot_spl_nodtb: blob-ext { > + filename = > "spl/u-boot-spl-nodtb.bin"; > + }; > + }; > + > + fdt-0 { > + description = "k3-am65-iot2050-spl.dtb"; > + type = "flat_dt"; > + arch = "arm"; > + compression = "none"; > + spl_am65x_evm_dtb: blob-ext { > + filename = > "spl/dts/k3-am65-iot2050-spl.dtb"; > + }; > + }; > + }; > + > + configurations { > + default = "spl"; > + spl { > + fdt = "fdt-0"; > + firmware = "atf"; > + loadables = "tee", "dm", "spl"; > + }; > + }; > }; > > fit@0x38 { Looks ok (will have to test), but this lacks adjustment of tools/iot2050-sign-fw.sh, probably something around s/tispl.bin/fit@0x18/g. Jan -- Siemens AG, Technology Competence Center Embedded Linux
Re: [PATCH 12/12] binman: Support simple templates
On 05.07.23 00:14, Simon Glass wrote: > Hi Jan, > > On Mon, 3 Jul 2023 at 20:34, Jan Kiszka wrote: >> >> Hi Simon, >> >> On 28.06.23 13:41, Simon Glass wrote: >>> Collections can used to collect the contents of other entries into a >>> single entry, but they result in a single entry, with the original entries >>> 'left behind' in their old place. >>> >>> It is useful to be able to specific a set of entries ones and have it used >>> in multiple images, or parts of an image. >>> >>> Implement this mechanism. >>> >>> Signed-off-by: Simon Glass >>> --- >>> >>> tools/binman/binman.rst | 80 >>> tools/binman/control.py | 9 +++ >>> tools/binman/etype/section.py| 3 +- >>> tools/binman/ftest.py| 8 +++ >>> tools/binman/test/286_entry_template.dts | 42 + >>> 5 files changed, 141 insertions(+), 1 deletion(-) >>> create mode 100644 tools/binman/test/286_entry_template.dts >>> >>> diff --git a/tools/binman/binman.rst b/tools/binman/binman.rst >>> index a4b31fe5397b..9be979ae1c5b 100644 >>> --- a/tools/binman/binman.rst >>> +++ b/tools/binman/binman.rst >>> @@ -727,6 +727,13 @@ optional: >>> Note that missing, optional blobs do not produce a non-zero exit code >>> from >>> binman, although it does show a warning about the missing external >>> blob. >>> >>> +insert-template: >>> +This is not strictly speaking an entry property, since it is processed >>> early >>> +in Binman before the entries are read. It is a list of phandles of >>> nodes to >>> +include in the current (target) node. For each node, its subnodes and >>> their >>> +properties are brought into the target node. See Templates_ below for >>> +more information. >>> + >>> The attributes supported for images and sections are described below. >>> Several >>> are similar to those for entries. >>> >>> @@ -1172,6 +1179,79 @@ If you are having trouble figuring out what is going >>> on, you can use >>> arch/arm/dts/u-boot.dtsi ... found: "arch/arm/dts/juno-r2-u-boot.dtsi" >>> >>> >>> +Templates >>> += >>> + >>> +Sometimes multiple images need to be created which have all have a common >>> +part. For example, a board may generate SPI and eMMC images which both >>> include >>> +a FIT. Since the FIT includes many entries, it is tedious to repeat them >>> twice >>> +in the image description. >>> + >>> +Templates provide a simple way to handle this:: >>> + >>> +binman { >>> +multiple-images; >>> +common_part: template-1 { >>> +fit { >>> +... lots of entries in here >>> +}; >>> + >>> +text { >>> +text = "base image"; >>> +}; >>> +}; >>> + >>> +spi-image { >>> +filename = "image-spi.bin"; >>> +insert-template = <&fit>; >>> + >>> +/* things specific to SPI follow */ >>> +header { >>> +]; >>> + >>> +text { >>> +text = "SPI image"; >>> +}; >>> +}; >>> + >>> +mmc-image { >>> +filename = "image-mmc.bin"; >>> +insert-template = <&fit>; >>> + >>> +/* things specific to MMC follow */ >>> +header { >>> +]; >>> + >>> +text { >>> +text = "MMC image"; >>> +}; >>> +}; >>> +}; >>> + >>> +The template node name must start with 'template', so it is not considered >>> to be >>> +an image itself. >>> + >>> +The mechanism is very simple. For each phandle in the 'insert-templates' >>> +property, the source node is looked up. Then the subnodes of that source >>> node >>> +are copied into the target node, i.e. the one containing the >>> `insert-template` >>> +property. >
Re: [PATCH 07/12] binman: Provide a way to specific the fdt-list directly
On 28.06.23 13:41, Simon Glass wrote: > Sometimes multiple boards are built with binman and it is useful to > specify a different FDT list for each. At present this is not possible > without providing multiple values of the of-list entryarg (which is not > supported in the U-Boot build system). > > Allow a fit,fdt-list-val string-list property to be used instead. > > Signed-off-by: Simon Glass > --- > > tools/binman/entries.rst | 6 +++ > tools/binman/etype/fit.py | 9 > tools/binman/ftest.py | 14 ++- > tools/binman/test/284_fit_fdt_list.dts | 58 ++ > 4 files changed, 86 insertions(+), 1 deletion(-) > create mode 100644 tools/binman/test/284_fit_fdt_list.dts > > diff --git a/tools/binman/entries.rst b/tools/binman/entries.rst > index b71af801fdad..b55f424620a3 100644 > --- a/tools/binman/entries.rst > +++ b/tools/binman/entries.rst > @@ -615,6 +615,12 @@ The top-level 'fit' node supports the following special > properties: > `of-list` meaning that `-a of-list="dtb1 dtb2..."` should be passed > to binman. > > +fit,fdt-list-val > +As an alternative to fit,fdt-list the list of device tree files > +can be provided in this property as a string list, e.g.:: > + > +fit,fdt-list-val = "dtb1", "dtb2"; > + > Substitutions > ~ > > diff --git a/tools/binman/etype/fit.py b/tools/binman/etype/fit.py > index c395706ece5f..ef4d0667578d 100644 > --- a/tools/binman/etype/fit.py > +++ b/tools/binman/etype/fit.py > @@ -81,6 +81,12 @@ class Entry_fit(Entry_section): > `of-list` meaning that `-a of-list="dtb1 dtb2..."` should be > passed > to binman. > > +fit,fdt-list-val > +As an alternative to fit,fdt-list the list of device tree files > +can be provided in this property as a string list, e.g.:: > + > +fit,fdt-list-val = "dtb1", "dtb2"; > + > Substitutions > ~ > > @@ -361,6 +367,9 @@ class Entry_fit(Entry_section): > [EntryArg(self._fit_list_prop.value, str)]) > if fdts is not None: > self._fdts = fdts.split() > +else: > +self._fdts = fdt_util.GetStringList(self._node, > 'fit,fdt-list-val') > + > self._fit_default_dt = > self.GetEntryArgsOrProps([EntryArg('default-dt', >str)])[0] > > diff --git a/tools/binman/ftest.py b/tools/binman/ftest.py > index 6d0ffda2f432..54691c420733 100644 > --- a/tools/binman/ftest.py > +++ b/tools/binman/ftest.py > @@ -6739,6 +6739,18 @@ fdt fdtmapExtract the > devicetree blob from the fdtmap > # Just check that the data appears in the file somewhere > self.assertIn(U_BOOT_DATA, data) > > +def testFitFdtList(self): > +"""Test an image with an FIT with the fit,fdt-list-val option""" > +entry_args = { > +'default-dt': 'test-fdt2', > +} > +data = self._DoReadFileDtb( > +'284_fit_fdt_list.dts', > +entry_args=entry_args, > +extra_indirs=[os.path.join(self._indir, TEST_FDT_SUBDIR)])[0] > +self.assertEqual(U_BOOT_NODTB_DATA, data[-len(U_BOOT_NODTB_DATA):]) > +fit_data = data[len(U_BOOT_DATA):-len(U_BOOT_NODTB_DATA)] > + > > -if __name__ == "_s_main__": > +if __name__ == "__main__": > unittest.main() > diff --git a/tools/binman/test/284_fit_fdt_list.dts > b/tools/binman/test/284_fit_fdt_list.dts > new file mode 100644 > index ..8885313f5b88 > --- /dev/null > +++ b/tools/binman/test/284_fit_fdt_list.dts > @@ -0,0 +1,58 @@ > +// SPDX-License-Identifier: GPL-2.0+ > + > +/dts-v1/; > + > +/ { > + #address-cells = <1>; > + #size-cells = <1>; > + > + binman { > + u-boot { > + }; > + fit { > + description = "test-desc"; > + #address-cells = <1>; > + fit,fdt-list-val = "test-fdt1", "test-fdt2"; > + > + images { > + kernel { > + description = "Vanilla Linux kernel"; > + type = "kernel"; > + arch = "ppc"; > + os = "linux"; > + compression = "gzip"; > + load = <>; > + entry = <>; > + hash-1 { > + algo = "crc32"; > + }; > + hash-2 { > + algo = "sha1"; > + }; > + u-boot { > +
Re: [PATCH 12/12] binman: Support simple templates
Hi Simon, On 28.06.23 13:41, Simon Glass wrote: > Collections can used to collect the contents of other entries into a > single entry, but they result in a single entry, with the original entries > 'left behind' in their old place. > > It is useful to be able to specific a set of entries ones and have it used > in multiple images, or parts of an image. > > Implement this mechanism. > > Signed-off-by: Simon Glass > --- > > tools/binman/binman.rst | 80 > tools/binman/control.py | 9 +++ > tools/binman/etype/section.py| 3 +- > tools/binman/ftest.py| 8 +++ > tools/binman/test/286_entry_template.dts | 42 + > 5 files changed, 141 insertions(+), 1 deletion(-) > create mode 100644 tools/binman/test/286_entry_template.dts > > diff --git a/tools/binman/binman.rst b/tools/binman/binman.rst > index a4b31fe5397b..9be979ae1c5b 100644 > --- a/tools/binman/binman.rst > +++ b/tools/binman/binman.rst > @@ -727,6 +727,13 @@ optional: > Note that missing, optional blobs do not produce a non-zero exit code > from > binman, although it does show a warning about the missing external blob. > > +insert-template: > +This is not strictly speaking an entry property, since it is processed > early > +in Binman before the entries are read. It is a list of phandles of nodes > to > +include in the current (target) node. For each node, its subnodes and > their > +properties are brought into the target node. See Templates_ below for > +more information. > + > The attributes supported for images and sections are described below. Several > are similar to those for entries. > > @@ -1172,6 +1179,79 @@ If you are having trouble figuring out what is going > on, you can use > arch/arm/dts/u-boot.dtsi ... found: "arch/arm/dts/juno-r2-u-boot.dtsi" > > > +Templates > += > + > +Sometimes multiple images need to be created which have all have a common > +part. For example, a board may generate SPI and eMMC images which both > include > +a FIT. Since the FIT includes many entries, it is tedious to repeat them > twice > +in the image description. > + > +Templates provide a simple way to handle this:: > + > +binman { > +multiple-images; > +common_part: template-1 { > +fit { > +... lots of entries in here > +}; > + > +text { > +text = "base image"; > +}; > +}; > + > +spi-image { > +filename = "image-spi.bin"; > +insert-template = <&fit>; > + > +/* things specific to SPI follow */ > +header { > +]; > + > +text { > +text = "SPI image"; > +}; > +}; > + > +mmc-image { > +filename = "image-mmc.bin"; > +insert-template = <&fit>; > + > +/* things specific to MMC follow */ > +header { > +]; > + > +text { > +text = "MMC image"; > +}; > +}; > +}; > + > +The template node name must start with 'template', so it is not considered > to be > +an image itself. > + > +The mechanism is very simple. For each phandle in the 'insert-templates' > +property, the source node is looked up. Then the subnodes of that source node > +are copied into the target node, i.e. the one containing the > `insert-template` > +property. > + > +If the target node has a node with the same name as a template, its > properties > +override corresponding properties in the template. This allows the template > to > +be uses as a base, with the node providing updates to the properties as > needed. > +The overriding happens recursively. > + > +At present there is an unpleasant limitation on this feature: it works by > +appending the template nodes after any existing subnodes to the target node. > +This means that if the target node includes any subnodes, these appear in > order > +before the template node. In the above example, 'header' becomes the first > +subnode of each image, followed by `fit` and `text`. If this is not what is > +desired, there is no way to adjust it. > + > +Note: The above limitation will likely be removed in future, so that the > +template subnodes appear before the target subnodes. > + > + > Updating an ELF file > > > diff --git a/tools/binman/control.py b/tools/binman/control.py > index 68597c4e7792..e7faca78e9aa 100644 > --- a/tools/binman/control.py > +++ b/tools/binman/control.py > @@ -22,6 +22,7 @@ from binman import bintool > from binman import cbfs_util > from binman import elf > from binman import entry > +from dtoc import fdt_util > from u_boot_pylib import command > from u_boot_pylib import tools > from u_boot_pylib import tout > @@ -478,6 +479,12 @@ def SignEntries(image_fname, input_fname, > privatekey_fname, algo, en
Re: [PATCH 1/3] binman: Allow to define custom arguments
On 20.06.23 16:36, Simon Glass wrote: > Hi Jan, > > On Tue, 20 Jun 2023 at 11:37, Jan Kiszka wrote: >> >> On 20.06.23 12:11, Simon Glass wrote: >>> Hi Jan, >>> >>> On Mon, 19 Jun 2023 at 16:09, Jan Kiszka wrote: >>>> >>>> On 19.06.23 16:09, Simon Glass wrote: >>>>> Hi Jan, >>>>> >>>>> On Mon, 19 Jun 2023 at 14:28, Jan Kiszka wrote: >>>>>> >>>>>> On 19.06.23 14:36, Simon Glass wrote: >>>>>>> Hi Jan, >>>>>>> >>>>>>> On Fri, 16 Jun 2023 at 16:42, Jan Kiszka wrote: >>>>>>>> >>>>>>>> On 15.06.23 13:46, Jan Kiszka wrote: >>>>>>>>> On 15.06.23 13:38, Simon Glass wrote: >>>>>>>>>> Hi Jan, >>>>>>>>>> >>>>>>>>>> On Thu, 15 Jun 2023 at 12:21, Jan Kiszka >>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>> On 15.06.23 13:19, Simon Glass wrote: >>>>>>>>>>>> Hi Jan, >>>>>>>>>>>> >>>>>>>>>>>> On Thu, 15 Jun 2023 at 12:09, Jan Kiszka >>>>>>>>>>>> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> On 15.06.23 12:55, Simon Glass wrote: >>>>>>>>>>>>>> Hi Jan, >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Thu, 15 Jun 2023 at 11:26, Jan Kiszka >>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 12.06.23 23:17, Simon Glass wrote: >>>>>>>>>>>>>>>> Hi Jan, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On Mon, 5 Jun 2023 at 15:39, Jan Kiszka >>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> From: Jan Kiszka >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Introduce BINMAN_EXTRA_ARGS that can be set per board, e.g., >>>>>>>>>>>>>>>>> to inject >>>>>>>>>>>>>>>>> specific settings. Will be used by IOT2050 first to define >>>>>>>>>>>>>>>>> multiple >>>>>>>>>>>>>>>>> of-lists. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Signed-off-by: Jan Kiszka >>>>>>>>>>>>>>>>> --- >>>>>>>>>>>>>>>>> CC: Simon Glass >>>>>>>>>>>>>>>>> --- >>>>>>>>>>>>>>>>> Makefile | 1 + >>>>>>>>>>>>>>>>> 1 file changed, 1 insertion(+) >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I'm really not keen on this, since it means that the Makefile >>>>>>>>>>>>>>>> (or some >>>>>>>>>>>>>>>> vars it sets) are again involved in controlling the image >>>>>>>>>>>>>>>> generation. >>>>>>>>>>>>>>>> It should really all be in the binman image description / >>>>>>>>>>>>>>>> .dtsi file >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> binman does not allow me to unrole of-list inside the dts file, >>>>>>>>>>>>>>> does it? >>>>>>>>>>>>>>> With such a feature, I wouldn't need any custom -a of-list-X >>>>>>>>>>>>>>> switches >>>>>>>>>>>>>>> and, thus, no such EXTRA_ARGS. >>>>>>>>>>>>>> >>>>>>>>>>
Re: [PATCH 1/3] binman: Allow to define custom arguments
On 20.06.23 12:11, Simon Glass wrote: > Hi Jan, > > On Mon, 19 Jun 2023 at 16:09, Jan Kiszka wrote: >> >> On 19.06.23 16:09, Simon Glass wrote: >>> Hi Jan, >>> >>> On Mon, 19 Jun 2023 at 14:28, Jan Kiszka wrote: >>>> >>>> On 19.06.23 14:36, Simon Glass wrote: >>>>> Hi Jan, >>>>> >>>>> On Fri, 16 Jun 2023 at 16:42, Jan Kiszka wrote: >>>>>> >>>>>> On 15.06.23 13:46, Jan Kiszka wrote: >>>>>>> On 15.06.23 13:38, Simon Glass wrote: >>>>>>>> Hi Jan, >>>>>>>> >>>>>>>> On Thu, 15 Jun 2023 at 12:21, Jan Kiszka >>>>>>>> wrote: >>>>>>>>> >>>>>>>>> On 15.06.23 13:19, Simon Glass wrote: >>>>>>>>>> Hi Jan, >>>>>>>>>> >>>>>>>>>> On Thu, 15 Jun 2023 at 12:09, Jan Kiszka >>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>> On 15.06.23 12:55, Simon Glass wrote: >>>>>>>>>>>> Hi Jan, >>>>>>>>>>>> >>>>>>>>>>>> On Thu, 15 Jun 2023 at 11:26, Jan Kiszka >>>>>>>>>>>> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> On 12.06.23 23:17, Simon Glass wrote: >>>>>>>>>>>>>> Hi Jan, >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Mon, 5 Jun 2023 at 15:39, Jan Kiszka >>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> From: Jan Kiszka >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Introduce BINMAN_EXTRA_ARGS that can be set per board, e.g., to >>>>>>>>>>>>>>> inject >>>>>>>>>>>>>>> specific settings. Will be used by IOT2050 first to define >>>>>>>>>>>>>>> multiple >>>>>>>>>>>>>>> of-lists. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Signed-off-by: Jan Kiszka >>>>>>>>>>>>>>> --- >>>>>>>>>>>>>>> CC: Simon Glass >>>>>>>>>>>>>>> --- >>>>>>>>>>>>>>> Makefile | 1 + >>>>>>>>>>>>>>> 1 file changed, 1 insertion(+) >>>>>>>>>>>>>> >>>>>>>>>>>>>> I'm really not keen on this, since it means that the Makefile >>>>>>>>>>>>>> (or some >>>>>>>>>>>>>> vars it sets) are again involved in controlling the image >>>>>>>>>>>>>> generation. >>>>>>>>>>>>>> It should really all be in the binman image description / .dtsi >>>>>>>>>>>>>> file >>>>>>>>>>>>> >>>>>>>>>>>>> binman does not allow me to unrole of-list inside the dts file, >>>>>>>>>>>>> does it? >>>>>>>>>>>>> With such a feature, I wouldn't need any custom -a of-list-X >>>>>>>>>>>>> switches >>>>>>>>>>>>> and, thus, no such EXTRA_ARGS. >>>>>>>>>>>> >>>>>>>>>>>> Can you explain a bit more about what you mean by 'unrole'? It is >>>>>>>>>>>> just >>>>>>>>>>>> software, so anything should be possible. >>>>>>>>>>> >>>>>>>>>>> To use a DT sequence, I need to specify fit,ftd-list. But I can say >>>>>>>>>>> >>>>>>>>>>> fit,ftd-list = "first.dtb second.dtb" >>>>>>>>>>> >>>>>>>>>>> I rather need to go via the EntryArg indirection
Re: [PATCH 1/3] binman: Allow to define custom arguments
On 19.06.23 16:09, Simon Glass wrote: > Hi Jan, > > On Mon, 19 Jun 2023 at 14:28, Jan Kiszka wrote: >> >> On 19.06.23 14:36, Simon Glass wrote: >>> Hi Jan, >>> >>> On Fri, 16 Jun 2023 at 16:42, Jan Kiszka wrote: >>>> >>>> On 15.06.23 13:46, Jan Kiszka wrote: >>>>> On 15.06.23 13:38, Simon Glass wrote: >>>>>> Hi Jan, >>>>>> >>>>>> On Thu, 15 Jun 2023 at 12:21, Jan Kiszka wrote: >>>>>>> >>>>>>> On 15.06.23 13:19, Simon Glass wrote: >>>>>>>> Hi Jan, >>>>>>>> >>>>>>>> On Thu, 15 Jun 2023 at 12:09, Jan Kiszka >>>>>>>> wrote: >>>>>>>>> >>>>>>>>> On 15.06.23 12:55, Simon Glass wrote: >>>>>>>>>> Hi Jan, >>>>>>>>>> >>>>>>>>>> On Thu, 15 Jun 2023 at 11:26, Jan Kiszka >>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>> On 12.06.23 23:17, Simon Glass wrote: >>>>>>>>>>>> Hi Jan, >>>>>>>>>>>> >>>>>>>>>>>> On Mon, 5 Jun 2023 at 15:39, Jan Kiszka >>>>>>>>>>>> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> From: Jan Kiszka >>>>>>>>>>>>> >>>>>>>>>>>>> Introduce BINMAN_EXTRA_ARGS that can be set per board, e.g., to >>>>>>>>>>>>> inject >>>>>>>>>>>>> specific settings. Will be used by IOT2050 first to define >>>>>>>>>>>>> multiple >>>>>>>>>>>>> of-lists. >>>>>>>>>>>>> >>>>>>>>>>>>> Signed-off-by: Jan Kiszka >>>>>>>>>>>>> --- >>>>>>>>>>>>> CC: Simon Glass >>>>>>>>>>>>> --- >>>>>>>>>>>>> Makefile | 1 + >>>>>>>>>>>>> 1 file changed, 1 insertion(+) >>>>>>>>>>>> >>>>>>>>>>>> I'm really not keen on this, since it means that the Makefile (or >>>>>>>>>>>> some >>>>>>>>>>>> vars it sets) are again involved in controlling the image >>>>>>>>>>>> generation. >>>>>>>>>>>> It should really all be in the binman image description / .dtsi >>>>>>>>>>>> file >>>>>>>>>>> >>>>>>>>>>> binman does not allow me to unrole of-list inside the dts file, >>>>>>>>>>> does it? >>>>>>>>>>> With such a feature, I wouldn't need any custom -a of-list-X >>>>>>>>>>> switches >>>>>>>>>>> and, thus, no such EXTRA_ARGS. >>>>>>>>>> >>>>>>>>>> Can you explain a bit more about what you mean by 'unrole'? It is >>>>>>>>>> just >>>>>>>>>> software, so anything should be possible. >>>>>>>>> >>>>>>>>> To use a DT sequence, I need to specify fit,ftd-list. But I can say >>>>>>>>> >>>>>>>>> fit,ftd-list = "first.dtb second.dtb" >>>>>>>>> >>>>>>>>> I rather need to go via the EntryArg indirection of the binman >>>>>>>>> command line. >>>>>>>> >>>>>>>> Do you mean you would rather not use '-a CONFIG_OF_LIST'. Or are you >>>>>>>> wanting to filter that list based on something else? >>>>>>>> >>>>>>>> I'm afraid I am really not following this at all. >>>>>>> >>>>>>> CONFIG_OF_LIST is not working here as we have two different boards with >>>>>>> two different lists. >>>>>> >>>>>> But we only build one board at a time, don't we? >>>>> >>>>> No, this is about building two flash images for two different board >>>>> generations in the same binman run (see patch 3). >>>>> >>>>>> >>>>>> We could provide a way to select between different lists, but how does >>>>>> Makefile get access to them? >>>>> >>>>> See patch 3: known lists, now put into board config.mk. >>>>> >>>> >>>> Any better suggestions for this issue? Otherwise, I will have to keep >>>> binman args extension for now. >>> >>> I've dug into this a bit. The use of #defines and macros looks to be >>> unnecessary, unless I am missing something. >>> >>> You can do things like this: >>> >>> fit_node: fit { >>> // base definition of FIT >>> }; >>> >>> the later on: >>> >>> fit_node: { >>> #ifdef xxx >>>// override a few things >>>fit,fdt-list = ... >>> #else >>> >>> #endif >> >> As I wrote already, I have a solution for that by using a template dtsi. >> >>> >>> There is no need to specify the properties all at once. You can update >>> a property later on just by referring to its node as above. >> >> Does not help when the anchor name needs to vary as well. That's where I >> will use a #define to customize the template on include. >> >>> >>> I think with this you should be above to eliminate BINMAN_EXTRA_ARGS >>> and all the #define stuff. >> >> You still didn't address my question. Should I share my version to make >> the problem clearer? But I thought I explained this in various shades >> already. > > Yes, if I am looking at the wrong patches, please point me to the > correct series, or push a tree somewhere. > Please have a look at https://github.com/siemens/u-boot/commit/393ce2b78cee9214edda7f7e04f6ca2ce144195e Thanks, Jan -- Siemens AG, Technology Competence Center Embedded Linux
Re: [PATCH 1/3] binman: Allow to define custom arguments
On 19.06.23 14:36, Simon Glass wrote: > Hi Jan, > > On Fri, 16 Jun 2023 at 16:42, Jan Kiszka wrote: >> >> On 15.06.23 13:46, Jan Kiszka wrote: >>> On 15.06.23 13:38, Simon Glass wrote: >>>> Hi Jan, >>>> >>>> On Thu, 15 Jun 2023 at 12:21, Jan Kiszka wrote: >>>>> >>>>> On 15.06.23 13:19, Simon Glass wrote: >>>>>> Hi Jan, >>>>>> >>>>>> On Thu, 15 Jun 2023 at 12:09, Jan Kiszka wrote: >>>>>>> >>>>>>> On 15.06.23 12:55, Simon Glass wrote: >>>>>>>> Hi Jan, >>>>>>>> >>>>>>>> On Thu, 15 Jun 2023 at 11:26, Jan Kiszka >>>>>>>> wrote: >>>>>>>>> >>>>>>>>> On 12.06.23 23:17, Simon Glass wrote: >>>>>>>>>> Hi Jan, >>>>>>>>>> >>>>>>>>>> On Mon, 5 Jun 2023 at 15:39, Jan Kiszka >>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>> From: Jan Kiszka >>>>>>>>>>> >>>>>>>>>>> Introduce BINMAN_EXTRA_ARGS that can be set per board, e.g., to >>>>>>>>>>> inject >>>>>>>>>>> specific settings. Will be used by IOT2050 first to define multiple >>>>>>>>>>> of-lists. >>>>>>>>>>> >>>>>>>>>>> Signed-off-by: Jan Kiszka >>>>>>>>>>> --- >>>>>>>>>>> CC: Simon Glass >>>>>>>>>>> --- >>>>>>>>>>> Makefile | 1 + >>>>>>>>>>> 1 file changed, 1 insertion(+) >>>>>>>>>> >>>>>>>>>> I'm really not keen on this, since it means that the Makefile (or >>>>>>>>>> some >>>>>>>>>> vars it sets) are again involved in controlling the image generation. >>>>>>>>>> It should really all be in the binman image description / .dtsi file >>>>>>>>> >>>>>>>>> binman does not allow me to unrole of-list inside the dts file, does >>>>>>>>> it? >>>>>>>>> With such a feature, I wouldn't need any custom -a of-list-X switches >>>>>>>>> and, thus, no such EXTRA_ARGS. >>>>>>>> >>>>>>>> Can you explain a bit more about what you mean by 'unrole'? It is just >>>>>>>> software, so anything should be possible. >>>>>>> >>>>>>> To use a DT sequence, I need to specify fit,ftd-list. But I can say >>>>>>> >>>>>>> fit,ftd-list = "first.dtb second.dtb" >>>>>>> >>>>>>> I rather need to go via the EntryArg indirection of the binman command >>>>>>> line. >>>>>> >>>>>> Do you mean you would rather not use '-a CONFIG_OF_LIST'. Or are you >>>>>> wanting to filter that list based on something else? >>>>>> >>>>>> I'm afraid I am really not following this at all. >>>>> >>>>> CONFIG_OF_LIST is not working here as we have two different boards with >>>>> two different lists. >>>> >>>> But we only build one board at a time, don't we? >>> >>> No, this is about building two flash images for two different board >>> generations in the same binman run (see patch 3). >>> >>>> >>>> We could provide a way to select between different lists, but how does >>>> Makefile get access to them? >>> >>> See patch 3: known lists, now put into board config.mk. >>> >> >> Any better suggestions for this issue? Otherwise, I will have to keep >> binman args extension for now. > > I've dug into this a bit. The use of #defines and macros looks to be > unnecessary, unless I am missing something. > > You can do things like this: > > fit_node: fit { > // base definition of FIT > }; > > the later on: > > fit_node: { > #ifdef xxx >// override a few things >fit,fdt-list = ... > #else > > #endif As I wrote already, I have a solution for that by using a template dtsi. > > There is no need to specify the properties all at once. You can update > a property later on just by referring to its node as above. Does not help when the anchor name needs to vary as well. That's where I will use a #define to customize the template on include. > > I think with this you should be above to eliminate BINMAN_EXTRA_ARGS > and all the #define stuff. You still didn't address my question. Should I share my version to make the problem clearer? But I thought I explained this in various shades already. Jan -- Siemens AG, Technology Competence Center Embedded Linux
Re: [PATCH 1/3] binman: Allow to define custom arguments
On 15.06.23 13:46, Jan Kiszka wrote: > On 15.06.23 13:38, Simon Glass wrote: >> Hi Jan, >> >> On Thu, 15 Jun 2023 at 12:21, Jan Kiszka wrote: >>> >>> On 15.06.23 13:19, Simon Glass wrote: >>>> Hi Jan, >>>> >>>> On Thu, 15 Jun 2023 at 12:09, Jan Kiszka wrote: >>>>> >>>>> On 15.06.23 12:55, Simon Glass wrote: >>>>>> Hi Jan, >>>>>> >>>>>> On Thu, 15 Jun 2023 at 11:26, Jan Kiszka wrote: >>>>>>> >>>>>>> On 12.06.23 23:17, Simon Glass wrote: >>>>>>>> Hi Jan, >>>>>>>> >>>>>>>> On Mon, 5 Jun 2023 at 15:39, Jan Kiszka wrote: >>>>>>>>> >>>>>>>>> From: Jan Kiszka >>>>>>>>> >>>>>>>>> Introduce BINMAN_EXTRA_ARGS that can be set per board, e.g., to inject >>>>>>>>> specific settings. Will be used by IOT2050 first to define multiple >>>>>>>>> of-lists. >>>>>>>>> >>>>>>>>> Signed-off-by: Jan Kiszka >>>>>>>>> --- >>>>>>>>> CC: Simon Glass >>>>>>>>> --- >>>>>>>>> Makefile | 1 + >>>>>>>>> 1 file changed, 1 insertion(+) >>>>>>>> >>>>>>>> I'm really not keen on this, since it means that the Makefile (or some >>>>>>>> vars it sets) are again involved in controlling the image generation. >>>>>>>> It should really all be in the binman image description / .dtsi file >>>>>>> >>>>>>> binman does not allow me to unrole of-list inside the dts file, does it? >>>>>>> With such a feature, I wouldn't need any custom -a of-list-X switches >>>>>>> and, thus, no such EXTRA_ARGS. >>>>>> >>>>>> Can you explain a bit more about what you mean by 'unrole'? It is just >>>>>> software, so anything should be possible. >>>>> >>>>> To use a DT sequence, I need to specify fit,ftd-list. But I can say >>>>> >>>>> fit,ftd-list = "first.dtb second.dtb" >>>>> >>>>> I rather need to go via the EntryArg indirection of the binman command >>>>> line. >>>> >>>> Do you mean you would rather not use '-a CONFIG_OF_LIST'. Or are you >>>> wanting to filter that list based on something else? >>>> >>>> I'm afraid I am really not following this at all. >>> >>> CONFIG_OF_LIST is not working here as we have two different boards with >>> two different lists. >> >> But we only build one board at a time, don't we? > > No, this is about building two flash images for two different board > generations in the same binman run (see patch 3). > >> >> We could provide a way to select between different lists, but how does >> Makefile get access to them? > > See patch 3: known lists, now put into board config.mk. > Any better suggestions for this issue? Otherwise, I will have to keep binman args extension for now. Jan -- Siemens AG, Technology Competence Center Embedded Linux
Re: [PATCH 1/3] binman: Allow to define custom arguments
On 15.06.23 13:38, Simon Glass wrote: > Hi Jan, > > On Thu, 15 Jun 2023 at 12:21, Jan Kiszka wrote: >> >> On 15.06.23 13:19, Simon Glass wrote: >>> Hi Jan, >>> >>> On Thu, 15 Jun 2023 at 12:09, Jan Kiszka wrote: >>>> >>>> On 15.06.23 12:55, Simon Glass wrote: >>>>> Hi Jan, >>>>> >>>>> On Thu, 15 Jun 2023 at 11:26, Jan Kiszka wrote: >>>>>> >>>>>> On 12.06.23 23:17, Simon Glass wrote: >>>>>>> Hi Jan, >>>>>>> >>>>>>> On Mon, 5 Jun 2023 at 15:39, Jan Kiszka wrote: >>>>>>>> >>>>>>>> From: Jan Kiszka >>>>>>>> >>>>>>>> Introduce BINMAN_EXTRA_ARGS that can be set per board, e.g., to inject >>>>>>>> specific settings. Will be used by IOT2050 first to define multiple >>>>>>>> of-lists. >>>>>>>> >>>>>>>> Signed-off-by: Jan Kiszka >>>>>>>> --- >>>>>>>> CC: Simon Glass >>>>>>>> --- >>>>>>>> Makefile | 1 + >>>>>>>> 1 file changed, 1 insertion(+) >>>>>>> >>>>>>> I'm really not keen on this, since it means that the Makefile (or some >>>>>>> vars it sets) are again involved in controlling the image generation. >>>>>>> It should really all be in the binman image description / .dtsi file >>>>>> >>>>>> binman does not allow me to unrole of-list inside the dts file, does it? >>>>>> With such a feature, I wouldn't need any custom -a of-list-X switches >>>>>> and, thus, no such EXTRA_ARGS. >>>>> >>>>> Can you explain a bit more about what you mean by 'unrole'? It is just >>>>> software, so anything should be possible. >>>> >>>> To use a DT sequence, I need to specify fit,ftd-list. But I can say >>>> >>>> fit,ftd-list = "first.dtb second.dtb" >>>> >>>> I rather need to go via the EntryArg indirection of the binman command >>>> line. >>> >>> Do you mean you would rather not use '-a CONFIG_OF_LIST'. Or are you >>> wanting to filter that list based on something else? >>> >>> I'm afraid I am really not following this at all. >> >> CONFIG_OF_LIST is not working here as we have two different boards with >> two different lists. > > But we only build one board at a time, don't we? No, this is about building two flash images for two different board generations in the same binman run (see patch 3). > > We could provide a way to select between different lists, but how does > Makefile get access to them? See patch 3: known lists, now put into board config.mk. Jan -- Siemens AG, Technology Competence Center Embedded Linux
Re: [PATCH 3/3] boards: siemens: iot2050: Unify PG1 and PG2/M.2 configurations again
On 12.06.23 23:17, Simon Glass wrote: > Hi Jan, > > On Mon, 5 Jun 2023 at 15:40, Jan Kiszka wrote: >> >> From: Jan Kiszka >> >> This avoids having to maintain to defconfigs that are 99% equivalent. >> The approach is to use binman to generate two flash images, >> flash-pg1.bin and flash-pg2.bin. With the help of some macros, we can >> avoid duplicating the common binman image definitions. >> >> Suggested-by: Andrew Davis >> Signed-off-by: Jan Kiszka >> --- >> arch/arm/dts/k3-am65-iot2050-boot-image.dtsi | 299 ++ >> board/siemens/iot2050/Kconfig | 30 +- >> board/siemens/iot2050/board.c | 14 +- >> board/siemens/iot2050/config.mk | 6 +- >> ...ot2050_pg1_defconfig => iot2050_defconfig} | 3 +- >> configs/iot2050_pg2_defconfig | 150 - >> doc/board/siemens/iot2050.rst | 29 +- >> tools/iot2050-sign-fw.sh | 9 +- >> 8 files changed, 202 insertions(+), 338 deletions(-) >> rename configs/{iot2050_pg1_defconfig => iot2050_defconfig} (97%) >> delete mode 100644 configs/iot2050_pg2_defconfig > > We need to find another way to do this... the macros are horrible. > > Could you put the common code in another .dtsi file and include it twice? > > Then in the 'main' .dtsi file refer to some anchors to set the properties: > > &u_boot { >fit,fdt-list = "..."; > }; I can use some preprocessor defines in that template code which need to be re-defined before the inclusions. Prototype is working already. > > Or do we need a new binman feature to handle this? > > BTW using #ifdef on a particular target is something we should avoid. > Isn't there another Kconfig (for the feature itself) that you can use? What are you referring to? Jan -- Siemens AG, Technology Competence Center Embedded Linux
Re: [PATCH 1/3] binman: Allow to define custom arguments
On 15.06.23 13:19, Simon Glass wrote: > Hi Jan, > > On Thu, 15 Jun 2023 at 12:09, Jan Kiszka wrote: >> >> On 15.06.23 12:55, Simon Glass wrote: >>> Hi Jan, >>> >>> On Thu, 15 Jun 2023 at 11:26, Jan Kiszka wrote: >>>> >>>> On 12.06.23 23:17, Simon Glass wrote: >>>>> Hi Jan, >>>>> >>>>> On Mon, 5 Jun 2023 at 15:39, Jan Kiszka wrote: >>>>>> >>>>>> From: Jan Kiszka >>>>>> >>>>>> Introduce BINMAN_EXTRA_ARGS that can be set per board, e.g., to inject >>>>>> specific settings. Will be used by IOT2050 first to define multiple >>>>>> of-lists. >>>>>> >>>>>> Signed-off-by: Jan Kiszka >>>>>> --- >>>>>> CC: Simon Glass >>>>>> --- >>>>>> Makefile | 1 + >>>>>> 1 file changed, 1 insertion(+) >>>>> >>>>> I'm really not keen on this, since it means that the Makefile (or some >>>>> vars it sets) are again involved in controlling the image generation. >>>>> It should really all be in the binman image description / .dtsi file >>>> >>>> binman does not allow me to unrole of-list inside the dts file, does it? >>>> With such a feature, I wouldn't need any custom -a of-list-X switches >>>> and, thus, no such EXTRA_ARGS. >>> >>> Can you explain a bit more about what you mean by 'unrole'? It is just >>> software, so anything should be possible. >> >> To use a DT sequence, I need to specify fit,ftd-list. But I can say >> >> fit,ftd-list = "first.dtb second.dtb" >> >> I rather need to go via the EntryArg indirection of the binman command line. > > Do you mean you would rather not use '-a CONFIG_OF_LIST'. Or are you > wanting to filter that list based on something else? > > I'm afraid I am really not following this at all. CONFIG_OF_LIST is not working here as we have two different boards with two different lists. Jan -- Siemens AG, Technology Competence Center Embedded Linux
Re: [PATCH 1/3] binman: Allow to define custom arguments
On 15.06.23 12:55, Simon Glass wrote: > Hi Jan, > > On Thu, 15 Jun 2023 at 11:26, Jan Kiszka wrote: >> >> On 12.06.23 23:17, Simon Glass wrote: >>> Hi Jan, >>> >>> On Mon, 5 Jun 2023 at 15:39, Jan Kiszka wrote: >>>> >>>> From: Jan Kiszka >>>> >>>> Introduce BINMAN_EXTRA_ARGS that can be set per board, e.g., to inject >>>> specific settings. Will be used by IOT2050 first to define multiple >>>> of-lists. >>>> >>>> Signed-off-by: Jan Kiszka >>>> --- >>>> CC: Simon Glass >>>> --- >>>> Makefile | 1 + >>>> 1 file changed, 1 insertion(+) >>> >>> I'm really not keen on this, since it means that the Makefile (or some >>> vars it sets) are again involved in controlling the image generation. >>> It should really all be in the binman image description / .dtsi file >> >> binman does not allow me to unrole of-list inside the dts file, does it? >> With such a feature, I wouldn't need any custom -a of-list-X switches >> and, thus, no such EXTRA_ARGS. > > Can you explain a bit more about what you mean by 'unrole'? It is just > software, so anything should be possible. To use a DT sequence, I need to specify fit,ftd-list. But I can say fit,ftd-list = "first.dtb second.dtb" I rather need to go via the EntryArg indirection of the binman command line. Jan -- Siemens AG, Technology Competence Center Embedded Linux
Re: [PATCH 1/3] binman: Allow to define custom arguments
On 12.06.23 23:17, Simon Glass wrote: > Hi Jan, > > On Mon, 5 Jun 2023 at 15:39, Jan Kiszka wrote: >> >> From: Jan Kiszka >> >> Introduce BINMAN_EXTRA_ARGS that can be set per board, e.g., to inject >> specific settings. Will be used by IOT2050 first to define multiple >> of-lists. >> >> Signed-off-by: Jan Kiszka >> --- >> CC: Simon Glass >> --- >> Makefile | 1 + >> 1 file changed, 1 insertion(+) > > I'm really not keen on this, since it means that the Makefile (or some > vars it sets) are again involved in controlling the image generation. > It should really all be in the binman image description / .dtsi file binman does not allow me to unrole of-list inside the dts file, does it? With such a feature, I wouldn't need any custom -a of-list-X switches and, thus, no such EXTRA_ARGS. Jan -- Siemens AG, Technology Competence Center Embedded Linux
Re: [PATCH v4 11/11] configs: starfive: Enable ID EEPROM configuration
On 07.06.23 04:19, yanhong wang wrote: > > > On 2023/6/5 3:23, Jan Kiszka wrote: >> On 25.05.23 11:36, Yanhong Wang wrote: >>> Enabled ID_EEPROM and I2C configuration for StarFive VisionFive2 board. >>> >>> Signed-off-by: Yanhong Wang >>> --- >>> configs/starfive_visionfive2_defconfig | 19 ++- >>> 1 file changed, 18 insertions(+), 1 deletion(-) >>> >>> diff --git a/configs/starfive_visionfive2_defconfig >>> b/configs/starfive_visionfive2_defconfig >>> index c57708199d..570a1f53a1 100644 >>> --- a/configs/starfive_visionfive2_defconfig >>> +++ b/configs/starfive_visionfive2_defconfig >>> @@ -13,6 +13,7 @@ CONFIG_SYS_PROMPT="StarFive #" >>> CONFIG_OF_LIBFDT_OVERLAY=y >>> CONFIG_DM_RESET=y >>> CONFIG_SPL_MMC=y >>> +CONFIG_SPL_DRIVERS_MISC=y >>> CONFIG_SPL_STACK=0x818 >>> CONFIG_SPL=y >>> CONFIG_SPL_SPI_FLASH_SUPPORT=y >>> @@ -23,6 +24,7 @@ CONFIG_SPL_OPENSBI_LOAD_ADDR=0x4000 >>> CONFIG_ARCH_RV64I=y >>> CONFIG_CMODEL_MEDANY=y >>> CONFIG_RISCV_SMODE=y >>> +# CONFIG_OF_BOARD_FIXUP is not set >>> CONFIG_FIT=y >>> CONFIG_DISTRO_DEFAULTS=y >>> CONFIG_QSPI_BOOT=y >>> @@ -34,6 +36,8 @@ CONFIG_PREBOOT="setenv fdt_addr ${fdtcontroladdr};fdt >>> addr ${fdtcontroladdr};" >>> CONFIG_DEFAULT_FDT_FILE="starfive/jh7110-starfive-visionfive-2.dtb" >>> CONFIG_DISPLAY_CPUINFO=y >>> CONFIG_DISPLAY_BOARDINFO=y >>> +CONFIG_ID_EEPROM=y >>> +CONFIG_SYS_EEPROM_BUS_NUM=5 >>> CONFIG_SPL_MAX_SIZE=0x4 >>> CONFIG_SPL_PAD_TO=0x0 >>> CONFIG_SPL_BSS_START_ADDR=0x804 >>> @@ -45,21 +49,34 @@ CONFIG_CUSTOM_SYS_SPL_MALLOC_ADDR=0x8000 >>> CONFIG_SYS_SPL_MALLOC_SIZE=0x40 >>> CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_USE_PARTITION=y >>> CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_PARTITION=0x2 >>> +CONFIG_SPL_I2C=y >>> CONFIG_SPL_DM_SPI_FLASH=y >>> CONFIG_SPL_DM_RESET=y >>> CONFIG_SPL_SPI_LOAD=y >>> CONFIG_SYS_CBSIZE=256 >>> CONFIG_SYS_PBSIZE=276 >>> CONFIG_SYS_BOOTM_LEN=0x400 >>> +CONFIG_CMD_EEPROM=y >>> +CONFIG_SYS_EEPROM_SIZE=512 >>> +CONFIG_SYS_EEPROM_PAGE_WRITE_BITS=4 >>> +CONFIG_SYS_EEPROM_PAGE_WRITE_DELAY_MS=5 >>> CONFIG_CMD_MEMINFO=y >>> +CONFIG_CMD_I2C=y >>> CONFIG_CMD_TFTPPUT=y >>> +CONFIG_OF_BOARD=y >>> CONFIG_SYS_RELOC_GD_ENV_ADDR=y >>> +CONFIG_SPL_DM_SEQ_ALIAS=y >>> CONFIG_REGMAP=y >>> CONFIG_SYSCON=y >>> CONFIG_SPL_CLK_COMPOSITE_CCF=y >>> CONFIG_CLK_COMPOSITE_CCF=y >>> CONFIG_SPL_CLK_JH7110=y >>> -# CONFIG_I2C is not set >>> +CONFIG_DM_I2C=y >>> +CONFIG_SYS_I2C_DW=y >>> +CONFIG_MISC=y >>> +CONFIG_I2C_EEPROM=y >>> +CONFIG_SPL_I2C_EEPROM=y >>> +CONFIG_SYS_I2C_EEPROM_ADDR=0X50 >>> CONFIG_MMC_HS400_SUPPORT=y >>> CONFIG_SPL_MMC_HS400_SUPPORT=y >>> CONFIG_MMC_DW=y >> >> This comes too late: Already patch 4 needs at least CONFIG_ID_EEPROM=y, >> if not more. >> > > Moving patch 4 to the series end, is that okay? > I didn't try. I would recommend that you to run a quick build check after each patch being applied for the affected defconfig(s). Can be automated (git rebase --exec ...). Jan -- Siemens AG, Technology Competence Center Embedded Linux
[PATCH 3/3] boards: siemens: iot2050: Unify PG1 and PG2/M.2 configurations again
From: Jan Kiszka This avoids having to maintain to defconfigs that are 99% equivalent. The approach is to use binman to generate two flash images, flash-pg1.bin and flash-pg2.bin. With the help of some macros, we can avoid duplicating the common binman image definitions. Suggested-by: Andrew Davis Signed-off-by: Jan Kiszka --- arch/arm/dts/k3-am65-iot2050-boot-image.dtsi | 299 ++ board/siemens/iot2050/Kconfig | 30 +- board/siemens/iot2050/board.c | 14 +- board/siemens/iot2050/config.mk | 6 +- ...ot2050_pg1_defconfig => iot2050_defconfig} | 3 +- configs/iot2050_pg2_defconfig | 150 - doc/board/siemens/iot2050.rst | 29 +- tools/iot2050-sign-fw.sh | 9 +- 8 files changed, 202 insertions(+), 338 deletions(-) rename configs/{iot2050_pg1_defconfig => iot2050_defconfig} (97%) delete mode 100644 configs/iot2050_pg2_defconfig diff --git a/arch/arm/dts/k3-am65-iot2050-boot-image.dtsi b/arch/arm/dts/k3-am65-iot2050-boot-image.dtsi index 03ccc543293..1ea3fa85120 100644 --- a/arch/arm/dts/k3-am65-iot2050-boot-image.dtsi +++ b/arch/arm/dts/k3-am65-iot2050-boot-image.dtsi @@ -1,6 +1,6 @@ // SPDX-License-Identifier: GPL-2.0 /* - * Copyright (c) Siemens AG, 2020-2022 + * Copyright (c) Siemens AG, 2020-2023 * * Authors: * Jan Kiszka @@ -8,158 +8,177 @@ */ #include +#include -/ { - binman { - filename = "flash.bin"; - pad-byte = <0xff>; - size = <0x8c>; - allow-repack; - - blob-ext@0x00 { - offset = <0x00>; -#ifdef CONFIG_TARGET_IOT2050_A53_PG1 - filename = "seboot_pg1.bin"; +#ifdef CONFIG_WDT_K3_RTI_FW_FILE +#define IOT2050_WDT_FIRMWARE_LOADABLE "k3-rti-wdt-firmware" +#define IOT2050_WDT_FIRMWARE \ + k3-rti-wdt-firmware { \ + type = "firmware"; \ + load = <0x8200>;\ + arch = "arm"; \ + compression = "none"; \ + blob-ext { \ + filename = CONFIG_WDT_K3_RTI_FW_FILE; \ + missing-msg = IOT2050_WDT_FIRMWARE_LOADABLE;\ + }; \ + hash { \ + algo = "sha256";\ + }; \ + }; #else - filename = "seboot_pg2.bin"; +#define IOT2050_WDT_FIRMWARE_LOADABLE +#define IOT2050_WDT_FIRMWARE #endif - missing-msg = "iot2050-seboot"; - }; - - blob@0x18 { - offset = <0x18>; - filename = "tispl.bin"; - }; - - fit@0x38 { - description = "U-Boot for IOT2050"; - fit,fdt-list = "of-list"; - offset = <0x38>; - images { - u-boot { - description = "U-Boot"; - type = "standalone"; - arch = "arm64"; - os = "u-boot"; - compression = "none"; - load = <0x8080>; - entry = <0x8080>; - u-boot-nodtb { - }; - hash { - algo = "sha256"; - }; - }; - @fdt-SEQ { - description = "fdt-NAME"; - type = "flat_dt"; - arch = "arm64"; - compression = "none"; - hash { - algo = "sha256"; - }; - }; - -#ifdef CONFIG_TARGET_IOT2050_A53_PG2 -
[PATCH 2/3] iot2050: Use binman in signing script
From: Jan Kiszka The underlying issue was fixed in the meantime. Switching to fully binman-based signing (script-free) remains a todo, though. Signed-off-by: Jan Kiszka --- CC: Simon Glass --- tools/iot2050-sign-fw.sh | 8 ++-- 1 file changed, 2 insertions(+), 6 deletions(-) diff --git a/tools/iot2050-sign-fw.sh b/tools/iot2050-sign-fw.sh index 4d1d79498c2..da425c94a5d 100755 --- a/tools/iot2050-sign-fw.sh +++ b/tools/iot2050-sign-fw.sh @@ -39,13 +39,9 @@ CERT_X509=$(mktemp .crt) openssl req -new -x509 -key $1 -nodes -outform DER -out $CERT_X509 -config $TEMP_X509 -sha512 cat $CERT_X509 tispl.bin > tispl.bin_signed -# currently broken in upstream -#source/tools/binman/binman replace -i flash.bin -f tispl.bin_signed blob@0x18 -dd if=tispl.bin_signed of=flash.bin bs=$((0x1000)) seek=$((0x18/0x1000)) conv=notrunc +source/tools/binman/binman replace -i flash.bin -f tispl.bin_signed blob@0x18 rm $TEMP_X509 $CERT_X509 tools/mkimage -G $1 -r -o sha256,rsa4096 -F f...@0x38.fit -# currently broken in upstream -#source/tools/binman/binman replace -i flash.bin -f f...@0x38.fit fit@0x38 -dd if=f...@0x38.fit of=flash.bin bs=$((0x1000)) seek=$((0x38/0x1000)) conv=notrunc +source/tools/binman/binman replace -i flash.bin -f f...@0x38.fit fit@0x38 -- 2.35.3
[PATCH 0/3] iot2050: Re-unify its configs and build processes
This restores the possibility to build firmware images for both PG1 and PG2-based IOT2050 devices in one run. We still end up with different binaries, but the the build is now fed again from a single defconfig. Should simplify maintenance and will also simplify our generation tooling around it. Jan CC: Simon Glass Jan Kiszka (3): binman: Allow to define custom arguments iot2050: Use binman in signing script boards: siemens: iot2050: Unify PG1 and PG2/M.2 configurations again Makefile | 1 + arch/arm/dts/k3-am65-iot2050-boot-image.dtsi | 299 ++ board/siemens/iot2050/Kconfig | 30 +- board/siemens/iot2050/board.c | 14 +- board/siemens/iot2050/config.mk | 6 +- ...ot2050_pg1_defconfig => iot2050_defconfig} | 3 +- configs/iot2050_pg2_defconfig | 150 - doc/board/siemens/iot2050.rst | 29 +- tools/iot2050-sign-fw.sh | 13 +- 9 files changed, 203 insertions(+), 342 deletions(-) rename configs/{iot2050_pg1_defconfig => iot2050_defconfig} (97%) delete mode 100644 configs/iot2050_pg2_defconfig -- 2.35.3
[PATCH 1/3] binman: Allow to define custom arguments
From: Jan Kiszka Introduce BINMAN_EXTRA_ARGS that can be set per board, e.g., to inject specific settings. Will be used by IOT2050 first to define multiple of-lists. Signed-off-by: Jan Kiszka --- CC: Simon Glass --- Makefile | 1 + 1 file changed, 1 insertion(+) diff --git a/Makefile b/Makefile index 10bfaa52adf..2285ae26b9b 100644 --- a/Makefile +++ b/Makefile @@ -1345,6 +1345,7 @@ cmd_binman = $(srctree)/tools/binman/binman $(if $(BINMAN_DEBUG),-D) \ -a spl-dtb=$(CONFIG_SPL_OF_REAL) \ -a tpl-dtb=$(CONFIG_TPL_OF_REAL) \ -a pre-load-key-path=${PRE_LOAD_KEY_PATH} \ + $(BINMAN_EXTRA_ARGS) \ $(BINMAN_$(@F)) OBJCOPYFLAGS_u-boot.ldr.hex := -I binary -O ihex -- 2.35.3
Re: [PATCH v4 11/11] configs: starfive: Enable ID EEPROM configuration
On 25.05.23 11:36, Yanhong Wang wrote: > Enabled ID_EEPROM and I2C configuration for StarFive VisionFive2 board. > > Signed-off-by: Yanhong Wang > --- > configs/starfive_visionfive2_defconfig | 19 ++- > 1 file changed, 18 insertions(+), 1 deletion(-) > > diff --git a/configs/starfive_visionfive2_defconfig > b/configs/starfive_visionfive2_defconfig > index c57708199d..570a1f53a1 100644 > --- a/configs/starfive_visionfive2_defconfig > +++ b/configs/starfive_visionfive2_defconfig > @@ -13,6 +13,7 @@ CONFIG_SYS_PROMPT="StarFive #" > CONFIG_OF_LIBFDT_OVERLAY=y > CONFIG_DM_RESET=y > CONFIG_SPL_MMC=y > +CONFIG_SPL_DRIVERS_MISC=y > CONFIG_SPL_STACK=0x818 > CONFIG_SPL=y > CONFIG_SPL_SPI_FLASH_SUPPORT=y > @@ -23,6 +24,7 @@ CONFIG_SPL_OPENSBI_LOAD_ADDR=0x4000 > CONFIG_ARCH_RV64I=y > CONFIG_CMODEL_MEDANY=y > CONFIG_RISCV_SMODE=y > +# CONFIG_OF_BOARD_FIXUP is not set > CONFIG_FIT=y > CONFIG_DISTRO_DEFAULTS=y > CONFIG_QSPI_BOOT=y > @@ -34,6 +36,8 @@ CONFIG_PREBOOT="setenv fdt_addr ${fdtcontroladdr};fdt addr > ${fdtcontroladdr};" > CONFIG_DEFAULT_FDT_FILE="starfive/jh7110-starfive-visionfive-2.dtb" > CONFIG_DISPLAY_CPUINFO=y > CONFIG_DISPLAY_BOARDINFO=y > +CONFIG_ID_EEPROM=y > +CONFIG_SYS_EEPROM_BUS_NUM=5 > CONFIG_SPL_MAX_SIZE=0x4 > CONFIG_SPL_PAD_TO=0x0 > CONFIG_SPL_BSS_START_ADDR=0x804 > @@ -45,21 +49,34 @@ CONFIG_CUSTOM_SYS_SPL_MALLOC_ADDR=0x8000 > CONFIG_SYS_SPL_MALLOC_SIZE=0x40 > CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_USE_PARTITION=y > CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_PARTITION=0x2 > +CONFIG_SPL_I2C=y > CONFIG_SPL_DM_SPI_FLASH=y > CONFIG_SPL_DM_RESET=y > CONFIG_SPL_SPI_LOAD=y > CONFIG_SYS_CBSIZE=256 > CONFIG_SYS_PBSIZE=276 > CONFIG_SYS_BOOTM_LEN=0x400 > +CONFIG_CMD_EEPROM=y > +CONFIG_SYS_EEPROM_SIZE=512 > +CONFIG_SYS_EEPROM_PAGE_WRITE_BITS=4 > +CONFIG_SYS_EEPROM_PAGE_WRITE_DELAY_MS=5 > CONFIG_CMD_MEMINFO=y > +CONFIG_CMD_I2C=y > CONFIG_CMD_TFTPPUT=y > +CONFIG_OF_BOARD=y > CONFIG_SYS_RELOC_GD_ENV_ADDR=y > +CONFIG_SPL_DM_SEQ_ALIAS=y > CONFIG_REGMAP=y > CONFIG_SYSCON=y > CONFIG_SPL_CLK_COMPOSITE_CCF=y > CONFIG_CLK_COMPOSITE_CCF=y > CONFIG_SPL_CLK_JH7110=y > -# CONFIG_I2C is not set > +CONFIG_DM_I2C=y > +CONFIG_SYS_I2C_DW=y > +CONFIG_MISC=y > +CONFIG_I2C_EEPROM=y > +CONFIG_SPL_I2C_EEPROM=y > +CONFIG_SYS_I2C_EEPROM_ADDR=0X50 > CONFIG_MMC_HS400_SUPPORT=y > CONFIG_SPL_MMC_HS400_SUPPORT=y > CONFIG_MMC_DW=y This comes too late: Already patch 4 needs at least CONFIG_ID_EEPROM=y, if not more. Make sure you don't leave non-bisectable commit series behind. Whenever something breaks (like 55171aedda88), people will use bisection to find the causing commit, and then they will appreciate not having to deal with such hick-ups. Jan -- Siemens AG, Technology Competence Center Embedded Linux
Re: [PATCH v4 10/11] configs: starfive: Enable ethernet configuration for StarFive VisionFive2
On 25.05.23 11:36, Yanhong Wang wrote: > Enable DWC_ETH_QOS and PHY_MOTORCOMM configuration to support ethernet > function for StarFive VisionFive 2 board,including versions 1.2A and > 1.3B. > > Signed-off-by: Yanhong Wang > --- > configs/starfive_visionfive2_defconfig | 13 +++-- > 1 file changed, 11 insertions(+), 2 deletions(-) > > diff --git a/configs/starfive_visionfive2_defconfig > b/configs/starfive_visionfive2_defconfig > index ffbc4b9476..c57708199d 100644 > --- a/configs/starfive_visionfive2_defconfig > +++ b/configs/starfive_visionfive2_defconfig > @@ -7,7 +7,7 @@ CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y > CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x8000 > CONFIG_SF_DEFAULT_SPEED=1 > CONFIG_SPL_DM_SPI=y > -CONFIG_DEFAULT_DEVICE_TREE="jh7110-starfive-visionfive-2-v1.3b" > +CONFIG_DEFAULT_DEVICE_TREE="jh7110-starfive-visionfive-2" > CONFIG_SPL_TEXT_BASE=0x800 > CONFIG_SYS_PROMPT="StarFive #" > CONFIG_OF_LIBFDT_OVERLAY=y > @@ -31,7 +31,7 @@ CONFIG_USE_BOOTARGS=y > CONFIG_BOOTARGS="console=ttyS0,115200 debug rootwait earlycon=sbi" > CONFIG_USE_PREBOOT=y > CONFIG_PREBOOT="setenv fdt_addr ${fdtcontroladdr};fdt addr > ${fdtcontroladdr};" > -CONFIG_DEFAULT_FDT_FILE="starfive/jh7110-starfive-visionfive-2-v1.3b.dtb" > +CONFIG_DEFAULT_FDT_FILE="starfive/jh7110-starfive-visionfive-2.dtb" These two hunks belong into patch 7. Jan > CONFIG_DISPLAY_CPUINFO=y > CONFIG_DISPLAY_BOARDINFO=y > CONFIG_SPL_MAX_SIZE=0x4 > @@ -54,6 +54,8 @@ CONFIG_SYS_BOOTM_LEN=0x400 > CONFIG_CMD_MEMINFO=y > CONFIG_CMD_TFTPPUT=y > CONFIG_SYS_RELOC_GD_ENV_ADDR=y > +CONFIG_REGMAP=y > +CONFIG_SYSCON=y > CONFIG_SPL_CLK_COMPOSITE_CCF=y > CONFIG_CLK_COMPOSITE_CCF=y > CONFIG_SPL_CLK_JH7110=y > @@ -66,6 +68,13 @@ CONFIG_SPI_FLASH_EON=y > CONFIG_SPI_FLASH_GIGADEVICE=y > CONFIG_SPI_FLASH_ISSI=y > CONFIG_SPI_FLASH_MACRONIX=y > +CONFIG_PHY_MOTORCOMM=y > +CONFIG_DM_MDIO=y > +CONFIG_DM_ETH_PHY=y > +CONFIG_DWC_ETH_QOS=y > +CONFIG_DWC_ETH_QOS_STARFIVE=y > +CONFIG_RGMII=y > +CONFIG_RMII=y > CONFIG_PINCTRL=y > CONFIG_PINCONF=y > CONFIG_SPL_PINCTRL=y -- Siemens AG, Technology Competence Center Embedded Linux
Re: [PATCH v3 01/17] dm: Emit the arch_cpu_init_dm() even only before relocation
On 05.05.23 00:50, Simon Glass wrote: > The original function was only called once, before relocation. The new > one is called again after relocation. This was not the intent of the > original call. Fix this by renaming and updating the calling logic. > > With this, chromebook_link64 makes it through SPL. > > Fixes: 7fe32b3442f ("event: Convert arch_cpu_init_dm() to") > Fixes: 7fe32b3442f0 ("event: Convert arch_cpu_init_dm() to use events") > Reviewed-by: Bin Meng > > Signed-off-by: Simon Glass > --- > > Changes in v3: > - Fix 'intend' typo > > arch/arm/mach-imx/imx8/cpu.c| 2 +- > arch/arm/mach-imx/imx8m/soc.c | 2 +- > arch/arm/mach-imx/imx8ulp/soc.c | 2 +- > arch/arm/mach-imx/imx9/soc.c| 2 +- > arch/arm/mach-omap2/am33xx/board.c | 2 +- > arch/arm/mach-omap2/hwinit-common.c | 2 +- > arch/mips/mach-pic32/cpu.c | 2 +- > arch/nios2/cpu/cpu.c| 2 +- > arch/riscv/cpu/cpu.c| 2 +- > arch/x86/cpu/baytrail/cpu.c | 2 +- > arch/x86/cpu/broadwell/cpu.c| 2 +- > arch/x86/cpu/ivybridge/cpu.c| 2 +- > arch/x86/cpu/quark/quark.c | 2 +- > arch/x86/lib/fsp2/fsp_init.c| 2 +- > doc/develop/event.rst | 6 +++--- > drivers/core/root.c | 4 ++-- > drivers/cpu/microblaze_cpu.c| 2 +- > include/event.h | 2 +- > 18 files changed, 21 insertions(+), 21 deletions(-) > > diff --git a/arch/arm/mach-imx/imx8/cpu.c b/arch/arm/mach-imx/imx8/cpu.c > index be1f4edded1..99772f68c32 100644 > --- a/arch/arm/mach-imx/imx8/cpu.c > +++ b/arch/arm/mach-imx/imx8/cpu.c > @@ -89,7 +89,7 @@ static int imx8_init_mu(void *ctx, struct event *event) > > return 0; > } > -EVENT_SPY(EVT_DM_POST_INIT, imx8_init_mu); > +EVENT_SPY(EVT_DM_POST_INIT_F, imx8_init_mu); > > #if defined(CONFIG_ARCH_MISC_INIT) > int arch_misc_init(void) > diff --git a/arch/arm/mach-imx/imx8m/soc.c b/arch/arm/mach-imx/imx8m/soc.c > index 4705e6c1192..5a4f8358c9f 100644 > --- a/arch/arm/mach-imx/imx8m/soc.c > +++ b/arch/arm/mach-imx/imx8m/soc.c > @@ -549,7 +549,7 @@ static int imx8m_check_clock(void *ctx, struct event > *event) > > return 0; > } > -EVENT_SPY(EVT_DM_POST_INIT, imx8m_check_clock); > +EVENT_SPY(EVT_DM_POST_INIT_F, imx8m_check_clock); > > static void imx8m_setup_snvs(void) > { > diff --git a/arch/arm/mach-imx/imx8ulp/soc.c b/arch/arm/mach-imx/imx8ulp/soc.c > index 8424332f429..81eae02b6a8 100644 > --- a/arch/arm/mach-imx/imx8ulp/soc.c > +++ b/arch/arm/mach-imx/imx8ulp/soc.c > @@ -808,7 +808,7 @@ static int imx8ulp_evt_dm_post_init(void *ctx, struct > event *event) > { > return imx8ulp_dm_post_init(); > } > -EVENT_SPY(EVT_DM_POST_INIT, imx8ulp_evt_dm_post_init); > +EVENT_SPY(EVT_DM_POST_INIT_F, imx8ulp_evt_dm_post_init); > > #if defined(CONFIG_SPL_BUILD) > __weak void __noreturn jump_to_image_no_args(struct spl_image_info > *spl_image) > diff --git a/arch/arm/mach-imx/imx9/soc.c b/arch/arm/mach-imx/imx9/soc.c > index a16e22ea6bb..252663a9eec 100644 > --- a/arch/arm/mach-imx/imx9/soc.c > +++ b/arch/arm/mach-imx/imx9/soc.c > @@ -262,7 +262,7 @@ int imx9_probe_mu(void *ctx, struct event *event) > > return 0; > } > -EVENT_SPY(EVT_DM_POST_INIT, imx9_probe_mu); > +EVENT_SPY(EVT_DM_POST_INIT_F, imx9_probe_mu); > > int timer_init(void) > { > diff --git a/arch/arm/mach-omap2/am33xx/board.c > b/arch/arm/mach-omap2/am33xx/board.c > index a52d04d85c8..ecc0a592e99 100644 > --- a/arch/arm/mach-omap2/am33xx/board.c > +++ b/arch/arm/mach-omap2/am33xx/board.c > @@ -535,4 +535,4 @@ static int am33xx_dm_post_init(void *ctx, struct event > *event) > #endif > return 0; > } > -EVENT_SPY(EVT_DM_POST_INIT, am33xx_dm_post_init); > +EVENT_SPY(EVT_DM_POST_INIT_F, am33xx_dm_post_init); > diff --git a/arch/arm/mach-omap2/hwinit-common.c > b/arch/arm/mach-omap2/hwinit-common.c > index c4a8eabc3eb..771533394bc 100644 > --- a/arch/arm/mach-omap2/hwinit-common.c > +++ b/arch/arm/mach-omap2/hwinit-common.c > @@ -246,7 +246,7 @@ static int omap2_system_init(void *ctx, struct event > *event) > > return 0; > } > -EVENT_SPY(EVT_DM_POST_INIT, omap2_system_init); > +EVENT_SPY(EVT_DM_POST_INIT_F, omap2_system_init); > > /* > * Routine: wait_for_command_complete > diff --git a/arch/mips/mach-pic32/cpu.c b/arch/mips/mach-pic32/cpu.c > index de449e3c6a2..ec3c2505313 100644 > --- a/arch/mips/mach-pic32/cpu.c > +++ b/arch/mips/mach-pic32/cpu.c > @@ -102,7 +102,7 @@ static int pic32_flash_prefetch(void *ctx, struct event > *event) > prefetch_init(); > return 0; > } > -EVENT_SPY(EVT_DM_POST_INIT, pic32_flash_prefetch); > +EVENT_SPY(EVT_DM_POST_INIT_F, pic32_flash_prefetch); > > /* Un-gate DDR2 modules (gated by default) */ > static void ddr2_pmd_ungate(void) > diff --git a/arch/nios2/cpu/cpu.c b/arch/nios2/cpu/cpu.c > index 85544503a5e..da167f4b29e 100644 > --- a/arch/nios2/cpu/cpu.c > +++ b/arch/nios2/cpu/cpu.c > @@ -80,7 +80,7 @@ static int
Re: [PATCH v3 00/19] Migration to using binman for bootloader
On 08.05.23 07:05, Neha Malcom Francis wrote: > Hi Jan, > > On 07/05/23 17:41, Jan Kiszka wrote: >> On 04.05.23 08:13, Neha Malcom Francis wrote: >>> Hi Jan >>> >>> On 04/05/23 10:13, Neha Malcom Francis wrote: >>>> Hi Jan, >>>> >>>> On 03/05/23 22:04, Jan Kiszka wrote: >>>>> On 03.05.23 14:56, Neha Malcom Francis wrote: >>>>>> Hi Jan, >>>>>> >>>>>> On 03/05/23 12:57, Neha Malcom Francis wrote: >>>>>>> Hi Tom >>>>>>> >>>>>>> On 27/04/23 04:07, Tom Rini wrote: >>>>>>>> On Fri, Apr 21, 2023 at 06:01:44PM +0530, Neha Malcom Francis >>>>>>>> wrote: >>>>>>>> >>>>>>>>> This series aims to eliminate the use of additional custom >>>>>>>>> repositories >>>>>>>>> such as k3-image-gen (K3 Image Generation) repo and >>>>>>>>> core-secdev-k3 (K3 >>>>>>>>> Security Development Tools) that was plumbed into the U-Boot >>>>>>>>> build flow >>>>>>>>> to generate boot images for TI K3 platform devices. And >>>>>>>>> instead, we >>>>>>>>> move >>>>>>>>> towards using binman that aligns better with the community >>>>>>>>> standard >>>>>>>>> build >>>>>>>>> flow. >>>>>>>>> >>>>>>>>> This series uses binman for all K3 platforms supported on U-Boot >>>>>>>>> currently; >>>>>>>>> both HS (High Security, both SE and FS) and GP (General Purpose) >>>>>>>>> devices. >>>>>>>>> >>>>>>>>> Background on using k3-image-gen: >>>>>>>>> * TI K3 devices require a SYSFW (System Firmware) image >>>>>>>>> consisting >>>>>>>>> of a signed system firmware image and board configuration >>>>>>>>> binaries, >>>>>>>>> this is needed to bring up system firmware during U-Boot >>>>>>>>> R5 SPL >>>>>>>>> startup. >>>>>>>>> * Board configuration data contain board-specific >>>>>>>>> information >>>>>>>>> such as resource management, power management and security. >>>>>>>>> >>>>>>>>> Background on using core-secdev-k3: >>>>>>>>> * Contains resources to sign x509 certificates for HS >>>>>>>>> devices >>>>>>>>> >>>>>>>>> Series intends to use binman to take over the packaging and >>>>>>>>> signing for >>>>>>>>> the R5 bootloader images tiboot3.bin (and sysfw.itb, for >>>>>>>>> non-combined >>>>>>>>> boot flow) instead of k3-image-gen. >>>>>>>>> >>>>>>>>> Series also packages the A72/A53 bootloader images (tispl.bin and >>>>>>>>> u-boot.img) using ATF, OPTEE and DM (Device Manager) >>>>>>>> >>>>>>>> So, next up is fixing this in CI. After taking Andrew's patch to >>>>>>>> fix the >>>>>>>> typedef issue, and after my patches to ensure we can get >>>>>>>> pyyaml/jsonschema for python, there's problems still: >>>>>>> >>>>>>> >>>>>>> Thanks for checking this! Couple things: >>>>>>> >>>>>>>> Over at https://source.denx.de/u-boot/u-boot/-/jobs/617966: >>>>>>>> binman: Filename 'spl/dts/k3-am68-sk-base-board.dtb' not found in >>>>>>>> input >>>>>>>> path (.,/builds/u-boot/u-boot,board/ti/j721s2,arch/arm/dts) >>>>>>>> (cwd='/tmp/.bm-work/j721s2_hs_evm_a72') >>>>>>> >>>>>>> 1. This is dependent on the patch merging J721S2 HS and GP configs >>>>>>> [1]. However it has been reverted on -next, seen in the same thread. >>>>>>> >>>>>>>> >
Re: [PATCH v3 00/19] Migration to using binman for bootloader
On 04.05.23 08:13, Neha Malcom Francis wrote: > Hi Jan > > On 04/05/23 10:13, Neha Malcom Francis wrote: >> Hi Jan, >> >> On 03/05/23 22:04, Jan Kiszka wrote: >>> On 03.05.23 14:56, Neha Malcom Francis wrote: >>>> Hi Jan, >>>> >>>> On 03/05/23 12:57, Neha Malcom Francis wrote: >>>>> Hi Tom >>>>> >>>>> On 27/04/23 04:07, Tom Rini wrote: >>>>>> On Fri, Apr 21, 2023 at 06:01:44PM +0530, Neha Malcom Francis wrote: >>>>>> >>>>>>> This series aims to eliminate the use of additional custom >>>>>>> repositories >>>>>>> such as k3-image-gen (K3 Image Generation) repo and >>>>>>> core-secdev-k3 (K3 >>>>>>> Security Development Tools) that was plumbed into the U-Boot >>>>>>> build flow >>>>>>> to generate boot images for TI K3 platform devices. And instead, we >>>>>>> move >>>>>>> towards using binman that aligns better with the community standard >>>>>>> build >>>>>>> flow. >>>>>>> >>>>>>> This series uses binman for all K3 platforms supported on U-Boot >>>>>>> currently; >>>>>>> both HS (High Security, both SE and FS) and GP (General Purpose) >>>>>>> devices. >>>>>>> >>>>>>> Background on using k3-image-gen: >>>>>>> * TI K3 devices require a SYSFW (System Firmware) image >>>>>>> consisting >>>>>>> of a signed system firmware image and board configuration >>>>>>> binaries, >>>>>>> this is needed to bring up system firmware during U-Boot R5 SPL >>>>>>> startup. >>>>>>> * Board configuration data contain board-specific information >>>>>>> such as resource management, power management and security. >>>>>>> >>>>>>> Background on using core-secdev-k3: >>>>>>> * Contains resources to sign x509 certificates for HS devices >>>>>>> >>>>>>> Series intends to use binman to take over the packaging and >>>>>>> signing for >>>>>>> the R5 bootloader images tiboot3.bin (and sysfw.itb, for >>>>>>> non-combined >>>>>>> boot flow) instead of k3-image-gen. >>>>>>> >>>>>>> Series also packages the A72/A53 bootloader images (tispl.bin and >>>>>>> u-boot.img) using ATF, OPTEE and DM (Device Manager) >>>>>> >>>>>> So, next up is fixing this in CI. After taking Andrew's patch to >>>>>> fix the >>>>>> typedef issue, and after my patches to ensure we can get >>>>>> pyyaml/jsonschema for python, there's problems still: >>>>> >>>>> >>>>> Thanks for checking this! Couple things: >>>>> >>>>>> Over at https://source.denx.de/u-boot/u-boot/-/jobs/617966: >>>>>> binman: Filename 'spl/dts/k3-am68-sk-base-board.dtb' not found in >>>>>> input >>>>>> path (.,/builds/u-boot/u-boot,board/ti/j721s2,arch/arm/dts) >>>>>> (cwd='/tmp/.bm-work/j721s2_hs_evm_a72') >>>>> >>>>> 1. This is dependent on the patch merging J721S2 HS and GP configs >>>>> [1]. However it has been reverted on -next, seen in the same thread. >>>>> >>>>>> >>>>>> And then: >>>>>> https://source.denx.de/u-boot/u-boot/-/jobs/617965#L1328 >>>>>> Error: arch/arm/dts/k3-am62a-sk-binman.dtsi:167.1-8 syntax error >>>>>> I've fixed this, minor but serious change. >>>>> >>>>> 2. Regarding iot2050, build fails since it uses >>>>> arch/arm/mach-k3/config.mk which is now entirely binman based. Will >>>>> try moving iot2050 to binman as well. >>>> >>>> I'll need some help with this, might need to know the bootloader >>>> flow to >>>> make a clean migration. >>> >>> Where do I have to look at? Is there a git repo with that experiment >>> somewhere? >>> >>> Jan >>> >> >> There's no experiment yet, I will send one today; but I do not have &
Re: [PATCH v3 00/19] Migration to using binman for bootloader
On 04.05.23 08:13, Neha Malcom Francis wrote: > Hi Jan > > On 04/05/23 10:13, Neha Malcom Francis wrote: >> Hi Jan, >> >> On 03/05/23 22:04, Jan Kiszka wrote: >>> On 03.05.23 14:56, Neha Malcom Francis wrote: >>>> Hi Jan, >>>> >>>> On 03/05/23 12:57, Neha Malcom Francis wrote: >>>>> Hi Tom >>>>> >>>>> On 27/04/23 04:07, Tom Rini wrote: >>>>>> On Fri, Apr 21, 2023 at 06:01:44PM +0530, Neha Malcom Francis wrote: >>>>>> >>>>>>> This series aims to eliminate the use of additional custom >>>>>>> repositories >>>>>>> such as k3-image-gen (K3 Image Generation) repo and >>>>>>> core-secdev-k3 (K3 >>>>>>> Security Development Tools) that was plumbed into the U-Boot >>>>>>> build flow >>>>>>> to generate boot images for TI K3 platform devices. And instead, we >>>>>>> move >>>>>>> towards using binman that aligns better with the community standard >>>>>>> build >>>>>>> flow. >>>>>>> >>>>>>> This series uses binman for all K3 platforms supported on U-Boot >>>>>>> currently; >>>>>>> both HS (High Security, both SE and FS) and GP (General Purpose) >>>>>>> devices. >>>>>>> >>>>>>> Background on using k3-image-gen: >>>>>>> * TI K3 devices require a SYSFW (System Firmware) image >>>>>>> consisting >>>>>>> of a signed system firmware image and board configuration >>>>>>> binaries, >>>>>>> this is needed to bring up system firmware during U-Boot R5 SPL >>>>>>> startup. >>>>>>> * Board configuration data contain board-specific information >>>>>>> such as resource management, power management and security. >>>>>>> >>>>>>> Background on using core-secdev-k3: >>>>>>> * Contains resources to sign x509 certificates for HS devices >>>>>>> >>>>>>> Series intends to use binman to take over the packaging and >>>>>>> signing for >>>>>>> the R5 bootloader images tiboot3.bin (and sysfw.itb, for >>>>>>> non-combined >>>>>>> boot flow) instead of k3-image-gen. >>>>>>> >>>>>>> Series also packages the A72/A53 bootloader images (tispl.bin and >>>>>>> u-boot.img) using ATF, OPTEE and DM (Device Manager) >>>>>> >>>>>> So, next up is fixing this in CI. After taking Andrew's patch to >>>>>> fix the >>>>>> typedef issue, and after my patches to ensure we can get >>>>>> pyyaml/jsonschema for python, there's problems still: >>>>> >>>>> >>>>> Thanks for checking this! Couple things: >>>>> >>>>>> Over at https://source.denx.de/u-boot/u-boot/-/jobs/617966: >>>>>> binman: Filename 'spl/dts/k3-am68-sk-base-board.dtb' not found in >>>>>> input >>>>>> path (.,/builds/u-boot/u-boot,board/ti/j721s2,arch/arm/dts) >>>>>> (cwd='/tmp/.bm-work/j721s2_hs_evm_a72') >>>>> >>>>> 1. This is dependent on the patch merging J721S2 HS and GP configs >>>>> [1]. However it has been reverted on -next, seen in the same thread. >>>>> >>>>>> >>>>>> And then: >>>>>> https://source.denx.de/u-boot/u-boot/-/jobs/617965#L1328 >>>>>> Error: arch/arm/dts/k3-am62a-sk-binman.dtsi:167.1-8 syntax error >>>>>> I've fixed this, minor but serious change. >>>>> >>>>> 2. Regarding iot2050, build fails since it uses >>>>> arch/arm/mach-k3/config.mk which is now entirely binman based. Will >>>>> try moving iot2050 to binman as well. >>>> >>>> I'll need some help with this, might need to know the bootloader >>>> flow to >>>> make a clean migration. >>> >>> Where do I have to look at? Is there a git repo with that experiment >>> somewhere? >>> >>> Jan >>> >> >> There's no experiment yet, I will send one today; but I do not have >> complete understanding of the booting; whether the tispl.bin (which I >> assume is the only boot component that is affecting iot2050 boot since >> k3_fit_atf.sh is no longer there) has any concept of signing? Is >> core-secdev-k3 ever used? >> > > I have a tree posted here [2] that builds flash.bin with no error for > me. Please confirm whether your build flow does the same and also let me > know if the binary actually boots. > > [2] > https://github.com/nehamalcom/u-boot/tree/migration-to-binman-cicd-iot2050 > FWIW, dependencies, signing procedure etc. are all documented in u-boot/doc/board/siemens/iot2050.rst. I will try to have a look at that patch as well. Jan -- Siemens AG, Technology Competence Center Embedded Linux
Re: [PATCH v3 00/19] Migration to using binman for bootloader
On 03.05.23 14:56, Neha Malcom Francis wrote: > Hi Jan, > > On 03/05/23 12:57, Neha Malcom Francis wrote: >> Hi Tom >> >> On 27/04/23 04:07, Tom Rini wrote: >>> On Fri, Apr 21, 2023 at 06:01:44PM +0530, Neha Malcom Francis wrote: >>> This series aims to eliminate the use of additional custom repositories such as k3-image-gen (K3 Image Generation) repo and core-secdev-k3 (K3 Security Development Tools) that was plumbed into the U-Boot build flow to generate boot images for TI K3 platform devices. And instead, we move towards using binman that aligns better with the community standard build flow. This series uses binman for all K3 platforms supported on U-Boot currently; both HS (High Security, both SE and FS) and GP (General Purpose) devices. Background on using k3-image-gen: * TI K3 devices require a SYSFW (System Firmware) image consisting of a signed system firmware image and board configuration binaries, this is needed to bring up system firmware during U-Boot R5 SPL startup. * Board configuration data contain board-specific information such as resource management, power management and security. Background on using core-secdev-k3: * Contains resources to sign x509 certificates for HS devices Series intends to use binman to take over the packaging and signing for the R5 bootloader images tiboot3.bin (and sysfw.itb, for non-combined boot flow) instead of k3-image-gen. Series also packages the A72/A53 bootloader images (tispl.bin and u-boot.img) using ATF, OPTEE and DM (Device Manager) >>> >>> So, next up is fixing this in CI. After taking Andrew's patch to fix the >>> typedef issue, and after my patches to ensure we can get >>> pyyaml/jsonschema for python, there's problems still: >> >> >> Thanks for checking this! Couple things: >> >>> Over at https://source.denx.de/u-boot/u-boot/-/jobs/617966: >>> binman: Filename 'spl/dts/k3-am68-sk-base-board.dtb' not found in input >>> path (.,/builds/u-boot/u-boot,board/ti/j721s2,arch/arm/dts) >>> (cwd='/tmp/.bm-work/j721s2_hs_evm_a72') >> >> 1. This is dependent on the patch merging J721S2 HS and GP configs >> [1]. However it has been reverted on -next, seen in the same thread. >> >>> >>> And then: >>> https://source.denx.de/u-boot/u-boot/-/jobs/617965#L1328 >>> Error: arch/arm/dts/k3-am62a-sk-binman.dtsi:167.1-8 syntax error >>> I've fixed this, minor but serious change. >> >> 2. Regarding iot2050, build fails since it uses >> arch/arm/mach-k3/config.mk which is now entirely binman based. Will >> try moving iot2050 to binman as well. > > I'll need some help with this, might need to know the bootloader flow to > make a clean migration. Where do I have to look at? Is there a git repo with that experiment somewhere? Jan -- Siemens AG, Technology Competence Center Embedded Linux
[PATCH] arm: dts: iot2050: Include u-boot specific bits implicitly
From: Jan Kiszka Create *-u-boot.dtsi files for each target dtb of the IOT2050 series so that we can drop the #include deviations from upstream dts[i] files here. Signed-off-by: Jan Kiszka --- This was tested against most of our boards with the DTS synced from kernel 6.3. arch/arm/dts/k3-am65-iot2050-common-pg2.dtsi | 2 -- arch/arm/dts/k3-am6528-iot2050-basic-common.dtsi | 3 --- arch/arm/dts/k3-am6528-iot2050-basic-pg2-u-boot.dtsi | 11 +++ arch/arm/dts/k3-am6528-iot2050-basic-u-boot.dtsi | 10 ++ arch/arm/dts/k3-am6548-iot2050-advanced-common.dtsi | 3 --- .../arm/dts/k3-am6548-iot2050-advanced-m2-u-boot.dtsi | 1 + .../dts/k3-am6548-iot2050-advanced-pg2-u-boot.dtsi| 1 + arch/arm/dts/k3-am6548-iot2050-advanced-u-boot.dtsi | 1 + 8 files changed, 24 insertions(+), 8 deletions(-) create mode 100644 arch/arm/dts/k3-am6528-iot2050-basic-pg2-u-boot.dtsi create mode 100644 arch/arm/dts/k3-am6528-iot2050-basic-u-boot.dtsi create mode 12 arch/arm/dts/k3-am6548-iot2050-advanced-m2-u-boot.dtsi create mode 12 arch/arm/dts/k3-am6548-iot2050-advanced-pg2-u-boot.dtsi create mode 12 arch/arm/dts/k3-am6548-iot2050-advanced-u-boot.dtsi diff --git a/arch/arm/dts/k3-am65-iot2050-common-pg2.dtsi b/arch/arm/dts/k3-am65-iot2050-common-pg2.dtsi index e7e0ca41597..e73458ca690 100644 --- a/arch/arm/dts/k3-am65-iot2050-common-pg2.dtsi +++ b/arch/arm/dts/k3-am65-iot2050-common-pg2.dtsi @@ -49,5 +49,3 @@ snps,dis-u1-entry-quirk; snps,dis-u2-entry-quirk; }; - -#include "k3-am65-iot2050-common-pg2-u-boot.dtsi" diff --git a/arch/arm/dts/k3-am6528-iot2050-basic-common.dtsi b/arch/arm/dts/k3-am6528-iot2050-basic-common.dtsi index 0d215b4d668..4a9bf7d7c07 100644 --- a/arch/arm/dts/k3-am6528-iot2050-basic-common.dtsi +++ b/arch/arm/dts/k3-am6528-iot2050-basic-common.dtsi @@ -11,9 +11,6 @@ #include "k3-am65-iot2050-common.dtsi" -#include "k3-am65-iot2050-common-u-boot.dtsi" -#include "k3-am65-iot2050-boot-image.dtsi" - / { memory@8000 { device_type = "memory"; diff --git a/arch/arm/dts/k3-am6528-iot2050-basic-pg2-u-boot.dtsi b/arch/arm/dts/k3-am6528-iot2050-basic-pg2-u-boot.dtsi new file mode 100644 index 000..1e393042ac0 --- /dev/null +++ b/arch/arm/dts/k3-am6528-iot2050-basic-pg2-u-boot.dtsi @@ -0,0 +1,11 @@ +// SPDX-License-Identifier: GPL-2.0 +/* + * Copyright (c) Siemens AG, 2023 + * + * Authors: + * Jan Kiszka + */ + +#include "k3-am65-iot2050-common-u-boot.dtsi" +#include "k3-am65-iot2050-common-pg2-u-boot.dtsi" +#include "k3-am65-iot2050-boot-image.dtsi" diff --git a/arch/arm/dts/k3-am6528-iot2050-basic-u-boot.dtsi b/arch/arm/dts/k3-am6528-iot2050-basic-u-boot.dtsi new file mode 100644 index 000..64afe25e38f --- /dev/null +++ b/arch/arm/dts/k3-am6528-iot2050-basic-u-boot.dtsi @@ -0,0 +1,10 @@ +// SPDX-License-Identifier: GPL-2.0 +/* + * Copyright (c) Siemens AG, 2023 + * + * Authors: + * Jan Kiszka + */ + +#include "k3-am65-iot2050-common-u-boot.dtsi" +#include "k3-am65-iot2050-boot-image.dtsi" diff --git a/arch/arm/dts/k3-am6548-iot2050-advanced-common.dtsi b/arch/arm/dts/k3-am6548-iot2050-advanced-common.dtsi index 816a4cb4a68..d25e8b26187 100644 --- a/arch/arm/dts/k3-am6548-iot2050-advanced-common.dtsi +++ b/arch/arm/dts/k3-am6548-iot2050-advanced-common.dtsi @@ -13,9 +13,6 @@ #include "k3-am65-iot2050-common.dtsi" -#include "k3-am65-iot2050-common-u-boot.dtsi" -#include "k3-am65-iot2050-boot-image.dtsi" - / { memory@8000 { device_type = "memory"; diff --git a/arch/arm/dts/k3-am6548-iot2050-advanced-m2-u-boot.dtsi b/arch/arm/dts/k3-am6548-iot2050-advanced-m2-u-boot.dtsi new file mode 12 index 000..859776d3ffe --- /dev/null +++ b/arch/arm/dts/k3-am6548-iot2050-advanced-m2-u-boot.dtsi @@ -0,0 +1 @@ +k3-am6528-iot2050-basic-pg2-u-boot.dtsi \ No newline at end of file diff --git a/arch/arm/dts/k3-am6548-iot2050-advanced-pg2-u-boot.dtsi b/arch/arm/dts/k3-am6548-iot2050-advanced-pg2-u-boot.dtsi new file mode 12 index 000..859776d3ffe --- /dev/null +++ b/arch/arm/dts/k3-am6548-iot2050-advanced-pg2-u-boot.dtsi @@ -0,0 +1 @@ +k3-am6528-iot2050-basic-pg2-u-boot.dtsi \ No newline at end of file diff --git a/arch/arm/dts/k3-am6548-iot2050-advanced-u-boot.dtsi b/arch/arm/dts/k3-am6548-iot2050-advanced-u-boot.dtsi new file mode 12 index 000..ac30e4ef46e --- /dev/null +++ b/arch/arm/dts/k3-am6548-iot2050-advanced-u-boot.dtsi @@ -0,0 +1 @@ +k3-am6528-iot2050-basic-u-boot.dtsi \ No newline at end of file -- 2.35.3
[PATCH] tools: Fall back to importlib_resources on Python 3.6
From: Jan Kiszka importlib.resources became part of 3.7 only. Allow using distros with 3.6 and the importlib_resources backport. Signed-off-by: Jan Kiszka --- Tested on OpenSUSE 15.4 with importlib_resources 1.1.0. tools/binman/control.py | 6 +- tools/buildman/control.py | 6 +- tools/patman/__main__.py | 6 +- 3 files changed, 15 insertions(+), 3 deletions(-) diff --git a/tools/binman/control.py b/tools/binman/control.py index 0febcb79a60..68597c4e779 100644 --- a/tools/binman/control.py +++ b/tools/binman/control.py @@ -7,7 +7,11 @@ from collections import OrderedDict import glob -import importlib.resources +try: +import importlib.resources +except ImportError: +# for Python 3.6 +import importlib_resources import os import pkg_resources import re diff --git a/tools/buildman/control.py b/tools/buildman/control.py index 35f44c0cf3d..09a11f25b3f 100644 --- a/tools/buildman/control.py +++ b/tools/buildman/control.py @@ -3,7 +3,11 @@ # import multiprocessing -import importlib.resources +try: +import importlib.resources +except ImportError: +# for Python 3.6 +import importlib_resources import os import shutil import subprocess diff --git a/tools/patman/__main__.py b/tools/patman/__main__.py index 48ffbc8eadf..8eba5d34864 100755 --- a/tools/patman/__main__.py +++ b/tools/patman/__main__.py @@ -7,7 +7,11 @@ """See README for more information""" from argparse import ArgumentParser -import importlib.resources +try: +import importlib.resources +except ImportError: +# for Python 3.6 +import importlib_resources import os import re import sys -- 2.35.3
Re: [PATCH V7 04/15] iot2050: Migrate settings into board env file
On 02.03.23 00:38, Simon Glass wrote: > Hi Jan, > > On Tue, 28 Feb 2023 at 11:20, Jan Kiszka wrote: >> >> From: Jan Kiszka >> >> Anything that is not boot-env related is better kept there by now. >> >> At this chance, also drop a stale comment from iot2050.h >> >> Signed-off-by: Jan Kiszka >> --- >> board/siemens/iot2050/iot2050.env | 9 + >> include/configs/iot2050.h | 11 ++- >> 2 files changed, 11 insertions(+), 9 deletions(-) >> create mode 100644 board/siemens/iot2050/iot2050.env >> >> diff --git a/board/siemens/iot2050/iot2050.env >> b/board/siemens/iot2050/iot2050.env >> new file mode 100644 >> index 000..4bd93f0b2f4 >> --- /dev/null >> +++ b/board/siemens/iot2050/iot2050.env >> @@ -0,0 +1,9 @@ >> +// SPDX-License-Identifier: GPL-2.0+ >> +/* >> + * Copyright (c) Siemens AG, 2023 >> + * >> + * Authors: >> + * Jan Kiszka >> + */ >> + >> +usb_pgood_delay=900 >> diff --git a/include/configs/iot2050.h b/include/configs/iot2050.h >> index cfff46ce339..8dfeaddf541 100644 >> --- a/include/configs/iot2050.h >> +++ b/include/configs/iot2050.h >> @@ -13,12 +13,6 @@ >> >> #include >> >> -/* SPL Loader Configuration */ >> - >> -/* U-Boot general configuration */ >> -#define EXTRA_ENV_IOT2050_BOARD_SETTINGS \ >> - "usb_pgood_delay=900\0" >> - >> #if IS_ENABLED(CONFIG_CMD_USB) >> # define BOOT_TARGET_USB(func) \ >> func(USB, usb, 0) \ >> @@ -40,10 +34,9 @@ >> >> #include >> >> -#define CFG_EXTRA_ENV_SETTINGS \ >> +#define CFG_EXTRA_ENV_SETTINGS \ >> DEFAULT_LINUX_BOOT_ENV \ >> - BOOTENV \ >> - EXTRA_ENV_IOT2050_BOARD_SETTINGS >> + BOOTENV >> >> #include >> >> -- >> 2.35.3 >> > > You might want to move to standard boot so you can use a text-based > environment. See for example [1] [2] and later patches from [3]. > Err, this patch is about introducing a text-based env for the parts that can be moved. I don't see a relevant delta after this patch to the referenced examples (btw, [2] is missing). Jan > Regards, > Simon > > [1] https://patchwork.ozlabs.org/project/uboot/list/?series=342718 > [2] > [3] from > https://patchwork.ozlabs.org/project/uboot/list/?series=338993&state=* -- Siemens AG, Technology Competence Center Embedded Linux
Re: [PATCH V7 15/15] iot2050: Add support for configuring M.2 connector
On 02.03.23 00:38, Simon Glass wrote: > Hi Jan, > > On Tue, 28 Feb 2023 at 11:23, Jan Kiszka wrote: >> >> From: Jan Kiszka >> >> The M.2 slots of the related IOT2050 variant need to be configured >> according to the plugged cards. This tries to detect the card using the >> M.2 configuration pins of the B-key slot. If that fails, a U-Boot >> environment variable can be set to configure manually. This variable is >> write-permitted also in secure boot mode as it is not able to undermine >> the integrity of the booted system. >> >> The configuration is then applied to mux the serdes and to fix up the >> device tree passed to or loaded by the bootloader. The fix-ups are >> coming from device tree overlays that are embedded into the firmware >> image and there also integrity protected. The OS remains free to load >> a device tree to which they do not apply: U-Boot will not fail to boot >> in that case. >> >> Based on original patch by Chao Zeng. >> >> Signed-off-by: Jan Kiszka >> --- >> arch/arm/dts/Makefile | 4 +- >> arch/arm/dts/k3-am65-iot2050-boot-image.dtsi | 38 ++- >> ...050-advanced-m2-bkey-ekey-pcie-overlay.dts | 27 ++ >> ...-iot2050-advanced-m2-bkey-usb3-overlay.dts | 47 >> board/siemens/iot2050/board.c | 259 +- >> doc/board/siemens/iot2050.rst | 18 ++ >> include/configs/iot2050.h | 1 + >> 7 files changed, 391 insertions(+), 3 deletions(-) >> create mode 100644 >> arch/arm/dts/k3-am6548-iot2050-advanced-m2-bkey-ekey-pcie-overlay.dts >> create mode 100644 >> arch/arm/dts/k3-am6548-iot2050-advanced-m2-bkey-usb3-overlay.dts > > There is an 'extension' command and associated infra available. To my understanding, this is about scripting, open-coding extension detection and overlay application. Here we are making this automatic. Also, we are not really detecting an extension board, more the used connector. struct extension therefore does not really fit. > Also > there is sysinfo. I just wanted to check if either of those is helpful > here. This might save a handful of lines of own code around gpio parsing. We will have a look on top of this. Thanks, Jan -- Siemens AG, Technology Competence Center Embedded Linux
Re: [PATCH V7 01/15] board: siemens: iot2050: Split the build for PG1 and PG2
On 01.03.23 19:34, Andrew Davis wrote: > On 3/1/23 12:29 PM, Jan Kiszka wrote: >> On 01.03.23 18:26, Andrew Davis wrote: >>> On 2/28/23 12:19 PM, Jan Kiszka wrote: >>>> From: Su Baocheng >>>> >>>> Due to different signature keys, the PG1 and the PG2 boards can no >>>> longer use the same FSBL (tiboot3). This makes it impossible anyway to >>>> maintaine a single flash.bin for both variants, so we can also split >>>> the >>>> build. >>>> >>> >>> Having two defconfigs just to make the small changes needed will be >>> more burden than it saves. Keeping them in sync and having your >>> integration >>> layer do two different builds just adds more work than it is worth IMHO. >>> >>> We (TI) are going in that direction for our HS boards and combining the >>> defconfigs back together now. The solution is to have the one defconfig >>> build both images, one for HS and one for non-HS. For you looks like you >>> are already calling the two PG boot images differently so this should >>> work >>> (seboot_pg1.bin and seboot_pg2.bin). Just add a new full entry in >>> boot-image.dtsi for each (vs that #ifdef check changing the output >>> name). >> >> How should that work? Will we somehow get two flash.bin out of a single >> build then? >> > > Yes if you add two enteries in your image.dtsi file. Then your integration > selects the right named one for the board, instead of selecting the right > defconfig for the board and doing a completely new build. Something like this? binman: binman { multiple-images; }; &binman { flash-pg1 { filename = "flash-pg1.bin" ... }; flash-pg2 { filename = "flash-pg2.bin" ... }; }; How to avoid duplicating the common nodes of flash-pg1/pg2? Jan -- Siemens AG, Technology Competence Center Embedded Linux
Re: [PATCH V7 01/15] board: siemens: iot2050: Split the build for PG1 and PG2
On 01.03.23 18:26, Andrew Davis wrote: > On 2/28/23 12:19 PM, Jan Kiszka wrote: >> From: Su Baocheng >> >> Due to different signature keys, the PG1 and the PG2 boards can no >> longer use the same FSBL (tiboot3). This makes it impossible anyway to >> maintaine a single flash.bin for both variants, so we can also split the >> build. >> > > Having two defconfigs just to make the small changes needed will be > more burden than it saves. Keeping them in sync and having your integration > layer do two different builds just adds more work than it is worth IMHO. > > We (TI) are going in that direction for our HS boards and combining the > defconfigs back together now. The solution is to have the one defconfig > build both images, one for HS and one for non-HS. For you looks like you > are already calling the two PG boot images differently so this should work > (seboot_pg1.bin and seboot_pg2.bin). Just add a new full entry in > boot-image.dtsi for each (vs that #ifdef check changing the output name). How should that work? Will we somehow get two flash.bin out of a single build then? Jan -- Siemens AG, Technology Competence Center Embedded Linux
[PATCH V7 14/15] arm: dts: iot2050: Add support for M.2 variant
From: chao zeng Add support for the M.2 board based on the iot2050 advanced board. The board has two m.2 connectors, one is B-keyed, the other E-keyed. The B-key slot can connect 5G/SSD devices, and E-key can be used for WIFI/BT devices. This variant is covered by PG2 firmware image. Signed-off-by: chao zeng [Jan: align DT to kernel, polish wording] Signed-off-by: Jan Kiszka --- arch/arm/dts/Makefile | 3 +- .../arm/dts/k3-am6548-iot2050-advanced-m2.dts | 121 ++ configs/iot2050_pg2_defconfig | 2 +- doc/board/siemens/iot2050.rst | 6 +- 4 files changed, 128 insertions(+), 4 deletions(-) create mode 100644 arch/arm/dts/k3-am6548-iot2050-advanced-m2.dts diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile index 7a577deb502..8e9e2bf9a42 100644 --- a/arch/arm/dts/Makefile +++ b/arch/arm/dts/Makefile @@ -1253,7 +1253,8 @@ dtb-$(CONFIG_SOC_K3_AM654) += \ k3-am6528-iot2050-basic.dtb \ k3-am6528-iot2050-basic-pg2.dtb \ k3-am6548-iot2050-advanced.dtb \ - k3-am6548-iot2050-advanced-pg2.dtb + k3-am6548-iot2050-advanced-pg2.dtb \ + k3-am6548-iot2050-advanced-m2.dtb dtb-$(CONFIG_SOC_K3_J721E) += k3-j721e-common-proc-board.dtb \ k3-j721e-r5-common-proc-board.dtb \ k3-j7200-common-proc-board.dtb \ diff --git a/arch/arm/dts/k3-am6548-iot2050-advanced-m2.dts b/arch/arm/dts/k3-am6548-iot2050-advanced-m2.dts new file mode 100644 index 000..9400e35882a --- /dev/null +++ b/arch/arm/dts/k3-am6548-iot2050-advanced-m2.dts @@ -0,0 +1,121 @@ +// SPDX-License-Identifier: GPL-2.0 +/* + * Copyright (c) Siemens AG, 2018-2023 + * + * Authors: + * Chao Zeng + * Jan Kiszka + * + * AM6548-based (quad-core) IOT2050 M.2 variant (based on Advanced Product + * Generation 2), 2 GB RAM, 16 GB eMMC, USB-serial converter on connector X30 + * + * Product homepage: + * https://new.siemens.com/global/en/products/automation/pc-based/iot-gateways/simatic-iot2050.html + */ + +#include "k3-am6548-iot2050-advanced-common.dtsi" +#include "k3-am65-iot2050-common-pg2.dtsi" + +/ { + compatible = "siemens,iot2050-advanced-m2", "ti,am654"; + model = "SIMATIC IOT2050 Advanced M2"; +}; + +&mcu_r5fss0 { + /* lock-step mode not supported on this board */ + ti,cluster-mode = <0>; +}; + +&main_pmx0 { + main_m2_enable_pins_default: main-m2-enable-pins-default { + pinctrl-single,pins = < + AM65X_IOPAD(0x01c4, PIN_INPUT_PULLUP, 7) /* (AH13) GPIO1_17 */ + >; + }; + + main_bkey_pcie_reset: main-bkey-pcie-reset { + pinctrl-single,pins = < + AM65X_IOPAD(0x01bc, PIN_OUTPUT_PULLUP, 7) /* (AG13) GPIO1_15 */ + >; + }; + + main_pmx0_m2_config_pins_default: main-pmx0-m2-config-pins-default { + pinctrl-single,pins = < + AM65X_IOPAD(0x01c8, PIN_INPUT_PULLUP, 7) /* (AE13) GPIO1_18 */ + AM65X_IOPAD(0x01cc, PIN_INPUT_PULLUP, 7) /* (AD13) GPIO1_19 */ + >; + }; + + main_m2_pcie_mux_control: main-m2-pcie-mux-control { + pinctrl-single,pins = < + AM65X_IOPAD(0x0148, PIN_INPUT_PULLUP, 7) /* (AG22) GPIO0_82 */ + AM65X_IOPAD(0x0160, PIN_INPUT_PULLUP, 7) /* (AE20) GPIO0_88 */ + AM65X_IOPAD(0x0164, PIN_INPUT_PULLUP, 7) /* (AF19) GPIO0_89 */ + >; + }; +}; + +&main_pmx1 { + main_pmx1_m2_config_pins_default: main-pmx1-m2-config-pins-default { + pinctrl-single,pins = < + AM65X_IOPAD(0x0018, PIN_INPUT_PULLUP, 7) /* (B22) GPIO1_88 */ + AM65X_IOPAD(0x001c, PIN_INPUT_PULLUP, 7) /* (C23) GPIO1_89 */ + >; + }; +}; + +&main_gpio0 { + pinctrl-names = "default"; + pinctrl-0 = < + &main_m2_pcie_mux_control + &arduino_io_d4_to_d9_pins_default + >; +}; + +&main_gpio1 { + pinctrl-names = "default"; + pinctrl-0 = < + &main_m2_enable_pins_default + &main_pmx0_m2_config_pins_default + &main_pmx1_m2_config_pins_default + &cp2102n_reset_pin_default + >; +}; + +/* + * Base configuration for B-key slot with PCIe x2, E-key with USB 2.0 only. + * Firmware switches to other modes via device tree overlays. + */ + +&serdes0 { + assigned-clocks = <&k3_clks 153 4>, <&serdes0 AM654_SERDES_CMU_REFCLK>; + assigned-clock-parents = <&k3_clks 153 8>, <&k3_clks 153 4>; +}; + +&pcie0_rc { + pinctrl-names = "default"; + pinctrl-0 = &l
[PATCH V7 15/15] iot2050: Add support for configuring M.2 connector
From: Jan Kiszka The M.2 slots of the related IOT2050 variant need to be configured according to the plugged cards. This tries to detect the card using the M.2 configuration pins of the B-key slot. If that fails, a U-Boot environment variable can be set to configure manually. This variable is write-permitted also in secure boot mode as it is not able to undermine the integrity of the booted system. The configuration is then applied to mux the serdes and to fix up the device tree passed to or loaded by the bootloader. The fix-ups are coming from device tree overlays that are embedded into the firmware image and there also integrity protected. The OS remains free to load a device tree to which they do not apply: U-Boot will not fail to boot in that case. Based on original patch by Chao Zeng. Signed-off-by: Jan Kiszka --- arch/arm/dts/Makefile | 4 +- arch/arm/dts/k3-am65-iot2050-boot-image.dtsi | 38 ++- ...050-advanced-m2-bkey-ekey-pcie-overlay.dts | 27 ++ ...-iot2050-advanced-m2-bkey-usb3-overlay.dts | 47 board/siemens/iot2050/board.c | 259 +- doc/board/siemens/iot2050.rst | 18 ++ include/configs/iot2050.h | 1 + 7 files changed, 391 insertions(+), 3 deletions(-) create mode 100644 arch/arm/dts/k3-am6548-iot2050-advanced-m2-bkey-ekey-pcie-overlay.dts create mode 100644 arch/arm/dts/k3-am6548-iot2050-advanced-m2-bkey-usb3-overlay.dts diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile index 8e9e2bf9a42..0bfc69ecc86 100644 --- a/arch/arm/dts/Makefile +++ b/arch/arm/dts/Makefile @@ -1254,7 +1254,9 @@ dtb-$(CONFIG_SOC_K3_AM654) += \ k3-am6528-iot2050-basic-pg2.dtb \ k3-am6548-iot2050-advanced.dtb \ k3-am6548-iot2050-advanced-pg2.dtb \ - k3-am6548-iot2050-advanced-m2.dtb + k3-am6548-iot2050-advanced-m2.dtb \ + k3-am6548-iot2050-advanced-m2-bkey-usb3-overlay.dtbo \ + k3-am6548-iot2050-advanced-m2-bkey-ekey-pcie-overlay.dtbo dtb-$(CONFIG_SOC_K3_J721E) += k3-j721e-common-proc-board.dtb \ k3-j721e-r5-common-proc-board.dtb \ k3-j7200-common-proc-board.dtb \ diff --git a/arch/arm/dts/k3-am65-iot2050-boot-image.dtsi b/arch/arm/dts/k3-am65-iot2050-boot-image.dtsi index a2fc8bbc123..03ccc543293 100644 --- a/arch/arm/dts/k3-am65-iot2050-boot-image.dtsi +++ b/arch/arm/dts/k3-am65-iot2050-boot-image.dtsi @@ -61,6 +61,36 @@ }; }; +#ifdef CONFIG_TARGET_IOT2050_A53_PG2 + bkey-usb3-overlay { + description = "M.2-bkey-usb3-overlay"; + type = "blob"; + load = <0x8210>; + arch = "arm64"; + compression = "none"; + blob-ext { + filename = "k3-am6548-iot2050-advanced-m2-bkey-usb3-overlay.dtbo"; + }; + hash { + algo = "sha256"; + }; + }; + + bkey-ekey-pcie-overlay { + description = "M.2-bkey-ekey-pcie-overlay"; + type = "blob"; + load = <0x8211>; + arch = "arm64"; + compression = "none"; + blob-ext { + filename = "k3-am6548-iot2050-advanced-m2-bkey-ekey-pcie-overlay.dtbo"; + }; + hash { + algo = "sha256"; + }; + }; +#endif + #ifdef CONFIG_WDT_K3_RTI_FW_FILE k3-rti-wdt-firmware { type = "firmware"; @@ -84,9 +114,15 @@ description = "NAME"; firmware = "u-boot"; fdt = "fdt-SEQ"; + loadables = +#ifdef CONFIG_TARGET_IOT2050_A53_PG2 + "bkey-usb3-overlay", + "bkey-ekey-pcie-overlay", +#e
[PATCH V7 13/15] iot2050: Refresh defconfigs and activate CONFIG_EFI_SCROLL_ON_CLEAR_SCREEN
From: Jan Kiszka This feature is desired on the platform. Signed-off-by: Jan Kiszka --- configs/iot2050_pg1_defconfig | 1 + configs/iot2050_pg2_defconfig | 5 + 2 files changed, 2 insertions(+), 4 deletions(-) diff --git a/configs/iot2050_pg1_defconfig b/configs/iot2050_pg1_defconfig index 258ad4c87e5..45c88fc134e 100644 --- a/configs/iot2050_pg1_defconfig +++ b/configs/iot2050_pg1_defconfig @@ -146,3 +146,4 @@ CONFIG_WDT=y CONFIG_WDT_K3_RTI=y CONFIG_WDT_K3_RTI_LOAD_FW=y CONFIG_OF_LIBFDT_OVERLAY=y +CONFIG_EFI_SCROLL_ON_CLEAR_SCREEN=y diff --git a/configs/iot2050_pg2_defconfig b/configs/iot2050_pg2_defconfig index 2ff360b0623..d2bdeab593b 100644 --- a/configs/iot2050_pg2_defconfig +++ b/configs/iot2050_pg2_defconfig @@ -25,11 +25,8 @@ CONFIG_ENV_OFFSET_REDUND=0x6a CONFIG_SPL_SPI_FLASH_SUPPORT=y CONFIG_SPL_SPI=y CONFIG_DISTRO_DEFAULTS=y -CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y -CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x8010 # CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set CONFIG_SPL_LOAD_FIT=y -# CONFIG_USE_SPL_FIT_GENERATOR is not set CONFIG_OF_BOARD_SETUP=y CONFIG_BOOTSTAGE=y CONFIG_SHOW_BOOT_PROGRESS=y @@ -78,7 +75,6 @@ CONFIG_SPL_OF_LIST="k3-am65-iot2050-spl" CONFIG_SPL_MULTI_DTB_FIT_NO_COMPRESSION=y CONFIG_ENV_IS_IN_SPI_FLASH=y CONFIG_SYS_REDUNDAND_ENVIRONMENT=y -CONFIG_DM=y CONFIG_SPL_DM=y CONFIG_SPL_DM_SEQ_ALIAS=y CONFIG_SPL_REGMAP=y @@ -150,3 +146,4 @@ CONFIG_WDT=y CONFIG_WDT_K3_RTI=y CONFIG_WDT_K3_RTI_LOAD_FW=y CONFIG_OF_LIBFDT_OVERLAY=y +CONFIG_EFI_SCROLL_ON_CLEAR_SCREEN=y -- 2.35.3
[PATCH V7 11/15] doc: iot2050: Add a note about the watchdog firmware
From: Jan Kiszka This is enabled by default, thus should be described as well. Signed-off-by: Jan Kiszka --- doc/board/siemens/iot2050.rst | 4 1 file changed, 4 insertions(+) diff --git a/doc/board/siemens/iot2050.rst b/doc/board/siemens/iot2050.rst index cb49a0e36bf..efe94a448a9 100644 --- a/doc/board/siemens/iot2050.rst +++ b/doc/board/siemens/iot2050.rst @@ -27,6 +27,10 @@ The following binaries from that source need to be present in the build folder: - seboot_pg1.bin - seboot_pg2.bin +When using the watchdog, a related firmware for the R5 core(s) is needed, e.g. +https://github.com/siemens/k3-rti-wdt. The name and location of the image is +configured via CONFIG_WDT_K3_RTI_FW_FILE. + For building an image containing the OTP key provisioning data, below binary needs to be present in the build folder: -- 2.35.3
[PATCH V7 10/15] arm: dts: iot2050: Optionally embed OTP programming data into image
From: Jan Kiszka Use external blob otpcmd.bin to replace the 0xff filled OTP programming command block to create a firmware image that provisions the OTP on first boot. This otpcmd.bin is generated from the customer keys using steps described in the meta-iot2050 integration layer for the device. Based on original patch by Baocheng Su. Signed-off-by: Jan Kiszka --- arch/arm/dts/k3-am65-iot2050-boot-image.dtsi | 9 + board/siemens/iot2050/Kconfig| 7 +++ doc/board/siemens/iot2050.rst| 8 tools/binman/missing-blob-help | 8 4 files changed, 32 insertions(+) diff --git a/arch/arm/dts/k3-am65-iot2050-boot-image.dtsi b/arch/arm/dts/k3-am65-iot2050-boot-image.dtsi index 9082a79a034..a2fc8bbc123 100644 --- a/arch/arm/dts/k3-am65-iot2050-boot-image.dtsi +++ b/arch/arm/dts/k3-am65-iot2050-boot-image.dtsi @@ -111,10 +111,19 @@ }; /* OTP update command block */ +#if CONFIG_IOT2050_EMBED_OTPCMD + blob-ext@0x6c { + offset = <0x6c>; + size = <0x01>; + filename = "otpcmd.bin"; + missing-msg = "iot2050-otpcmd"; + }; +#else fill@0x6c { offset = <0x6c>; size = <0x01>; fill-byte = [ff]; }; +#endif }; }; diff --git a/board/siemens/iot2050/Kconfig b/board/siemens/iot2050/Kconfig index a2b40881d11..e66b2427d95 100644 --- a/board/siemens/iot2050/Kconfig +++ b/board/siemens/iot2050/Kconfig @@ -49,4 +49,11 @@ config IOT2050_BOOT_SWITCH bool "Disable eMMC boot via USER button (Advanced version only)" default y +config IOT2050_EMBED_OTPCMD + bool "Embed OTP programming data" + help + Embed signed OTP programming data 'otpcmd.bin' into the firmware + image. This data will be evaluated and executed on first boot of the + device. + endif diff --git a/doc/board/siemens/iot2050.rst b/doc/board/siemens/iot2050.rst index 4e0925c72c9..cb49a0e36bf 100644 --- a/doc/board/siemens/iot2050.rst +++ b/doc/board/siemens/iot2050.rst @@ -27,6 +27,14 @@ The following binaries from that source need to be present in the build folder: - seboot_pg1.bin - seboot_pg2.bin +For building an image containing the OTP key provisioning data, below binary +needs to be present in the build folder: + + - otpcmd.bin + +Regarding how to generating this otpcmd.bin, please refer to: +https://github.com/siemens/meta-iot2050/tree/master/recipes-bsp/secure-boot-otp-provisioning/files/make-otpcmd.sh + Building diff --git a/tools/binman/missing-blob-help b/tools/binman/missing-blob-help index 1a30da7b5aa..db16229f9f2 100644 --- a/tools/binman/missing-blob-help +++ b/tools/binman/missing-blob-help @@ -23,6 +23,14 @@ See the documentation for IOT2050 board. Your image is missing SEBoot which is mandatory for board startup. Prebuilt SEBoot located at meta-iot2050/tree/master/recipes-bsp/u-boot/files/prebuild/seboot_pg*.bin. +iot2050-otpcmd: +See the documentation for IOT2050 board. Your image is missing OTP command data +block which is used for provisioning the customer keys to the board. +Please refer to +meta-iot2050/tree/master/recipes-bsp/secure-boot-otp-provisioning/files/make-otpcmd.sh +for how to generate this binary. If you are not using secure boot or do not +intend to provision the keys, disable CONFIG_IOT2050_EMBED_OTPCMD. + k3-rti-wdt-firmware: If CONFIG_WDT_K3_RTI_LOAD_FW is enabled, a firmware image is needed for the R5F core(s) to trigger the system reset. One possible source is -- 2.35.3
[PATCH V7 08/15] tools: Add script for converting public key into device tree include
From: Jan Kiszka Allows to create a public key device tree dtsi for inclusion into U-Boot SPL and proper during first build already. This can be achieved via CONFIG_DEVICE_TREE_INCLUDES. Signed-off-by: Jan Kiszka --- tools/key2dtsi.py | 64 +++ 1 file changed, 64 insertions(+) create mode 100755 tools/key2dtsi.py diff --git a/tools/key2dtsi.py b/tools/key2dtsi.py new file mode 100755 index 000..1dbb2cc94bf --- /dev/null +++ b/tools/key2dtsi.py @@ -0,0 +1,64 @@ +#!/usr/bin/env python3 +# SPDX-License-Identifier: GPL-2.0-only +# +# Public key to dtsi converter. +# +# Copyright (c) Siemens AG, 2022 +# + +from argparse import ArgumentParser, FileType +from os.path import basename, splitext +from Cryptodome.PublicKey import RSA +from Cryptodome.Util.number import inverse + +def int_to_bytestr(n, length=None): +if not length: +length = (n.bit_length() + 7) // 8 +byte_array = n.to_bytes(length, 'big') +return ' '.join(['{:02x}'.format(byte) for byte in byte_array]) + +ap = ArgumentParser(description='Public key to dtsi converter') + +ap.add_argument('--hash', '-H', default='sha256', +help='hash to be used with key (default: sha256)') +ap.add_argument('--required-conf', '-c', action='store_true', +help='mark key required for configuration') +ap.add_argument('--required-image', '-i', action='store_true', +help='mark key required for image') +ap.add_argument('--spl', '-s', action='store_true', +help='mark key for usage in SPL') +ap.add_argument('key_file', metavar='KEY_FILE', type=FileType('r'), +help='key file (formats: X.509, PKCS#1, OpenSSH)') +ap.add_argument('dtsi_file', metavar='DTSI_FILE', type=FileType('w'), +help='dtsi output file') + +args = ap.parse_args() + +key_name, _ = splitext(basename(args.key_file.name)) + +key_data = args.key_file.read() +key = RSA.importKey(key_data) + +r_squared = (2**key.size_in_bits())**2 % key.n +n0_inverse = 2**32 - inverse(key.n, 2**32) + +out = args.dtsi_file +out.write('/ {\n') +out.write('\tsignature {\n') +out.write('\t\tkey-{} {{\n'.format(key_name)) +out.write('\t\t\tkey-name-hint = "{}";\n'.format(key_name)) +out.write('\t\t\talgo = "{},rsa{}";\n'.format(args.hash, key.size_in_bits())) +out.write('\t\t\trsa,num-bits = <{}>;\n'.format(key.size_in_bits())) +out.write('\t\t\trsa,modulus = [{}];\n'.format(int_to_bytestr(key.n))) +out.write('\t\t\trsa,exponent = [{}];\n'.format(int_to_bytestr(key.e, 8))) +out.write('\t\t\trsa,r-squared = [{}];\n'.format(int_to_bytestr(r_squared))) +out.write('\t\t\trsa,n0-inverse = <0x{:x}>;\n'.format(n0_inverse)) +if args.required_conf: +out.write('\t\t\trequired = "conf";\n') +elif args.required_image: +out.write('\t\t\trequired = "image";\n') +if args.spl: +out.write('\t\t\tu-boot,dm-spl;\n') +out.write('\t\t};\n') +out.write('\t};\n') +out.write('};\n') -- 2.35.3
[PATCH V7 09/15] iot2050: Add script for signing artifacts
From: Jan Kiszka There are many ways to get a signed firmware for the IOT2050 devices, namely for the parts under user-control. This script documents one way of doing it, given a signing key. Augment the board documentation with the required procedure around it. Signed-off-by: Jan Kiszka --- doc/board/siemens/iot2050.rst | 52 +++ tools/iot2050-sign-fw.sh | 51 ++ 2 files changed, 103 insertions(+) create mode 100755 tools/iot2050-sign-fw.sh diff --git a/doc/board/siemens/iot2050.rst b/doc/board/siemens/iot2050.rst index 26972e20ae9..4e0925c72c9 100644 --- a/doc/board/siemens/iot2050.rst +++ b/doc/board/siemens/iot2050.rst @@ -79,3 +79,55 @@ Via external programmer Dediprog SF100 or SF600: .. code-block:: text $ dpcmd --vcc 2 -v -u flash.bin + +Signing (optional) +-- + +To enable verified boot for the firmware artifacts after the Siemens-managed +first-stage loader (seboot_pg*.bin), the following steps need to be taken +before and after the build: + +Generate dtsi holding the public key + + +.. code-block:: text + + tools/key2dtsi.py -c -s key.pem public-key.dtsi + +This will be used to embed the public key into U-Boot SPL and main so that each +step can validate signatures of the succeeding one. + +Adjust U-Boot configuration +^^^ + +Enabled at least the following options in U-Boot: + +.. code-block:: text + + CONFIG_SPL_FIT_SIGNATURE=y + CONFIG_DEVICE_TREE_INCLUDES="/path/to/public-key.dtsi" + CONFIG_RSA=y + +Note that there are more configuration changes needed in order to lock-down +the command line and the boot process of U-Boot for secure scenarios. These are +not in scope here. + +Build U-Boot + + +See related section above. + +Sign flash.bin +^^ + +In the build folder still containing artifacts from step 3, invoke: + +.. code-block:: text + + tools/iot2050-sign-fw.sh /path/to/key.pem + +Flash signed flash.bin +^^ + +The signing has happen in-place in flash.bin, thus the flashing procedure +described above. diff --git a/tools/iot2050-sign-fw.sh b/tools/iot2050-sign-fw.sh new file mode 100755 index 000..4d1d79498c2 --- /dev/null +++ b/tools/iot2050-sign-fw.sh @@ -0,0 +1,51 @@ +#!/bin/sh + +if [ -z "$1" ]; then + echo "Usage: $0 KEY" + exit 1 +fi + +TEMP_X509=$(mktemp .temp) + +REVISION=${2:-0} +SHA_VAL=$(openssl dgst -sha512 -hex tispl.bin | sed -e "s/^.*= //g") +BIN_SIZE=$(stat -c %s tispl.bin) + +cat <$TEMP_X509 +[ req ] +distinguished_name = req_distinguished_name +x509_extensions= v3_ca +prompt = no +dirstring_type = nobmp + +[ req_distinguished_name ] +CN = IOT2050 Firmware Signature + +[ v3_ca ] +basicConstraints = CA:true +1.3.6.1.4.1.294.1.3= ASN1:SEQUENCE:swrv +1.3.6.1.4.1.294.1.34 = ASN1:SEQUENCE:sysfw_image_integrity + +[ swrv ] +swrv = INTEGER:$REVISION + +[ sysfw_image_integrity ] +shaType= OID:2.16.840.1.101.3.4.2.3 +shaValue = FORMAT:HEX,OCT:$SHA_VAL +imageSize = INTEGER:$BIN_SIZE +EOF + +CERT_X509=$(mktemp .crt) + +openssl req -new -x509 -key $1 -nodes -outform DER -out $CERT_X509 -config $TEMP_X509 -sha512 +cat $CERT_X509 tispl.bin > tispl.bin_signed +# currently broken in upstream +#source/tools/binman/binman replace -i flash.bin -f tispl.bin_signed blob@0x18 +dd if=tispl.bin_signed of=flash.bin bs=$((0x1000)) seek=$((0x18/0x1000)) conv=notrunc + +rm $TEMP_X509 $CERT_X509 + +tools/mkimage -G $1 -r -o sha256,rsa4096 -F f...@0x38.fit +# currently broken in upstream +#source/tools/binman/binman replace -i flash.bin -f f...@0x38.fit fit@0x38 +dd if=f...@0x38.fit of=flash.bin bs=$((0x1000)) seek=$((0x38/0x1000)) conv=notrunc -- 2.35.3
[PATCH V7 12/15] board: siemens: iot2050: use the named gpio to control the user-button
From: chao zeng User-button is controlled by the mcu domain gpio number 25. But main0 main1 mcu domain all have gpio number 25. To identify where the gpio is from, Using gpio controll base as the prefix to indicate the gpio resource. Signed-off-by: chao zeng --- board/siemens/iot2050/board.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/board/siemens/iot2050/board.c b/board/siemens/iot2050/board.c index 57d7009e8c7..2735ae3fb74 100644 --- a/board/siemens/iot2050/board.c +++ b/board/siemens/iot2050/board.c @@ -183,7 +183,7 @@ static bool user_button_pressed(void) memset(&gpio, 0, sizeof(gpio)); - if (dm_gpio_lookup_name("25", &gpio) < 0 || + if (dm_gpio_lookup_name("gpio@4211_25", &gpio) < 0 || dm_gpio_request(&gpio, "USER button") < 0 || dm_gpio_set_dir_flags(&gpio, GPIOD_IS_IN) < 0) return false; -- 2.35.3