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

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.

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

I must check if fw_setenv handles images generated by mkenvimage (or
boot.src [1] generated by mkimage).


[1] - <u-boot repo>/board/samsung/common/bootscripts/autoboot.cmd

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@denx.de