Hi Jan, On Tue, 20 Jun 2023 at 11:37, Jan Kiszka <jan.kis...@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.kis...@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.kis...@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.kis...@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.kis...@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.kis...@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.kis...@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.kis...@siemens.com> wrote: > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> From: Jan Kiszka <jan.kis...@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.kis...@siemens.com> > >>>>>>>>>>>>>>> --- > >>>>>>>>>>>>>>> CC: Simon Glass <s...@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