[PATCH 0/3] iot2050: Re-unify its configs and build processes

[PATCH 0/3] iot2050: Re-unify its configs and build processes

[Jan Kiszka]

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 <sjg@chromium.org>

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

[Jan Kiszka]

From: Jan Kiszka <jan.kiszka@siemens.com>

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 <jan.kiszka@siemens.com>
---
CC: Simon Glass <sjg@chromium.org>
---
 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 1/3] binman: Allow to define custom arguments

[Simon Glass]

Hi Jan,

On Mon, 5 Jun 2023 at 15:39, Jan Kiszka <jan.kiszka@siemens.com> wrote:
>
> From: Jan Kiszka <jan.kiszka@siemens.com>
>
> 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 <jan.kiszka@siemens.com>
> ---
> CC: Simon Glass <sjg@chromium.org>
> ---
>  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

Regards,
Simon

Re: [PATCH 1/3] binman: Allow to define custom arguments

[Jan Kiszka]

On 12.06.23 23:17, Simon Glass wrote:
> Hi Jan,
> 
> On Mon, 5 Jun 2023 at 15:39, Jan Kiszka <jan.kiszka@siemens.com> wrote:
>>
>> From: Jan Kiszka <jan.kiszka@siemens.com>
>>
>> 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 <jan.kiszka@siemens.com>
>> ---
>> CC: Simon Glass <sjg@chromium.org>
>> ---
>>  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 1/3] binman: Allow to define custom arguments

[Simon Glass]

Hi Jan,

On Thu, 15 Jun 2023 at 11:26, Jan Kiszka <jan.kiszka@siemens.com> wrote:
>
> On 12.06.23 23:17, Simon Glass wrote:
> > Hi Jan,
> >
> > On Mon, 5 Jun 2023 at 15:39, Jan Kiszka <jan.kiszka@siemens.com> wrote:
> >>
> >> From: Jan Kiszka <jan.kiszka@siemens.com>
> >>
> >> 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 <jan.kiszka@siemens.com>
> >> ---
> >> CC: Simon Glass <sjg@chromium.org>
> >> ---
> >>  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.

Regards,
Simon

>
> Jan
>
> --
> Siemens AG, Technology
> Competence Center Embedded Linux
>

Re: [PATCH 1/3] binman: Allow to define custom arguments

[Jan Kiszka]

On 15.06.23 12:55, Simon Glass wrote:
> Hi Jan,
> 
> On Thu, 15 Jun 2023 at 11:26, Jan Kiszka <jan.kiszka@siemens.com> wrote:
>>
>> On 12.06.23 23:17, Simon Glass wrote:
>>> Hi Jan,
>>>
>>> On Mon, 5 Jun 2023 at 15:39, Jan Kiszka <jan.kiszka@siemens.com> wrote:
>>>>
>>>> From: Jan Kiszka <jan.kiszka@siemens.com>
>>>>
>>>> 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 <jan.kiszka@siemens.com>
>>>> ---
>>>> CC: Simon Glass <sjg@chromium.org>
>>>> ---
>>>>  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

[Simon Glass]

Hi Jan,

On Thu, 15 Jun 2023 at 12:09, Jan Kiszka <jan.kiszka@siemens.com> wrote:
>
> On 15.06.23 12:55, Simon Glass wrote:
> > Hi Jan,
> >
> > On Thu, 15 Jun 2023 at 11:26, Jan Kiszka <jan.kiszka@siemens.com> wrote:
> >>
> >> On 12.06.23 23:17, Simon Glass wrote:
> >>> Hi Jan,
> >>>
> >>> On Mon, 5 Jun 2023 at 15:39, Jan Kiszka <jan.kiszka@siemens.com> wrote:
> >>>>
> >>>> From: Jan Kiszka <jan.kiszka@siemens.com>
> >>>>
> >>>> 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 <jan.kiszka@siemens.com>
> >>>> ---
> >>>> CC: Simon Glass <sjg@chromium.org>
> >>>> ---
> >>>>  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.

Regards,
Simon

Re: [PATCH 1/3] binman: Allow to define custom arguments

[Jan Kiszka]

On 15.06.23 13:19, Simon Glass wrote:
> Hi Jan,
> 
> On Thu, 15 Jun 2023 at 12:09, Jan Kiszka <jan.kiszka@siemens.com> wrote:
>>
>> On 15.06.23 12:55, Simon Glass wrote:
>>> Hi Jan,
>>>
>>> On Thu, 15 Jun 2023 at 11:26, Jan Kiszka <jan.kiszka@siemens.com> wrote:
>>>>
>>>> On 12.06.23 23:17, Simon Glass wrote:
>>>>> Hi Jan,
>>>>>
>>>>> On Mon, 5 Jun 2023 at 15:39, Jan Kiszka <jan.kiszka@siemens.com> wrote:
>>>>>>
>>>>>> From: Jan Kiszka <jan.kiszka@siemens.com>
>>>>>>
>>>>>> 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 <jan.kiszka@siemens.com>
>>>>>> ---
>>>>>> CC: Simon Glass <sjg@chromium.org>
>>>>>> ---
>>>>>>  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

[Simon Glass]

Hi Jan,

On Thu, 15 Jun 2023 at 12:21, Jan Kiszka <jan.kiszka@siemens.com> wrote:
>
> On 15.06.23 13:19, Simon Glass wrote:
> > Hi Jan,
> >
> > On Thu, 15 Jun 2023 at 12:09, Jan Kiszka <jan.kiszka@siemens.com> wrote:
> >>
> >> On 15.06.23 12:55, Simon Glass wrote:
> >>> Hi Jan,
> >>>
> >>> On Thu, 15 Jun 2023 at 11:26, Jan Kiszka <jan.kiszka@siemens.com> wrote:
> >>>>
> >>>> On 12.06.23 23:17, Simon Glass wrote:
> >>>>> Hi Jan,
> >>>>>
> >>>>> On Mon, 5 Jun 2023 at 15:39, Jan Kiszka <jan.kiszka@siemens.com> wrote:
> >>>>>>
> >>>>>> From: Jan Kiszka <jan.kiszka@siemens.com>
> >>>>>>
> >>>>>> 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 <jan.kiszka@siemens.com>
> >>>>>> ---
> >>>>>> CC: Simon Glass <sjg@chromium.org>
> >>>>>> ---
> >>>>>>  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?

We could provide a way to select between different lists, but how does
Makefile get access to them?

Regards,
Simon

Re: [PATCH 1/3] binman: Allow to define custom arguments

[Jan Kiszka]

On 15.06.23 13:38, Simon Glass wrote:
> Hi Jan,
> 
> On Thu, 15 Jun 2023 at 12:21, Jan Kiszka <jan.kiszka@siemens.com> wrote:
>>
>> On 15.06.23 13:19, Simon Glass wrote:
>>> Hi Jan,
>>>
>>> On Thu, 15 Jun 2023 at 12:09, Jan Kiszka <jan.kiszka@siemens.com> wrote:
>>>>
>>>> On 15.06.23 12:55, Simon Glass wrote:
>>>>> Hi Jan,
>>>>>
>>>>> On Thu, 15 Jun 2023 at 11:26, Jan Kiszka <jan.kiszka@siemens.com> wrote:
>>>>>>
>>>>>> On 12.06.23 23:17, Simon Glass wrote:
>>>>>>> Hi Jan,
>>>>>>>
>>>>>>> On Mon, 5 Jun 2023 at 15:39, Jan Kiszka <jan.kiszka@siemens.com> wrote:
>>>>>>>>
>>>>>>>> From: Jan Kiszka <jan.kiszka@siemens.com>
>>>>>>>>
>>>>>>>> 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 <jan.kiszka@siemens.com>
>>>>>>>> ---
>>>>>>>> CC: Simon Glass <sjg@chromium.org>
>>>>>>>> ---
>>>>>>>>  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 1/3] binman: Allow to define custom arguments

[Jan Kiszka]

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 <jan.kiszka@siemens.com> wrote:
>>>
>>> On 15.06.23 13:19, Simon Glass wrote:
>>>> Hi Jan,
>>>>
>>>> On Thu, 15 Jun 2023 at 12:09, Jan Kiszka <jan.kiszka@siemens.com> wrote:
>>>>>
>>>>> On 15.06.23 12:55, Simon Glass wrote:
>>>>>> Hi Jan,
>>>>>>
>>>>>> On Thu, 15 Jun 2023 at 11:26, Jan Kiszka <jan.kiszka@siemens.com> wrote:
>>>>>>>
>>>>>>> On 12.06.23 23:17, Simon Glass wrote:
>>>>>>>> Hi Jan,
>>>>>>>>
>>>>>>>> On Mon, 5 Jun 2023 at 15:39, Jan Kiszka <jan.kiszka@siemens.com> wrote:
>>>>>>>>>
>>>>>>>>> From: Jan Kiszka <jan.kiszka@siemens.com>
>>>>>>>>>
>>>>>>>>> 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 <jan.kiszka@siemens.com>
>>>>>>>>> ---
>>>>>>>>> CC: Simon Glass <sjg@chromium.org>
>>>>>>>>> ---
>>>>>>>>>  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

[Simon Glass]

Hi Jan,

On Fri, 16 Jun 2023 at 16:42, Jan Kiszka <jan.kiszka@siemens.com> 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 <jan.kiszka@siemens.com> wrote:
> >>>
> >>> On 15.06.23 13:19, Simon Glass wrote:
> >>>> Hi Jan,
> >>>>
> >>>> On Thu, 15 Jun 2023 at 12:09, Jan Kiszka <jan.kiszka@siemens.com> wrote:
> >>>>>
> >>>>> On 15.06.23 12:55, Simon Glass wrote:
> >>>>>> Hi Jan,
> >>>>>>
> >>>>>> On Thu, 15 Jun 2023 at 11:26, Jan Kiszka <jan.kiszka@siemens.com> wrote:
> >>>>>>>
> >>>>>>> On 12.06.23 23:17, Simon Glass wrote:
> >>>>>>>> Hi Jan,
> >>>>>>>>
> >>>>>>>> On Mon, 5 Jun 2023 at 15:39, Jan Kiszka <jan.kiszka@siemens.com> wrote:
> >>>>>>>>>
> >>>>>>>>> From: Jan Kiszka <jan.kiszka@siemens.com>
> >>>>>>>>>
> >>>>>>>>> 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 <jan.kiszka@siemens.com>
> >>>>>>>>> ---
> >>>>>>>>> CC: Simon Glass <sjg@chromium.org>
> >>>>>>>>> ---
> >>>>>>>>>  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

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.

I think with this you should be above to eliminate BINMAN_EXTRA_ARGS
and all the #define stuff.

Please take a look and let me know if it doesn't make sense.

Regards,
Simon

Re: [PATCH 1/3] binman: Allow to define custom arguments

[Jan Kiszka]

On 19.06.23 14:36, Simon Glass wrote:
> Hi Jan,
> 
> On Fri, 16 Jun 2023 at 16:42, Jan Kiszka <jan.kiszka@siemens.com> 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 <jan.kiszka@siemens.com> wrote:
>>>>>
>>>>> On 15.06.23 13:19, Simon Glass wrote:
>>>>>> Hi Jan,
>>>>>>
>>>>>> On Thu, 15 Jun 2023 at 12:09, Jan Kiszka <jan.kiszka@siemens.com> wrote:
>>>>>>>
>>>>>>> On 15.06.23 12:55, Simon Glass wrote:
>>>>>>>> Hi Jan,
>>>>>>>>
>>>>>>>> On Thu, 15 Jun 2023 at 11:26, Jan Kiszka <jan.kiszka@siemens.com> wrote:
>>>>>>>>>
>>>>>>>>> On 12.06.23 23:17, Simon Glass wrote:
>>>>>>>>>> Hi Jan,
>>>>>>>>>>
>>>>>>>>>> On Mon, 5 Jun 2023 at 15:39, Jan Kiszka <jan.kiszka@siemens.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>> From: Jan Kiszka <jan.kiszka@siemens.com>
>>>>>>>>>>>
>>>>>>>>>>> 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 <jan.kiszka@siemens.com>
>>>>>>>>>>> ---
>>>>>>>>>>> CC: Simon Glass <sjg@chromium.org>
>>>>>>>>>>> ---
>>>>>>>>>>>  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

[Simon Glass]

Hi Jan,

On Mon, 19 Jun 2023 at 14:28, Jan Kiszka <jan.kiszka@siemens.com> wrote:
>
> On 19.06.23 14:36, Simon Glass wrote:
> > Hi Jan,
> >
> > On Fri, 16 Jun 2023 at 16:42, Jan Kiszka <jan.kiszka@siemens.com> 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 <jan.kiszka@siemens.com> wrote:
> >>>>>
> >>>>> On 15.06.23 13:19, Simon Glass wrote:
> >>>>>> Hi Jan,
> >>>>>>
> >>>>>> On Thu, 15 Jun 2023 at 12:09, Jan Kiszka <jan.kiszka@siemens.com> wrote:
> >>>>>>>
> >>>>>>> On 15.06.23 12:55, Simon Glass wrote:
> >>>>>>>> Hi Jan,
> >>>>>>>>
> >>>>>>>> On Thu, 15 Jun 2023 at 11:26, Jan Kiszka <jan.kiszka@siemens.com> wrote:
> >>>>>>>>>
> >>>>>>>>> On 12.06.23 23:17, Simon Glass wrote:
> >>>>>>>>>> Hi Jan,
> >>>>>>>>>>
> >>>>>>>>>> On Mon, 5 Jun 2023 at 15:39, Jan Kiszka <jan.kiszka@siemens.com> wrote:
> >>>>>>>>>>>
> >>>>>>>>>>> From: Jan Kiszka <jan.kiszka@siemens.com>
> >>>>>>>>>>>
> >>>>>>>>>>> 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 <jan.kiszka@siemens.com>
> >>>>>>>>>>> ---
> >>>>>>>>>>> CC: Simon Glass <sjg@chromium.org>
> >>>>>>>>>>> ---
> >>>>>>>>>>>  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.

Regards,
Simon

Re: [PATCH 1/3] binman: Allow to define custom arguments

[Jan Kiszka]

On 19.06.23 16:09, Simon Glass wrote:
> Hi Jan,
> 
> On Mon, 19 Jun 2023 at 14:28, Jan Kiszka <jan.kiszka@siemens.com> wrote:
>>
>> On 19.06.23 14:36, Simon Glass wrote:
>>> Hi Jan,
>>>
>>> On Fri, 16 Jun 2023 at 16:42, Jan Kiszka <jan.kiszka@siemens.com> 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 <jan.kiszka@siemens.com> wrote:
>>>>>>>
>>>>>>> On 15.06.23 13:19, Simon Glass wrote:
>>>>>>>> Hi Jan,
>>>>>>>>
>>>>>>>> On Thu, 15 Jun 2023 at 12:09, Jan Kiszka <jan.kiszka@siemens.com> wrote:
>>>>>>>>>
>>>>>>>>> On 15.06.23 12:55, Simon Glass wrote:
>>>>>>>>>> Hi Jan,
>>>>>>>>>>
>>>>>>>>>> On Thu, 15 Jun 2023 at 11:26, Jan Kiszka <jan.kiszka@siemens.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>> On 12.06.23 23:17, Simon Glass wrote:
>>>>>>>>>>>> Hi Jan,
>>>>>>>>>>>>
>>>>>>>>>>>> On Mon, 5 Jun 2023 at 15:39, Jan Kiszka <jan.kiszka@siemens.com> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> From: Jan Kiszka <jan.kiszka@siemens.com>
>>>>>>>>>>>>>
>>>>>>>>>>>>> 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 <jan.kiszka@siemens.com>
>>>>>>>>>>>>> ---
>>>>>>>>>>>>> CC: Simon Glass <sjg@chromium.org>
>>>>>>>>>>>>> ---
>>>>>>>>>>>>>  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

[Simon Glass]

Hi Jan,

On Mon, 19 Jun 2023 at 16:09, Jan Kiszka <jan.kiszka@siemens.com> wrote:
>
> On 19.06.23 16:09, Simon Glass wrote:
> > Hi Jan,
> >
> > On Mon, 19 Jun 2023 at 14:28, Jan Kiszka <jan.kiszka@siemens.com> wrote:
> >>
> >> On 19.06.23 14:36, Simon Glass wrote:
> >>> Hi Jan,
> >>>
> >>> On Fri, 16 Jun 2023 at 16:42, Jan Kiszka <jan.kiszka@siemens.com> 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 <jan.kiszka@siemens.com> wrote:
> >>>>>>>
> >>>>>>> On 15.06.23 13:19, Simon Glass wrote:
> >>>>>>>> Hi Jan,
> >>>>>>>>
> >>>>>>>> On Thu, 15 Jun 2023 at 12:09, Jan Kiszka <jan.kiszka@siemens.com> wrote:
> >>>>>>>>>
> >>>>>>>>> On 15.06.23 12:55, Simon Glass wrote:
> >>>>>>>>>> Hi Jan,
> >>>>>>>>>>
> >>>>>>>>>> On Thu, 15 Jun 2023 at 11:26, Jan Kiszka <jan.kiszka@siemens.com> wrote:
> >>>>>>>>>>>
> >>>>>>>>>>> On 12.06.23 23:17, Simon Glass wrote:
> >>>>>>>>>>>> Hi Jan,
> >>>>>>>>>>>>
> >>>>>>>>>>>> On Mon, 5 Jun 2023 at 15:39, Jan Kiszka <jan.kiszka@siemens.com> wrote:
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> From: Jan Kiszka <jan.kiszka@siemens.com>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> 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 <jan.kiszka@siemens.com>
> >>>>>>>>>>>>> ---
> >>>>>>>>>>>>> CC: Simon Glass <sjg@chromium.org>
> >>>>>>>>>>>>> ---
> >>>>>>>>>>>>>  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

OK that looks a lot better to me. We can go with that until we come up
with something better.

There has been a long-standing request to support common parts of images.

I am thinking something like this:

common_part: common-part {
    template;   // indicates this is not a real image
    entry1 {
        ...
    };
    entry2 {
        ...
   };
};

image1 {
   add-entries = <&common_part>;
   entry1 {
      fit,fdt-list = "something";
   };
};

image2 {
   add-entries = <&common_part>;

   // override a few things from entry1
   entry1 {
      fit,fdt-list = "something else";
   };
};

This would allow a common part to be included but still be adjusted
depending on what each image needs. What do you think?

Regards,
Simon

Re: [PATCH 1/3] binman: Allow to define custom arguments

[Jan Kiszka]

On 20.06.23 12:11, Simon Glass wrote:
> Hi Jan,
> 
> On Mon, 19 Jun 2023 at 16:09, Jan Kiszka <jan.kiszka@siemens.com> wrote:
>>
>> On 19.06.23 16:09, Simon Glass wrote:
>>> Hi Jan,
>>>
>>> On Mon, 19 Jun 2023 at 14:28, Jan Kiszka <jan.kiszka@siemens.com> wrote:
>>>>
>>>> On 19.06.23 14:36, Simon Glass wrote:
>>>>> Hi Jan,
>>>>>
>>>>> On Fri, 16 Jun 2023 at 16:42, Jan Kiszka <jan.kiszka@siemens.com> 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 <jan.kiszka@siemens.com> wrote:
>>>>>>>>>
>>>>>>>>> On 15.06.23 13:19, Simon Glass wrote:
>>>>>>>>>> Hi Jan,
>>>>>>>>>>
>>>>>>>>>> On Thu, 15 Jun 2023 at 12:09, Jan Kiszka <jan.kiszka@siemens.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>> On 15.06.23 12:55, Simon Glass wrote:
>>>>>>>>>>>> Hi Jan,
>>>>>>>>>>>>
>>>>>>>>>>>> On Thu, 15 Jun 2023 at 11:26, Jan Kiszka <jan.kiszka@siemens.com> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 12.06.23 23:17, Simon Glass wrote:
>>>>>>>>>>>>>> Hi Jan,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Mon, 5 Jun 2023 at 15:39, Jan Kiszka <jan.kiszka@siemens.com> wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> From: Jan Kiszka <jan.kiszka@siemens.com>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 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 <jan.kiszka@siemens.com>
>>>>>>>>>>>>>>> ---
>>>>>>>>>>>>>>> CC: Simon Glass <sjg@chromium.org>
>>>>>>>>>>>>>>> ---
>>>>>>>>>>>>>>>  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
> 
> OK that looks a lot better to me. We can go with that until we come up
> with something better.
> 
> There has been a long-standing request to support common parts of images.
> 
> I am thinking something like this:
> 
> common_part: common-part {
>     template;   // indicates this is not a real image
>     entry1 {
>         ...
>     };
>     entry2 {
>         ...
>    };
> };
> 
> image1 {
>    add-entries = <&common_part>;
>    entry1 {
>       fit,fdt-list = "something";
>    };
> };
> 
> image2 {
>    add-entries = <&common_part>;
> 
>    // override a few things from entry1
>    entry1 {
>       fit,fdt-list = "something else";
>    };
> };
> 
> This would allow a common part to be included but still be adjusted
> depending on what each image needs. What do you think?

Ok, that saves us from the less ugly but still ugly template inclusion -
starting to understand. Will play with that.

But it still does not resolve the need to customize the bitman command
line for multiple of-lists.

Jan

-- 
Siemens AG, Technology
Competence Center Embedded Linux

Re: [PATCH 1/3] binman: Allow to define custom arguments

[Simon Glass]

Hi Jan,

On Tue, 20 Jun 2023 at 11:37, Jan Kiszka <jan.kiszka@siemens.com> wrote:
>
> On 20.06.23 12:11, Simon Glass wrote:
> > Hi Jan,
> >
> > On Mon, 19 Jun 2023 at 16:09, Jan Kiszka <jan.kiszka@siemens.com> wrote:
> >>
> >> On 19.06.23 16:09, Simon Glass wrote:
> >>> Hi Jan,
> >>>
> >>> On Mon, 19 Jun 2023 at 14:28, Jan Kiszka <jan.kiszka@siemens.com> wrote:
> >>>>
> >>>> On 19.06.23 14:36, Simon Glass wrote:
> >>>>> Hi Jan,
> >>>>>
> >>>>> On Fri, 16 Jun 2023 at 16:42, Jan Kiszka <jan.kiszka@siemens.com> 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 <jan.kiszka@siemens.com> wrote:
> >>>>>>>>>
> >>>>>>>>> On 15.06.23 13:19, Simon Glass wrote:
> >>>>>>>>>> Hi Jan,
> >>>>>>>>>>
> >>>>>>>>>> On Thu, 15 Jun 2023 at 12:09, Jan Kiszka <jan.kiszka@siemens.com> wrote:
> >>>>>>>>>>>
> >>>>>>>>>>> On 15.06.23 12:55, Simon Glass wrote:
> >>>>>>>>>>>> Hi Jan,
> >>>>>>>>>>>>
> >>>>>>>>>>>> On Thu, 15 Jun 2023 at 11:26, Jan Kiszka <jan.kiszka@siemens.com> wrote:
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> On 12.06.23 23:17, Simon Glass wrote:
> >>>>>>>>>>>>>> Hi Jan,
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> On Mon, 5 Jun 2023 at 15:39, Jan Kiszka <jan.kiszka@siemens.com> wrote:
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> From: Jan Kiszka <jan.kiszka@siemens.com>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> 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 <jan.kiszka@siemens.com>
> >>>>>>>>>>>>>>> ---
> >>>>>>>>>>>>>>> CC: Simon Glass <sjg@chromium.org>
> >>>>>>>>>>>>>>> ---
> >>>>>>>>>>>>>>>  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
> >
> > OK that looks a lot better to me. We can go with that until we come up
> > with something better.
> >
> > There has been a long-standing request to support common parts of images.
> >
> > I am thinking something like this:
> >
> > common_part: common-part {
> >     template;   // indicates this is not a real image
> >     entry1 {
> >         ...
> >     };
> >     entry2 {
> >         ...
> >    };
> > };
> >
> > image1 {
> >    add-entries = <&common_part>;
> >    entry1 {
> >       fit,fdt-list = "something";
> >    };
> > };
> >
> > image2 {
> >    add-entries = <&common_part>;
> >
> >    // override a few things from entry1
> >    entry1 {
> >       fit,fdt-list = "something else";
> >    };
> > };
> >
> > This would allow a common part to be included but still be adjusted
> > depending on what each image needs. What do you think?
>
> Ok, that saves us from the less ugly but still ugly template inclusion -
> starting to understand. Will play with that.

Note that the above is not implemented yet! It is just an idea, so let
me know what you think.

>
> But it still does not resolve the need to customize the bitman command
> line for multiple of-lists.

At the moment you have:

fit,fdt-list = IOT2050_FLASH_DT_LIST;

with that defined as:

#define IOT2050_FLASH_DT_LIST "of-list-pg2"

and then you do:

-a of-list-pg1="k3-am6528-iot2050-basic k3-am6548-iot2050-advanced" \

I wonder if we should have something like:

fit,fdt-list-val = "k3-am6528-iot2050-basic", "k3-am6548-iot2050-advanced";

and avoid the entry-arg redirection? Then you can add the property in
as I showed above.

Regards,
Simon

Re: [PATCH 1/3] binman: Allow to define custom arguments

[Jan Kiszka]

On 20.06.23 16:36, Simon Glass wrote:
> Hi Jan,
> 
> On Tue, 20 Jun 2023 at 11:37, Jan Kiszka <jan.kiszka@siemens.com> wrote:
>>
>> On 20.06.23 12:11, Simon Glass wrote:
>>> Hi Jan,
>>>
>>> On Mon, 19 Jun 2023 at 16:09, Jan Kiszka <jan.kiszka@siemens.com> wrote:
>>>>
>>>> On 19.06.23 16:09, Simon Glass wrote:
>>>>> Hi Jan,
>>>>>
>>>>> On Mon, 19 Jun 2023 at 14:28, Jan Kiszka <jan.kiszka@siemens.com> wrote:
>>>>>>
>>>>>> On 19.06.23 14:36, Simon Glass wrote:
>>>>>>> Hi Jan,
>>>>>>>
>>>>>>> On Fri, 16 Jun 2023 at 16:42, Jan Kiszka <jan.kiszka@siemens.com> 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 <jan.kiszka@siemens.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>> On 15.06.23 13:19, Simon Glass wrote:
>>>>>>>>>>>> Hi Jan,
>>>>>>>>>>>>
>>>>>>>>>>>> On Thu, 15 Jun 2023 at 12:09, Jan Kiszka <jan.kiszka@siemens.com> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 15.06.23 12:55, Simon Glass wrote:
>>>>>>>>>>>>>> Hi Jan,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Thu, 15 Jun 2023 at 11:26, Jan Kiszka <jan.kiszka@siemens.com> wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 12.06.23 23:17, Simon Glass wrote:
>>>>>>>>>>>>>>>> Hi Jan,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On Mon, 5 Jun 2023 at 15:39, Jan Kiszka <jan.kiszka@siemens.com> wrote:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> From: Jan Kiszka <jan.kiszka@siemens.com>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> 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 <jan.kiszka@siemens.com>
>>>>>>>>>>>>>>>>> ---
>>>>>>>>>>>>>>>>> CC: Simon Glass <sjg@chromium.org>
>>>>>>>>>>>>>>>>> ---
>>>>>>>>>>>>>>>>>  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
>>>
>>> OK that looks a lot better to me. We can go with that until we come up
>>> with something better.
>>>
>>> There has been a long-standing request to support common parts of images.
>>>
>>> I am thinking something like this:
>>>
>>> common_part: common-part {
>>>     template;   // indicates this is not a real image
>>>     entry1 {
>>>         ...
>>>     };
>>>     entry2 {
>>>         ...
>>>    };
>>> };
>>>
>>> image1 {
>>>    add-entries = <&common_part>;
>>>    entry1 {
>>>       fit,fdt-list = "something";
>>>    };
>>> };
>>>
>>> image2 {
>>>    add-entries = <&common_part>;
>>>
>>>    // override a few things from entry1
>>>    entry1 {
>>>       fit,fdt-list = "something else";
>>>    };
>>> };
>>>
>>> This would allow a common part to be included but still be adjusted
>>> depending on what each image needs. What do you think?
>>
>> Ok, that saves us from the less ugly but still ugly template inclusion -
>> starting to understand. Will play with that.
> 
> Note that the above is not implemented yet! It is just an idea, so let
> me know what you think.
> 
>>
>> But it still does not resolve the need to customize the bitman command
>> line for multiple of-lists.
> 
> At the moment you have:
> 
> fit,fdt-list = IOT2050_FLASH_DT_LIST;
> 
> with that defined as:
> 
> #define IOT2050_FLASH_DT_LIST "of-list-pg2"
> 
> and then you do:
> 
> -a of-list-pg1="k3-am6528-iot2050-basic k3-am6548-iot2050-advanced" \
> 
> I wonder if we should have something like:
> 
> fit,fdt-list-val = "k3-am6528-iot2050-basic", "k3-am6548-iot2050-advanced";
> 
> and avoid the entry-arg redirection? Then you can add the property in
> as I showed above.

Yep, that is what would help as said before.

Jan

-- 
Siemens AG, Technology
Competence Center Embedded Linux

Re: [PATCH 1/3] binman: Allow to define custom arguments

[Simon Glass]

Hi Jan,

On Tue, 20 Jun 2023 at 18:05, Jan Kiszka <jan.kiszka@siemens.com> wrote:
>
> On 20.06.23 16:36, Simon Glass wrote:
> > Hi Jan,
> >
> > On Tue, 20 Jun 2023 at 11:37, Jan Kiszka <jan.kiszka@siemens.com> wrote:
> >>
> >> On 20.06.23 12:11, Simon Glass wrote:
> >>> Hi Jan,
> >>>
> >>> On Mon, 19 Jun 2023 at 16:09, Jan Kiszka <jan.kiszka@siemens.com> wrote:
> >>>>
> >>>> On 19.06.23 16:09, Simon Glass wrote:
> >>>>> Hi Jan,
> >>>>>
> >>>>> On Mon, 19 Jun 2023 at 14:28, Jan Kiszka <jan.kiszka@siemens.com> wrote:
> >>>>>>
> >>>>>> On 19.06.23 14:36, Simon Glass wrote:
> >>>>>>> Hi Jan,
> >>>>>>>
> >>>>>>> On Fri, 16 Jun 2023 at 16:42, Jan Kiszka <jan.kiszka@siemens.com> 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 <jan.kiszka@siemens.com> wrote:
> >>>>>>>>>>>
> >>>>>>>>>>> On 15.06.23 13:19, Simon Glass wrote:
> >>>>>>>>>>>> Hi Jan,
> >>>>>>>>>>>>
> >>>>>>>>>>>> On Thu, 15 Jun 2023 at 12:09, Jan Kiszka <jan.kiszka@siemens.com> wrote:
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> On 15.06.23 12:55, Simon Glass wrote:
> >>>>>>>>>>>>>> Hi Jan,
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> On Thu, 15 Jun 2023 at 11:26, Jan Kiszka <jan.kiszka@siemens.com> wrote:
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> On 12.06.23 23:17, Simon Glass wrote:
> >>>>>>>>>>>>>>>> Hi Jan,
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> On Mon, 5 Jun 2023 at 15:39, Jan Kiszka <jan.kiszka@siemens.com> wrote:
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> From: Jan Kiszka <jan.kiszka@siemens.com>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> 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 <jan.kiszka@siemens.com>
> >>>>>>>>>>>>>>>>> ---
> >>>>>>>>>>>>>>>>> CC: Simon Glass <sjg@chromium.org>
> >>>>>>>>>>>>>>>>> ---
> >>>>>>>>>>>>>>>>>  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
> >>>
> >>> OK that looks a lot better to me. We can go with that until we come up
> >>> with something better.
> >>>
> >>> There has been a long-standing request to support common parts of images.
> >>>
> >>> I am thinking something like this:
> >>>
> >>> common_part: common-part {
> >>>     template;   // indicates this is not a real image
> >>>     entry1 {
> >>>         ...
> >>>     };
> >>>     entry2 {
> >>>         ...
> >>>    };
> >>> };
> >>>
> >>> image1 {
> >>>    add-entries = <&common_part>;
> >>>    entry1 {
> >>>       fit,fdt-list = "something";
> >>>    };
> >>> };
> >>>
> >>> image2 {
> >>>    add-entries = <&common_part>;
> >>>
> >>>    // override a few things from entry1
> >>>    entry1 {
> >>>       fit,fdt-list = "something else";
> >>>    };
> >>> };
> >>>
> >>> This would allow a common part to be included but still be adjusted
> >>> depending on what each image needs. What do you think?
> >>
> >> Ok, that saves us from the less ugly but still ugly template inclusion -
> >> starting to understand. Will play with that.
> >
> > Note that the above is not implemented yet! It is just an idea, so let
> > me know what you think.
> >
> >>
> >> But it still does not resolve the need to customize the bitman command
> >> line for multiple of-lists.
> >
> > At the moment you have:
> >
> > fit,fdt-list = IOT2050_FLASH_DT_LIST;
> >
> > with that defined as:
> >
> > #define IOT2050_FLASH_DT_LIST "of-list-pg2"
> >
> > and then you do:
> >
> > -a of-list-pg1="k3-am6528-iot2050-basic k3-am6548-iot2050-advanced" \
> >
> > I wonder if we should have something like:
> >
> > fit,fdt-list-val = "k3-am6528-iot2050-basic", "k3-am6548-iot2050-advanced";
> >
> > and avoid the entry-arg redirection? Then you can add the property in
> > as I showed above.
>
> Yep, that is what would help as said before.

OK I will take a look.

Regards,
Simon

[PATCH 2/3] iot2050: Use binman in signing script

[Jan Kiszka]

From: Jan Kiszka <jan.kiszka@siemens.com>

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 <jan.kiszka@siemens.com>
---
CC: Simon Glass <sjg@chromium.org>
---
 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 XXXXXXXX.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@0x180000
-dd if=tispl.bin_signed of=flash.bin bs=$((0x1000)) seek=$((0x180000/0x1000)) conv=notrunc
+source/tools/binman/binman replace -i flash.bin -f tispl.bin_signed blob@0x180000
 
 rm $TEMP_X509 $CERT_X509
 
 tools/mkimage -G $1 -r -o sha256,rsa4096 -F fit@0x380000.fit
-# currently broken in upstream
-#source/tools/binman/binman replace -i flash.bin -f fit@0x380000.fit fit@0x380000
-dd if=fit@0x380000.fit of=flash.bin bs=$((0x1000)) seek=$((0x380000/0x1000)) conv=notrunc
+source/tools/binman/binman replace -i flash.bin -f fit@0x380000.fit fit@0x380000
-- 
2.35.3

Re: [PATCH 2/3] iot2050: Use binman in signing script

[Simon Glass]

On Mon, 5 Jun 2023 at 15:39, Jan Kiszka <jan.kiszka@siemens.com> wrote:
>
> From: Jan Kiszka <jan.kiszka@siemens.com>
>
> 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 <jan.kiszka@siemens.com>
> ---
> CC: Simon Glass <sjg@chromium.org>
> ---
>  tools/iot2050-sign-fw.sh | 8 ++------
>  1 file changed, 2 insertions(+), 6 deletions(-)

Reviewed-by: Simon Glass <sjg@chromium.org>

[PATCH 3/3] boards: siemens: iot2050: Unify PG1 and PG2/M.2 configurations again

[Jan Kiszka]

From: Jan Kiszka <jan.kiszka@siemens.com>

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 <afd@ti.com>
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
---
 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 <jan.kiszka@siemens.com>
@@ -8,158 +8,177 @@
  */
 
 #include <config.h>
+#include <linux/stringify.h>
 
-/ {
-	binman {
-		filename = "flash.bin";
-		pad-byte = <0xff>;
-		size = <0x8c0000>;
-		allow-repack;
-
-		blob-ext@0x000000 {
-			offset = <0x000000>;
-#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 = <0x82000000>;					\
+		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@0x180000 {
-			offset = <0x180000>;
-			filename = "tispl.bin";
-		};
-
-		fit@0x380000 {
-			description = "U-Boot for IOT2050";
-			fit,fdt-list = "of-list";
-			offset = <0x380000>;
-			images {
-				u-boot {
-					description = "U-Boot";
-					type = "standalone";
-					arch = "arm64";
-					os = "u-boot";
-					compression = "none";
-					load = <0x80800000>;
-					entry = <0x80800000>;
-					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
-				bkey-usb3-overlay {
-					description = "M.2-bkey-usb3-overlay";
-					type = "blob";
-					load = <0x82100000>;
-					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 = <0x82110000>;
-					arch = "arm64";
-					compression = "none";
-					blob-ext {
-						filename = "k3-am6548-iot2050-advanced-m2-bkey-ekey-pcie-overlay.dtbo";
-					};
-					hash {
-						algo = "sha256";
-					};
-				};
+#if CONFIG_IOT2050_EMBED_OTPCMD
+#define IOT2050_OTPCMD_BLOCK						\
+	blob-ext@0x6c0000 {						\
+		offset = <0x6c0000>;					\
+									\
+		size   = <0x010000>;					\
+		filename = "otpcmd.bin";				\
+		missing-msg = "iot2050-otpcmd";				\
+	};
+#else
+#define IOT2050_OTPCMD_BLOCK						\
+	fill@0x6c0000 {							\
+		offset = <0x6c0000>;					\
+		size   = <0x010000>;					\
+		fill-byte = [ff];					\
+	};
 #endif
 
-#ifdef CONFIG_WDT_K3_RTI_FW_FILE
-				k3-rti-wdt-firmware {
-					type = "firmware";
-					load = <0x82000000>;
-					arch = "arm";
-					compression = "none";
-					blob-ext {
-						filename = CONFIG_WDT_K3_RTI_FW_FILE;
-						missing-msg = "k3-rti-wdt-firmware";
-					};
-					hash {
-						algo = "sha256";
-					};
-				};
-#endif
-			};
+#define IOT2050_FLASH_COMMON(variant, default_dt, extra_loadables...)	\
+	filename = __stringify(flash-##variant##.bin);			\
+	pad-byte = <0xff>;						\
+	size = <0x8c0000>;						\
+	allow-repack;							\
+									\
+	blob-ext@0x000000 {						\
+		offset = <0x000000>;					\
+		filename = __stringify(seboot_##variant##.bin);		\
+		missing-msg = "iot2050-seboot";				\
+	};								\
+									\
+	blob@0x180000 {							\
+		offset = <0x180000>;					\
+		filename = "tispl.bin";					\
+	};								\
+									\
+	fit@0x380000 {							\
+		description = "U-Boot for IOT2050";			\
+		fit,fdt-list = __stringify(of-list-##variant);		\
+		offset = <0x380000>;					\
+		u_boot_images_##variant: images {			\
+			u-boot {					\
+				description = "U-Boot";			\
+				type = "standalone";			\
+				arch = "arm64";				\
+				os = "u-boot";				\
+				compression = "none";			\
+				load = <0x80800000>;			\
+				entry = <0x80800000>;			\
+				u-boot-nodtb {				\
+				};					\
+				hash {					\
+					algo = "sha256";		\
+				};					\
+			};						\
+									\
+			@fdt-SEQ {					\
+				description = "fdt-NAME";		\
+				type = "flat_dt";			\
+				arch = "arm64";				\
+				compression = "none";			\
+				hash {					\
+					algo = "sha256";		\
+				};					\
+			};						\
+									\
+			IOT2050_WDT_FIRMWARE				\
+		};							\
+									\
+		configurations {					\
+			default = default_dt;				\
+			@config-SEQ {					\
+				description = "NAME";			\
+				firmware = "u-boot";			\
+				fdt = "fdt-SEQ";			\
+				loadables =				\
+					IOT2050_WDT_FIRMWARE_LOADABLE,	\
+					## extra_loadables,		\
+					<>;				\
+				signature {				\
+					sign-images = "firmware", "fdt", "loadables"; \
+				};					\
+			};						\
+		};							\
+	};								\
+									\
+	fdtmap {							\
+	};								\
+									\
+	/* primary env */						\
+	fill@0x680000 {							\
+		offset = <0x680000>;					\
+		size   = <0x020000>;					\
+		fill-byte = [00];					\
+	};								\
+	/* secondary env */						\
+	fill@0x6a0000 {							\
+		offset = <0x6a0000>;					\
+		size   = <0x020000>;					\
+		fill-byte = [00];					\
+	};								\
+									\
+	/* OTP update command block */					\
+	IOT2050_OTPCMD_BLOCK
 
-			configurations {
-				default = "@config-DEFAULT-SEQ";
-				@config-SEQ {
-					description = "NAME";
-					firmware = "u-boot";
-					fdt = "fdt-SEQ";
-					loadables =
-#ifdef CONFIG_TARGET_IOT2050_A53_PG2
-						"bkey-usb3-overlay",
-						"bkey-ekey-pcie-overlay",
-#endif
-#ifdef CONFIG_WDT_K3_RTI_FW_FILE
-						"k3-rti-wdt-firmware",
-#endif
-						<>;
-					signature {
-						sign-images = "firmware", "fdt", "loadables";
-					};
-				};
-			};
-		};
+/ {
+	binman: binman {
+		multiple-images;
+	};
+};
 
-		fdtmap {
-		};
+&binman {
+	flash-pg1 {
+		IOT2050_FLASH_COMMON(pg1, "k3-am6528-iot2050-basic")
+	};
+
+	flash-pg2 {
+		IOT2050_FLASH_COMMON(pg2, "k3-am6528-iot2050-basic-pg2",
+				     "bkey-usb3-overlay",
+				     "bkey-ekey-pcie-overlay")
+	};
+};
 
-		/* primary env */
-		fill@0x680000 {
-			offset = <0x680000>;
-			size   = <0x020000>;
-			fill-byte = [00];
+&u_boot_images_pg2 {
+	bkey-usb3-overlay {
+		description = "M.2-bkey-usb3-overlay";
+		type = "blob";
+		load = <0x82100000>;
+		arch = "arm64";
+		compression = "none";
+		blob-ext {
+			filename = "k3-am6548-iot2050-advanced-m2-bkey-usb3-overlay.dtbo";
 		};
-		/* secondary env */
-		fill@0x6a0000 {
-			offset = <0x6a0000>;
-			size   = <0x020000>;
-			fill-byte = [00];
+		hash {
+			algo = "sha256";
 		};
+	};
 
-		/* OTP update command block */
-#if CONFIG_IOT2050_EMBED_OTPCMD
-		blob-ext@0x6c0000 {
-			offset = <0x6c0000>;
-			size   = <0x010000>;
-			filename = "otpcmd.bin";
-			missing-msg = "iot2050-otpcmd";
+	bkey-ekey-pcie-overlay {
+		description = "M.2-bkey-ekey-pcie-overlay";
+		type = "blob";
+		load = <0x82110000>;
+		arch = "arm64";
+		compression = "none";
+		blob-ext {
+			filename = "k3-am6548-iot2050-advanced-m2-bkey-ekey-pcie-overlay.dtbo";
 		};
-#else
-		fill@0x6c0000 {
-			offset = <0x6c0000>;
-			size   = <0x010000>;
-			fill-byte = [ff];
+		hash {
+			algo = "sha256";
 		};
-#endif
 	};
 };
diff --git a/board/siemens/iot2050/Kconfig b/board/siemens/iot2050/Kconfig
index e66b2427d95..a6170aae807 100644
--- a/board/siemens/iot2050/Kconfig
+++ b/board/siemens/iot2050/Kconfig
@@ -1,40 +1,22 @@
 # SPDX-License-Identifier: GPL-2.0+
 #
-# Copyright (c) Siemens AG, 2018-2022
+# Copyright (c) Siemens AG, 2018-2023
 #
 # Authors:
 #   Le Jin <le.jin@siemens.com>
 #   Jan Kiszka <jan.kiszka@siemens.com>
 
-choice
-        prompt "Siemens SIMATIC IOT2050 boards"
-        optional
-
-config TARGET_IOT2050_A53_PG1
-	bool "IOT2050 PG1 running on A53"
-	select IOT2050_A53_COMMON
-	help
-	  This builds U-Boot for the Product Generation 1 (PG1) of the IOT2050
-	  devices.
-
-config TARGET_IOT2050_A53_PG2
-	bool "IOT2050 PG2 running on A53"
-	select IOT2050_A53_COMMON
-	help
-	  This builds U-Boot for the Product Generation 2 (PG2) of the IOT2050
-	  devices.
-
-endchoice
-
-config IOT2050_A53_COMMON
-	bool
+config TARGET_IOT2050_A53
+	bool "IOT2050 running on A53"
 	select ARM64
 	select SOC_K3_AM654
 	select BOARD_LATE_INIT
 	select SYS_DISABLE_DCACHE_OPS
 	select BINMAN
+	help
+	  This builds U-Boot for the IOT2050 devices.
 
-if IOT2050_A53_COMMON
+if TARGET_IOT2050_A53
 
 config SYS_BOARD
 	default "iot2050"
diff --git a/board/siemens/iot2050/board.c b/board/siemens/iot2050/board.c
index 2653e107450..cab23494030 100644
--- a/board/siemens/iot2050/board.c
+++ b/board/siemens/iot2050/board.c
@@ -1,7 +1,7 @@
 // SPDX-License-Identifier: GPL-2.0+
 /*
  * Board specific initialization for IOT2050
- * Copyright (c) Siemens AG, 2018-2022
+ * Copyright (c) Siemens AG, 2018-2023
  *
  * Authors:
  *   Le Jin <le.jin@siemens.com>
@@ -164,6 +164,14 @@ static bool board_is_advanced(void)
 		strstr((char *)info->name, "IOT2050-ADVANCED") != NULL;
 }
 
+static bool board_is_sr1(void)
+{
+	struct iot2050_info *info = IOT2050_INFO_DATA;
+
+	return info->magic == IOT2050_INFO_MAGIC &&
+		!strstr((char *)info->name, "-PG2");
+}
+
 static void remove_mmc1_target(void)
 {
 	char *boot_targets = strdup(env_get("boot_targets"));
@@ -210,14 +218,14 @@ void set_board_info_env(void)
 	}
 
 	if (board_is_advanced()) {
-		if (IS_ENABLED(CONFIG_TARGET_IOT2050_A53_PG1))
+		if (board_is_sr1())
 			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 (IS_ENABLED(CONFIG_TARGET_IOT2050_A53_PG1))
+		if (board_is_sr1())
 			fdtfile = "ti/k3-am6528-iot2050-basic.dtb";
 		else
 			fdtfile = "ti/k3-am6528-iot2050-basic-pg2.dtb";
diff --git a/board/siemens/iot2050/config.mk b/board/siemens/iot2050/config.mk
index 267ec76c4ef..05111d5ebab 100644
--- a/board/siemens/iot2050/config.mk
+++ b/board/siemens/iot2050/config.mk
@@ -1,8 +1,12 @@
 # SPDX-License-Identifier: GPL-2.0+
 #
-# Copyright (c) Siemens AG, 2020-2021
+# Copyright (c) Siemens AG, 2020-2023
 #
 # Authors:
 #   Jan Kiszka <jan.kiszka@siemens.com>
 
+BINMAN_EXTRA_ARGS = \
+	-a of-list-pg1="k3-am6528-iot2050-basic k3-am6548-iot2050-advanced" \
+	-a of-list-pg2="k3-am6528-iot2050-basic-pg2 k3-am6548-iot2050-advanced-pg2 k3-am6548-iot2050-advanced-m2"
+
 flash.bin: all
diff --git a/configs/iot2050_pg1_defconfig b/configs/iot2050_defconfig
similarity index 97%
rename from configs/iot2050_pg1_defconfig
rename to configs/iot2050_defconfig
index cc1b9673d79..bbbc040af40 100644
--- a/configs/iot2050_pg1_defconfig
+++ b/configs/iot2050_defconfig
@@ -8,7 +8,7 @@ CONFIG_SPL_LIBCOMMON_SUPPORT=y
 CONFIG_SPL_LIBGENERIC_SUPPORT=y
 CONFIG_NR_DRAM_BANKS=2
 CONFIG_SOC_K3_AM654=y
-CONFIG_TARGET_IOT2050_A53_PG1=y
+CONFIG_TARGET_IOT2050_A53=y
 CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y
 CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x80100000
 CONFIG_ENV_SIZE=0x20000
@@ -73,7 +73,6 @@ CONFIG_CMD_TIME=y
 # CONFIG_ISO_PARTITION is not set
 CONFIG_OF_CONTROL=y
 CONFIG_SPL_OF_CONTROL=y
-CONFIG_OF_LIST="k3-am6528-iot2050-basic k3-am6548-iot2050-advanced"
 CONFIG_SPL_MULTI_DTB_FIT=y
 CONFIG_SPL_OF_LIST="k3-am65-iot2050-spl"
 CONFIG_SPL_MULTI_DTB_FIT_NO_COMPRESSION=y
diff --git a/configs/iot2050_pg2_defconfig b/configs/iot2050_pg2_defconfig
deleted file mode 100644
index c5741a4dae4..00000000000
--- a/configs/iot2050_pg2_defconfig
+++ /dev/null
@@ -1,150 +0,0 @@
-CONFIG_ARM=y
-CONFIG_SKIP_LOWLEVEL_INIT=y
-CONFIG_ARCH_K3=y
-CONFIG_SYS_MALLOC_LEN=0x2000000
-CONFIG_SYS_MALLOC_F_LEN=0x8000
-CONFIG_SPL_GPIO=y
-CONFIG_SPL_LIBCOMMON_SUPPORT=y
-CONFIG_SPL_LIBGENERIC_SUPPORT=y
-CONFIG_NR_DRAM_BANKS=2
-CONFIG_SOC_K3_AM654=y
-CONFIG_TARGET_IOT2050_A53_PG2=y
-CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y
-CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x80100000
-CONFIG_ENV_SIZE=0x20000
-CONFIG_ENV_OFFSET=0x680000
-CONFIG_ENV_SECT_SIZE=0x20000
-CONFIG_DM_GPIO=y
-CONFIG_SPL_DM_SPI=y
-CONFIG_DEFAULT_DEVICE_TREE="k3-am6528-iot2050-basic-pg2"
-CONFIG_SPL_TEXT_BASE=0x80080000
-CONFIG_SYS_PROMPT="IOT2050> "
-CONFIG_OF_LIBFDT_OVERLAY=y
-CONFIG_DM_RESET=y
-CONFIG_SPL_SERIAL=y
-CONFIG_SPL_STACK_R_ADDR=0x82000000
-CONFIG_ENV_OFFSET_REDUND=0x6a0000
-CONFIG_SPL_SPI_FLASH_SUPPORT=y
-CONFIG_SPL_SPI=y
-CONFIG_PCI=y
-# CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set
-CONFIG_SPL_LOAD_FIT=y
-CONFIG_OF_BOARD_SETUP=y
-CONFIG_OF_SYSTEM_SETUP=y
-CONFIG_DISTRO_DEFAULTS=y
-CONFIG_BOOTSTAGE=y
-CONFIG_SHOW_BOOT_PROGRESS=y
-CONFIG_SPL_SHOW_BOOT_PROGRESS=y
-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
-CONFIG_SPL_BSS_START_ADDR=0x80a00000
-CONFIG_SPL_BSS_MAX_SIZE=0x80000
-CONFIG_SPL_BOARD_INIT=y
-CONFIG_SPL_SYS_MALLOC_SIMPLE=y
-CONFIG_SPL_STACK_R=y
-CONFIG_SYS_SPL_MALLOC=y
-CONFIG_SYS_SPL_MALLOC_SIZE=0x800000
-CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_USE_SECTOR=y
-CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR=0x1400
-CONFIG_SPL_DM_MAILBOX=y
-CONFIG_SPL_DM_SPI_FLASH=y
-CONFIG_SPL_DM_RESET=y
-CONFIG_SPL_POWER_DOMAIN=y
-# CONFIG_SPL_SPI_FLASH_TINY is not set
-CONFIG_SPL_SPI_FLASH_SFDP_SUPPORT=y
-CONFIG_SPL_SPI_LOAD=y
-CONFIG_SYS_SPI_U_BOOT_OFFS=0x380000
-CONFIG_SYS_MAXARGS=64
-CONFIG_SYS_PBSIZE=1050
-CONFIG_CMD_ASKENV=y
-CONFIG_CMD_DFU=y
-CONFIG_CMD_GPT=y
-CONFIG_CMD_I2C=y
-CONFIG_CMD_MMC=y
-CONFIG_CMD_PCI=y
-CONFIG_CMD_REMOTEPROC=y
-CONFIG_CMD_USB=y
-CONFIG_CMD_WDT=y
-# CONFIG_CMD_SETEXPR is not set
-CONFIG_CMD_TIME=y
-# CONFIG_ISO_PARTITION is not set
-CONFIG_OF_CONTROL=y
-CONFIG_SPL_OF_CONTROL=y
-CONFIG_OF_LIST="k3-am6528-iot2050-basic-pg2 k3-am6548-iot2050-advanced-pg2 k3-am6548-iot2050-advanced-m2"
-CONFIG_SPL_MULTI_DTB_FIT=y
-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_SPL_DM=y
-CONFIG_SPL_DM_SEQ_ALIAS=y
-CONFIG_SPL_REGMAP=y
-CONFIG_SPL_OF_TRANSLATE=y
-CONFIG_CLK=y
-CONFIG_SPL_CLK=y
-CONFIG_CLK_TI_SCI=y
-CONFIG_DFU_MMC=y
-CONFIG_DFU_RAM=y
-CONFIG_DFU_SF=y
-CONFIG_DMA_CHANNELS=y
-CONFIG_TI_K3_NAVSS_UDMA=y
-CONFIG_TI_SCI_PROTOCOL=y
-CONFIG_DA8XX_GPIO=y
-CONFIG_DM_PCA953X=y
-CONFIG_DM_I2C=y
-CONFIG_I2C_SET_DEFAULT_BUS_NUM=y
-CONFIG_SYS_I2C_OMAP24XX=y
-CONFIG_LED=y
-CONFIG_SPL_LED=y
-CONFIG_LED_GPIO=y
-CONFIG_SPL_LED_GPIO=y
-CONFIG_DM_MAILBOX=y
-CONFIG_K3_SEC_PROXY=y
-CONFIG_MMC_HS200_SUPPORT=y
-CONFIG_MMC_SDHCI=y
-CONFIG_MMC_SDHCI_ADMA=y
-CONFIG_MMC_SDHCI_AM654=y
-CONFIG_DM_SPI_FLASH=y
-CONFIG_SPI_FLASH_SFDP_SUPPORT=y
-CONFIG_SPI_FLASH_STMICRO=y
-CONFIG_SPI_FLASH_WINBOND=y
-# CONFIG_SPI_FLASH_USE_4K_SECTORS is not set
-CONFIG_PCI_KEYSTONE=y
-CONFIG_PHY=y
-CONFIG_AM654_PHY=y
-CONFIG_OMAP_USB2_PHY=y
-CONFIG_PINCTRL=y
-# CONFIG_PINCTRL_GENERIC is not set
-CONFIG_SPL_PINCTRL=y
-# CONFIG_SPL_PINCTRL_GENERIC is not set
-CONFIG_PINCTRL_SINGLE=y
-CONFIG_POWER_DOMAIN=y
-CONFIG_TI_SCI_POWER_DOMAIN=y
-CONFIG_REMOTEPROC_TI_K3_R5F=y
-CONFIG_RESET_TI_SCI=y
-CONFIG_DM_SERIAL=y
-CONFIG_SOC_DEVICE=y
-CONFIG_SOC_DEVICE_TI_K3=y
-CONFIG_SOC_TI=y
-CONFIG_SPI=y
-CONFIG_DM_SPI=y
-CONFIG_CADENCE_QSPI=y
-CONFIG_SYSRESET=y
-CONFIG_SPL_SYSRESET=y
-CONFIG_SYSRESET_TI_SCI=y
-CONFIG_USB=y
-CONFIG_USB_XHCI_HCD=y
-CONFIG_USB_XHCI_DWC3=y
-CONFIG_USB_DWC3=y
-CONFIG_USB_DWC3_GENERIC=y
-CONFIG_USB_KEYBOARD=y
-# CONFIG_WATCHDOG is not set
-# CONFIG_WATCHDOG_AUTOSTART is not set
-CONFIG_WATCHDOG_TIMEOUT_MSECS=0
-CONFIG_WDT=y
-CONFIG_WDT_K3_RTI=y
-CONFIG_WDT_K3_RTI_LOAD_FW=y
-CONFIG_EFI_SCROLL_ON_CLEAR_SCREEN=y
diff --git a/doc/board/siemens/iot2050.rst b/doc/board/siemens/iot2050.rst
index 074d6aa15af..9c7b5bac6ea 100644
--- a/doc/board/siemens/iot2050.rst
+++ b/doc/board/siemens/iot2050.rst
@@ -66,17 +66,16 @@ U-Boot:
 
 .. code-block:: text
 
- $ export ATF=/path/to/bl31.bin
+ $ export BL31=/path/to/bl31.bin
  $ export TEE=/path/to/tee-pager_v2.bin
-
- # configure for PG1
- $ make iot2050_pg1_defconfig
-
- # or configure for PG2 or the M.2 variant
- $ make iot2050_pg2_defconfig
+ $ make iot2050_defconfig
 
  $ make
 
+This will generate two different flash images: flash-p1.bin that targets the
+first generation of IOT2050 devices and flash-pg2.bin that runs on PG2
+including M.2 devices.
+
 Flashing
 --------
 
@@ -85,20 +84,20 @@ Via U-Boot:
 .. code-block:: text
 
  IOT2050> sf probe
- IOT2050> load mmc 0:1 $loadaddr /path/to/flash.bin
+ IOT2050> load mmc 0:1 $loadaddr /path/to/flash-pgX.bin
  IOT2050> sf update $loadaddr 0x0 $filesize
 
 Via external programmer Dediprog SF100 or SF600:
 
 .. code-block:: text
 
- $ dpcmd --vcc 2 -v -u flash.bin
+ $ dpcmd --vcc 2 -v -u flash-pgX.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
+first-stage loader (seboot_pgX.bin), the following steps need to be taken
 before and after the build:
 
 Generate dtsi holding the public key
@@ -131,8 +130,8 @@ Build U-Boot
 
 See related section above.
 
-Sign flash.bin
-^^^^^^^^^^^^^^
+Sign flash-pgX.bin
+^^^^^^^^^^^^^^^^^^
 
 In the build folder still containing artifacts from step 3, invoke:
 
@@ -140,10 +139,10 @@ In the build folder still containing artifacts from step 3, invoke:
 
  tools/iot2050-sign-fw.sh /path/to/key.pem
 
-Flash signed flash.bin
-^^^^^^^^^^^^^^^^^^^^^^
+Flash signed flash-pgX.bin
+^^^^^^^^^^^^^^^^^^^^^^^^^^
 
-The signing has happen in-place in flash.bin, thus the flashing procedure
+The signing has happen in-place in flash-pgX.bin, thus the flashing procedure
 described above.
 
 M.2 slot configuration
diff --git a/tools/iot2050-sign-fw.sh b/tools/iot2050-sign-fw.sh
index da425c94a5d..74084f0980e 100755
--- a/tools/iot2050-sign-fw.sh
+++ b/tools/iot2050-sign-fw.sh
@@ -39,9 +39,12 @@ CERT_X509=$(mktemp XXXXXXXX.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.bin -f tispl.bin_signed blob@0x180000
+source/tools/binman/binman replace -i flash-pg1.bin -f tispl.bin_signed blob@0x180000
+source/tools/binman/binman replace -i flash-pg2.bin -f tispl.bin_signed blob@0x180000
 
 rm $TEMP_X509 $CERT_X509
 
-tools/mkimage -G $1 -r -o sha256,rsa4096 -F fit@0x380000.fit
-source/tools/binman/binman replace -i flash.bin -f fit@0x380000.fit fit@0x380000
+tools/mkimage -G $1 -r -o sha256,rsa4096 -F flash-pg1.fit@0x380000.fit
+tools/mkimage -G $1 -r -o sha256,rsa4096 -F flash-pg2.fit@0x380000.fit
+source/tools/binman/binman replace -i flash-pg1.bin -f flash-pg1.fit@0x380000.fit fit@0x380000
+source/tools/binman/binman replace -i flash-pg2.bin -f flash-pg2.fit@0x380000.fit fit@0x380000
-- 
2.35.3

Re: [PATCH 3/3] boards: siemens: iot2050: Unify PG1 and PG2/M.2 configurations again

[Simon Glass]

Hi Jan,

On Mon, 5 Jun 2023 at 15:40, Jan Kiszka <jan.kiszka@siemens.com> wrote:
>
> From: Jan Kiszka <jan.kiszka@siemens.com>
>
> 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 <afd@ti.com>
> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
> ---
>  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 = "...";
};

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?

Regards,
Simon

Re: [PATCH 3/3] boards: siemens: iot2050: Unify PG1 and PG2/M.2 configurations again

[Jan Kiszka]

On 12.06.23 23:17, Simon Glass wrote:
> Hi Jan,
> 
> On Mon, 5 Jun 2023 at 15:40, Jan Kiszka <jan.kiszka@siemens.com> wrote:
>>
>> From: Jan Kiszka <jan.kiszka@siemens.com>
>>
>> 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 <afd@ti.com>
>> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
>> ---
>>  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