U-Boot Environment Variables

1.4. U-Boot Environment Variables

The U-Boot environment is a block of memory that is kept on NAND flash and copied to SDRAM when u-boot starts. It is used to store environment variables which can be used to configure the system. The environment is protected by a CRC32 checksum. It is much like a traditional Linux shell, the U-Boot shell uses environment variables to tailor its operation. The U-Boot commands to manipulate environment variables have the same names as the BASH shell. For instance printenv and setenv behave the same as their BASH shell counterparts.

This section lists the most important environment variables, some of which have a special meaning to u-boot. You can use these variables to configure the behaviour of u-boot to your liking.

• autoload: if set to "no" (or any string beginning with 'n'), the rarpb, bootp or dhcp commands will perform only a configuration lookup from the BOOTP / DHCP server, but not try to load any image using TFTP.
• autostart: if set to "yes", an image loaded using the rarpb, bootp, dhcp, tftp, disk, or docb commands will be automatically started (by internally calling the bootm command).
• baudrate: a decimal number that selects the console baudrate (in bps). Only a predefined list of baudrate settings is available.
  When you change the baudrate (using the "setenv baudrate ..." command), U-Boot will switch the baudrate of the console terminal and wait for a newline which must be entered with the new speed setting. This is to make sure you can actually type at the new speed. If this fails, you have to reset the board (which will operate at the old speed since you were not able to saveenv the new settings.)
  If no "baudrate" variable is defined, the default baudrate of 115200 is used.
• bootargs: The contents of this variable are passed to the Linux kernel as boot arguments (aka "command line").
• bootcmd: This variable defines a command string that is automatically executed when the initial countdown is not interrupted.
  This command is only executed when the variable bootdelay is also defined!
• bootdelay: After reset, u-boot will wait this number of seconds before it executes the contents of the bootcmd variable. During this time a countdown is printed, which can be interrupted by pressing any key.
  Set this variable to 0 boot without delay. Be careful: depending on the contents of your bootcmd variable, this can prevent you from entering interactive commands again forever!
  Set this variable to -1 to disable autoboot.
• bootfile: name of the default image to load with TFTP
• cpuclk: On some processors, the CPU clock frequency can be adjusted by the user (for example to optimize performance versus power dissipation). On such systems the cpuclk variable can be set to the desired CPU clock value, in MHz. If the cpuclk variable exists and its value is within the compile-time defined limits (CFG_866_CPUCLK_MIN and CFG_866_CPUCLK_MAX = minimum resp. maximum allowed CPU clock), then the specified value is used. Otherwise, the default CPU clock value is set.
• ethaddr: Ethernet MAC address for first/only ethernet interface (= eth0 in Linux).
  This variable can be set only once (usually during manufacturing of the board). U-Boot refuses to delete or overwrite this variable once it has been set.
• eth1addr: Ethernet MAC address for second ethernet interface (= eth1 in Linux).
• eth2addr: Ethernet MAC address for third ethernet interface (= eth2 in Linux).
• initrd_high: used to restrict positioning of initrd ramdisk images:
  If this variable is not set, initrd images will be copied to the highest possible address in RAM; this is usually what you want since it allows for maximum initrd size. If for some reason you want to make sure that the initrd image is loaded below the CFG_BOOTMAPSZ limit, you can set this environment variable to a value of "no" or "off" or "0". Alternatively, you can set it to a maximum upper address to use (U-Boot will still check that it does not overwrite the U-Boot stack and data).
  For instance, when you have a system with 16 MB RAM, and want to reserve 4 MB from use by Linux, you can do this by adding "mem=12M" to the value of the "bootargs" variable. However, now you must make sure that the initrd image is placed in the first 12 MB as well - this can be done with

  => setenv initrd_high 00c00000

  Setting initrd_high to the highest possible address in your system (0xFFFFFFFF) prevents U-Boot from copying the image to RAM at all. This allows for faster boot times, but requires a Linux kernel with zero-copy ramdisk support.

• ipaddr: IP address; needed for tftp command
• loadaddr: Default load address for commands like tftp or loads.
• loads_echo: If set to 1, all characters received during a serial download (using the loads command) are echoed back. This might be needed by some terminal emulations (like cu), but may as well just take time on others.
• pram: If the "Protected RAM" feature is enabled in your board's configuration, this variable can be defined to enable the reservation of such "protected RAM", i. e. RAM which is not overwritten by U-Boot. Define this variable to hold the number of kB you want to reserve for pRAM. Note that the board info structure will still show the full amount of RAM. If pRAM is reserved, a new environment variable "mem" will automatically be defined to hold the amount of remaining RAM in a form that can be passed as boot argument to Linux, for instance like that:

  => setenv bootargs ${bootargs} mem=\${mem}

  => saveenv

  This way you can tell Linux not to use this memory, either, which results in a memory region that will not be affected by reboots.

• oserverip: TFTP server IP address; needed for tftp command.
• serial#: contains hardware identification information such as type string and/or serial number.
  This variable can be set only once (usually during manufacturing of the board). U-Boot refuses to delete or overwrite this variable once it hass been set.
• silent: If the configuration option CONFIG_SILENT_CONSOLE has been enabled for your board, setting this variable to any value will suppress all console messages. Please see doc/README.silent for details.
• verify: If set to n or no disables the checksum calculation over the complete image in the bootm command to trade speed for safety in the boot process. Note that the header checksum is still verified.

The following environment variables may be used and automatically updated by the network boot commands (bootp, dhcp, or tftp), depending the information provided by your boot server:

• bootfile: see above
• dnsip: IP address of your Domain Name Server
• gatewayip: IP address of the Gateway (Router) to use
• hostname: Target hostname
• ipaddr: see above
• netmask: Subnet Mask
• rootpath: Pathname of the root filesystem on the NFS server
• serverip: see above
• filesize: Size (as hex number in bytes) of the file downloaded using the last bootp, dhcp, or tftp command.

=> setenv ipaddr 192.168.3.71
=> setenv serverip 192.168.3.1
=> setenv netdev eth0
=> setenv hostname testbox
=> setenv rootpath /opt/eldk/ppc_8xx
=> setenv ramargs setenv bootargs root=/dev/ram rw
=> setenv nfsargs 'setenv bootargs root=/dev/nfs rw nfsroot=${serverip}:${rootpath}'
=> setenv kernel_addr 40040000
=> setenv ramdisk_addr 40100000
=> setenv flash_ram 'run ramargs addip;bootm ${kernel_addr} ${ramdisk_addr}'
=> setenv flash_nfs 'run nfsargs addip;bootm ${kernel_addr}'
=> setenv net_nfs 'tftp 200000 ${bootfile};run nfsargs addip;bootm'
=> setenv net_ram 'tftp 200000 ${bootfile};run ramargs addip;bootm 200000 ${ramdisk_addr}'
Boot Kernel Image in flash with ramdisk in flash:
=> run flash_ram
Boot Kernel Image in flash with root filesystem over NFS:
=> run flash_nfs
Download Kernel Image over network and use root filesystem over NFS:
=> run flash_ram
Download Kernel Image over network with ramdisk in flash:
=> run flash_ram

U-Boot also allows to store commands or command sequences in a plain text file. Using the mkimage tool you can then convert this file into a script image which can be executed using u-boot's autoscr command. Nevertheless; U-Boot allows to dynamically load and run "standalone" applications, which can use some resources of U-Boot like console I/O functions, memory allocation or interrupt services. U-Boot supports the concept of a splash screen for booting image. If developers would like to learn more, please refer to DENX U-Boot manual.

We will detail how to download firmware (u-boot, Linux kernel and rescue root filesystems) into NAND flash using the tftp command of u-boot via Ethernet.