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

[Stefano Babic]

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.

>>> 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.

>> 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 ;-)

Regards,
Stefano

-- 
=====================================================================
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sbabic at denx.de
=====================================================================