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/ecos-3.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
This command loads the data from the kernel flash partition named kernel and loads the data starting at address 0x100000. 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>
The first command configures the first adapter on the board to have the IP address <ip address> (remember to use an acceptable address for your network or hardware configuration; duplicate IP addresses summon an IT staff member who won’t be impressed) and looks to address <address of tftp server> when performing a TFTP download. The TFTP server IP address should be the one of the host configured earlier in the book. 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"
This command runs the kernel loaded into memory at 0x0100000 that’s 0x80000 bytes long with the parameters sent to the kernel following the -c parameter. The kernel is now off and running. RedBoot has support for mounting, reading, and writing Journaling Flash File System (JFFS) partitions, a handy feature because reading these file systems usually requires starting Linux. However, because RedBoot is built on a very small embedded operating system, eCos, this feature isn’t surprising. In addition to being able to perform operations like listing directory contents and reading files, you can also create files. 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.
Source of Information : Pro Linux Embedded Systems
No comments:
Post a Comment