On 05/03/2018 10:58 PM, Stefano Babic wrote: > Hi Marek, > > On 03/05/2018 18:59, Marek Vasut wrote: >> 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 ? >> > > Well, quite. But in the specific case, it is weird that the environment > tools are built by a separate recipe. u-boot-fw-utils generates binaries > from the same sources as u-boot (or it should), and building the tool > per machine means for me to have a single recipe for it, that generates > as additional package the env tools. This guarantees that they are > always in sync.
Patches welcome ? :) >>>> OR fix fw_setenv to take env defaults from a file or somesuch ? >>> > > Having a separate recipe as now means for me to try to have the tools > not per machine, and then makes sense to pass as input the default > environment to the tools. Cfr the conclusion (?) we reached with Lukasz I think ? >>> 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 ? > > Not the current patch - we are discussing how it could evolve ;-) Ah, I wonder if we shouldn't start a new thread for this and crosspost it to the U-Boot ML too then ? -- Best regards, Marek Vasut -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
