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

[Marek Vasut <marex@denx.de>]

On 05/09/2018 01:45 PM, Lukasz Majewski wrote:
> Hi Marek, Stefano,
> 
>> 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@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
> 
> I've looked a bit more on the topic, and I do have some further
> questions:
> 
> 1. It seems like u-boot is compiled at least twice - once when
> do_comiple() is invoked in u-boot.inc (here we support multiple
> configs, and targets) and in u-boot-fw-utils (also u-boot-mkimage
> compiles u-boot for sandbox_defconfig).
> 
> It seems like the synchronization of the built package (and envs) is
> ensured with u-boot-common_2018.03.inc package. 
> 
> 2. It seems like it would be feasible to have a separate recipe -
> u-boot-envs_2018.03.bb [*] which would:
> 
> 	- Use u-boot-env.txt provided as an external file (from e.g.
> 	  SRC += "./file/u-boot-env.txt"). This is the approach similar
> 	  to
> 	  https://github.com/webosose/meta-webosose/blob/master/meta-webos-raspberrypi/recipes-bsp/u-boot/u-boot-env.bb
> 
> 	- If above input *.txt file is not present then get the envs
> 	  extracted from built u-boot. 
> 
> The main question for above item - how and where to extract this file?
> 
> 	- The most feasible would be to extend do_compile of u-boot.inc
> 	  to run get_default_envs.sh script there (as it builds all
> 	  the kind of u-boot variants/binaries).
> 
> 	- Then "export" those generated *.txt files to [*] recipe.
> 	  What would be the best way?
> 
> 	  Via ${DEPLOYDIR} ? Install it on /boot directory (exported by
> 	  u-boot) ? 

Compile the fw env utils per-machine for now and in parallel add option
to compile it with blank env and use env from file into upstream u-boot
fwutils ?

-- 
Best regards,
Marek Vasut