This document describes how the mechanism for booting and flashing the developer board over ethernet works. It also explains the different images created when building software for ETRAX.
You should have read How to Use the Top-Level Makefile.
ETRAX contains on-chip boot code which is capable of initializing the processor, load one packet from ethernet into the cache and start executing in the cache. By pressing and holding S8 (the boot button on the developer boards, see http://developer.axis.com/products/devboard/pinout.txt or http://developer.axis.com/products/devboard_bt/comp_ref.txt) while powering up, ETRAX is put in the network boot mode. Network booting is performed with an Axis specific protocol called Network Boot Protocol (NBP). The boot code in ETRAX listens for packets sent to the ethernet multicast address 01:40:8c:00:01:00. Every packet is checked, and the first NBP packet is loaded into the cache. The code in this packet is executed and loads the rest of the boot loader into the cache. The size of the boot loader is therefore limited to the size of the cache, which is 8kB.
The easiest way to network boot the target system is to use the flashit or ktest scripts that comes with the developer board software.
These scripts use the boot_linux or boot_elinux tool (depending on the target operating system), which is located in the tools directory.
This script extracts hardware register settings from the compiled kernel and runs e100boot (source code is in the tools/e100boot directory) with these settings.
Two programs are involved in this boot loading.
One is the program on the host (workstation) that sends packets to the target (ETRAX
), this is called the server boot loader
(SBL).
The other one is the one in ETRAX 100 that receives packets from the SBL and acts upon the data therein.
This is called the client boot loader (CBL).
The configuration packet, generated on the fly by the SBL, can contain information to the
CBL, that initializes external memory, reads and writes all ETRAX registers, reads and writes memory, etc.
Since the network boot is based on sending packets to the multicast address, more than one unit on a local network segment can reply on the boot packet. Only the first client replying will be answered by the server, but if your unit is in boot mode it may boot using a packet sent by someone else's server. This may be a problem if many people are working on the same network segment. You can, however, not damage or destroy your target system by network booting. The worst thing that can happen is that someone writes a flash image that overwrites your bootblock parameters and thereby overwrites the serial number of your device, which is used as the ethernet address of the device.
The ETRAX 100 network boot loader supports programming of the flashes with an arbitrary image. A flash memory can be divided into multiple partitions, where each partition can be one of the following:
flashitall script.
As shown in the figure below, the entire romfs image is compressed too.
|
Bootblock |
|
Partition table |
|
Decompress code |
|
|
|
Padding |
|
|
|
Padding |
The bootblock contains rescue code, made to reside at the beginning of the flash memory. When it starts, it checks a partition table at the first sector after the bootblock. The partition table was generated by mkptable and contains offsets, lengths, types and checksums for each partition that this code should check. If any of the checksums fail, it assumes the flash is so corrupt that we initialize the serial port to receive a flash loader and new flash image. It does not include any flash code, but accepts a certain amount of bytes from the serial port and jumps into it. The downloaded code is put in the cache. The partitiontable is designed so that it does not matter if you execute it; it has a relative branch opcode in the beginning that jumps over it.
Bootblock parameters are strings such as hardware ID and serial number.
This is what the partition table can look like when using 2MB flash:
| Name | Size | rw-options | Type | Contents |
|---|---|---|---|---|
| rescue | 64kB | ro | rescue | Bootblock |
| flash1 | 1664kB | ro | kernel | Partition table Decompress code Compressed kernel romfs |
| flash2 | 320kB | rw | JFFS | Flash file system |
When you have built your software you should have the following images in the product direcory (axis/devboard{,_lx,_bt}):
The flashit and ktest scripts can send the kimage and fimage to the target system.
Running the ktest script results in booting the target system with the kernel and romfs in RAM (for fast testing).
Running the flashit script results in a flash write of everything except the bootblock in the
fimage.