[PATCH 1/3] binman: Allow to define custom arguments
Jan Kiszka
jan.kiszka at siemens.com
Tue Jun 20 19:05:19 CEST 2023
On 20.06.23 16:36, Simon Glass wrote:
> Hi Jan,
>
> On Tue, 20 Jun 2023 at 11:37, Jan Kiszka <jan.kiszka at 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 at 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 at 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 at 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 at 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 at 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 at 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 at siemens.com> wrote:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> From: Jan Kiszka <jan.kiszka at 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 at siemens.com>
>>>>>>>>>>>>>>>>> ---
>>>>>>>>>>>>>>>>> CC: Simon Glass <sjg at 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
More information about the U-Boot
mailing list