AG Vernetzte Systeme Research ARM (Imote2) Bootloader

 
Based upon the TinyOS-Bootloader for the Imote2, a new, completely rewritten Bootloader was developed.

Outline

1. Motivation
2. Comparison old vs. new version
3. Documentation
4. Installation
5. Download
6. References
7. Authors

Motivation

The TinyOS Bootloader did not meet our requirements in several ways:

1. We do not develop TinyOS Programs, but own C++ Application. The Linkerscript and Loader which are provided with tinyos were insufficient for these needs
2. The programs we wanted to deploy where therefore somewhat larger. The TinyOS Bootloader is rather slow and inflexible, larger programs can even corrupt the bootloader itself, transforming your Imote2 into an expensive brick (unless you are comfortable with JTAG).
3. We wanted to use Linux for the Upload process, but there was no such possibility with the TinyOS Codeloader

Because of this all, we did not fix the TinyOS Bootloader (which has some rather overcomplicated design by the way) but we wrote our own Bootloader, Codeloader, Linkerscript and startup code. In further developments we extended the functionality between these components and therefore our work provides some very useful features.

Comparison old vs. new version

Disadvantages of the standard-bootloader (preinstalled/TinyOS)

Advantages of the new bootloader

platform specific implementation of codeloader (MS Windows + cygwin) support only for C-executables (gcc) support for images up to 1-2MB, depending on location (primary/secondary) unreliable communication, sometimes failes low data-programming speed <20kb/s on USB possible corruption of the bootloader itself bad and incorrect documentation

platform independent codeloader (java) based on libusb support for C/C++-executeables (gcc / g++) capable of replacing the TinyOS bootloader support for images up to 28MB support for independent configuration/data storage communication model is technologie independent (programming via wireless may be possible with same communication protocol) programming only at boottime - more reliable avoids accidental programming of false node due to node specific configuration fast development using in-RAM-execution feature Optional Abort Handler in additionally given new startup code higher data-programming speed due to better USB utilization, DMA transfer and compression ~350kb/s permanent flash programming ~950kb/s in-RAM-execution documentation via technical report and detailed using doxygen

Documentation

• Detailed documentation available in the bachelor thesis (german)
• Basic concepts are presented in the technical report
• Implementation details can be found in the doxygen-documentation

Codeloader, Bootloader, Linkerscript, Startup Code

This small image should illustrate the difference between the two names "bootloader" and "codeloader". The bootloader resides on the Imote2 and is static, except for our new releases. The codeloader is a small Java program and is located on the pc-side. The new image is sent by the codeloader via USB cable to the bootloader on the Imote2.
Besides the bootloader and codeloader, there is additional work related to these concepts: The "Linkerscript" is provided to the linker and controls therefore the linkprocess. The bootloader and startup code need the image to be at specific addresses in the memory and the linkerscript assures that the image fulfils these requirements.
The "Loader" is included in every image. It does some initialization of the hardware and finaly starts the application. In case of a runtime error (such as a faulty memory access) the startup code also takes control and tries to output fault information and a backtrace of the current call stack.

Installation instructions
First of all you should know that the bootloader is not yet capable of updating itself. This means that you need JTAG access to the device.

• There is no possibility to revert to the original tinyos bootloader without using JTAG
• There is no possibility to update the bootloader without using JTAG

Thus it is highly recommended that you have the interface board and a JTAG dongle or some equivalent JTAG access and you should be familar with using these things. If you still consider using our bootloader, here are your instructions for installing it:

• using the TinyOS-Bootloader
• using an additional JTAG-Flasher (recommended in any case, resp. even needed with .NET edition)
  • jflashmm.exe
  • OpenOCD
• new arm-gcc for linux/windows is available
• Installation instructions for codeloader
  • Windows
  • Linux
  • MacOS

Building an image for the Imote2 platform

Note: we do not use the Wasabi xscale-elf toolchain anymore and we stopped supporting this toolchain. It is outdated and the binutils of that toolchain lack some features which were quite useful and there is no point in using such an old toolchain. Instead, we use a newer toolchain based on gcc-4.4.2 which we built from source.

If you want to build your own application (without TinyOS), you can start like this:

• Create your main.c and define your int main() { ... }. Obviously you should not return from that function.
• Define your interrupt handler. It should have the following signature __attribute__ ((interrupt ("IRQ"))) void hplarmv_irq()
  If you are writing C++, don't forget the extern "C"
• Define a function void hardwareInit(). This function is called before main and you should initialize your Hardware, such as the core frequency, power manager, interrupts and so on
• If you want do do something with the MMU, you should understand what our loader does. Read the technical report and maybe the code of the loader.
• You can optionally define hplarmv_undef, hplarmv_swi, hplarmv_pabort, hplarmv_dabort and hplarmv_fiq with appropriate signatures as hplarmv_irq to overwrite the code for undefined instruction handling, software interrupts, prefetch aborts, data aborts and fast interrupts respectively.
  If you do not define these symbols, a default implementation will give some fault information through the standard UART port
• Compile the code and link it using

  arm-elf-g++ -o image.elf objectfile1.o objectfile2.o -Wl,--whole-archive imote.a \
  	-Wl,--no-whole-archive -nostartfiles -T imote2.ld
  arm-elf-objcopy -Obinary image.elf image.out
  

  and upload image.out
• You can try our minimal example. Try to build and upload the image. You can also execute that image from ram using the -execram swith for the codeloader. Another thing you can do is to provoke some fault (e.g. uncomment the swi 56 line to raise a software interrupt) and see the output through the UART port.
• Our Loader can be configured in several ways. You can control several things with the Makefile of the loader (if you're about building the loader on your own - source is provided in the download section). Another way to control things are the symbols __RELEASE__ and _IMAGE_DESC. You can see the whole definition in main.c. If the symbol __RELEASE__ evaluates to true, no output is done in case of a fault.

Building an image for the Imote2 platform with tinyOS

NOTE: Your "old" TinyOS applications won't run directly by using the new code-/bootloader. We have changed the image location, which makes it neccessary to relink (recompile) your source code with a patched linkerscript and startup code.
We provide a patch for tinyos-2.x CVS, which applies the necessary changes to tos.x and toscrt0.s in your tinyos-2.x source folder. Just apply the patch using

cd path/to/tinyos-2.x; patch -p1 < /path/to/tinyos.patch

After that, the newly created images (main.bin.out) follow our "old image format", which can be used by our bootloader.
As you might guess, there is also a "new image format" but for the moment, we did not attempt to get it work with TinyOS. That means, that there are some features missing, such as executing the image from RAM, having detailed fault information in case of an errornous memory access and so on. If you want to get that work, you have to look above and try to merge these to methods of creating images.

Using Codeloader to flash Imote2

Consider you want to flash image.out:

java -jar codeloader.jar -file image.out

After starting the Imote, the image will be transferred. Note that the libusbJava.so must be in your JREs default library path, or you have to provide it using the -Djava.library.path=... switch.
Details on using the codeloader (i.e. configuration files)

NOTE: The new bootloader will only accept new images at boottime. This is wanted and expected behaviour and not considered as a fault.

Download

• Codeloader (Java) (formerly USBHostLoader)
  • Prebuilt codeloader.jar. You will also need the libusbJava.so, see below
  • Sources codeloader-2.2.tar.gz
• libusbJava-driver
  • Installation Package for Windows (including LibUsb-Win32 and libusbJava)
  • Linux, 686 32-Bit compatible
  • Mac
  • Patch to build libusbJava.so from source
  The driver was built from the Java libusb project (see references below) but for the newest version of the codeloader we had to patch the code (at least the java part of it) to transmit zero-length packets.
• Bootloader Image
  • Prebuilt bootloader-2.2.bin
  • Sources bootloader-2.2.tar.gz
• Config for...
  • older versions of OpenOCD for JTAGkey-Tiny
  • newer versions of OpenOCD for JTAGkey-Tiny
• Imote2 serial number-tool (src, win, linux)
• Image Loader
  • Linkerscript supporting C++ and moving image to 0x400000
  • Linkerscript supporting C++ and moving image to 0x400000 with support for SDRAM
  • Loader as archive for linking
  • Sources for Loader
• patched jflashmm
• codeloader.sh wrapper script
• Patch for tinyos 2.x
• Linux Loader
  Booting Linux was not a design goal of our loader, but newertheless there is the possibility to do so.
  Source archive: loadlin.tar.gz

References

• TinyOS
• libUSB
  • libusb
  • Java libusb / libusb-win32 wrapper
  • LibUsb-Win32
• JTAGkey-Tiny
• Oracle Java
• OpenOCD

Authors

Concepts and realization by

• Markus Engel
• Marc Krämer

---

	Superordinated page: Research
	research activities, projects and organisations

	Feedback
	Go to the contact details of the person in charge of this page

	Deutsch
	This page in german. Diese Seite auf deutsch.