Uboot environment variable（一）

• 了解uboot 环境变量 （参考出处）

1.What Is This U-Boot Environment?

  A simple answer to that question would be “a collection of name=value pairs”.

• “name” refers to the name of the environment variable to which you want to assign some “value”.
• “value” could be of any type: string, hexadecimal, boolean and so forth.

  Whatever type the value is, it is converted into a string before being stored in a linearized environment data block. Each environment variable pair (“name=value”) would be stored as a null-terminated string. So, the collection of many environment variables is nothing but a null-separated list with a double-null terminator. Figure 1 illustrates how a list of strings is actually stored. The left-hand side is just a logical representation of environment variables, whereas the right-hand side shows that the variables have been flattened and written in a serialized form.

2.How Is the Environment Stored?

  U-Boot has two types of persistent environments.

2.1.Default Environment (Compiled-In, Read-Only)

  Every U-Boot binary has a default built-in environment of its own (Figure 2a). During compilation, a character array called default_environment is embedded into the U-Boot image. This character array stores the environment variables as a list of null-terminated strings with a double-null terminator. The contents of this array are populated conditionally based on the config options selected for your board. Environment variables that are commonly used can be enabled by defining the corresponding CONFIGs in your board’s config file (include/configs/<YOUR_BOARD>.h). Figure 3 lists some commonly used options, which, once defined, would make their way into the default environment of your board.

Figure 2. (a) Type 1 Persistent Environment Read-Only, Embedded; (b) Type 2 Persistent Environment User-Supplied, Read-Write Enabled

  include/env_default.h:
   22 const uchar default_environment[] = {
   23 #endif
   24 #ifndef CONFIG_USE_DEFAULT_ENV_FILE
   25 #ifdef  CONFIG_ENV_CALLBACK_LIST_DEFAULT
   26     ENV_CALLBACK_VAR "=" CONFIG_ENV_CALLBACK_LIST_DEFAULT "\0"
   27 #endif
   28 #ifdef  CONFIG_ENV_FLAGS_LIST_DEFAULT
   29     ENV_FLAGS_VAR "=" CONFIG_ENV_FLAGS_LIST_DEFAULT "\0"
   30 #endif
   31 #ifdef  CONFIG_USE_BOOTARGS
   32     "bootargs=" CONFIG_BOOTARGS         "\0"
   33 #endif
   34 #ifdef  CONFIG_BOOTCOMMAND
   35     "bootcmd="  CONFIG_BOOTCOMMAND      "\0"
   36 #endif                                                                                                 
   37 #ifdef  CONFIG_RAMBOOTCOMMAND
   38     "ramboot="  CONFIG_RAMBOOTCOMMAND       "\0"
   39 #endif
   40 #ifdef  CONFIG_NFSBOOTCOMMAND
   41     "nfsboot="  CONFIG_NFSBOOTCOMMAND       "\0"

  Apart from the standard variables used across boards, you may want to add certain environment variables that are specific to your board or that just are convenient for you. You may, for instance, want to embed the revision number of the board into this environment. You could do that by defining all of these variables in a macro called CONFIG_EXTRA_ENV_SETTINGS in your board’s config file:

include/configs/xxx.h:
#define CONFIG_EXTRA_ENV_SETTINGS \
        "board=" XSTR(BOARD) "\0" \
        "load_addr=" XSTR(CONFIG_SYS_LOAD_ADDR) "\0"

Figure 3. System variables defined in your board’s config become part of the default environment.

  Remember that the default environment is “read-only”, as it is part of the U-Boot image itself. Vendors normally keep some essential system variables as part of this environment.

  There are some good reasons to keep a default environment as part of the image:

• Because it is read-only, you always have a default state to revert to.
• During early bootup, a user-supplied environment (defined next) may be inaccessible or must not be used due to security concerns.
• A user-supplied environment may be inaccessible due to a storage device malfunction or environment data corruption.

  You shouldn’t keep too much data in this default environment, as it directly adds to the weight of the binary. Keep only critical system variables in this environment.

2.2.User-Supplied Environment (Flashed in External Storage, Writable):

  Typically, vendors flash an environment data image to external storage present on your board. The format of this pre-built environment is again the same—that is, a linearized list of strings, but there is a 4-byte CRC header prefixed to it. This CRC is computed over the environment data. Figure 2b illustrates such an environment blob with CRC data, followed by valid environment data and an invalid one after that. The total size of this environment data is fixed to CONFIG_ENV_SIZE during compilation. So, if your environment usage exceeds this size, you would need to recompile your U-Boot binary after increasing CONFIG_ENV_SIZE. If you do not increase the size, U-Boot will refuse to save the environment variables.

  You may decide to keep this environment in external storage, but you must configure the board’s config accordingly. U-Boot must know which storage method (and at what offset) will be used to hold the user environment. U-Boot provides a number of options to configure the location of the environment data. U-Boot has the infrastructure to access environment data stored in serial flashes, NVRAM, NAND, dataflash, MMC and even UBI volumes. See the U-Boot documentation for more information on how to use these CONFIG options(README). Since the default environment size has to be minimized, most of the environment variables are stored here. Certain storage technologies like raw NAND flashes are inherently unreliable. To combat such possibilities (including power failure), and for robustness in general, you also can configure a redundant user environment. You can configure the location and size of this duplicate environment data as well in your board’s config.

• CONFIG_ENV_OFFSET：offset of the environment area
• CONFIG_ENV_SIZE：size of the environment area

3.Saving Environment

  Out of the two default environments (default and user), only the user is writable. So, whenever you modify a variable and issue a saveenv command, that variable ends up in the user environment.

When you do a saveenv, U-Boot does the following:

• Sorts the list of current environment variables.
• Converts them to a linearized list of strings.
• Computes CRC over this data and burns the env back at its fixed location in storage.

4.Creating a Pre-Built User Environment

  U-Boot provides a utility named mkenvimage that can be used to generate an environment blob suitable to be flashed. mkenvimage needs at least two inputs to create the blob：

• Environment variables in a text file (only one env “name=value” string on each line).
• The size of the environment blob in bytes (remember, this must comply with the CONFIG_ENV_SIZE you have defined in your board’s config).

  For example, if my env data file is called my_env_data.txt, and the size of my desired env blob is 16384 (16 KiB), I would use the following command:

$./tools/mkenvimage -s 16384 -o env_blob my_env_data.txt

You can see the dump of the env blob using the od command:

$ od -t x1c env_blob
0000000 0d d2 49 96 62 61 75 64 72 61 74 65 3d 31 31 35
\r 322 I 226 b a u d r a t e = 1 1 5
0000020 32 30 30 00 62 6f 6f 74 64 65 6c 61 79 3d 31 30
2 0 0 \0 b o o t d e l a y = 1 0
0000040 00 6c 6f 61 64 5f 61 64 64 72 3d 30 78 34 30 30
\0 l o a d _ a d d r = 0 x 4 0 0
0000060 30 30 30 30 30 00 00 00 00 00 00 00 00 00 00 00
0 0 0 0 0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0
0000100 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
\0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0
*
0040000

  This environment data blob must be flashed at the predefined offset in the storage device. You can use U-Boot, Linux or any other flasher to burn this blob.