On 02/05/18 21:32, Simon Glass wrote:
Hi Stefano,
On 2 May 2018 at 02:48, Stefano Babic sbabic@denx.de wrote:
Hi,
I am thinking about how it is possible to export in a clean way the default environment from u-boot. The general use case happens when the environment must be changed from user space (via fw_setenv or whatever) and no environment was still stored - board boots with default environment.
Up now, the trick is to compile the environment tools (u-boot-fw-utils in Yocto) with exactly the same U-Boot sources. This works, but it is error prone when a new Yocto version is delivered (and maybe with a different u-boot-fw-utils) or even if the bootloader is updated. I am searching for an alterntive method.
The code in tools/env is really generic, but it becomes board specific just for the default environment. If the default environment can read in a reliable way from u-boot itslef (its binary), the tool can search for the default environment instead of linking again, and tools/env becomes "distro capable" - one binary that works on all boards.
I have some thoughts and I would like to share, maybe some of you has better ideas. So what I would like to get directly from the binary is the offset of "default_environment" (default_environment) CONFIG_SYS_TEXT_BASE:
- put this offset in the .img header. Yes, it works just for SPL /
u-boot.img (drawback).
How about putting the default environment in a FIT? That is typically easy to find using the magic word.
- surround default environment with some easy to recognize magic number.
Offset is not known, but user space can find it, like
magic (long string) ... default_environment end default environment (long string)Seems like FIT would take care of this for you.
- adding a section in the linker. I think we tried something in the
past, see __UBOOT_ENV_SECTION__ (it replaced __PPCENV__ from the old good mpc8xx times..) that is currently unused. I do not like this approach, it can increase (due to alignment) footprint in SPL, where I am starting to have issues for smaller i.MX.
Also I wonder if compression might be useful? FIT supports that fairly easily.
I like the FIT idea, but in all proposals so far, you still have the problem of locating either the U-Boot binary or the FIT image. It's not always clear where they can be found.
I've been having another idea in the back of my head for while, using a very different approach: Instead of requiring that the tool be able to fall back to a default environment, require that U-Boot write the environment to storage if the CRC check fails when it boots, and remove the ability to write to an uninitialized environment from the tools. This would guarantee that the environment is available in its expected storage location when entering userspace, and would also have the benefit of exposing dangerous situations where a newly flashed root filesystem has a /etc/fw_env.config which is wrong.
The downside is that if the environment somehow gets messed up from userspace, you have to reboot to fix the problem. This could be somewhat, but not completely remedied by requiring a redundant environment.