Hello,
On 15.01.21 13:12, AD wrote:
>> You'll probably want to run saveenv -z to override this
>> and force use of the built-in environment.
>
> If I understand well, the issue is not that my built-in env is not "updated" on the target, but that it is not loaded at startup.
Exactly.
> And it is not loaded, because I already have a modified environment, on which I did a "saveenv" previously ; as a consequence, at startup, this "local dev env" is loaded instead of the built-in one?
Yep.
> I tried a saveenv -z on a modified env, and it restores properly the built-in env at the next startup.
>
> On some targets, I don't have the issue.
> Is it possible that on those targets, I never did a saveenv which would have created a "local" env ; as a consequence, every time I update Barebox, the built-in env is always used?
That's my assumption as well.
> As a conclusion, I guess that updating barebox with "cp ${image} /dev/mmc2" and "saveenv -z" instead of only using the first command would solve this issue.
Preferably, you'd update barebox with barebox_update ${image}. barebox_update knows
how to handle eMMC boot partitions if you need that and it can be readily exported
over Android Fastboot.
saveenv -z is something you need to do when you have written an environment manually
during development. When bringing up a board in the factory, there shouldn't be
a valid environment in the eMMC, so you could skip that step.
> In any case, many thanks for helping me to understand this mechanism.
Glad it helped,
Ahmad
>
> Best Regards,
> AD
>
>
>
--
Pengutronix e.K. | |
Steuerwalder Str. 21 | http://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
_______________________________________________
barebox mailing list
barebox@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/barebox
