[OE-core] [PATCH] u-boot: Add {gen|deploy}_default_envs tasks to generate environment images

[Marek Vasut]

On 05/03/2018 10:58 PM, Stefano Babic wrote:
> Hi Marek,
> 
> On 03/05/2018 18:59, Marek Vasut wrote:
>> On 05/03/2018 06:50 PM, Stefano Babic wrote:
>>> On 03/05/2018 18:36, Marek Vasut wrote:
>>>> On 05/03/2018 06:28 PM, Stefano Babic wrote:
>>>>> On 27/04/2018 17:07, Marek Vasut wrote:
>>>>>> On 04/27/2018 04:51 PM, Lukasz Majewski wrote:
>>>>>>> This commit provides the ability to generate u-boot environment(s) as
>>>>>>> images, which afterwards can be used to produce image (with wic) for
>>>>>>> flashing (eMMC or SPI-NOR).
>>>>>>>
>>>>>>> This change removes the need to run "env default" during production phase,
>>>>>>> as proper environment (including redundant one) is already stored on
>>>>>>> persistent memory (the CRC is also correct).
>>>>>>>
>>>>>>> Signed-off-by: Lukasz Majewski <lukma at denx.de>
>>>>>>
>>>>>> If your default env is correct, why do you need this ? I can see some
>>>>>> use with non-default env, but then that can be wrapped into a separate
>>>>>> recipe.
>>>>>>
>>>>>
>>>>> A use case is when the environment must be changed from user space.
>>>>> fw_setenv will report the CRC error and it needs the default environment
>>>>> to add changes. The default environment is linked together to fw_setenv,
>>>>> but this prohibites to use fw_setenv for multiple boards and must be
>>>>> explicitely built for that machine and with the same sources as u-boot
>>>>> (at least, they must share the same CONFIG_EXTRA_ENV). If the default
>>>>> environment is extracted, we could have a general (distro ?) fw_setenv.
>>>>
>>>> I think in that case, the real solution is to either build fw_setenv per
>>>> machine 
>>>
>>> This is how we try to do now, fw_setenv is built per machine but it is
>>> enough that u-boot-fw-utils is built in a different version as u-boot to
>>> get a mess.
>>
>> Well yes, if you mix and match packages, it becomes a mess. Isn't that
>> to be expected ?
>>
> 
> Well, quite. But in the specific case, it is weird that the environment
> tools are built by a separate recipe. u-boot-fw-utils generates binaries
> from the same sources as u-boot (or it should), and building the tool
> per machine means for me to have a single recipe for it, that generates
> as additional package the env tools. This guarantees that they are
> always in sync.

Patches welcome ? :)

>>>> OR fix fw_setenv to take env defaults from a file or somesuch ?
>>>
> 
> Having a separate recipe as now means for me to try to have the tools
> not per machine, and then makes sense to pass as input the default
> environment to the tools.

Cfr the conclusion (?) we reached with Lukasz I think ?

>>> Right, I interprete this patch as a step in this direction. This patch
>>> generates a default that can be used as input for fw_setenv.
>>
>> It generates environment images which can be written -- on certain
>> specific setups -- into the flash. It doesn't generate any sort of input
>> for the fw_setenv to my knowledge ?
> 
> Not the current patch - we are discussing how it could evolve ;-)

Ah, I wonder if we shouldn't start a new thread for this and crosspost
it to the U-Boot ML too then ?

-- 
Best regards,
Marek Vasut