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 <lu...@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: w...@denx.de
pgp6KE6FcDbON.pgp
Description: OpenPGP digital signature
-- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
