ADS U-boot User's Manual

ADS document # 110010-40011

Applied Data Systems
www.applieddata.net

10260 Old Columbia Road

Columbia MD, 21046 USA
301-490-4007

c 2005 ADS

August 11, 2005

ADS U-boot Bootloader Manual

ADS U-boot Bootloader Manual

1. Overview
This document is the bootloader user manual for ADS single board computers that run the U-boot bootloader.
These boards use U-boot to boot and run the Linux operating system. If your ADS board does not run Uboot, please see the manual for your supported bootloader (either the XScale/PXA or SA1110 bootloader).
U-boot is an open-source, multi-platform bootloader, with ports for many dierent embedded platforms. Uboot supports interactive commands, environment variables, command scripting, and booting from external
media (PCMCIA/CF, MMC). You can nd more information about U-boot and download its source code
from U-boot's Sourceforge home page at http://u-boot.sourceforge.net/
This is not an exhaustive manual for U-boot. If you are looking for a detailed reference manual or command
index, you should consult the main U-boot manual 1 at http://www.denx.de/twiki/bin/view/DULG/Manual.
To get started, you will need a serial terminal program to view the output of U-boot. By default, U-boot
sends it's output the the \debug" port on your board. The manual for your board should indicate which
serial port is the debug port. Windows usually comes with a serial terminal program called \HyperTerminal";
many Linux distributions ship with either the minicom or the kermit serial terminal program installed. ADS
U-boot uses a baud rate of 38400, 8 data bits and no stop bits.

2. Booting Linux on ADS boards with U-boot

This section presents some examples for booting various types of root lesystems on your ADS board. U-boot
uses external media, such as compact ash or MMC cards, to load Linux images (kernels, ramdisks, etc.)
into either RAM or on-board ash. External media must be formatted with a FAT12 or FAT16 lesystem to
be used with U-boot. Compact ash cards can be used either in a compact ash slot or in a PCMCIA slot,
with a CF-to-PCMCIA adapter. 2
Note:

Most CF/MMC cards come formatted with supported FAT lesystems, so if you have a new
card, try it before you re-format it. The FAT requirement is only for U-boot; there are many
formats that work ne once Linux is running.

2.1 The ADS U-boot boot scripts

When booting from external media (CF or MMC card), you will need to place several U-boot scripts on your
card to control the behavior of U-boot. The scripts ADS provides split U-boot's conguration into smaller
sections, making it easier to control how your board boots.
1 The DULG manual is targeted
2 If your board is equipped with

at a specic PowerPC board, but the majority of the document also applies to other boards
both a PCMCIA and a CF slot, only the PCMCIA slot (slot 0) can be used with U-boot

ADS document #110010-40011, August 11, 2005

Page 1

ADS U-boot Bootloader Manual

 start.txt

The main script which U-boot loads and runs when booting from external media.
 root cong.txt

This le controls the type and location of the kernel and root lesystem. Examples of root lesystems
include ext2 ramdisks loaded from external media, JFFS2 lesystems programmed into on-board ash
and ext3 lesystems stored on a Microdrive or USB hard drive.
This le also controls whether a kernel and root lesystem will be booted directly from external media
or programmed into on-board ash.
 hw cong.txt

Congures machine-specic hardware registers (e.g., for framebuer bit depth).
This le is optional and is only required if you need to change the default register settings.
 tty cong.txt

Congures the console, serial TTYs and baud rate.

This le is optional and is only required if you need to change the default serial login or console settings.
If you wish to modify the booting behavior of U-boot, other than simply altering tty or root settings, you
should consider changing the value of the 'bootcmd' environment variable or editing the start.txt le to meet
your needs. Consult the main U-boot manual for the commands and syntax used by U-boot.
Under most situations, the provided start.txt le should meet your needs.

3. Booting from external media

This section describes how to boot your system from external media without modifying the on-board ash.
When booting from external media, U-boot loads a Linux kernel directly from external media into RAM
instead of loading it from the on-board ash chips.
ADS systems can be booted from compact ash cards in either a compact ash slot or a PCMCIA slot with
an adapter. 3 Systems with an MMC slot can also be booted from MMC cards.
When booting from external media, you have many options for your root lesystem, including ramdisks, NFS
servers and lesystems on a USB hard drive or MicrodriveTM .

3.1 Booting a ramdisk from CF or MMC

To boot a Linux using a ramdisk as the root lesystem, follow these steps:
1. Place a kernel (zImage) and ramdisk (ramdisk.gz) on your compact ash or MMC card
2. Place the U-boot start.txt on your card
3. Create a root cong.txt on your card with the following contents:
3 If

your board is equipped with both a PCMCIA and a CF slot, only the PCMCIA slot (slot 0) can be used with U-boot

ADS document #110010-40011, August 11, 2005

Page 2

ADS U-boot Bootloader Manual

images to dram='zImage ramdisk.gz'
setenv root args rw root=/dev/ram initrd=$fINITRDg,5m ramdisk size=12288
setenv boot linux 'bootm zImage buffer'

4. Insert your card into the board and apply power to boot your system.
Note:

It is not necessary to program a zImage and ramdisk.gz to ash before booting it. This type
of root lesystem can be booted directly from a CF or MMC card.

3.2 Booting a full distribution from a USB hard drive

When running the full Debian GNU/Linux distribution, your ADS board becomes a complete native development environment, with compilers, editors and debuggers. You also have access to the Debian package
system \apt", which provides thousands of pre-compiled software packages ready to be installed on your ADS
board.
Since U-boot cannot actually boot (load a kernel, etc.) from a USB storage device, you must prepare a CF
or MMC card to boot from as well as a USB hard drive for the root lesystem.
Partition you USB hard drive as follows:
1. Linux swap - Linux will use this partition as virtual memory. A size of 128 to 256 MB is recommended.
2. Linux EXT3 - This is the root lesystem. You can use the remaining space on your USB hard drive
for this partition, but very large partition sizes will take a long time to check if a lesystem check is
required.
Place the zImage and the U-boot scripts on your external media and set the following environment variables
in root cong.txt:
images to dram='zImage'
setenv root args root=/dev/sda2 rootfstype=ext3 noinitrd rootdelay=5
setenv boot linux 'bootm zImage buffer'

Since a USB hard drive requires no initial ramdisk (initrd) to be used as a root lesystem, only the kernel
(zImage) is listed in images to ash.
Note:

If your USB hard disk takes a longer time to become ready for Linux to use it, it may be
necessary to increase the 'rootdelay' parameter to give your hard drive more time to settle
before Linux mounts it.
Note:

In this example, since the mtd args have not been set in the root cong.txt, the default MTD
partitioning will be used.

3.3 Booting a full distribution from a Microdrive

Microdrives are small rotating-disk hard drives in a compact ash form-factor. Microdrives oer a large
amount of storage (up to 4GB at the time of writing) at a reasonable cost and can be used to run a full

ADS document #110010-40011, August 11, 2005

Page 3

ADS U-boot Bootloader Manual

GNU/Linux environment on your ADS board. Since they employ a rotating-disk hard drive instead of ash
memory, they are also suitable for repetitive use patterns such as software compilation and swap partitions
(virtual memory). 4
Since a Microdrive is seen by Linux as a PCMCIA device, you must use an initial ramdisk or initrd to load
the PCMCIA card manager (cardmgr) before mounting the root lesystem. Such an initrd is provided with
the Full/Traditional Debian root lesystem for ADS boards.
Partition your Microdrive as follows:
1. FAT12 or FAT16 bootloader partition - U-boot will read the kernel and other les from this partition.
About 10 MB will be needed.
2. Linux swap - Linux will use this partition as virtual memory. A size of 64 to 128 MB is recommended.
3. EXT3 - This is the root lesystem and should use the remaining space on the Microdrive.
Note:

ADS provides a Microdrive installer script with the full ADS Debian distribution tarball that
will properly partition and format a Microdrive. If you use this script, you will only need to
copy the U-boot scripts onto the rst partition.
Place the le initrd.gz, along with the zImage and the U-boot scripts, on the rst (FAT) partition of your
Microdrive.
Place the following in your root cong.txt:
images to dram='zImage initrd.gz'
setenv root args root=/dev/hda3 initrd=$fINITRDg,3m ramdisk size=6500
setenv boot linux 'bootm zImage buffer'
Note:

When using an EXT2 initrd with a 2.6 kernel, do not include a \rootfstype=" parameter, as
it will confuse the kernel if the initrd and the root lesystem types are dierent.

3.4 Booting a full distribution from an NFS server

If you have an NFS server available, you can run the full Debian GNU/Linux distribution by mounting your
NFS server as the root lesystem. This will give you all the benets of running a full distribution without
requiring a USB hard drive or Microdrive.
Place the following in your root cong.txt:
images to dram='zImage'
setenv root args root=/dev/nfs nfsroot=NFS server IP:/path/to/root ip=dhcp noinitrd
setenv boot linux 'bootm zImage buffer'
Note:

When setting up an NFS server for any diskless system (such as this), you must export the
lesystem with the 'no root squash' option. Since this option is a potential security risk to the
NFS server, you should take appropriate security precautions on your network.
4 Flash

memory cells have a limited number of write/erase cycles and are not suitable for use as swap space

ADS document #110010-40011, August 11, 2005

Page 4

ADS U-boot Bootloader Manual

3.5 Booting a kernel from external media using ash as the root
lesystem
You can use an existing ash lesystem (a JFFS2, CRAMFS, etc. that you have already programmed into
on-board ash) as your root even when loading the kernel from external media. This is especially useful for
testing a new kernel as you do not need to reprogram your ash.
To boot your board in this fashion, use the same root cong.txt that you used when programming the ash
lesystem, 5 but replace the images to ash line with the line:
images to dram='zImage'

It is not necessary to have the ash lesystem image on the external media. Only the kernel and the U-boot
les are needed.

4. Programming a kernel and root lesystem into

on-board ash
4.1 How installation works
U-boot installs a kernel and root lesystem into on-board ash by erasing the ash partition and writing the
image into the ash chips. The ash programming process is driven by the same start.txt le used to boot
from external media. Once your board's ash has been programmed with a kernel and root lesystem, your
board will boot that system whenever it is booted without external media.
Note:

After programming your ash, you should immediately remove the external media and delete
or rename the start.txt le so you don't accidentally reprogram your system later on.

4.2 Programming a kernel and ramdisk

When your ADS board has a kernel and ramdisk programmed into on-board ash, U-boot boots the system
by loading the kernel zImage and the compressed ramdisk into system memory (RAM) and executing the
Linux kernel. Linux then uncompresses the ramdisk, frees the memory consumed by the compressed copy
and mounts the ramdisk as the root lesystem.
To program a kernel and ramdisk into on-board ash, follow these steps:
1. Place a kernel (zImage) and ramdisk (ramdisk.gz) on your CF or MMC card.
2. Place the U-boot start.txt on your card
3. Create a root cong.txt on your card with the following contents:
5 See

section 4

ADS document #110010-40011, August 11, 2005

Page 5

ADS U-boot Bootloader Manual

images to flash='zImage ramdisk.gz'
setenv root args root=/dev/ram initrd=$fINITRDg,5m ramdisk size=12288 rootfstype=ext2
setenv mtd args mtdparts=flash0:$fFLBLOCKSZg(boot),$fFLBLOCKSZg(bootvars),2048k(zImage),5m(ramdisk.gz),-(flashfs1)

4. Insert your card into the board and apply power to boot your system.
Note:

The nal partition, ashfs1, is not programmed with any image in this example. You can use
this partition from within Linux, however, by erasing it and mounting it as js2, as in this
example:
eraseall /dev/mtd4
mount -t jffs2 /dev/mtdblock4 /mnt/flash

The mount command or the rst write to the lesystem may take a few minutes to complete as the lesystem
is created/checked.

4.3 Programming a kernel and JFFS2 image

JFFS2 is the second version of the journaling ash lesystem for Linux. JFFS2 lesystems are accessed
directly from the on-board ash and do not consume large amounts of memory (DRAM) like ramdisks.
JFFS2 lesystems are writable and persistent allowing you to make permanent changes to the lesystem
stored in your on-board ash.
To program a kernel and JFFS2 lesystem into on-board ash, follow these steps:
1. Place a kernel (zImage) and JFFS2 image ( ashfs1) on your CF or MMC card
2. Place the U-boot start.txt on your card
3. Create a root cong.txt on your card with the following contents:
images to flash='zImage flashfs1'
setenv root args root=/dev/mtdblock3 noinitrd rootfstype=jffs2
setenv mtd args mtdparts=flash0:$fFLBLOCKSZg(boot),$fFLBLOCKSZg(bootvars),2048k(zImage),-(flashfs1)

4. Insert your card into the board and apply power to boot your system.

4.4 Programming a kernel and CRAMFS image

CRAMFS is a compressed read-only lesystem for ash. Like JFFS2, it is accessed directly from the on-board
ash, but the contents of a CRAMFS lesystem cannot be modied. This is a useful feature, however, if you
need to be absolutely sure that your lesystem cannot be corrupted or altered.
Since CRAMFS is read-only (unlike ramdisks and JFFS2), you will need to combine it with either JFFS2
or a ramdisk to provide space for programs/users to write les. For example, the ADS Debian CRAMFS
distribution also uses a JFFS2 image for persistent storage. You will have problems if you try to use a
completely read-only lesystem.
To program a kernel, a CRAMFS lesystem and a JFFS2 lesystem into on-board ash, follow these steps:

ADS document #110010-40011, August 11, 2005

Page 6

ADS U-boot Bootloader Manual

1. Place a kernel (zImage), CRAMFS image (cramfs.img) and JFFS2 image ( ashfs2) on your CF or MMC
card
2. Place the U-boot start.txt on your card
3. Create a root cong.txt on your card with the following contents:

images to flash='zImage cramfs.img flashfs2'

setenv root args rw root=/dev/mtdblock3 noinitrd rootfstype=cramfs
setenv mtd args mtdparts=flash0:$fFLBLOCKSZg(boot),$fFLBLOCKSZg(bootvars),2048k(zImage),14848k(cramfs.img),-(flashfs2

4. Insert your card into the board and apply power to boot your system.

5. Important concepts in U-boot

5.1 Using environment variables
U-boot stores its collection of settings commands and scripts in \environment variables". These environment
variables are stored in the second ash partition, named 'bootvars'.
On boot, U-boot automatically attempts to load the environment variables from ash. If U-boot cannot load
it's environment variables (if the partition is corrupt or erased, for instance), you will see the following error
message:
*** Warning - bad CRC, using default environment

and U-boot will fall back to it's compiled-in default environment. To prevent this message from occurring
again, type saveenv to save the environment into ash.

5.2 Restoring the default environment variables

If you need to restore U-boot's default environment, you can remove all of the saved environment variables
by typing:
run eraseenv

at the U-boot prompt and resetting your board. When U-boot restarts, you will see the above error message
and U-boot will use it's compiled-in defaults. Again, you should save these defaults to on-board ash by
typing:
saveenv

ADS document #110010-40011, August 11, 2005

Page 7

ADS U-boot Bootloader Manual

after restarting U-boot.
Warning:

Restoring the default environment will destroy any changes made to the environment variables,
including conguration information needed to boot lesystems installed in on-board ash. You
should capture the output of the printenv command to back-up your environment if you
make changes.

5.3 Scripts versus commands

Being an interactive bootloader, U-boot has several built-in commands that you can run from U-boot's
command prompt. 6 You can see a list of U-boot commands by typing help at the command prompt. More
detailed information about built-in U-boot commands can be found in the ocial U-boot manual. Built-in
commands are run by simply typing the name of the command at the prompt.
In addition to the built-in commands, ADS U-boot also supports scripts, which are complex collections of
commands stored in environment variables or text les on external media. 7 For more information on using
scripts, see chapter 9 of this manual.

6. Boot and install scripts

Boot scripts are les that are loaded by U-boot from CF or MMC cards. They contain U-boot commands to
set variables, perform operations and execute other scripts to control U-boot's behavior when it starts up.
Refer to the main U-boot manual for information about U-boot commands.

6.1 start.txt
On boot, ADS U-boot looks for the le start.txt 8 on external media (CF or MMC, if present on your board)
and, if found, loads and executes it. Start.txt instructs U-boot to look for several other les which you can
modify to control how your ADS board boots Linux (root lesystems, hardware registers, etc.) Section 6.5
describes U-boot's behavior without the start.txt le.
Below is a list of the les start.txt uses to boot your system. In most circumstances, changes to these les
should be all that is necessary to make your board boot the way you want it to. You should not need to
make any changes to start.txt for typical operation.

6.2 root cong.txt

The root cong.txt le is used to tell U-boot and Linux about the layout of your root lesystem. The
conguration in root cong.txt is also used to build the Linux kernel command line.
6 U-boot presents an interactive command prompt if autoboot is interrupted during the 3-second timer at startup or if
autoboot fails for any reason.
7 This is an ADS U-boot extension. See section 9.4
8 Actually, it runs the 'bootcmd' environment variable which, by default, executes the 'start' environment variable.

ADS document #110010-40011, August 11, 2005

Page 8

ADS U-boot Bootloader Manual

Environment variables used in root cong.txt:

images to ash Space-separated list of les to be programmed into on-board ash. The le names should
correspond to MTD partition names in the mtd args section.
images to flash='zImage flashfs1'

images to dram Space-separated list of les to be loaded into RAM.

images to dram='zImage ramdisk.gz'

mtd args Part of the kernel command line where MTD partitions are dened.
setenv mtd args mtdparts=flash0:$fFLBLOCKSZg(boot),$fFLBLOCKSZg(bootvars),2048k(zImage),-(flashfs1)

boot linux This is the command U-boot should run to nish booting linux. In most cases, this command
should copy the kernel into RAM and run it.

setenv boot linux cp zImage zImage buffer; bootm zImage buffer

If you have already copied a kernel into the zImage buer (e.g., from external media), then 'boot linux'
only needs to run the loaded kernel:
setenv boot linux 'bootm zImage buffer'
Note:

When a kernel and root lesystem are programmed to on-board ash using the 'images to ash'
method, the environment variables are automatically saved to on-board ash, as well.

6.3 tty cong.txt

Environment variables used in tty cong.txt:

tty args Part of the kernel command line where the console and serial ttys are congured
setenv tty args console=ttyS0,38400 SERIALGETTY=ttyS0 SERIALBAUD=38400

The 'console' parameter determines where the Linux kernel messages will be sent. The SERIALGETTY
and SERIALBAUD parameters are variables used by the init process to congure the serial login
terminals once Linux is running.
You can also specify a normal keyboard/LCD tty as the console by setting
console=tty1,38400
Note:

Some hardware will require a dierent tty name (ttyAM0, ttyS1) to function properly.

ADS document #110010-40011, August 11, 2005

Page 9

ADS U-boot Bootloader Manual

6.4 hw cong.txt

The hw cong.txt le is used to congure hardware registers prior to booting Linux. This is most often used
for setting up the framebuer registers. These settings will be specic to the type of board you are using.
See chapter 7 for more details.
Note:

The kernels for ADS Linux systems contain compiled-in default hardware settings that will be
used if hw cong.txt is not present when booting. These settings usually specify a 640x480
8-bit display for a LQ64D343 LCD display.

6.5 U-boot's behavior without external media

If U-boot does not nd a CF or MMC card on boot (or doesn't nd the start.txt le on any inserted CF or
MMC cards) U-boot's behavior is controlled solely by the environment variables saved in the bootvars ash
partition. 9
If you have programmed a kernel and root lesystem into on-board ash using the procedures outlined in
section 4, U-boot's environment variables will be set to automatically boot that system after the three-second
delay. If U-boot is not interrupted by activity on the debug port, Linux will boot automatically and you will
not receive a U-boot command prompt.
If you wish to alter the default behavior of U-boot, you should use the setenv command to change the
environment variables. Once you have set the environment variables the way you want them, use the saveenv
command to store your current environment into ash.
If U-boot is not set up to boot from on-board ash, or if U-boot's environment has been erased, U-boot will
abort automatic booting and present its command prompt instead. U-boot will also abort if is set up to boot
a kernel from on-board ash, but ash does not contain a valid kernel.
If U-boot is set up to boot from on-board ash, but on-board ash does not contain a valid root lesystem,
Linux will give a kernel panic with an error message like this:
Unable to mount root on <device>
Kernel panic - not syncing: VFS: Unable to mount root fs on <device>

You will need to re-program your kernel and root lesystem or change the environment variables to point to
a proper root lesystem in order to boot Linux properly.

7. Register settings and hw cong

U-boot uses the commands given in hw cong.txt to set up machine-specic register settings prior to booting
Linux. This script replaces the functionality of the register.txt les from our legacy PXA bootloader.
For each register setting, a command is created that uses the U-boot command mw to set a word at a
particular address to a specic value. Since the commands are stored in environment variables, they can be
9 If

your bootvars partition is erased, the compiled-in defaults will be used for the environment.

ADS document #110010-40011, August 11, 2005

Page 10

ADS U-boot Bootloader Manual

given meaningful variable names. The command 'hw cong' is set to run all of the commands for conguring
the hardware registers. If there are too many individual mw commands, 10 you will need to add subcommands,
as shown in the example below. U-boot will execute the command 'hw cong' prior to loading and running
Linux.
Example lines for hw cong.txt:
setenv
setenv
setenv
setenv
setenv
setenv
setenv
# too
setenv
setenv
# run
setenv

message echo hw_config.txt example only - do not use

vidclkdiv mw 0x80930084 0x0000c205
pixelmode mw 0x80030054 0x0000140c
scrnlines mw 0x80030030 0x000001E0
vlinestep mw 0x80030038 0x00000140
hclktotal mw 0x80030010 0x0000031f
hactstrtstop mw 0x80030018 0x001F029F
many to fit on a single command/line
hw1 run message vidclkdiv pixelmode scrnlines vlinestep
hw2 run hclktotal hactstrtstop
all of them
hw_config run hw1 hw2

Using this format for hw cong.txt allows you to easily split up the le into multiple lines and keep the le
easy to read.

8. Advanced U-boot conguration

8.1 How to reprogram (upgrade) U-boot
The default U-boot environment shipped with ADS systems contains several scripts that can be used to
re-program the U-boot bootloader to a new version. To re-program U-boot, follow these steps:
1. Place the new u-boot.bin le on a CF or MMC card.
Warning:

The u-boot.bin le MUST contain a valid version of U-boot for your ADS board. If
u-boot.bin is not a valid bootloader or contains bugs, using it can render your board
inoperable. If you have downloaded an updated u-boot.bin from the ADS support web
site, double-check to be sure you have downloaded the proper le for your model board.
Also, you should use md5 to verify that the le downloaded correctly.
2. Insert the card into your board, connect a serial terminal and boot your system.
3. After applying power (but before the three-second timer expires), press the Enter key to receive the
U-boot command prompt.
4. If you are using a CF card (either in a CF slot or a PCMCIA slot), type the command:
run p reprogram uboot

If you are using an MMC card, type the command

run mmc reprogram uboot
10 U-boot

allows a maximum of 16 arguments per command

ADS document #110010-40011, August 11, 2005

Page 11

ADS U-boot Bootloader Manual

Warning:

Do not remove power from your board while U-boot is being programmed. Power loss
during a bootloader update may render your board unbootable. If this happens you may
have to return the board to ADS for reprogramming.
5. Once programming has completed, you will see the following message:
Copy to Flash... done

You should now type reset to boot the newly-installed U-boot.

8.2 How to make U-boot secure

To make U-boot more secure, there are several changes you can make to the environment variables to disable
booting from external media and interactive booting.
To prevent U-boot from allowing activity on the serial console from interrupting the automatic boot process,
remove the autoboot delay by running:
setenv bootdelay 0
Warning:

This will prevent you from getting a U-boot prompt. It will be necessary to erase U-boot's
environment from within Linux to get a U-boot prompt.
To prevent U-boot from reading external media at startup, you should change the 'start' environment variable
to boot your system only from on-board ash. The 'start' variable stores the commands U-boot runs during
automatic boot. To set a minimal automatic boot command, type the following at the U-boot command
prompt:
setenv start 'test -n $fhw configg && run hw config; test -n $fboot linuxg && run boot linux'

This start command would only read the 'hw cong' and 'boot linux' commands from the saved environment
and not from external media. These commands would also need to be stored in the environment.
Note:

You must run the saveenv command to save your environment changes to ash or they will be
lost when you reboot.

8.3 How to make U-boot quiet

Setting the environment variable 'silent' to any value (i.e., having this variable present) will prevent U-boot
from sending any output to the debug port:
setenv silent 1
saveenv

ADS document #110010-40011, August 11, 2005

Page 12

ADS U-boot Bootloader Manual

When silent mode is enabled, you can still get a U-boot command prompt by pressing Enter during the
autoboot countdown after applying power to the board. The countdown will not be visible but the system
still gives you a chance to interrupt the boot process.
To disable silent mode, clear the 'silent' variable by typing:
setenv silent
saveenv

When the silent variable is set, U-boot will set the Linux console to null (empty, console=) on the command
line automatically. If you wish to silence the serial gettys, as well, you should disable (comment out) the
serial login gettys in the le /etc/inittab.

9. ADS-specic features and changes

9.1 Raw zImage kernels
Normally, U-boot expects to boot kernels from a special uzImage, which encapsulates the Linux kernel into
a U-boot -specic format. The ADS U-boot, however, also accepts raw zImage les, as produced by a make
zImage command.

9.2 Raw ASCII scripts

ADS U-boot provides the ability to run U-boot scripts in memory without having to encapsulate the script
inside a uImage (using the mkimage tool is not necessary). This functionality allows the execute txt le
script to load and execute scripts stored as ASCII text les on external media.

9.3 Setting the ethernet MAC address

On supported boards, the U-boot command macaddr can be used to set the ethernet MAC address. The MAC
address is a 6-byte hexadecimal number that uniquely identies each endpoint on an ethernet network/LAN.
You can view your board's MAC address by typing either:
macaddr

(with no arguments) or:

printenv ethaddr

To set the MAC address, provide the address as an argument to the macaddr command, as in the following
example:

ADS document #110010-40011, August 11, 2005

Page 13

ADS U-boot Bootloader Manual

$ macaddr 00:60:0c:aa:bb:cc

The MAC address can be entered with or without the colons between the bytes. No other type of separator
is allowed.
Note:

You board should come from the factory pre-programmed with a valid, unique MAC address.
You should not change your board's MAC address unless you have a valid reason for doing so.

9.4 Running scripts from text les

The default U-boot environment contains an ADS-supplied script that allows you to easily run a U-boot
script that is stored as a text le on a CF or MMC card. To run a U-boot script from a text le, specify the
name of the script by typing:
txt file=my script.txt

then run the script by typing

run execute txt file

You can also use this technique from within another text le script to call one script from another.
Note:

If les with the same name exist on both a CF and MMC card, the CF card will take precedence.
(Use printenv to observe the 'execute txt le' variable)

9.5 Map commands

The commands mapinfo , mapadd , and mapdel , can be used to maintain a human-readable memory map.
This map allows you to name various memory ranges, including ash regions (partitions) and memory regions
(buers).
The output of the mapinfo command will list all of the default regions:
$ mapinfo
Name
---boot
bootvars
zImage
flashfs1
script_buffer
zImage_buffer
scratch_buffer

Location
-------0x00000000
0x00040000
0x00080000
0x00200000
0xa0000800
0xa0008000
0xa0600000

Size
---0x00040000
0x00040000
0x00180000
0x01e00000
0x00007800
0x00180000
0x01000000

Type
---Flash
Flash
Flash
Flash
DRAM
DRAM
DRAM

Source
-----bootargs
bootargs
bootargs
bootargs
Initial
Initial
Initial

Guard
----Off
Off
Off
Off
Off
Off
Off

These regions are used by many of the ADS-supplied scripts and default commands. The regions of type
\Flash" correspond to MTD partitions in on-board ash, and are named according to the partition names.
The regions of the \DRAM" are sections in memory and are used to hold scripts, kernel images, ramdisks
and ash images that are loaded by U-boot.

ADS document #110010-40011, August 11, 2005

Page 14

ADS U-boot Bootloader Manual

The mapdel command deletes a named region from the map table. The only argument is the name of the
region to delete.
The mapadd command will add a named region in either DRAM or ash (depending on the address) to the
map table. The rst argument is the name of the region. The second argument is the beginning address of
the region. The third argument is the size of the region. The fourth argument is optional and determines
whether or not U-boot will prevent writes to the region.
To create a new buer called \foo" at address 0xa0600000, with a size of 16MiB (16777216 bytes), enter the
command:
mapadd foo 0xa0600000 0x01000000
Note:

U-boot interprets most numerical values as hexadecimal values even if a leading '0x' is not
supplied. A notable exception to this rule is the 'baudrate' value, which is interpreted as
decimal.

9.6 ADS-supplied boot/install scripts

The les start.txt, hw cong.txt, root cong.txt, tty cong.txt are boot scripts that ADS has provided to
make it easier to control the behaviour of U-boot. These scripts break down the boot process into steps and
allow for simpler individual les.

ADS document #110010-40011, August 11, 2005

Page 15