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

[Marek Vasut]

On 04/29/2018 03:53 PM, Lukasz Majewski wrote:
> Hi Marek,

Hello Lukasz,

>> On 04/27/2018 06:15 PM, Lukasz Majewski wrote:
>>> Hi Marek,
>>>
>>> Thanks for prompt feedback.
>>>   
>>>> 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 ?   
>>>
>>> Some users wants to have the working board (i.e. without any
>>> warnings that CRC for envs is bad) after flashing the SPI-NOR/eMMC  
>>
>> And the board is not working when it tells you your env is not
>> populated? 
> 
> It complains that CRC is wrong, which is true as without this patch
> (and some wic adjustments) we don't have proper envs in expected
> non-volatile area.

This is NOT an error, this is warning and a correct behavior. If your
default U-Boot environment is not correct, that is a bug in your U-Boot
port.

If you need to adjust that environment later in the product life cycle,
that's a different topic.

>> Then maybe the board port is broken.
> 
> Then it proceeds with default envs - and boots.

I think I might not quite understand the problem anymore. Is the issue
here that U-Boot informs you that it's using default environment which
you do not like ?

[...]

>>>>> +# Generate default environment
>>>>> +do_gen_default_envs[doc] = "Generate image with default U-Boot
>>>>> environment(s)" +do_gen_default_envs () {
>>>>> +	${B}/source/scripts/get_default_envs.sh ${B} >
>>>>> ${B}/${DEFAULT_ENVS} +
>>>>> +	# Generate env image
>>>>> +	${B}/tools/mkenvimage -s ${DEFAULT_ENVS_SIZE} -o
>>>>> ${B}/${UBOOT_ENVS_DEFAULT} ${B}/${DEFAULT_ENVS}    
>>>>
>>>> Does this actually work during cross build , when mkenvimage
>>>> architecture is different than host architecture ?  
>>>
>>> Yes. This was tested.  
>>
>> How can it work if this binary cannot be executed ? :)
> 
> Could you be more specific here?
> 
> I do follow normal u-boot recipe build. If mkenvimage is build in a
> wrong way (as other tools) - then I suppose that the whole u-boot recipe
> is broken.
> 
> The get_default_envs.sh script is prepared to use either native or
> cross-compiled set of binutils (that thought I had in mind when I said
> that it was tested).

Consider you crosscompile mkenvimage for ARM and try to run it on x86 host.

>>>>> +	# Generate redundant env image
>>>>> +	${B}/tools/mkenvimage -r -s ${DEFAULT_ENVS_SIZE} -o
>>>>> ${B}/${UBOOT_ENVS_DEFAULT}_r ${B}/${DEFAULT_ENVS}    
>>>>
>>>> Is redundant env always needed on all systems ?  
>>>
>>> No, they are not. However, it shall not be a problem if it is build
>>> anyway - user can adjust wic to only put primary env image.  
>>
>> So many wasted CPU cycles for a feature barely anyone needs. Nope :)
> 
> I will try to craft some OE magic to make it not build when not
> needed... :-)

Can't you just patch a correct default env into the U-Boot port ?

-- 
Best regards,
Marek Vasut