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

[Lukasz Majewski]

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

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

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

Lukasz Majewski

--

DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20180509/75f1ae9b/attachment-0002.sig>