The Boot Loader Object (Blob) allows the user to:
initialise the hardware (CPU speed, memory, interrupts, RS232);
boot a Linux kernel and provide that kernel with a RAMdisk;
download a kernel or a RAMdisk to the target device;
write a freshly downloaded kernel or RAMdisk to the flash memory (see below for limitations).
Blob was originally written for the LART by Jan-Derk Bakker and Erik Mouw, but has also been modified to work on the Assabet by Jeff Sutherland and Chester and on the Intel Brutus SA-1100 evaluation platform by Erik Mouw, and on the PLEB Linux board by Adam Wiggins. You need to compile the correct version for the hardware you want to use it with as the hardware varies in important ways (processor, memory type and layout, debug serial port).
Assuming that you have already installed Blob then this is how you should use it. If you need to install the boot loader for your device read the chapter on that device or Chapter 2 for details.
connect a terminal (or a terminal emulator like miniterm or Seyon) to the target device's serial port;
use the appropriate settings for your device: usually 9600 8N1 or 115200 8N1; on the LART there is no hardware flow control so you'll need to turn that off too;
use the appropriate terminal emulation, usually VT100;
switch the target device on.
You should then see something like (this example is from a LART):
Consider yourself LARTed! |
Note that it always says Loading kernel/ramdisk whether or not a kernel and RAMdisk are actually present. It will just hang if it tries to boot a 'blank' kernel.
Blob version 1.0.8-pre2, |
If you didn't press Enter within 10 seconds, Blob will automatically start the Linux kernel:
Starting kernel ... |
However, if you press Enter, you will see the Blob prompt:
Autoboot aborted |
Blob comes with a selection of useful commands. Type help for a list or refer to Table 6-1.
Table 6-1. Blob Commands
| Command with Options | Explanation |
|---|---|
| boot [kernel options] | Boot Linux with kernel options |
| clock PPCR MDCNFG MDCAS0 MDCAS1 MDCAS2 | Experimental speed setting option - USE WITH CARE! |
| download {kernel|ramdisk} | Download kernel or RAMdisk image to RAM |
| flash {kernel|ramdisk} | Copy kernel or RAMdisk from RAM to flash |
| help | Get this help |
| reload {kernel|ramdisk} | Reload kernel or RAMdisk from flash to RAM |
| reset | Reset terminal |
| speed | Set download speed |
| status | Display current status |
Note that two versions of pre-compiled Blobs are provided on the CD and the LART website so most people will not need to compile Blob until you want to modify it or perhaps get a newer version. Should you need to, here are the details. First you need a suitable GNU toolchain:
A native ARM/StrongARM Linux system with gcc 2.95.2, and binutils 2.9.5.0.22 or better
Or any UNIX system with cross compiling binutils 2.9.5.0.22 (or better) and gcc 2.95.2 installed
GNU make (although some vendor supplied make utilities will do)
Next you need to get the software, then configure and compile it. The lastest version available at the time of writing is blob 1.0.8-pre2.tar.gz which is on the CD in /tools/blob/
This example assumes you will unpack it in /usr/src
cd /usr/src
tar -xzvf /cdrom/tools/blob/blob 1.0.8-pre2.tar.gz
cd blob-1.0.8-pre2
Now you need to specify the board for which you want to compile it, and whether you are cross-compiling or not, i.e. if you are compiling on a PC rather than a native ARM machine. There are currently four valid board names, choose from: 'assabet', 'brutus', 'lart', or 'pleb'. If the board name is omitted, lart will be choosen as a default. If you are modifying Blob itself then you should turn on the --enable-maintainer-mode flag. This will automatically regenerate Makefiles and configure scripts if you change the source files. You need autoconf (>= 2.13) and automake (>= 1.4) installed for this feature.
export CC=/path/to/cross/gcc
export OBJCOPY=/path/to/cross/objcopy
./configure --with-linux-prefix=/path/to/armlinux/source --with-board=boardname
So on our example host machine the correct runes are as follows (this machine needs to be told the host type, otherwise configure complains):
export CC=arm-linux-gcc
export OBJCOPY=arm-linux-objcopy
./configure --with-linux-prefix=/usr/src/arm-linux/linux/ --with-board=lart --host=i386
If things have worked you should get confirmation text like this:
Target board lart |
For a native ARM machine it's much simpler - all you should need is this:
./configure --with-board=lart
So, now you just make Blob with:
make
This will result in a blob-elf32 which is the full executable with headers and a stripped binary blob in the blob-1.0.8-pre2/src/ directory. The much smaller blob is the one you actually upload. blob-elf32 is useful for examining the code produced. The best way to upload Blob to you device is using the appropriate version of JFlash-linux.
In addition to the Blob-related resources which are available on our CD, you can find:
the Blob source and pre-compiled binaries http://www.lart.tudelft.nl/lartware/blob and on the CD.
Uploading can be achieved via the JTAG port using software such a Jflash and Jflash-linux. Usage for Windows or GNU/Linux host is essentially identical. The examples given here use GNU/Linux syntax.
In order to use the JTAG programmer, you need to connect the parallel port of your computer to the JTAG port of the device you want to program. The details of this vary from device to device - see the relevant install chapter. Ensure the device is powered up. Jflash and Jflash-linux both autosense for available parallel ports so it shouldn't matter where you plug it in.
You can then issue the following command as root:
./Jflash-linux blob-1.0.7b
and you should see something like the following (this example is using the blob-1.08-pre2 binary on the CD on a LART). After uploading the device will reset itself before running Blob.
using printer port at 378 |
Note: If something is wrong you will see error messages like the following:
error, failed to read device ID |
or
error, failed to read device ID |
or
error, failed to read device ID |
There are a number of possible causes. If you get all 1's then you maybe using the wrong parallel port, or the cable or dongle is not plugged in, or the device is not powered up. If you get all zeros then you may be using the wrong version of JFlash-linux, or (on a LART) you may be suffering from the 'JTAG reset problem', see the section called LART JTAG reset problem in Chapter 3. If you get random numbers some of the time and zeros the rest of the time then you are almost certainly using the wrong version of JFlash-linux.
Angel and Angelboot together make a simple but effective boot loader that can upload a kernel and RAMdisk to a target device from a host then run them. Angel is the code that lives on the device that gets started on boot and Angelboot is the program that runs on the host and manages the upload. Angel is in fact part of the ARM SDT and can be used as a debugger in that environment. Angelboot allows it to be used outside this environment.
The Windows Jflash code 'SA-1110 Development Board, JTAG Programming Software v0.3' to give it its full title, can be downloaded from: http://developer.intel.com/design/strong/swsup/SA1110Jflash.htm whilst Jflash-linux is obtainable from: ftp://ftp.netwinder.org/users/n/nico/SA1110Jflash.tgz.
Copy dot.angelrc and Angelboot from the CD to your development directory and rename dot.angelrc to .angelrc. .angelrc is now classified as a hidden file so your filer may hide it from you. You will however, need to edit .angelrc to match your device. so that it has the following settings:
This is an example for an Assabet board
base 0xc0008000 |
The meaning of these settings is as follows:
The base address is the address in target memory that the kernel is loaded to. The file loaded is zImage in the current directory;
entry is the address in target memory that gets jumped to when the loading is complete. For the kernel this is normally the same as the load address;
r0 is what will be in register r0 when the kernel is started - this is normally zero;
r1 is what will be in register r1 when the kernel is started - this is normally the architecture number for the device;
device is the device to use for the upload - normally a serial port such as /dev/ttyS0;
options are the serial port settings to use after the upload is complete - these should match your minicom settings;
baud is the serial speed to use for the upload;
otherfile is the name of a second file to upload - normally the RAMdisk;
otherbase is the address in target memory that otherfile is loaded to;
exec allows a command to be executed once the upload is completed - normally starting your serial communication program.
Make sure your device is ready and that the serial port is connected. Run:
./angelboot
Angelboot will run using the config in .angelrc. You should see the following:
Initialising execution environment. |
Downloading other image size 0x26935d to 0xc0800000 |
Obvisouly the sizes and number of lines of dots and stars vary with the size of the uploaded images and the target addresses are what you specify in .angelrc.
The device should now be running, booting the kernel and using the RAMdisk as the root filing system. If you specified an exec line to run your serial program then it will start and show you the kernel boot info and login prompt.