U-Boot环境变量
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.
The real power of environment variable results from the fact that Unix shell like variable expansion is available. For example:
=> 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.
阅读(882) | 评论(0) | 转发(0) |