Booting the Board in embedded system

Booting the Board

The Boot Loader

A boot loader isn’t unique to Linux or embedded systems. It’s a program first run by a computer so that a more sophisticated program can be loaded next. In a Linux system, two boot loaders usually run before the Linux kernel starts running. The code also populates a data structure that you can view by doing the following after the system is up and running:

$ cat /proc/cpuinfo

Many boot loaders are available for Linux, all of which are open source. The boot loader included with the board is the best choice to use for shipping the board, because it’s proven to work; getting another boot loader working is a combination engineering and research project that can be difficult to schedule. The maker of the board has likely paid for the development of a working boot loader so that engineers can easily use the board for development. Because the boot loader is open source, the source code should be included or available for customization. Boot loaders have matured over the past few years to have the functionality of a minimal operating system: they can run video devices, serial ports, flash memory, USB devices, and even IP networking over Ethernet.

Boot loaders have also become less agnostic and have additional features built in for supporting Linux—for example, U-Boot has the ability to uncompress the kernel rather than have the kernel decompress itself. Getting the source code for a boot loader and building it works much like any other open source

project. The part that’s very different is getting the code on the board so that it can be run. In some cases, the boot loader supplied by the board can access the flash memory to write the new code; in other cases, you must place the code on the board with a Joint Task Action Group (JTAG) device. JTAG is a communication mechanism, akin to serial or parallel. The software that runs in a JTAG debugger can usually program flash memory on the board. Some vendors, like Atmel, have flash programming tools that use USB instead of JTAG.

The following sections contain detailed information about the boot loaders found on most systems.

RedBoot

This boot loader is built on the hardware abstraction layer of the eCos embedded operating system. The result is a very robust boot loader with a wide range of architecture and device support. As you can guess from the name, this software is part of the Red Hat family of projects. You can obtain the sources for RedBoot from sourceware like so:

$ mkdir ~/redboot

$ cd ~/redboot

$ wget --passive-ftp ftp://ecos.sourceware.org/pub/ecos/ecos-install.tcl

$ cd ecos-install.tcl

The file downloaded is a script that downloads the rest of the RedBoot’s code. This script is written in Tcl (it was first TCL, for Tool Command Language, but now it’s frequently referred to as “tickle”). The code first prompts for a download mirror; select one close to your current location. Next, the software prompts for the installation directory; you can accept the default. The next question asks what prebuilt tools to install. The RedBoot loader is picky about the configuration of the compiler used to build it. The cross-compiler created earlier works fine under most conditions; however, the best practice is to download the toolchain offered by the installation program:

Available prebuilt GNU tools:

[1] arm-eabi

[2] arm-elf (old)

[3] i386-elf

[4] m68k-elf

[5] mipsisa32-elf

[6] powerpc-eabi

[7] sh-elf

[q] Finish selecting GNU tools

The menu lets you select several tool chains. Each architecture has one toolchain (except ARM; in that case, choose the first), After the installation process finishes, you rebuild by running ecosconfig to configure the source tree and then make to run a build. For example, to do this for an ARM Integrator board, you need the following commnds:

$ cd <redboot installation directory>

$ source ./ecosenv.sh

$ ecosconfig new integrator redboot

$ ecosconfig import ~/ecos/ecos3.0/packages/hal/arm/integrator/v3_0/misc/redboot_ROMRAM.ecm

$ ecosconfig tree

$ make

The first two lines configure environment variables for eCos based on the installation script. The next line creates a skeleton project for the ARM Integrator board, and the next two lines import a configuration file for that board and create the source tree for the build. The build product is in the install/bin directory. The correct values for the parameters passed into ecosconfig for the configuration steps are contained in the http://ecos.sourceware.org/docs-latest/redboot/installationand- testing.html file. This example builds two binaries: one to be loaded into RAM and executed and the other suitable to be written into flash. After it’s built, you can write the new boot loader into flash using RedBoot. This is platform specific. The basis process involves uploading the image on the board into RAM and then writing the data to flash. An example of the commands to perform these steps follows; again, the exact instructions vary for each board. You issue these commands d on the board using the existing redboot program:

redboot> fis init -f

redboot> load -r -b <address> redboot_ROM.bin

redboot> cksum

redboot> fiscreate redboot

When the board is reset, the new version of RedBoot is running.

Using RedBoot

The general process for using RedBoot is to load the kernel into memory and run it. A kernel comes from either flash storage or from a TFTP server. To load a kernel from flash, use these commands:

redboot> fis load -b 0x1000000 kernel

A flash partition is a logical division of the flash memory space that’s been

assigned a name.

From TFTP, use these commands:

redboot> ip_address -l <ip address> -h <address of tftp server>

redboot> load <kernel_image_file>

After it’s loaded into memory, you can run the kernel by doing the following:

exec -b 0x100000 -l 0x80000 -c "init=runme root=/dev/mtdblock2"

You do so by loading the file into memory and then writing it out into a flash partition.

For example:

redboot> fs mount -d /dev/flash1 -t jffs2 /rfs

redboot> fis cd /opt

redboot> load <file> -b 0x80000000

redboot> fis write -b 0x80000000 -l <length> <file name>

<file> is a file loaded from the TFTP server. After it loads into memory, RedBoot returns the length of the file and uses that length in the next command when writing the data from the RAM into the flash file system using the fis write command.

YAMON

YAMON is the boot loader used on MIPS development boards and is created and maintained by MIPS. Because YAMON is specific to MIPS development boards, it’s rarely rebuilt. The best thing to do is download the required binary from http://www.mips.com/products/system-software/yamon/.To download and run a kernel, do the following:

YAMON> load tftp://<tftp server ip address>/<file>

YAMON> go

<tftp server ip address> is the IP address of a host running TFTP, and <file> is the SREC to

download.

Das U-Boot

U-Boot (which means “the submarine” in German) is a popular boot loader for ARM and PowerPC boards. This tools is maintained primarily by DENX Software is part of this company’s embedded Linux suite of products. This company contracts with hardware manufacturers to keep U-Boot up to date for their hardware, which means U-Boot is frequently the first boot loader ready for a large number of boards. The sources are available via Git or using the FTP site. To download with Git, do the following:

$ cd ~

$ git clone git://git.denx.de/uboot.git u-boot

If you want to use a specific release of the software, download via FTP and unpack the compressed tar file. Substitute the version number for <version> in the commands:

$ wget ftp://ftp.denx.de/pub/u-boot/u-boot-<version>.tar.bz2

$ tar xjf u-boot-<version>.tar.bz2

After you download the sources, the building software works using the configure/build model. The project has configurations stored in theinclude/configs directory; to use the configuration, strip off the path, remove the training .h, and append _config to the remaining text. The include/configs directory contains this file: MPC8260ADS To configure a U-Boot build for this board, do the following:

$ make MPC8260ADS_config

The software works a little while and shows a confirmation message indicating that the project was configured. If you’re working with several boards, be sure to clear the environment between configurations by doing the following to empty the build directory of any leftovers that could cause errors:

$ make distclean

GRUB

GRUB is the boot loader commonly used in desktop systems, having supplanted LILO in the past few years. GRUB performs the same job as LILO: after the first-stage boot loader has run, GRUB finds a kernel, puts it into memory, and lets the system start. The partition is

the logical division of the drive. To find the partitions on a drive, use the sfdisk command:

$ sudo /sbin/sfdisk -l

GRUB allows you to load the kernel from a TFTP server. To do this, you need to configure the IP parameters and use (nd) instead of (hd0,1) as the root device. For example:

ifconfig –address=10.0.0.1 –server=10.0.0.2 kernel (nd)/bzImage This results in GRUB configuring the adapter to have an IP address of 10.0.0.1 and use the default netmask (255.0.0.0) and contact 10.0.0.2 to download the kernel file bzImage via TFTP to boot the

system.