參考來源
http://www.denx.de/wiki/publish/DULG/DULG-tqm8xxl.html
4. System Setup
Some tools are needed to install and configure U-Boot and Linux on the target system. Also, especially during development, you will want to be able to interact with the target system. This section describes how to configure your host system for this purpose.
4.1. Serial Console Access
To use U-Boot and Linux as a development system and to make full use of all their capabilities you will need access to a serial console port on your target system. Later, U-Boot and Linux can be configured to allow for automatic execution without any user interaction.
There are several ways to access the serial console port on your target system, such as using a terminal server, but the most common way is to attach it to a serial port on your host. Additionally, you will need a terminal emulation program on your host system, such as cu or kermit.
4.2. Configuring the "cu" command
The cu command is part of the UUCP package and can be used to act as a dial-in terminal. It can also do simple file transfers, which can be used in U-Boot for image download.
On RedHat systems you can check if the UUCP package is installed as follows:
$ rpm -q uucp
If necessary, install the UUCP package from your distribution media.
To configure cu for use with U-Boot and Linux please make sure that the following entries are present in the UUCP configuration files; depending on your target configuration the serial port and/or the console baudrate may be different from the values used in this example: (/dev/ttyS0, 115200 bps, 8N1):
- /etc/uucp/sys:
# # /dev/ttyS0 at 115200 bps: # system S0@115200 port serial0_115200 time any
- /etc/uucp/port:
# # /dev/ttyS0 at 115200 bps: # port serial0_115200 type direct device /dev/ttyS0 speed 115200 hardflow false
You can then connect to the serial line using the command
$ cu S0@115200 Connected.
To disconnect, type the escape character '~' followed by '.' at the beginning of a line.
See also: cu(1), info uucp.
4.3. Configuring the "kermit" command
The name kermit stands for a whole family of communications software for serial and network connections. The fact that it is available for most computers and operating systems makes it especially well suited for our purposes.
kermit executes the commands in its initialization file, .kermrc, in your home directory before it executes any other commands, so this can be easily used to customize its behaviour using appropriate initialization commands. The following settings are recommended for use with U-Boot and Linux:
- ~/.kermrc:
set line /dev/ttyS0 set speed 115200 set carrier-watch off set handshake none set flow-control none robust set file type bin set file name lit set rec pack 1000 set send pack 1000 set window 5
This example assumes that you use the first serial port of your host system (/dev/ttyS0) at a baudrate of 115200 to connect to the target's serial console port.
You can then connect to the serial line:
$ kermit -c Connecting to /dev/ttyS0, speed 115200. The escape character is Ctrl-\ (ASCII 28, FS) Type the escape character followed by C to get back, or followed by ? to see other options. ----------------------------------------------------
Due to licensing conditions you will often find two kermit packages in your GNU/Linux distribution. In this case you will want to install the ckermit package. The gkermit package is only a command line tool implementing the kermit transfer protocol.
If you cannot find kermit on the distribution media for your Linux host system, you can download it from the kermit project home page: http://www.columbia.edu/kermit/
4.4. Using the "minicom" program
minicom is another popular serial communication program. Unfortunately, many users have reported problems using it with U-Boot and Linux, especially when trying to use it for serial image download. It's use is therefore discouraged.
4.5. Permission Denied Problems
The terminal emulation program must have write access to the serial port and to any locking files that are used to prevent concurrent access from other applications. Depending on the used Linux distribution you may have to make sure that:
- the serial device belongs to the same group as the
cucommand, and that the permissions ofcuhave the setgid bit set - the
kermitbelongs to the same group ascuand has the setgid bit set - the /var/lock directory belongs to the same group as the
cucommand, and that the write permissions for the group are set
4.6. Configuration of a TFTP Server
The fastest way to use U-Boot to load a Linux kernel or an application image is file transfer over Ethernet. For this purpose, U-Boot implements the TFTP protocol (see the tftpboot command in U-Boot).
To enable TFTP support on your host system you must make sure that the TFTP daemon program /usr/sbin/in.tftpd is installed. On RedHat systems you can verify this by running:
$ rpm -q tftp-server
If necessary, install the TFTP daemon program from your distribution media.
Most Linux distributions disable the TFTP service by default. To enable it for example on RedHat systems, edit the file /etc/xinetd.d/tftp and remove the line
disable = yes
or change it into a comment line by putting a hash character in front of it:
# default: off
# description: The tftp server serves files using the trivial file transfer
# protocol. The tftp protocol is often used to boot diskless
# workstations, download configuration files to network-aware printers,
# and to start the installation process for some operating systems.
service tftp
{
socket_type = dgram
protocol = udp
wait = yes
user = root
server = /usr/sbin/in.tftpd
server_args = -s /tftpboot
# disable = yes
per_source = 11
cps = 100 2
}
Also, make sure that the /tftpboot directory exists and is world-readable (permissions at least "dr-xr-xr-x").
4.7. Configuration of a BOOTP / DHCP Server
BOOTP resp. DHCP can be used to automatically pass configuration information to the target. The only thing the target must "know" about itself is its own Ethernet hardware (MAC) address. The following command can be used to check if DHCP support is available on your host system:
$ rpm -q dhcp
If necessary, install the DHCP package from your distribution media.
Then you have to create the DHCP configuration file /etc/dhcpd.conf that matches your network setup. The following example gives you an idea what to do:
subnet 10.0.0.0 netmask 255.0.0.0 {
option routers 10.0.0.2;
option subnet-mask 255.0.0.0;
option domain-name "local.net";
option domain-name-servers ns.local.net;
host trgt { hardware ethernet 00:30:BF:01:02:D0;
fixed-address 10.0.0.99;
option root-path "/opt/eldk/ppc_8xx";
option host-name "tqm";
next-server 10.0.0.2;
filename "/tftpboot/TQM8xxL/uImage";
}
}
With this configuration, the DHCP server will reply to a request from the target with the ethernet address 00:30:BF:01:02:D0 with the following information:
- The target is located in the subnet
10.0.0.0which uses the netmask255.0.0.0. - The target has the hostname
tqmand the IP address10.0.0.99. - The host with the IP address
10.0.0.2will provide the boot image for the target and provide NFS server function in cases when the target mounts it's root filesystem over NFS.
The host listed with thenext-serveroption can be different from the host that is running the DHCP server. - The host provides the file /tftpboot/TQM8xxL/uImage as boot image for the target.
- The target can mount the directory /opt/eldk/ppc_8xx on the NFS server as root filesystem.
4.8. Configuring a NFS Server
For a development environment it is very convenient when the host and the target can share the same files over the network. The easiest way for such a setup is when the host provides NFS server functionality and exports a directory that can be mounted from the target as the root filesystem.
Assuming NFS server functionality is already provided by your host, the only configuration that needs to be added is an entry for your target root directory to your /etc/exports file, for instance like this:
/opt/eldk/ppc_8xx 10.0.0.0/255.0.0.0(rw,no_root_squash,sync)
This line exports the /opt/eldk/ppc_8xx directory with read and write permissions to all hosts on the 10.0.0.0 subnet.
After modifying the /etc/exports file you must make sure the NFS system is notified about the change, for instance by issuing the command:
# /sbin/service nfs restart
- 5. Das U-Boot
- 5.1. Current Versions
- 5.2. Unpacking the Source Code
- 5.3. Configuration
- 5.4. Installation
- 5.5. Tool Installation
- 5.6. Initialization
- 5.7. Initial Steps
- 5.8. The First Power-On
- 5.9. U-Boot Command Line Interface
- 5.9.1. Information Commands
- 5.9.2. Memory Commands
- 5.9.2.1. base - print or set address offset
- 5.9.2.2. crc32 - checksum calculation
- 5.9.2.3. cmp - memory compare
- 5.9.2.4. cp - memory copy
- 5.9.2.5. md - memory display
- 5.9.2.6. mm - memory modify (auto-incrementing)
- 5.9.2.7. mtest - simple RAM test
- 5.9.2.8. mw - memory write (fill)
- 5.9.2.9. nm - memory modify (constant address)
- 5.9.2.10. loop - infinite loop on address range
- 5.9.3. Flash Memory Commands
- 5.9.4. Execution Control Commands
- 5.9.5. Download Commands
- 5.9.5.1. bootp - boot image via network using BOOTP/TFTP protocol
- 5.9.5.2. dhcp - invoke DHCP client to obtain IP/boot params
- 5.9.5.3. loadb - load binary file over serial line (kermit mode)
- 5.9.5.4. loads - load S-Record file over serial line
- 5.9.5.5. rarpboot- boot image via network using RARP/TFTP protocol
- 5.9.5.6. tftpboot- boot image via network using TFTP protocol
- 5.9.6. Environment Variables Commands
- 5.9.7. Special Commands
- 5.9.8. Miscellaneous Commands
- 5.10. U-Boot Environment Variables
- 5.11. U-Boot Scripting Capabilities
- 5.12. U-Boot Standalone Applications
- 5.13. U-Boot Image Formats
- 5.14. U-Boot Advanced Features
5. Das U-Boot
5.1. Current Versions
Das U-Boot (or just "U-Boot" for short) is Open Source Firmware for Embedded PowerPC, ARM, MIPS, x86 and other processors. The U-Boot project is hosted by DENX, where you can also find the project home page: http://www.denx.de/wiki/UBoot
The current version of the U-Boot source code can be retrieved from the DENX "git" repository.
You can browse the "git" repositories at http://www.denx.de/cgi-bin/gitweb.cgi
The trees can be accessed through the git, HTTP, and rsync protocols. For example you can use one of the following commands to create a local clone of one of the source trees:
git clone git://www.denx.de/git/u-boot.git u-boot/ git clone http://www.denx.de/git/u-boot.git u-boot/ git clone rsync://www.denx.de/git/u-boot.git u-boot/
For details please see here.
The U-Boot source code can also be retrieved from our CVS repository using anonymous (pserver) CVS. Press the "Enter" key when asked for the password for user "anonymous":
$ cvs -d:pserver:anonymous@www.denx.de:/cvsroot login $ cvs -z6 -d:pserver:anonymous@www.denx.de:/cvsroot co -P u-boot
Official releases of U-Boot are also available through FTP. Compressed tar archives can downloaded from the directory ftp://ftp.denx.de/pub/u-boot/.
Those poor people sitting behind a restrictive firewall may use http tunneling to access the repositories. Here is an example for cvsgrab, available from http://cvsgrab.sourceforge.net/, to access the U-Boot repository:
cvsgrab -quiet -proxyHost <http_proxy> -proxyPort <proxy_port> -proxyUser <proxy_user> \
-cvsRoot :pserver:anonymous@www.denx.de:/cvsroot \
-rootUrl http://www.denx.de/cvsweb/ -packagePath u-boot -packageDir u-boot
Of course you have to set http_proxy , proxy_port and proxy_user properly.
5.2. Unpacking the Source Code
If you used CVS to get a copy of the U-Boot sources, then you can skip this next step since you already have an unpacked directory tree. If you downloaded a compressed tarball from the DENX FTP server, you can unpack it as follows:
$ cd /opt/eldk/usr/src $ wget ftp://ftp.denx.de/pub/u-boot/u-boot-0.4.5.tar.bz2 $ rm -f u-boot $ bunzip2 < u-boot-0.4.5.tar.bz2 | tar xf - $ ln -s u-boot-0.4.5 u-boot $ cd u-boot
5.3. Configuration
After changing to the directory with the U-Boot source code you should make sure that there are no build results from any previous configurations left:
$ make distclean
The following (model) command configures U-Boot for the TQM8xxL board:
$ make tqm8xxl_config
The TQM8xxL boards are available in many configurations (different CPUs, clock frequencies, with or without LCD display, with or without Fast Ethernet interface). Depending on the board configuration chose one of the following make targets:
| TQM823L_config | TQM823L_66MHz_config | TQM823L_80MHz_config |
| TQM823L_LCD_config | TQM823L_LCD_66MHz_config | TQM823L_LCD_80MHz_config |
| TQM850L_config | TQM850L_66MHz_config | TQM850L_80MHz_config |
| TQM855L_config | TQM855L_66MHz_config | TQM855L_80MHz_config |
| TQM860L_config | TQM860L_66MHz_config | TQM860L_80MHz_config |
| TQM862L_config | TQM862L_66MHz_config | TQM862L_80MHz_config |
| TQM855M_config | TQM855M_66MHz_config | TQM855M_80MHz_config |
| TQM860M_config | TQM860M_66MHz_config | TQM860M_80MHz_config |
| TQM862M_config | TQM862M_66MHz_config | TQM862M_80MHz_config |
| TQM862M_100MHz_config |
And finally we can compile the tools and U-Boot itself:
$ make all
By default the build is performed locally and the objects are saved in the source directory. One of the two methods can be used to change this behaviour and build U-Boot to some external directory:
1. Add O= to the make command line invocations:
make O=/tmp/build distclean make O=/tmp/build tqm8xxl_config make O=/tmp/build all
Note that if the 'O=output/dir' option is used then it must be used for all invocations of make.
2. Set environment variable BUILD_DIR to point to the desired location:
export BUILD_DIR=/tmp/build make distclean make tqm8xxl_config make all
Note that the command line "O=" setting overrides the BUILD_DIR environment variable.
5.4. Installation
5.4.1. Before You Begin
5.4.1.1. Installation Requirements
The following section assumes that flash memory is used as the storage device for the firmware on your board. If this is not the case, the following instructions will not work - you will probably have to replace the storage device (probably ROM or EPROM) on such systems to install or update U-Boot.
5.4.1.2. Board Identification Data
All TQM8xxL boards use a serial number for identification purposes. Also, all boards have at least one ethernet (MAC) address assigned. You may lose your warranty on the board if this data gets lost. Before installing U-Boot or otherwise changing the software configuration of a board (like erasing some flash memory) you should make sure that you have all necessary information about such data.
5.4.2. Installation Using a BDM/JTAG Debugger
A fast and simple way to write new data to flash memory is via the use of a debugger or flash programmer with a BDM or JTAG interface. In cases where there is no running firmware at all (for instance on new hardware), this is usually the only way to install any software at all.
We use (and highly recommend) the BDI2000 by Abatron .
Other BDM / JTAG debuggers may work too, but how to use them is beyond the scope of this document. Please see the documentation for the tool you want to use.
Before you can use the BDI2000 you have to configure it. A configuration file that can be used with TQM8xxL boards is included in section 13.1. BDI2000 Configuration file
To install a new U-Boot image on your TQM8xxL board using a BDI2000, proceed as follows:
BDI>reset BDI>- TARGET: processing user reset request BDI>- TARGET: reseting target passed BDI>- TARGET: processing target init list .... BDI>- TARGET: processing target init list passed BDI>md 0x1FFC0 0001ffc0 : 54514d38 36304c44 44424133 2d503530 TQM860LDDBA3-P50 0001ffd0 : 2e323033 20313032 32363132 32203030 .203 10226122 00 0001ffe0 : 44303933 30303238 38312034 00000000 D093002881 4.... 0001fff0 : 00000000 00000000 00000000 00000000 ................ 00020000 : ffffffff ffffffff ffffffff ffffffff ................ \... BDI>rm der 0x2006000f BDI>erase 00000000 Erasing flash at 0x00000000 Erasing flash passed BDI>erase 0x008000 Erasing flash at 0x00008000 Erasing flash passed BDI>erase 0x00c000 Erasing flash at 0x0000c000 Erasing flash passed BDI>erase 0x010000 Erasing flash at 0x00010000 Erasing flash passed BDI>erase 0x020000 Erasing flash at 0x00020000 Erasing flash passed BDI>prog 0 uboot.bin bin Programming uboot.bin , please wait .... Programming flash passed BDI>rm der 0x2002000f
5.4.3. Installation using U-Boot
If U-Boot is already installed and running on your board, you can use these instructions to download another U-Boot image to replace the current one.
Warning: Before you can install the new image, you have to erase the current one. If anything goes wrong your board will be dead. It is strongly recommended that:
- you have a backup of the old, working U-Boot image
- you know how to install an image on a virgin system
Proceed as follows:
=> tftp 100000 /tftpboot/uboot.bin
ARP broadcast 1
TFTP from server 10.0.0.2; our IP address is 10.0.0.100
Filename '/tftpboot/uboot.bin'.
Load address: 0x100000
Loading: ###############################
done
Bytes transferred = 155376 (25ef0 hex)
=> protect off 40000000 4003FFFF
Un-Protected 5 sectors
=> era 40000000 4003FFFF
Erase Flash from 0x40000000 to 0x4003ffff
......... done
Erased 5 sectors
=> cp.b 100000 40000000 ${filesize}
Copy to Flash... done
=> setenv filesize
=> saveenv
Saving Enviroment to Flash...
Un-Protected 1 sectors
Erasing Flash...
.. done
Erased 1 sectors
Writing to Flash... done
Protected 1 sectors
=> reset
5.4.4. Installation using Linux
If you have Linux running on your TQM8xxL system and your Linux configuration includes a flash device driver, then you can use this to install a U-Boot image to the appropriate address in flash memory:
# cat /proc/mtd dev: size erasesize name mtd0: 00040000 00020000 "uboot" mtd1: 000c0000 00020000 "kernel" mtd2: 00100000 00020000 "user" mtd3: 00200000 00020000 "initrd" mtd4: 00200000 00020000 "cramfs" mtd5: 00200000 00020000 "jffs" # eraseall /dev/mtd0 Erased 256 Kibyte @ 0 -- 100% complete. # dd if=/tmp/uboot.bin of=/dev/mtd0 bs=128k conv=sync 1+1 records in 2+0 records out
5.4.5. Installation using firmware
Connect to the SMC1 port of the tqm8xxl board using the cu program. See the hints for configuring cu above. Make sure you can communicate with the MON8xx firmware: reset the board and hit ENTER a couple of times until you see the MON8xx prompt (MON:>). Then proceed as follows:
5.4.5.1. Read Board ID and MAC Address
The same information is also printed on labels on the module, but often these labels are on the underside of the module so you have to remove it from the carrier board to read the text.
MON8xx.105 on TQM860L - (C) TQ-Systems 1998-2000
CPU speed: 50 MHz
MON:>
MON:>read 4001ff80
4001FF80: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ................
4001FF90: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ................
4001FFA0: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ................
4001FFB0: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ................
4001FFC0: 54 51 4D 38 36 30 4C 43 42 30 41 33 2D 53 52 35 TQM860LCB0A3-SR5
4001FFD0: 30 2E 32 30 32 20 31 30 31 33 34 38 37 33 20 30 0.202 10134873 0
4001FFE0: 30 44 30 39 33 30 30 31 32 33 34 20 34 00 00 00 0D093001234 4...
4001FFF0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
40020000: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ................
40020010: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ................
40020020: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ................
40020030: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ................
40020040: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ................
40020050: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ................
40020060: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ................
40020070: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ................
MON:>
In the memory dump you can identify 4 strings of ASCII characters, separated by space characters: "TQM860LCB0A3-SR50.202", "10134873", "00D093001234", and "4". These have the following meaning:
- Module Type and Revision
- Serial Number
- Ethernet Address
- Number of additional Ethernet Addresses reserved for this board
In PPCBoot this is stored in two environment variables:
- Serial Number:
serial#= TQM860LCB0A3-SR50.202 10134873 4 - Ethernet Address:
ethaddr= 00D093001234 (==> 00:D0:93:00:12:34)
5.4.5.2. Test Download
This step is to make sure that you can download the U-Boot image to the flash memory. We load the U-Boot image to another (free) position in flash memory.
MON:>erase 40100000 4013ffff
* Erasing FLASH from 40100000h to 4013FFFFh
* Please wait
MON:>load 100000 flash
* Ready for s-record download to FLASH ...
~>ppcboot.srec
1 2 3 4 5 6 7 8 9 10 11 12 ...
\...
\... 6619 6620 6621 6622 6623
[file transfer complete]
[connected]
* Start address 40000000
MON:>
5.4.5.3. Verify Download
To make sure that the download and flash programming worked we dump the start of the U-Boot image. You should be able to read the U-Boot header information like that:
MON:>read 40100000
40100000: 27 05 19 56 50 50 43 42 6F 6F 74 20 31 2E 30 2E '..VPPCBoot 1.0.
40100010: 30 2D 70 72 65 32 20 28 4A 75 6E 20 20 33 20 32 0-pre2 (Jun 3 2
40100020: 30 30 31 20 2D 20 32 33 3A 35 38 3A 34 30 29 00 001 - 23:58:40).
40100030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
\...
MON:>
5.4.5.4. Erase MON8xx Firmware
The MON8xx Firmware is write-protected. We un-protect and erase it:
MON:>protect 1234
* Protection for sectors containing MON8xx disabled
MON:>erase 40000000 4003ffff
* Erasing FLASH from 40000000h to 4003FFFFh
* Please wait
MON:>
5.4.5.5. Load U-Boot
Now we load PPCBoot at it's correct position.
MON:>load 0 flash * Ready for s-record download to FLASH ... ~>ppcboot.srec 1 2 3 4 5 6 7 8 9 10 11 12 ... \... \... 6619 6620 6621 6622 6623 [file transfer complete] [connected] * Start address 40000000 MON:>
5.4.5.6. Verify Download
MON:>read 40000000 40000000: 27 05 19 56 50 50 43 42 6F 6F 74 20 31 2E 30 2E '..VPPCBoot 1.0. 40000010: 30 2D 70 72 65 32 20 28 4A 75 6E 20 20 33 20 32 0-pre2 (Jun 3 2 40000020: 30 30 31 20 2D 20 32 33 3A 35 38 3A 34 30 29 00 001 - 23:58:40). 40000030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ \... MON:>
In case anything goes wrong: Do NOT reset the board! Do NOT switch off the power! Instead, recover the old TQ monitor which is still running in RAM:
5.4.5.7. Recover Old MON8xx Firmware
MON:>erase 40000000 4003ffff * Erasing FLASH from 40000000h to 4003FFFFh * Please wait MON:>copy monitor Copy monitor MON:>sethwi TQM860LCB0A3-SR50.202 10134873 00D093001234 4 * Hardware information written to 4001FFC0 MON:>
5.4.5.8. Reset Board, and Re-Initialize
PPCBoot 1.0.0-pre2 (Jun 3 2001 - 23:58:40)
Initializing...
CPU: XPC860xxZPnnD3 at 50 MHz: 4 kB I-Cache 4 kB D-Cache FEC present
Board: ### No HW ID - assuming TQM8xxL
DRAM: 16 MB
FLASH: 4 MB
PCMCIA: No Card found
In: serial
Out: serial
Err: serial
Hit any key to stop autoboot: 0
=> setenv serial# TQM860LCB0A3-SR50.202 10134873
=> setenv ethaddr 00:D0:93:00:12:34
=> saveenv
Un-Protected 1 sectors
Erasing Flash...
\.. done
Erased 1 sectors
Saving Environment to Flash...
Protected 1 sectors
=> reset
5.5. Tool Installation
U-Boot uses a special image format when loading the Linux kernel or ramdisk or other images. This image contains (among other things) information about the time of creation, operating system, compression type, image type, image name and CRC32 checksums.
The tool mkimage is used to create such images or to display the information they contain. When using the ELDK, the mkimage command is already included with the other ELDK tools.
If you don't use the ELDK then you should install mkimage in some directory that is in your command search PATH, for instance:
$ cp tools/mkimage /usr/local/bin/
5.6. Initialization
To initialize the U-Boot firmware running on your TQM8xxL board, you have to connect a terminal to the board's serial console port.
The default configuration of the console port on the TQM8xxL board uses a baudrate of 115200/8N1 (115200 bps, 8 Bit per character, no parity, 1 stop bit, no handshake).
If you are running Linux on your host system we recommend either kermit or cu as terminal emulation programs. Do not use minicom, since this has caused problems for many users, especially for software download over the serial port.
For the configuration of your terminal program see section 4.1. Serial Console Access
Make sure that both hardware and software flow control are disabled.
5.7. Initial Steps
In the default configuration, U-Boot operates in an interactive mode which provides a simple command line-oriented user interface using a serial console on port "COM.1 (X.18)".
In the simplest case, this means that U-Boot shows a prompt (default: =>) when it is ready to receive user input. You then type a command, and press enter. U-Boot will try to run the required action(s), and then prompt for another command.
To see a list of the available U-Boot commands, you can type help (or simply ?). This will print a list of all commands that are available in your current configuration. [Please note that U-Boot provides a lot of configuration options; not all options are available for all processors and boards, and some options might be simply not selected for your configuration.]
=> help
askenv - get environment variables from stdin
autoscr - run script from memory
base - print or set address offset
bdinfo - print Board Info structure
bootm - boot application image from memory
bootp - boot image via network using BootP/TFTP protocol
bootd - boot default, i.e., run 'bootcmd'
cmp - memory compare
coninfo - print console devices and informations
cp - memory copy
crc32 - checksum calculation
date - get/set/reset date & time
dhcp - invoke DHCP client to obtain IP/boot params
diskboot- boot from IDE device
echo - echo args to console
erase - erase FLASH memory
flinfo - print FLASH memory information
go - start application at address 'addr'
help - print online help
ide - IDE sub-system
iminfo - print header information for application image
loadb - load binary file over serial line (kermit mode)
loads - load S-Record file over serial line
loop - infinite loop on address range
md - memory display
mm - memory modify (auto-incrementing)
mtest - simple RAM test
mw - memory write (fill)
nm - memory modify (constant address)
printenv- print environment variables
protect - enable or disable FLASH write protection
rarpboot- boot image via network using RARP/TFTP protocol
reset - Perform RESET of the CPU
run - run commands in an environment variable
saveenv - save environment variables to persistent storage
setenv - set environment variables
sleep - delay execution for some time
tftpboot- boot image via network using TFTP protocol
and env variables ipaddr and serverip
version - print monitor version
? - alias for 'help'
=>
With the command help <command> you can get additional information about most commands:
=> help tftpboot
tftpboot [loadAddress] [bootfilename]
=> help setenv printenv
setenv name value ...
- set environment variable 'name' to 'value ...'
setenv name
- delete environment variable 'name'
printenv
- print values of all environment variables
printenv name ...
- print value of environment variable 'name'
=>
Most commands can be abbreviated as long as the string remains unambiguous:
=> help fli tftp
flinfo
- print information for all FLASH memory banks
flinfo N
- print information for FLASH memory bank # N
tftpboot [loadAddress] [bootfilename]
=>
5.8. The First Power-On
Note: If you bought your TQM8xxL board with U-Boot already installed, you can skip this section since the manufacturer probably has already performed these steps.
Connect the port labeled "COM.1 (X.18)" on your TQM8xxL board to the designated serial port of your host, start the terminal program, and connect the power supply of your TQM8xxL board. You should see messages like this:
Connecting to /dev/ttyS1, speed 115200. The escape character is Ctrl-\ (ASCII 28, FS) Type the escape character followed by C to get back, or followed by ? to see other options. ---------------------------------------------------- ^@ PPCBoot 1.1.5 (Mar 21 2002 - 19:55:04) CPU: XPC860xxZPnnD3 at 50 MHz: 16 kB I-Cache 8 kB D-Cache FEC present Board: TQM860LDDBA3-P50.203 DRAM: 64 MB FLASH: 8 MB In: serial Out: serial Err: serial PCMCIA: No Card found Type "run flash_nfs" to mount root filesystem over NFS Hit any key to stop autoboot: 0 =>
You can interrupt the "Count-Down" by pressing any key. If you don't you will probably see some (harmless) error messages because the system has not been initialized yet.
In some cases you may see a message
*** Warning - bad CRC, using default environment
This is harmless and will go away as soon as you have initialized and saved the environment variables.
At first you have to enter the serial number and the ethernet address of your board. Pay special attention here since these parameters are write protected and cannot be changed once saved (usually this is done by the manufacturer of the board). To enter the data you have to use the U-Boot command setenv, followed by the variable name and the data, all separated by white space (blank and/or TAB characters). Use the variable name serial# for the board ID and/or serial number, and ethaddr for the ethernet address, for instance:
=> setenv serial# TQM860LDB0A3-P.200 10061684 4 => setenv ethaddr 00:D0:93:00:05:B5
Use the printenv command to verify that you have entered the correct values:
=> printenv serial# ethaddr serial#=TQM860LDDBA3-P50.203 10226122 4 ethaddr=00:D0:93:00:28:81 =>
Please double check that the printed values are correct! You will not be able to correct any errors later! If there is something wrong, reset the board and restart from the beginning; otherwise you can store the parameters permanently using the saveenv command:
=> saveenv Saving Enviroment to Flash... Un-Protected 1 sectors Erasing Flash... . done Erased 1 sectors Writing to Flash... done Protected 1 sectors =>
5.9. U-Boot Command Line Interface
The following section describes the most important commands available in U-Boot. Please note that U-Boot is highly configurable, so not all of these commands may be available in the configuration of U-Boot installed on your hardware, or additional commands may exist. You can use the help command to print a list of all available commands for your configuration.
For most commands, you do not need to type in the full command name; instead it is sufficient to type a few characters. For instance, help can be abbreviated as h.
The behaviour of some commands depends of the configuration of U-Boot and on the definition of some variables in your U-Boot environment.
All U-Boot commands expect numbers to be entered in hexadecimal input format.
Be careful not to use edit keys besides 'Backspace', as hidden characters in things like environment variables can be very difficult to find.
5.9.1. Information Commands
5.9.1.1. bdinfo - print Board Info structure
=> help bdinfo bdinfo - No help available. =>
The bdinfo command (short: bdi) prints the information that U-Boot passes about the board such as memory addresses and sizes, clock frequencies, MAC address, etc. This information is mainly needed to be passed to the Linux kernel.
=> bdi memstart = 0x00000000 memsize = 0x04000000 flashstart = 0x40000000 flashsize = 0x00800000 flashoffset = 0x00030000 sramstart = 0x00000000 sramsize = 0x00000000 immr_base = 0xFFF00000 bootflags = 0x00000001 intfreq = 50 MHz busfreq = 50 MHz ethaddr = 00:D0:93:00:28:81 IP addr = 10.0.0.99 baudrate = 115200 bps => 5.9.1.2. coninfo - print console devices and informations
=> help conin
coninfo
=>
The coninfo command (short: conin) displays information about the available console I/O devices.
=> conin
List of available devices:
serial 80000003 SIO stdin stdout stderr
=>
The output contains the device name, flags, and the current usage. For example, the output
serial 80000003 SIO stdin stdout stderr
means that the serial device is a system device (flag 'S') which provides input (flag 'I') and output (flag 'O') functionality and is currently assigned to the 3 standard I/O streams stdin, stdout and stderr.
5.9.1.3. flinfo - print FLASH memory information
=> help flinfo
flinfo
- print information for all FLASH memory banks
flinfo N
- print information for FLASH memory bank # N
=>
The command flinfo (short: fli) can be used to get information about the available flash memory (see Flash Memory Commands below).
=> fli
Bank # 1: FUJITSU AM29LV160B (16 Mbit, bottom boot sect)
Size: 4 MB in 35 Sectors
Sector Start Addresses:
40000000 (RO) 40008000 (RO) 4000C000 (RO) 40010000 (RO) 40020000 (RO)
40040000 40060000 40080000 400A0000 400C0000
400E0000 40100000 40120000 40140000 40160000
40180000 401A0000 401C0000 401E0000 40200000
40220000 40240000 40260000 40280000 402A0000
402C0000 402E0000 40300000 40320000 40340000
40360000 40380000 403A0000 403C0000 403E0000
Bank # 2: FUJITSU AM29LV160B (16 Mbit, bottom boot sect)
Size: 4 MB in 35 Sectors
Sector Start Addresses:
40400000 40408000 4040C000 40410000 40420000
40440000 40460000 40480000 404A0000 404C0000
404E0000 40500000 40520000 40540000 40560000
40580000 405A0000 405C0000 405E0000 40600000
40620000 40640000 40660000 40680000 406A0000
406C0000 406E0000 40700000 40720000 40740000
40760000 40780000 407A0000 407C0000 407E0000
=>
5.9.1.4. iminfo - print header information for application image
=> help iminfo
iminfo addr [addr ...]
- print header information for application image starting at
address 'addr' in memory; this includes verification of the
image contents (magic number, header and payload checksums)
=>
iminfo (short: imi) is used to print the header information for images like Linux kernels or ramdisks. It prints (among other information) the image name, type and size and verifies that the CRC32 checksums stored within the image are OK.
=> imi 100000 ## Checking Image at 00100000 ... Image Name: Linux-2.4.4 Created: 2002-04-07 21:31:59 UTC Image Type: PowerPC Linux Kernel Image (gzip compressed) Data Size: 605429 Bytes = 591 kB = 0 MB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK =>
Like with many other commands, the exact operation of this command can be controlled by the settings of some U-Boot environment variables (here: the verify variable). See below for details.
5.9.1.5. help - print online help
=> help help
help [command ...]
- show help information (for 'command')
'help' prints online help for the monitor commands.
Without arguments, it prints a short usage message for all commands.
To get detailed help information for specific commands you can type
'help' with one or more command names as arguments.
=>
The help command (short: h or ?) prints online help. Without any arguments, it prints a list of all U-Boot commands that are available in your configuration of U-Boot. You can get detailed information for a specific command by typing its name as argument to the help command:
=> help protect
protect on start end
- protect FLASH from addr 'start' to addr 'end'
protect on N:SF[-SL]
- protect sectors SF-SL in FLASH bank # N
protect on bank N
- protect FLASH bank # N
protect on all
- protect all FLASH banks
protect off start end
- make FLASH from addr 'start' to addr 'end' writable
protect off N:SF[-SL]
- make sectors SF-SL writable in FLASH bank # N
protect off bank N
- make FLASH bank # N writable
protect off all
- make all FLASH banks writable
=>
5.9.2. Memory Commands
5.9.2.1. base - print or set address offset
=> help base
base
- print address offset for memory commands
base off
- set address offset for memory commands to 'off'
=>
You can use the base command (short: ba) to print or set a "base address" that is used as address offset for all memory commands; the default value of the base address is 0, so all addresses you enter are used unmodified. However, when you repeatedly have to access a certain memory region (like the internal memory of some embedded PowerPC processors) it can be very convenient to set the base address to the start of this area and then use only the offsets:
=> base Base Address: 0x00000000 => md 0 c 00000000: feffffff 00000000 7cbd2b78 7cdc3378 ........|.+x|.3x 00000010: 3cfb3b78 3b000000 7c0002e4 39000000 <.;x;...|...9... 00000020: 7d1043a6 3d000400 7918c3a6 3d00c000 }.C.=...y...=... => base 40000000 Base Address: 0x40000000 => md 0 c 40000000: 27051956 50504342 6f6f7420 312e312e '..VPPCBoot 1.1. 40000010: 3520284d 61722032 31203230 3032202d 5 (Mar 21 2002 - 40000020: 2031393a 35353a30 34290000 00000000 19:55:04)...... =>
5.9.2.2. crc32 - checksum calculation
The crc32 command (short: crc) can be used to caculate a CRC32 checksum over a range of memory:
=> crc 100004 3FC CRC32 for 00100004 ... 001003ff ==> d433b05b =>
When used with 3 arguments, the command stores the calculated checksum at the given address:
=> crc 100004 3FC 100000 CRC32 for 00100004 ... 001003ff ==> d433b05b => md 100000 4 00100000: d433b05b ec3827e4 3cb0bacf 00093cf5 .3.[.8'.<.....<. =>
As you can see, the CRC32 checksum was not only printed, but also stored at address 0x100000.
5.9.2.3. cmp - memory compare
=> help cmp
cmp [.b, .w, .l] addr1 addr2 count
- compare memory
=>
With the cmp command you can test of the contents of two memory areas is identical or not. The command will either test the whole area as specified by the 3rd (length) argument, or stop at the first difference.
=> cmp 100000 40000000 400 word at 0x00100004 (0x50ff4342) != word at 0x40000004 (0x50504342) Total of 1 word were the same => md 100000 C 00100000: 27051956 50ff4342 6f6f7420 312e312e '..VP.CBoot 1.1. 00100010: 3520284d 61722032 31203230 3032202d 5 (Mar 21 2002 - 00100020: 2031393a 35353a30 34290000 00000000 19:55:04)...... => md 40000000 C 40000000: 27051956 50504342 6f6f7420 312e312e '..VPPCBoot 1.1. 40000010: 3520284d 61722032 31203230 3032202d 5 (Mar 21 2002 - 40000020: 2031393a 35353a30 34290000 00000000 19:55:04)...... =>
Like most memory commands the cmp can access the memory in different sizes: as 32 bit (long word), 16 bit (word) or 8 bit (byte) data. If invoked just as cmp the default size (32 bit or long words) is used; the same can be selected explicitely by typing cmp.l instead. If you want to access memory as 16 bit or word data, you can use the variant cmp.w instead; and to access memory as 8 bit or byte data please use cmp.b.
Please note that the count argument specifies the number of data items to process, i. e. the number of long words or words or bytes to compare.
=> cmp.l 100000 40000000 400 word at 0x00100004 (0x50ff4342) != word at 0x40000004 (0x50504342) Total of 1 word were the same => cmp.w 100000 40000000 800 halfword at 0x00100004 (0x50ff) != halfword at 0x40000004 (0x5050) Total of 2 halfwords were the same => cmp.b 100000 40000000 1000 byte at 0x00100005 (0xff) != byte at 0x40000005 (0x50) Total of 5 bytes were the same =>
5.9.2.4. cp - memory copy
=> help cp
cp [.b, .w, .l] source target count
- copy memory
=>
The cp is used to copy memory areas.
=> cp 40000000 100000 10000 =>
The cp understands the type extensions .l, .w and .b :
Note: Included topic DULGData.tqm8xxlUBootCpExt does not exist yet
5.9.2.5. md - memory display
=> help md
md [.b, .w, .l] address [# of objects]
- memory display
=>
The md can be used to display memory contents both as hexadecimal and ASCII data.
=> md 100000
00100000: 27051956 50504342 6f6f7420 312e312e '..VPPCBoot 1.1.
00100010: 3520284d 61722032 31203230 3032202d 5 (Mar 21 2002 -
00100020: 2031393a 35353a30 34290000 00000000 19:55:04)......
00100030: 00000000 00000000 00000000 00000000 ................
00100040: 00000000 00000000 00000000 00000000 ................
00100050: 00000000 00000000 00000000 00000000 ................
00100060: 00000000 00000000 00000000 00000000 ................
00100070: 00000000 00000000 00000000 00000000 ................
00100080: 00000000 00000000 00000000 00000000 ................
00100090: 00000000 00000000 00000000 00000000 ................
001000a0: 00000000 00000000 00000000 00000000 ................
001000b0: 00000000 00000000 00000000 00000000 ................
001000c0: 00000000 00000000 00000000 00000000 ................
001000d0: 00000000 00000000 00000000 00000000 ................
001000e0: 00000000 00000000 00000000 00000000 ................
001000f0: 00000000 00000000 00000000 00000000 ................
=>
00100100: 3c60fff0 7c7e9ba6 3aa00001 4800000c <`..|~..:...H...
00100110: 3aa00002 48000004 38601002 7c600124 :...H...8`..|`.$
00100120: 7c7b03a6 7c7422a6 7c000278 7c1c23a6 |{..|t".|..x|.#.
00100130: 7c1d23a6 7c1623a6 7c1723a6 7c708aa6 |.#.|.#.|.#.|p..
00100140: 7c788aa6 3c600a00 7c708ba6 7c788ba6 |x..<`..|p..|x..
00100150: 3c600c00 7c708ba6 7c788ba6 3c600400 <`..|p..|x..<`..
00100160: 7c788ba6 3c600200 7c708ba6 7c0002e4 |x..<`..|p..|...
00100170: 4c00012c 3c604000 60630000 38630188 L..,<`@.`c..8c..
00100180: 7c6803a6 4e800020 3c60fff0 60612ec0 |h..N.. <`..`a..
00100190: 9401fffc 9401fffc 38400007 7c5e23a6 ........8@..|^#.
001001a0: 3c400000 60420000 7c5523a6 48000005 <@..`B..|U#.H...
001001b0: 7dc802a6 800e22bc 7dc07214 48019d41 }.....".}.r.H..A
001001c0: 7ea3ab78 4800c05d 00000000 00000000 ~..xH..]........
001001d0: 00000000 00000000 00000000 00000000 ................
001001e0: 00000000 00000000 00000000 00000000 ................
001001f0: 00000000 00000000 00000000 00000000 ................
=>
This command, too, can be used with the type extensions .l, .w and .b :
=> md.w 100000 00100000: 2705 1956 5050 4342 6f6f 7420 312e 312e '..VPPCBoot 1.1. 00100010: 3520 284d 6172 2032 3120 3230 3032 202d 5 (Mar 21 2002 - 00100020: 2031 393a 3535 3a30 3429 0000 0000 0000 19:55:04)...... 00100030: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 00100040: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 00100050: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 00100060: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 00100070: 0000 0000 0000 0000 0000 0000 0000 0000 ................ => md.b 100000 00100000: 27 05 19 56 50 50 43 42 6f 6f 74 20 31 2e 31 2e '..VPPCBoot 1.1. 00100010: 35 20 28 4d 61 72 20 32 31 20 32 30 30 32 20 2d 5 (Mar 21 2002 - 00100020: 20 31 39 3a 35 35 3a 30 34 29 00 00 00 00 00 00 19:55:04)...... 00100030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ =>
The last displayed memory address and the value of the count argument are remembered, so when you enter md again without arguments it will automatically continue at the next address, and use the same count again.
=> md.b 100000 20 00100000: 27 05 19 56 50 50 43 42 6f 6f 74 20 31 2e 31 2e '..VPPCBoot 1.1. 00100010: 35 20 28 4d 61 72 20 32 31 20 32 30 30 32 20 2d 5 (Mar 21 2002 - => md.w 100000 00100000: 2705 1956 5050 4342 6f6f 7420 312e 312e '..VPPCBoot 1.1. 00100010: 3520 284d 6172 2032 3120 3230 3032 202d 5 (Mar 21 2002 - 00100020: 2031 393a 3535 3a30 3429 0000 0000 0000 19:55:04)...... 00100030: 0000 0000 0000 0000 0000 0000 0000 0000 ................ => md 100000 00100000: 27051956 50504342 6f6f7420 312e312e '..VPPCBoot 1.1. 00100010: 3520284d 61722032 31203230 3032202d 5 (Mar 21 2002 - 00100020: 2031393a 35353a30 34290000 00000000 19:55:04)...... 00100030: 00000000 00000000 00000000 00000000 ................ 00100040: 00000000 00000000 00000000 00000000 ................ 00100050: 00000000 00000000 00000000 00000000 ................ 00100060: 00000000 00000000 00000000 00000000 ................ 00100070: 00000000 00000000 00000000 00000000 ................ =>
5.9.2.6. mm - memory modify (auto-incrementing)
=> help mm
mm [.b, .w, .l] address
- memory modify, auto increment address
=>
The mm is a method to interactively modify memory contents. It will display the address and current contents and then prompt for user input. If you enter a legal hexadecimal number, this new value will be written to the address. Then the next address will be prompted. If you don't enter any value and just press ENTER, then the contents of this address will remain unchanged. The command stops as soon as you enter any data that is not a hex number (like .):
=> mm 100000 00100000: 27051956 ? 0 00100004: 50504342 ? AABBCCDD 00100008: 6f6f7420 ? 01234567 0010000c: 312e312e ? . => md 100000 10 00100000: 00000000 aabbccdd 01234567 312e312e .........#Eg1.1. 00100010: 3520284d 61722032 31203230 3032202d 5 (Mar 21 2002 - 00100020: 2031393a 35353a30 34290000 00000000 19:55:04)...... 00100030: 00000000 00000000 00000000 00000000 ................ =>
Again this command can be used with the type extensions .l, .w and .b :
=> mm.w 100000 00100000: 0000 ? 0101 00100002: 0000 ? 0202 00100004: aabb ? 4321 00100006: ccdd ? 8765 00100008: 0123 ? . => md 100000 10 00100000: 01010202 43218765 01234567 312e312e ....C!.e.#Eg1.1. 00100010: 3520284d 61722032 31203230 3032202d 5 (Mar 21 2002 - 00100020: 2031393a 35353a30 34290000 00000000 19:55:04)...... 00100030: 00000000 00000000 00000000 00000000 ................ =>
=> mm.b 100000 00100000: 01 ? 48 00100001: 01 ? 61 00100002: 02 ? 6c 00100003: 02 ? 6c 00100004: 43 ? 6f 00100005: 21 ? 20 00100006: 87 ? 20 00100007: 65 ? 20 00100008: 01 ? . => md 100000 10 00100000: 48616c6c 6f202020 01234567 312e312e Hallo .#Eg1.1. 00100010: 3520284d 61722032 31203230 3032202d 5 (Mar 21 2002 - 00100020: 2031393a 35353a30 34290000 00000000 19:55:04)...... 00100030: 00000000 00000000 00000000 00000000 ................ =>
5.9.2.7. mtest - simple RAM test
=> help mtest
mtest [start [end [pattern]]]
- simple RAM read/write test
=>
The mtest provides a simple memory test.
=> mtest 100000 200000 Testing 00100000 ... 00200000: Pattern 0000000F Writing... Reading... =>
This tests writes to memory, thus modifying the memory contents. It will fail when applied to ROM or flash memory.
This command may crash the system when the tested memory range includes areas that are needed for the operation of the U-Boot firnware (like exception vector code, or U-Boot's internal program code, stack or heap memory areas).
5.9.2.8. mw - memory write (fill)
=> help mw
mw [.b, .w, .l] address value [count]
- write memory
=>
The mw is a way to initialize (fill) memory with some value. When called without a count argument, the value will be written only to the specified address. When used with a count, then a whole memory areas will be initialized with this value:
=> md 100000 10 00100000: 0000000f 00000010 00000011 00000012 ................ 00100010: 00000013 00000014 00000015 00000016 ................ 00100020: 00000017 00000018 00000019 0000001a ................ 00100030: 0000001b 0000001c 0000001d 0000001e ................ => mw 100000 aabbccdd => md 100000 10 00100000: aabbccdd 00000010 00000011 00000012 ................ 00100010: 00000013 00000014 00000015 00000016 ................ 00100020: 00000017 00000018 00000019 0000001a ................ 00100030: 0000001b 0000001c 0000001d 0000001e ................ => mw 100000 0 6 => md 100000 10 00100000: 00000000 00000000 00000000 00000000 ................ 00100010: 00000000 00000000 00000015 00000016 ................ 00100020: 00000017 00000018 00000019 0000001a ................ 00100030: 0000001b 0000001c 0000001d 0000001e ................ =>
This is another command that accepts the type extensions .l, .w and .b :
=> mw.w 100004 1155 6 => md 100000 10 00100000: 00000000 11551155 11551155 11551155 .....U.U.U.U.U.U 00100010: 00000000 00000000 00000015 00000016 ................ 00100020: 00000017 00000018 00000019 0000001a ................ 00100030: 0000001b 0000001c 0000001d 0000001e ................ => mw.b 100007 ff 7 => md 100000 10 00100000: 00000000 115511ff ffffffff ffff1155 .....U.........U 00100010: 00000000 00000000 00000015 00000016 ................ 00100020: 00000017 00000018 00000019 0000001a ................ 00100030: 0000001b 0000001c 0000001d 0000001e ................ =>
5.9.2.9. nm - memory modify (constant address)
=> help nm
nm [.b, .w, .l] address
- memory modify, read and keep address
=>
The nm command (non-incrementing memory modify) can be used to interactively write different data several times to the same address. This can be useful for instance to access and modify device registers:
=> nm.b 100000 00100000: 00 ? 48 00100000: 48 ? 61 00100000: 61 ? 6c 00100000: 6c ? 6c 00100000: 6c ? 6f 00100000: 6f ? . => md 100000 8 00100000: 6f000000 115511ff ffffffff ffff1155 o....U.........U 00100010: 00000000 00000000 00000015 00000016 ................ =>
The nm command too accepts the type extensions .l, .w and .b.
5.9.2.10. loop - infinite loop on address range
=> help loop
loop [.b, .w, .l] address number_of_objects
- loop on a set of addresses
=>
The loop command reads in a tight loop from a range of memory. This is intended as a special form of a memory test, since this command tries to read the memory as fast as possible.
This command will never terminate. There is no way to stop it but to reset the board!
=> loop 100000 8
5.9.3. Flash Memory Commands
5.9.3.1. cp - memory copy
=> help cp
cp [.b, .w, .l] source target count
- copy memory
=>
The cp command "knows" about flash memory areas and will automatically invoke the necessary flash programming algorithm when the target area is in flash memory.
=> cp 100000 40000000 10000 Copy to Flash... done =>
Writing to flash memory may fail when the target area has not been erased (see erase below), or if it is write-protected (see protect below).
=> cp 100000 40000000 10000 Copy to Flash... Can't write to protected Flash sectors =>
Remember that the count argument specifies the number of items to copy. If you have a "length" instead (= byte count) you should use cp.b or you will have to calculate the correct number of items.
5.9.3.2. flinfo - print FLASH memory information
The command flinfo (short: fli) can be used to get information about the available flash memory. The number of flash banks is printed with information about the size and organization into flash "sectors" or erase units. For all sectors the start addresses are printed; write-protected sectors are marked as read-only (RO). Some configurations of U-Boot also mark empty sectors with an (E).
=> fli
Bank # 1: FUJITSU AM29LV160B (16 Mbit, bottom boot sect)
Size: 4 MB in 35 Sectors
Sector Start Addresses:
40000000 (RO) 40008000 (RO) 4000C000 (RO) 40010000 (RO) 40020000 (RO)
40040000 40060000 40080000 400A0000 400C0000
400E0000 40100000 40120000 40140000 40160000
40180000 401A0000 401C0000 401E0000 40200000
40220000 40240000 40260000 40280000 402A0000
402C0000 402E0000 40300000 40320000 40340000
40360000 40380000 403A0000 403C0000 403E0000
Bank # 2: FUJITSU AM29LV160B (16 Mbit, bottom boot sect)
Size: 4 MB in 35 Sectors
Sector Start Addresses:
40400000 40408000 4040C000 40410000 40420000
40440000 40460000 40480000 404A0000 404C0000
404E0000 40500000 40520000 40540000 40560000
40580000 405A0000 405C0000 405E0000 40600000
40620000 40640000 40660000 40680000 406A0000
406C0000 406E0000 40700000 40720000 40740000
40760000 40780000 407A0000 407C0000 407E0000
=>
5.9.3.3. erase - erase FLASH memory
=> help era
erase start end
- erase FLASH from addr 'start' to addr 'end'
erase N:SF[-SL]
- erase sectors SF-SL in FLASH bank # N
erase bank N
- erase FLASH bank # N
erase all
- erase all FLASH banks
=>
The erase command (short: era) is used to erase the contents of one or more sectors of the flash memory. It is one of the more complex commands; the help output shows this.
Probably the most frequent usage of this command is to pass the start and end addresses of the area to be erased:
=> era 40040000 402FFFFF Erase Flash from 0x40040000 to 0x402fffff .............. done Erased 22 sectors =>
Note that both the start and end addresses for this command must point exactly at the start resp. end addresses of flash sectors. Otherwise the command will not be executed.
Another way to select certain areas of the flash memory for the erase command uses the notation of flash banks and sectors:
Technically speaking, a bank is an area of memory implemented by one or more memory chips that are connected to the same chip select signal of the CPU, and a flash sector or erase unit is the smallest area that can be erased in one operation.
For practical purposes it is sufficient to remember that with flash memory a bank is something that eventually may be erased as a whole in a single operation. This may be more efficient (faster) than erasing the same area sector by sector.
[It depends on the actual type of flash chips used on the board if such a fast bank erase algorithm exists, and on the implementation of the flash device driver if is actually used.]
In U-Boot, flash banks are numbered starting with 1, while flash sectors start with 0.
To erase the same flash area as specified using start and end addresses in the example above you could also type:
=> era 1:6-8 Erase Flash Sectors 6-8 in Bank # 1 .. done =>
To erase a whole bank of flash memory you can use a command like this one:
Note: Included topic DULGData.tqm8xxlUBootEraseBank does not exist yet
Note that a warning message is printed because some write protected sectors exist in this flash bank which were not erased.
With the command:
=> era all Erase Flash Bank # 1 - Warning: 5 protected sectors will not be erased! ................... done Erase Flash Bank # 2 ......................... done =>
the whole flash memory (except for the write-protected sectors) can be erased.
=> help protect
protect on start end
- protect FLASH from addr 'start' to addr 'end'
protect on N:SF[-SL]
- protect sectors SF-SL in FLASH bank # N
protect on bank N
- protect FLASH bank # N
protect on all
- protect all FLASH banks
protect off start end
- make FLASH from addr 'start' to addr 'end' writable
protect off N:SF[-SL]
- make sectors SF-SL writable in FLASH bank # N
protect off bank N
- make FLASH bank # N writable
protect off all
- make all FLASH banks writable
=>
The protect command is another complex one. It is used to set certain parts of the flash memory to read-only mode or to make them writable again. Flash memory that is "protected" (= read-only) cannot be written (with the cp command) or erased (with the erase command). Protected areas are marked as (RO) (for "read-only") in the output of the flinfo command:
=> fli
Bank # 1: FUJITSU AM29LV160B (16 Mbit, bottom boot sect)
Size: 4 MB in 35 Sectors
Sector Start Addresses:
40000000 (RO) 40008000 (RO) 4000C000 (RO) 40010000 (RO) 40020000 (RO)
40040000 40060000 40080000 400A0000 400C0000
400E0000 40100000 40120000 40140000 40160000
40180000 401A0000 401C0000 401E0000 40200000
40220000 40240000 40260000 40280000 402A0000
402C0000 402E0000 40300000 40320000 40340000
40360000 40380000 403A0000 403C0000 403E0000
Bank # 2: FUJITSU AM29LV160B (16 Mbit, bottom boot sect)
Size: 4 MB in 35 Sectors
Sector Start Addresses:
40400000 40408000 4040C000 40410000 40420000
40440000 40460000 40480000 404A0000 404C0000
404E0000 40500000 40520000 40540000 40560000
40580000 405A0000 405C0000 405E0000 40600000
40620000 40640000 40660000 40680000 406A0000
406C0000 406E0000 40700000 40720000 40740000
40760000 40780000 407A0000 407C0000 407E0000
=> protect on 40100000 401FFFFF
Protected 8 sectors
=> fli
Bank # 1: FUJITSU AM29LV160B (16 Mbit, bottom boot sect)
Size: 4 MB in 35 Sectors
Sector Start Addresses:
40000000 (RO) 40008000 (RO) 4000C000 (RO) 40010000 (RO) 40020000 (RO)
40040000 40060000 40080000 400A0000 400C0000
400E0000 40100000 (RO) 40120000 (RO) 40140000 (RO) 40160000 (RO)
40180000 (RO) 401A0000 (RO) 401C0000 (RO) 401E0000 (RO) 40200000
40220000 40240000 40260000 40280000 402A0000
402C0000 402E0000 40300000 40320000 40340000
40360000 40380000 403A0000 403C0000 403E0000
Bank # 2: FUJITSU AM29LV160B (16 Mbit, bottom boot sect)
Size: 4 MB in 35 Sectors
Sector Start Addresses:
40400000 40408000 4040C000 40410000 40420000
40440000 40460000 40480000 404A0000 404C0000
404E0000 40500000 40520000 40540000 40560000
40580000 405A0000 405C0000 405E0000 40600000
40620000 40640000 40660000 40680000 406A0000
406C0000 406E0000 40700000 40720000 40740000
40760000 40780000 407A0000 407C0000 407E0000
=> era 40100000 401FFFFF
Erase Flash from 0x40100000 to 0x401fffff - Warning: 8 protected sectors will not be erased!
done
Erased 8 sectors
=> protect off 1:11
Un-Protect Flash Sectors 11-11 in Bank # 1
=> fli
Bank # 1: FUJITSU AM29LV160B (16 Mbit, bottom boot sect)
Size: 4 MB in 35 Sectors
Sector Start Addresses:
40000000 (RO) 40008000 (RO) 4000C000 (RO) 40010000 (RO) 40020000 (RO)
40040000 40060000 40080000 400A0000 400C0000
400E0000 40100000 40120000 (RO) 40140000 (RO) 40160000 (RO)
40180000 (RO) 401A0000 (RO) 401C0000 (RO) 401E0000 (RO) 40200000
40220000 40240000 40260000 40280000 402A0000
402C0000 402E0000 40300000 40320000 40340000
40360000 40380000 403A0000 403C0000 403E0000
Bank # 2: FUJITSU AM29LV160B (16 Mbit, bottom boot sect)
Size: 4 MB in 35 Sectors
Sector Start Addresses:
40400000 40408000 4040C000 40410000 40420000
40440000 40460000 40480000 404A0000 404C0000
404E0000 40500000 40520000 40540000 40560000
40580000 405A0000 405C0000 405E0000 40600000
40620000 40640000 40660000 40680000 406A0000
406C0000 406E0000 40700000 40720000 40740000
40760000 40780000 407A0000 407C0000 407E0000
=> era 1:11
Erase Flash Sectors 11-11 in Bank # 1
. done
=>
The actual level of protection depends on the flash chips used on your hardware, and on the implementation of the flash device driver for this board. In most cases U-Boot provides just a simple software-protection, i. e. it prevents you from erasing or overwriting important stuff by accident (like the U-Boot code itself or U-Boot's environment variables), but it cannot prevent you from circumventing these restrictions - a nasty user who is loading and running his own flash driver code cannot and will not be stopped by this mechanism. Also, in most cases this protection is only effective while running U-Boot, i. e. any operating system will not know about "protected" flash areas and will happily erase these if requested to do so.
5.9.3.5. mtdparts - define a Linux compatible MTD partition scheme
U-Boot implements two different approaches to define a MTD partition scheme that can be shared easily with the linux kernel.
The first one is to define a single, static partition in your board config file, for example:
#undef CONFIG_JFFS2_CMDLINE #define CONFIG_JFFS2_DEV "nor0" #define CONFIG_JFFS2_PART_SIZE 0xFFFFFFFF /* use whole device */ #define CONFIG_JFFS2_PART_SIZE 0x00100000 /* use 1MB */ #define CONFIG_JFFS2_PART_OFFSET 0x00000000
The second method uses the Linux kernel's mtdparts command line option and dynamic partitioning:
#define CONFIG_JFFS2_CMDLINE #define MTDIDS_DEFAULT "nor1=zuma-1,nor2=zuma-2" #define MTDPARTS_DEFAULT "mtdparts=zuma-1:-(jffs2),zuma-2:-(user)"
Command line of course produces bigger images, and may be inappropriate for some targets, so by default it's off.
The mtdparts command offers an easy to use and powerful interface to define the contents of the environment variable of the same name that can be passed as boot argument to the Linux kernel:
=> help mtdparts
mtdparts
- list partition table
mtdparts delall
- delete all partitions
mtdparts del part-id
- delete partition (e.g. part-id = nand0,1)
mtdparts add <mtd-dev> <size>[@<offset>] [<name>] [ro]
- add partition
mtdparts default
- reset partition table to defaults
-----
this command uses three environment variables:
'partition' - keeps current partition identifier
partition := <part-id>
<part-id> := <dev-id>,part_num
'mtdids' - linux kernel mtd device id <-> u-boot device id mapping
mtdids=<idmap>[,<idmap>,...]
<idmap> := <dev-id>=<mtd-id>
<dev-id> := 'nand'|'nor'<dev-num>
<dev-num> := mtd device number, 0...
<mtd-id> := unique device tag used by linux kernel to find mtd device (mtd->name)
'mtdparts' - partition list
mtdparts=mtdparts=<mtd-def>[;<mtd-def>...]
<mtd-def> := <mtd-id>:<part-def>[,<part-def>...]
<mtd-id> := unique device tag used by linux kernel to find mtd device (mtd->name)
<part-def> := <size>[@<offset>][<name>][<ro-flag>]
<size> := standard linux memsize OR '-' to denote all remaining space
<offset> := partition start offset within the device
<name> := '(' NAME ')'
<ro-flag> := when set to 'ro' makes partition read-only (not used, passed to kernel)
For example, on some target system the mtdparts command might display this information:
=> mtdparts device nor0 <TQM5200-0>, # parts = 4 #: name size offset mask_flags 0: firmware 0x00100000 0x00000000 1 1: kernel 0x00180000 0x00100000 0 2: small-fs 0x00d80000 0x00280000 0 3: big-fs 0x01000000 0x01000000 0 active partition: nor0,0 - (firmware) 0x00100000 @ 0x00000000 defaults: mtdids : nor0=TQM5200-0 mtdparts: mtdparts=TQM5200-0:1m(firmware),1536k(kernel),3584k(small-fs),2m(initrd),8m(misc),16m(big-fs)
The partition table printed here obviously differs from the default value for the mtdparts variable printed in the last line. To verify this, we can check the current content of this variable:
=> print mtdparts mtdparts=mtdparts=TQM5200-0:1024k(firmware)ro,1536k(kernel),13824k(small-fs),16m(big-fs)
and we can see that it exactly matches the partition table printed above.
Now let's switch back to the default settings:
=> mtdparts default => mtdparts device nor0 <TQM5200-0>, # parts = 6 #: name size offset mask_flags 0: firmware 0x00100000 0x00000000 0 1: kernel 0x00180000 0x00100000 0 2: small-fs 0x00380000 0x00280000 0 3: initrd 0x00200000 0x00600000 0 4: misc 0x00800000 0x00800000 0 5: big-fs 0x01000000 0x01000000 0 active partition: nor0,0 - (firmware) 0x00100000 @ 0x00000000 defaults: mtdids : nor0=TQM5200-0 mtdparts: mtdparts=TQM5200-0:1m(firmware),1536k(kernel),3584k(small-fs),2m(initrd),8m(misc),16m(big-fs) => print mtdparts mtdparts=mtdparts=TQM5200-0:1m(firmware),1536k(kernel),3584k(small-fs),2m(initrd),8m(misc),16m(big-fs)
Then we delete the last 4 partitions ("small-fs", "initrd", "misc" and "big-fs") ...
=> mtdparts del small-fs => mtdparts del initrd => mtdparts del misc => mtdparts del big-fs => mtdparts device nor0 <TQM5200-0>, # parts = 2 #: name size offset mask_flags 0: firmware 0x00100000 0x00000000 0 1: kernel 0x00180000 0x00100000 0 active partition: nor0,0 - (firmware) 0x00100000 @ 0x00000000 defaults: mtdids : nor0=TQM5200-0 mtdparts: mtdparts=TQM5200-0:1m(firmware),1536k(kernel),3584k(small-fs),2m(initrd),8m(misc),16m(big-fs)
... and combine the free space into a singe big partition:
=> mtdparts add nor0 - new-part => mtdparts device nor0 <TQM5200-0>, # parts = 3 #: name size offset mask_flags 0: firmware 0x00100000 0x00000000 0 1: kernel 0x00180000 0x00100000 0 2: new-part 0x01d80000 0x00280000 0 active partition: nor0,0 - (firmware) 0x00100000 @ 0x00000000 defaults: mtdids : nor0=TQM5200-0 mtdparts: mtdparts=TQM5200-0:1m(firmware),1536k(kernel),3584k(small-fs),2m(initrd),8m(misc),16m(big-fs) => print mtdparts mtdparts=mtdparts=TQM5200-0:1m(firmware),1536k(kernel),30208k(new-part)
5.9.4. Execution Control Commands
5.9.4.1. autoscr - run script from memory
=> help autoscr autoscr [addr] - run script starting at addr. A valid autoscr header must be present =>
With the autoscr command you can run "shell" scripts under U-Boot: You create a U-Boot script image by simply writing the commands you want to run into a text file; then you will have to use the mkimage tool to convert this text file into a U-Boot image (using the image type script).
This image can be loaded like any other image file, and with autoscr you can run the commands in such an image. For instance, the following text file:
echo echo Network Configuration: echo ---------------------- echo Target: printenv ipaddr hostname echo echo Server: printenv serverip rootpath echo
can be converted into a U-Boot script image using the mkimage command like this:
bash$ mkimage -A ppc -O linux -T script -C none -a 0 -e 0 \ > -n "autoscr example script" \ > -d /tftpboot/TQM860L/example.script /tftpboot/TQM860L/example.img Image Name: autoscr example script Created: Mon Apr 8 01:15:02 2002 Image Type: PowerPC Linux Script (uncompressed) Data Size: 157 Bytes = 0.15 kB = 0.00 MB Load Address: 0x00000000 Entry Point: 0x00000000 Contents: Image 0: 149 Bytes = 0 kB = 0 MB
Now you can load and execute this script image in U-Boot:
=> tftp 100000 /tftpboot/TQM860L/example.img ARP broadcast 1 TFTP from server 10.0.0.2; our IP address is 10.0.0.99 Filename '/tftpboot/TQM860L/example.img'. Load address: 0x100000 Loading: # done Bytes transferred = 221 (dd hex) => autoscr 100000 ## Executing script at 00100000 Network Configuration: ---------------------- Target: ipaddr=10.0.0.99 hostname=tqm Server: serverip=10.0.0.2 rootpath=/opt/hardhat/devkit/ppc/8xx/target =>
5.9.4.2. bootm - boot application image from memory
=> help bootm
bootm [addr [arg ...]]
- boot application image stored in memory
passing arguments 'arg ...'; when booting a Linux kernel,
'arg' can be the address of an initrd image
=>
The bootm command is used to start operating system images. From the image header it gets information about the type of the operating system, the file compression method used (if any), the load and entry point addresses, etc. The command will then load the image to the required memory address, uncompressing it on the fly if necessary. Depending on the OS it will pass the required boot arguments and start the OS at it's entry point.
The first argument to bootm is the memory address (in RAM, ROM or flash memory) where the image is stored, followed by optional arguments that depend on the OS.
For Linux, exactly one optional argument can be passed. If it is present, it is interpreted as the start address of a initrd ramdisk image (in RAM, ROM or flash memory). In this case the bootm command consists of three steps: first the Linux kernel image is uncompressed and copied into RAM, then the ramdisk image is loaded to RAM, and finally controll is passed to the Linux kernel, passing information about the location and size of the ramdisk image.
To boot a Linux kernel image without a initrd ramdisk image, the following command can be used:
=> bootm ${kernel_addr}
If a ramdisk image shall be used, you can type:
=> bootm ${kernel_addr} ${ramdisk_addr}
Both examples of course imply that the variables used are set to correct addresses for a kernel and a initrd ramdisk image.
When booting images that have been loaded to RAM (for instance using TFTP download) you have to be careful that the locations where the (compressed) images were stored do not overlap with the memory needed to load the uncompressed kernel. For instance, if you load a ramdisk image at a location in low memory, it may be overwritten when the Linux kernel gets loaded. This will cause undefined system crashes.
5.9.4.3. go - start application at address 'addr'
=> help go
go addr [arg ...]
- start application at address 'addr'
passing 'arg' as arguments
=>
U-Boot has support for so-called standalone applications. These are programs that do not require the complex environment of an operating system to run. Instead they can be loaded and executed by U-Boot directly, utilizing U-Boot's service functions like console I/O or malloc() and free().
This can be used to dynamically load and run special extensions to U-Boot like special hardware test routines or bootstrap code to load an OS image from some filesystem.
The go command is used to start such standalone applications. The optional arguments are passed to the application without modification. For more informatoin see 5.12. U-Boot Standalone Applications.
5.9.5. Download Commands
5.9.5.1. bootp - boot image via network using BOOTP/TFTP protocol
=> help bootp bootp [loadAddress] [bootfilename] =>
5.9.5.2. dhcp - invoke DHCP client to obtain IP/boot params
=> help dhcp dhcp =>
5.9.5.3. loadb - load binary file over serial line (kermit mode)
=> help loadb
loadb [ off ] [ baud ]
- load binary file over serial line with offset 'off' and baudrate 'baud'
=>
With kermit you can download binary data via the serial line. Here we show how to download uImage, the Linux kernel image. Please make sure, that you have set up kermit as described in section 4.3. Configuring the "kermit" command and then type:
=> loadb 100000 ## Ready for binary (kermit) download ... Ctrl-\c (Back at denx.denx.de) ---------------------------------------------------- C-Kermit 7.0.197, 8 Feb 2000, for Linux Copyright (C) 1985, 2000, Trustees of Columbia University in the City of New York. Type ? or HELP for help. Kermit> send /bin /tftpboot/pImage ... Kermit> connect Connecting to /dev/ttyS0, speed 115200. The escape character is Ctrl-\ (ASCII 28, FS) Type the escape character followed by C to get back, or followed by ? to see other options. ---------------------------------------------------- = 550260 Bytes ## Start Addr = 0x00100000 => iminfo 100000 ## Checking Image at 00100000 ... Image Name: Linux-2.4.4 Created: 2002-07-02 22:10:11 UTC Image Type: PowerPC Linux Kernel Image (gzip compressed) Data Size: 550196 Bytes = 537 kB = 0 MB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK
5.9.5.4. loads - load S-Record file over serial line
=> help loads
loads [ off ]
- load S-Record file over serial line with offset 'off'
=>
5.9.5.5. rarpboot- boot image via network using RARP/TFTP protocol
=> help rarp rarpboot [loadAddress] [bootfilename] =>
5.9.5.6. tftpboot- boot image via network using TFTP protocol
=> help tftp tftpboot [loadAddress] [bootfilename] =>
5.9.6. Environment Variables Commands
5.9.6.1. printenv- print environment variables
=> help printenv
printenv
- print values of all environment variables
printenv name ...
- print value of environment variable 'name'
=>
The printenv command prints one, several or all variables of the U-Boot environment. When arguments are given, these are interpreted as the names of environment variables which will be printed with their values:
=> printenv ipaddr hostname netmask ipaddr=10.0.0.99 hostname=tqm netmask=255.0.0.0 =>
Without arguments, printenv prints all a list with all variables in the environment and their values, plus some statistics about the current usage and the total size of the memory available for the environment.
=> printenv
baudrate=115200
serial#=TQM860LDDBA3-P50.203 10226122 4
ethaddr=00:D0:93:00:28:81
bootdelay=5
loads_echo=1
clocks_in_mhz=1
load=tftp 100000 /tftpboot/ppcboot.bin
update=protect off all;era 1:0-4;cp.b 100000 40000000 ${filesize};setenv filesize;saveenv
rtai=tftp 100000 /tftpboot/pImage.rtai;run nfsargs;run addip;bootm
preboot=echo;echo Type "run flash_nfs" to mount root filesystem over NFS;echo
nfsargs=setenv bootargs root=/dev/nfs rw nfsroot=${serverip}:${rootpath}
addip=setenv bootargs ${bootargs} ip=${ipaddr}:${serverip}:${gatewayip}:${netmask}:${hostname}:${netdev}:off panic=1
flash_nfs=run nfsargs;run addip;bootm ${kernel_addr}
kernel_addr=40040000
netdev=eth0
hostname=tqm
rootpath=/opt/hardhat/devkit/ppc/8xx/target
ramargs=setenv bootargs root=/dev/ram rw
flash_self=run ramargs;run addip;bootm ${kernel_addr} ${ramdisk_addr}
ramdisk_addr=40100000
bootcmd=run flash_self
stdin=serial
stderr=serial
stdout=serial
filesize=dd
netmask=255.0.0.0
ipaddr=10.0.0.99
serverip=10.0.0.2
Environment size: 992/16380 bytes
=>
5.9.6.2. saveenv - save environment variables to persistent storage
=> help saveenv saveenv - No help available. =>
All changes you make to the U-Boot environment are made in RAM only. They are lost as soon as you reboot the system. If you want to make your changes permanent you have to use the saveenv command to write a copy of the environment settings to persistent storage, from where they are automatically loaded during startup:
=> saveenv Saving Enviroment to Flash... Un-Protected 1 sectors Erasing Flash... . done Erased 1 sectors Writing to Flash... done Protected 1 sectors =>
5.9.6.3. setenv - set environment variables
=> help setenv
setenv name value ...
- set environment variable 'name' to 'value ...'
setenv name
- delete environment variable 'name'
=>
To modify the U-Boot environment you have to use the setenv command. When called with exactly one argument, it will delete any variable of that name from U-Boot's environment, if such a variable exists. Any storage occupied for such a variable will be automatically reclaimed:
=> printenv foo foo=This is an example value. => setenv foo => printenv foo ## Error: "foo" not defined =>
When called with more arguments, the first one will again be the name of the variable, and all following arguments will (concatenated by single space characters) form the value that gets stored for this variable. New variables will be automatically created, existing ones overwritten.
=> printenv bar ## Error: "bar" not defined => setenv bar This is a new example. => printenv bar bar=This is a new example. =>
Remember standard shell quoting rules when the value of a variable shall contain characters that have a special meaning to the command line parser (like the $ character that is used for variable substitution or the semicolon which separates commands). Use the backslash (\) character to escape such special characters, or enclose the whole phrase in apstrophes ('). Use "${name}" for variable expansion (see 14.2.11. How the Command Line Parsing Works for details).
=> setenv cons_opts console=tty0 console=ttyS0,\${baudrate}
=> printenv cons_opts
cons_opts=console=tty0 console=ttyS0,${baudrate}
=>
There is no restriction on the characters that can be used in a variable name except the restrictions imposed by the command line parser (like using backslash for quoting, space and tab characters to separate arguments, or semicolon and newline to separate commands). Even strange input like "=-/|()+=" is a perfectly legal variable name in U-Boot.
A common mistake is to write
setenv name=value
instead of
setenv name value
There will be no error message, which lets you believe everything went OK, but it didn't: instead of setting the variable name to the value value you tried to delete a variable with the name name=value - this is probably not what you intended! Always remember that name and value have to be separated by space and/or tab characters!
5.9.6.4. run - run commands in an environment variable
=> help run
run var [...]
- run the commands in the environment variable(s) 'var'
=>
You can use U-Boot environment variables to store commands and even sequences of commands. To execute such a command, you use the run command:
=> setenv test echo This is a test\;printenv ipaddr\;echo Done.
=> printenv test
test=echo This is a test;printenv ipaddr;echo Done.
=> run test
This is a test
ipaddr=10.0.0.99
Done.
=>
You can call run with several variables as arguments, in which case these commands will be executed in sequence:
=> setenv test2 echo This is another Test\;printenv serial#\;echo Done. => printenv test test2 test=echo This is a test;printenv ipaddr;echo Done. test2=echo This is another Test;printenv serial#;echo Done. => run test test2 This is a test ipaddr=10.0.0.99 Done. This is another Test serial#=TQM860LDDBA3-P50.203 10226122 4 Done. =>
If a U-Boot variable contains several commands (separated by semicolon), and one of these commands fails when you "run" this variable, the remaining commands will be executed anyway.
If you execute several variables with one call to run, any failing command will cause "run" to terminate, i. e. the remaining variables are not executed.
5.9.6.5. bootd - boot default, i.e., run 'bootcmd'
=> help boot bootd - No help available. =>
The bootd (short: boot) executes the default boot command, i. e. what happens when you don't interrupt the initial countdown. This is a synonym for the run bootcmd command.
5.9.7. Special Commands
5.9.7.1. i2c - I2C sub-system
=> help i2c Unknown command 'i2c' - try 'help' without arguments for list of all known commands =>
5.9.7.2. ide - IDE sub-system
=> help ide
ide reset - reset IDE controller
ide info - show available IDE devices
ide device [dev] - show or set current device
ide part [dev] - print partition table of one or all IDE devices
ide read addr blk# cnt
ide write addr blk# cnt - read/write `cnt' blocks starting at block `blk#'
to/from memory address `addr'
=>
5.9.7.3. diskboot- boot from IDE device
=> help disk diskboot loadAddr dev:part =>
5.9.8. Miscellaneous Commands
5.9.8.1. date - get/set/reset date & time
=> help date date [MMDDhhmm[[CC]YY][.ss]] date reset - without arguments: print date & time - with numeric argument: set the system date & time - with 'reset' argument: reset the RTC =>
The date command is used to display the current time in a standard format, or to set the system date. On some systems it can also be used to reset (initialize) the system clock:
=> date Date: 1970-01-01 (Thursday) Time: 0:-1:-18 => date 040723152002.35 Date: 2002-04-07 (Sunday) Time: 23:15:35 => date reset Reset RTC... Date: 2002-04-07 (Sunday) Time: 23:15:36 =>
5.9.8.2. echo - echo args to console
=> help echo
echo [args..]
- echo args to console; \c suppresses newline
=>
The echo command echoes the arguments to the console:
=> echo The quick brown fox jumped over the lazy dog. The quick brown fox jumped over the lazy dog. =>
5.9.8.3. reset - Perform RESET of the CPU
=> help reset reset - No help available. =>
The reset command reboots the system.
*** MISSING ***
5.9.8.4. sleep - delay execution for some time
=> help sleep
sleep N
- delay execution for N seconds (N is _decimal_ !!!)
=>
The sleep command pauses execution for the number of seconds given as the argument:
=> date ; sleep 5 ; date Date: 2002-04-07 (Sunday) Time: 23:15:40 Date: 2002-04-07 (Sunday) Time: 23:15:45 =>
5.9.8.5. version - print monitor version
=> help version version - No help available. =>
You can print the version and build date of the U-Boot image running on your system using the version command (short: vers):
=> version PPCBoot 1.1.5 (Mar 21 2002 - 19:55:04) =>
5.9.8.6. ? - alias for 'help'
You can use ? as a short form for the help command (see description above).
5.10. U-Boot Environment Variables
The U-Boot environment is a block of memory that is kept on persistent storage and copied to RAM 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.
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'), therarpb,bootpordhcpcommands 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 therarpb,bootp,dhcp,tftp,disk, ordocbcommands will be automatically started (by internally calling thebootmcommand).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 tosaveenvthe 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 variablebootdelayis also defined!bootdelay: After reset, U-Boot will wait this number of seconds before it executes the contents of thebootcmdvariable. During this time a countdown is printed, which can be interrupted by pressing any key.
Set this variable to0boot without delay. Be careful: depending on the contents of yourbootcmdvariable, this can prevent you from entering interactive commands again forever!
Set this variable to-1to disable autoboot.bootfile: name of the default image to load with TFTPcpuclk: (Only with MPC859 / MPC866 / MPC885 processors) On some processors, the CPU clock frequency can be adjusted by the user (for example to optimize performance versus power dissipation). On such systems thecpuclkvariable can be set to the desired CPU clock value, in MHz. If thecpuclkvariable exists and its value is within the compile-time defined limits (CFG_866_CPUCLK_MINandCFG_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 (=eth0in 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 (=eth1in Linux).eth2addr: Ethernet MAC address for third ethernet interface (=eth2in 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 fortftpcommandloadaddr: Default load address for commands liketftporloads.loads_echo: If set to 1, all characters received during a serial download (using theloadscommand) are echoed back. This might be needed by some terminal emulations (likecu), but may as well just take time on others.mtdparts: This variable (usually defined using the mtdparts command) allows to share a common MTD partition scheme between U-Boot and the Linux kernel.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.
serverip: TFTP server IP address; needed fortftpcommand.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 optionCONFIG_SILENT_CONSOLEhas been enabled for your board, setting this variable to any value will suppress all console messages. Please seedoc/README.silentfor details.verify: If set tonornodisables the checksum calculation over the complete image in thebootmcommand 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 abovednsip: IP address of your Domain Name Servergatewayip: IP address of the Gateway (Router) to usehostname: Target hostnameipaddr: see abovenetmask: Subnet Maskrootpath: Pathname of the root filesystem on the NFS serverserverip: see abovefilesize: Size (as hex number in bytes) of the file downloaded using the lastbootp,dhcp, ortftpcommand.
5.11. U-Boot Scripting Capabilities
U-Boot 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.
For example, assume that you will have to run the following sequence of commands on many boards, so you store them in a text file, say "setenv-commands":
bash$ cat setenv-commands
setenv loadaddr 00200000
echo ===== U-Boot settings =====
setenv u-boot /tftpboot/TQM860L/u-boot.bin
setenv u-boot_addr 40000000
setenv load_u-boot 'tftp ${loadaddr} ${u-boot}'
setenv install_u-boot 'protect off ${u-boot_addr} +${filesize};era ${u-boot_addr} +${filesize};cp.b ${loadaddr} ${u-boot_addr} ${filesize};saveenv'
setenv update_u-boot run load_u-boot install_u-boot
echo ===== Linux Kernel settings =====
setenv bootfile /tftpboot/TQM860L/uImage
setenv kernel_addr 40040000
setenv load_kernel 'tftp ${loadaddr} ${bootfile};'
setenv install_kernel 'era ${kernel_addr} +${filesize};cp.b ${loadaddr} ${kernel_addr} ${filesize}'
setenv update_kernel run load_kernel install_kernel
echo ===== Ramdisk settings =====
setenv ramdisk /tftpboot/TQM860L/uRamdisk
setenv ramdisk_addr 40100000
setenv load_ramdisk 'tftp ${loadaddr} ${ramdisk};'
setenv install_ramdisk 'era ${ramdisk_addr} +${filesize};cp.b ${loadaddr} ${ramdisk_addr} ${filesize}'
setenv update_ramdisk run load_ramdisk install_ramdisk
echo ===== Save new definitions =====
saveenv
bash$
To convert the text file into a script image for U-Boot, you have to use the mkimage tool as follows:
bash$ mkimage -T script -C none -n 'Demo Script File' -d setenv-commands setenv.img Image Name: Demo Script File Created: Mon Jun 6 13:33:14 2005 Image Type: PowerPC Linux Script (uncompressed) Data Size: 1147 Bytes = 1.12 kB = 0.00 MB Load Address: 0x00000000 Entry Point: 0x00000000 Contents: Image 0: 1139 Bytes = 1 kB = 0 MB bash$
On the target, you can download this image as usual (for example, using the "tftp" command). Use the "autoscr" command to execute it:
=> tftp 100000 /tftpboot/TQM860L/setenv.img Using FEC ETHERNET device TFTP from server 192.168.3.1; our IP address is 192.168.3.80 Filename '/tftpboot/TQM860L/setenv.img'. Load address: 0x100000 Loading: # done Bytes transferred = 1211 (4bb hex) => imi 100000 ## Checking Image at 00100000 ... Image Name: Demo Script File Created: 2005-06-06 11:33:14 UTC Image Type: PowerPC Linux Script (uncompressed) Data Size: 1147 Bytes = 1.1 kB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK => autoscr 100000 ## Executing script at 00100000 ===== U-Boot settings ===== ===== Linux Kernel settings ===== ===== Ramdisk settings ===== ===== Save new definitions ===== Saving Environment to Flash... Un-Protected 1 sectors Un-Protected 1 sectors Erasing Flash... . done Erased 1 sectors Writing to Flash... done Protected 1 sectors Protected 1 sectors =>
Hint: maximum flexibility can be achieved if you are using the Hush shell as command interpreter in U-Boot; see section 14.2.11. How the Command Line Parsing Works
5.12. U-Boot Standalone Applications
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.
A couple of simple examples are included with the U-Boot source code:
5.12.1. "Hello World" Demo
examples/hello_world.c contains a small "Hello World" Demo application; it is automatically compiled when you build U-Boot. It's configured to run at address 0x00040004, so you can play with it like that:
=> loads ## Ready for S-Record download ... ~>examples/hello_world.srec 1 2 3 4 5 6 7 8 9 10 11 ... [file transfer complete] [connected] ## Start Addr = 0x00040004 => go 40004 Hello World! This is a test. ## Starting application at 0x00040004 ... Hello World argc = 7 argv[0] = "40004" argv[1] = "Hello" argv[2] = "World!" argv[3] = "This" argv[4] = "is" argv[5] = "a" argv[6] = "test." argv[7] = "" Hit any key to exit ... ## Application terminated, rc = 0x0
Alternatively, you can of course use TFTP to download the image over the network. In this case the binary image (hello_world.bin) is used.
Note that the entry point of the program is at offset 0x0004 from the start of file, i. e. the download address and the entry point address differ by four bytes.
=> tftp 40000 /tftpboot/hello_world.bin ... => go 40004 This is another test. ## Starting application at 0x00040004 ... Hello World argc = 5 argv[0] = "40004" argv[1] = "This" argv[2] = "is" argv[3] = "another" argv[4] = "test." argv[5] = "" Hit any key to exit ... ## Application terminated, rc = 0x0
5.12.2. Timer Demo
This example is only available on MPC8xx CPUs.
This example, which demonstrates how to register a CPM interrupt handler with the U-Boot code, can be found in examples/timer.c. Here, a CPM timer is set up to generate an interrupt every second. The interrupt service routine is trivial, just printing a '.' character, but this is just a demo program. The application can be controlled by the following keys:
? - print current values og the CPM Timer registers
b - enable interrupts and start timer
e - stop timer and disable interrupts
q - quit application
=> loads
## Ready for S-Record download ...
~>examples/timer.srec
1 2 3 4 5 6 7 8 9 10 11 ...
[file transfer complete]
[connected]
## Start Addr = 0x00040004
=> go 40004
## Starting application at 0x00040004 ...
TIMERS=0xfff00980
Using timer 1
tgcr @ 0xfff00980, tmr @ 0xfff00990, trr @ 0xfff00994, tcr @ 0xfff00998, tcn @ 0xfff0099c, ter @ 0xfff009b0
Hit 'b':
[q, b, e, ?] Set interval 1000000 us
Enabling timer
Hit '?':
[q, b, e, ?] ........
tgcr=0x1, tmr=0xff1c, trr=0x3d09, tcr=0x0, tcn=0xef6, ter=0x0
Hit '?':
[q, b, e, ?] .
tgcr=0x1, tmr=0xff1c, trr=0x3d09, tcr=0x0, tcn=0x2ad4, ter=0x0
Hit '?':
[q, b, e, ?] .
tgcr=0x1, tmr=0xff1c, trr=0x3d09, tcr=0x0, tcn=0x1efc, ter=0x0
Hit '?':
[q, b, e, ?] .
tgcr=0x1, tmr=0xff1c, trr=0x3d09, tcr=0x0, tcn=0x169d, ter=0x0
Hit 'e':
[q, b, e, ?] ...Stopping timer
Hit 'q':
[q, b, e, ?] ## Application terminated, rc = 0x0
5.13. U-Boot Image Formats
U-Boot operates on "image" files which can be basically anything, preceeded by a special header; see the definitions in include/image.h for details; basically, the header defines the following image properties:
- Target Operating System (Provisions for OpenBSD, NetBSD, FreeBSD, 4.4BSD, Linux, SVR4, Esix, Solaris, Irix, SCO, Dell, NCR, LynxOS, pSOS, QNX, RTEMS, ARTOS, Unity OS; Currently supported: Linux, NetBSD, VxWorks, QNX, RTEMS, ARTOS, Unity OS).
- Target CPU Architecture (Provisions for Alpha, ARM, Intel x86, IA64, MIPS, MIPS, PowerPC, IBM S390, SuperH, Sparc, Sparc 64 Bit, M68K, NIOS; Currently supported: ARM, PowerPC, MIPS, MIPS64, M68K, NIOS).
- Compression Type (Provisions for uncompressed, gzip, bzip2; Currently supported: uncompressed, gzip, bzip2).
- Load Address
- Entry Point
- Image Name
- Image Timestamp
The header is marked by a special Magic Number, and both the header and the data portions of the image are secured against corruption by CRC32 checksums.
5.14. U-Boot Advanced Features
5.14.1. Boot Count Limit
The Open Source Development Labs Carrier Grade Linux Requirements Definition version 2.0 (http://www.osdl.org/docs/carrier_grade_linux_requirements_definition___version_20_final_public_draft.pdf) contains the following requirement definition (ID PLT.4.0, p. 44):
CGL shall provide support for detecting a repeating reboot cycle due to recurring failures and will go to an offline state if this occurs.
This feature is available in U-Boot if you enable the CONFIG_BOOTCOUNT_LIMIT configuration option. The implementation uses the following environment variables:
- bootcount:
- This variable will be automatically created if it does not exist, and it will be updated at each reset of the processor. After a power-on reset, it will be initialized with 1, and each reboot will increment the value by 1.
- bootlimit:
- If this variable exists, its contents are taken as the maximum number of reboot cycles allowed.
- altbootcmd:
- If, after a reboot, the new value of
bootcountexceeds the value ofbootlimit, then instead of the standard boot action (executing the contents ofbootcmd) an alternate boot action will be performed, and the contents ofaltbootcmdwill be executed.
If the variable bootlimit is not defined in the environment, the Boot Count Limit feature is disabled. If it is enabled, but altbootcmd is not defined, then U-Boot will drop into interactive mode and remain there.
It is the responsibility of some application code (typically a Linux application) to reset the variable bootcount, thus allowing for more boot cycles.
At the moment, the Boot Count Limit feature is available only for MPC8xx and MPC82xx PowerPC processors.
5.14.2. Bitmap Support
By adding the CFG_CMD_BMP option to your CONFIG_COMMANDS command selections you can enable support for bitmap images in U-Boot. This will add bmp to the list of commands in your configuration of U-Boot:
=> help bmp bmp info <imageAddr> - display image info bmp display <imageAddr> - display image
This command can be used to show information about bitmap images or to display the images on your screen.
- Example:
-
=> tftp 100000 /tftpboot/LWMON/denk_startup.bmp TFTP from server 192.168.3.1; our IP address is 192.168.3.74 Filename '/tftpboot/LWMON/denk_startup.bmp'. Load address: 0x100000 Loading: ############################################################# done Bytes transferred = 308278 (4b436 hex) => bmp info 100000 Image size : 640 x 480 Bits per pixel: 8 Compression : 0 => bmp display 100000
To keep the code in U-Boot simple and as fast as possible, the bitmap images must match the color depth of your framebuffer device. For example, if your display is configured for a color depth of 8 bpp (bit per pixel) then the bmp command will complain if you try to load images with a different color depth:
=> tftp 100000 /tftpboot/LWMON/Bergkirchen.bmp
TFTP from server 192.168.3.1; our IP address is 192.168.3.74
Filename '/tftpboot/LWMON/Bergkirchen.bmp'.
Load address: 0x100000
Loading: #################################################################
#################################################################
###################################################
done
Bytes transferred = 921654 (e1036 hex)
=> bmp i 100000
Image size : 640 x 480
Bits per pixel: 24
Compression : 0
=> bmp d 100000
Error: 8 bit/pixel mode, but BMP has 24 bit/pixel
(As you can see above, the sub-commands "info" and "display" can be abbreviated as "i" resp. "d" .)
Images that are bigger than your framebuffer device will be clipped on the top and right hand side.
Images that are smaller than the display will be loaded into the top left corner.
Since loading an image will define a new color map, the remainder of the display will appear with incorrect colors. It is therefore recommended that all images match exactly the size of the current display device. We accepted these restrictions since speed was top priority, and all attempts to implement scaling or optimizing the color maps would slow down the display too much. It is much easier to perform the necessary transformations on the development host, where a plethora of tools is available.
For example, to convert existing images to bitmap files with the required color depth (here: 8 bpp), the "PBM" -Tools can be used (PBM = portable pix map - see "man 5 ppm" ):
bash$ jpegtopnm Bergkirchen.jpg | \ > ppmquant 256 | \ > ppmtobmp -bpp 8 >Bergkirchen-8bit.bmp jpegtopnm: WRITING PPM FILE ppmquant: making histogram... ppmquant: too many colors! ppmquant: scaling colors from maxval=255 to maxval=127 to improve clustering... ppmquant: making histogram... ppmquant: too many colors! ppmquant: scaling colors from maxval=127 to maxval=63 to improve clustering... ppmquant: making histogram... ppmquant: 9760 colors found ppmquant: choosing 256 colors... ppmquant: mapping image to new colors... ppmtobmp: analyzing colors... ppmtobmp: 231 colors found ppmtobmp: Writing 8 bits per pixel with a color pallette
This gives the following results on the target:
=> tftp 100000 /tftpboot/LWMON/Bergkirchen-8bit.bmp TFTP from server 192.168.3.1; our IP address is 192.168.3.74 Filename '/tftpboot/LWMON/Bergkirchen-8bit.bmp'. Load address: 0x100000 Loading: ############################################################# done Bytes transferred = 308278 (4b436 hex) => bmp i 100000 Image size : 640 x 480 Bits per pixel: 8 Compression : 0 => bmp d 100000
5.14.3. Splash Screen Support
Even if you manage to boot U-Boot and Linux into a graphical user application within 5 or 6 seconds of power-on (which is not difficult), many customers expect to see "something" immediately. U-Boot supports the concept of a splash screen for such purposes.
To enable splash screen support, you have to add a "#define CONFIG_SPLASH_SCREEN" to your board configuration file. This will also implicitly enable U-Boot Bitmap Support.
After power-on, U-Boot will test if the environment variable "splashimage" is defined, and if it contains the address of a valid bitmap image. If this is the case, the normal startup messages will be suppressed and the defined splash screen will be displayed instead. Also, all output (devices stdout and stderr ) will be suppressed (redirected to the "nulldev" device).
For example, to install this feature on a system, proceed as follows:
=> tftp 100000 /tftpboot/denx_startup.bmp TFTP from server 192.168.3.1; our IP address is 192.168.3.74 Filename '/tftpboot/denx_startup.bmp'. Load address: 0x100000 Loading: ############################################################# done Bytes transferred = 308278 (4b436 hex) => cp.b 100000 41F80000 $filesize Copy to Flash... done => setenv splashimage 41F80000 => saveenv Saving Environment to Flash... Un-Protected 1 sectors Erasing Flash... . done Erased 1 sectors Writing to Flash... done Protected 1 sectors => bmp info $splashimage Image size : 640 x 480 Bits per pixel: 8 Compression : 0
Note that, for perfect operation, this option has to be complemented by matching Splash Screen Support in Linux.
留言列表
生活集錦 (3)