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

[Marek Vasut]

On 05/03/2018 08:15 PM, Lukasz Majewski wrote:
> Hi Marek, Stefano,
> 
>> 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 ?
>>
>>>> OR fix fw_setenv to take env defaults from a file or somesuch ?  
>>>
>>> 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 ?
>>
> 
> I think that it would be great if:
> 
> 1. We would have this code as a separate recipe - as suggested by Marek
> and Stefano already. This recipe would end up as a package to be
> installed on the rootfs
> 
> 2. As input I would use default_envs.txt (or any other name) - either
> extracted from u-boot build or provided from external file
> 
> 3. For now I do use mkenvimage -> and I do have env image [*] to be
> flashed on the board.

Sounds about good. I think this approach fails with NAND, so be careful
there.

> However, I do wonder if for the default fw_setenv envs we could:
> 
> - modify fw_setenv to read (and store) [*] when no correct default env
>   is available
Or add some build-time option to build it with blank default env. Then
you can apply your file-based approach, the setenv would be
board-agnostic and it should do I guess ?

-- 
Best regards,
Marek Vasut