[PATCH 0/3] iot2050: Re-unify its configs and build processes
This restores the possibility to build firmware images for both PG1 and PG2-based IOT2050 devices in one run. We still end up with different binaries, but the the build is now fed again from a single defconfig. Should simplify maintenance and will also simplify our generation tooling around it.
Jan
CC: Simon Glass 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
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
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
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
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
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
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
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
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
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
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
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
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
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
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/393ce2b78cee9214edda7f7e04f6ca2ce14...
Thanks, Jan
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/393ce2b78cee9214edda7f7e04f6ca2ce14...
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
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/393ce2b78cee9214edda7f7e04f6ca2ce14...
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
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/393ce2b78cee9214edda7f7e04f6ca2ce14...
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
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/393ce2b78cee9214edda7f7e04f6ca2ce14...
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
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/393ce2b78cee9214edda7f7e04f6ca2ce14...
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
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
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
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
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
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
participants (2)
-
Jan Kiszka -
Simon Glass