27/07/2011

Running a C HelloWorld on ARM BeagleBoard

In this simple tutorial I will show you howto prepare your linux distribution for compiling and running C code on a BeagleBoard (ARM architecture). In short, you will need to install the cross-compiler, connect the board with your computer, load the compiled binaries to the board and finally execute them. Here we go in more details:

0. Prerequisites
  • Linux OS distribution (Ubuntu or Fedora should do)
  • BeagleBoard-xm with ARM A7 processor (or higher)


1. Install the ARM compiler

You will need to install a compiler for ARMv7 / Linux. See for example ARM/GNU Linux.

Let's assume you have installed the compiler into the following location: /opt/CodeSourcery/Sourcery_G++_Lite.

Then add the location into your PATH:
$ export  PATH=$PATH:/opt/CodeSourcery/Sourcery_g++_Lite/bin

And test your compile by executing:
$ arm-none-linux-gnueabi-gcc  -o hello.arm hello.c

This should work, later on we will use the generated hello.arm to run it on the beagle-board.

2. Connecting the BeagleBoard

Here is a nice manual on setting up the BeagleBoard on a linux-server machine:
http://elinux.org/BeagleBoardBeginners

After going through the manul, your board should be sitting on your network at some IP address, it may be for example 192.168.0.2

To connect to the board:
$ shh root@192.168.90.2

Tip: If you reboot your linux desktop, you probably want to do the following to re-enable the connection with the board:
$ sudo ifconfig usb0 192.168.0.3

3. Running HelloWorld on BeagleBoard

First, we need to copy the executable to the BeagleBoard:
$ scp hello.arm root@192.168.0.3

And then just login to the board and run the executable:
$ shh root@192.168.90.2
$ ./hello.arm 
Hello World!

And that should be all.

[Note: This tutorial is based on my notes when working with the beagle-board, so it may omit some details. Hope it will help anyway.]

26/07/2011

Real-time Embedded Java HelloWorld with FijiVM

The previous post introduced FijiVM. In this follow up we show how to compile and run simple Java programs with FijiVM.

Consider a classical HelloWorld Java Program :
public class HelloWorld {
  public static void main(String[] args) {
    System.out.println("Hello World.");
  }
}

1. Compile .java files

Running a Java compiler on this program will produce HelloWorld.class – a Java byte code representation of this program. In most Java implementations HelloWorld.class would then be provided as input to a Java VM. The program’s main method would be interpreted or JIT-compiled and run.
$ javac -d build/ HelloWorld.java


2. Java2C generation

Instead, to run this program in the Fiji JVM, HelloWorld.class would be provided as input to Fiji’s AOT compiler fivmc. The Fiji compiler then creates a native executable for the target platform as well as a build directory containing the generated code and the resources required to build this executable.
$ $(FIJI_HOME)/bin/fivmc  -o HelloWorld ./build/*.class

This command will then execute the Fiji Java2C compiler that translates the bytecode from the .build/ dir to a C source code and then generates a binary executable file "HelloWorld".

Notable compiler options and runtime variables are:

  • --more-opt   - enable maximal possible performance optimizations
  • --max-threads 5     - max number of threads running in the application
  • --g-def-max-mem=1200k    - set up the heap size
  • --g-def-trigger=850k             -  set up the trigger for the GC
  • export FIVMR_LOG_FILE=log.txt            - log file to document fiji runtime
  • export FIVMR_LOG_LEVEL=3  - filter the log messages, the level 3 will give you the most information
  • export FIVMR_FAKE_RT_PRIORITIES=true         - make FijiVM run on an OS that does not provide real-time guarantees
  • FIVMR_GC_COMPILE_INFO=true
  • FIVMR_GC_MAX_MEM=1m
  • FIVMR_TRIGGER_LOG_GC=true
  • FIVMR_SHOW_COMPILE_INFO=true
  • --no-inline - disable inlining of the C methods, useful when hacking the Java2C compiler or debugging the generated code.
  • --c-debug yes  - enables C debug mode

3. Running HelloWorld

And, to run:
$ ./HelloWorld
Hello World! 


4. FijiVM generated content

Inspection of the build directory after successful compilation gives us some insight into how Fiji works. The build directory contains five types of files:

XML files — one which contains the mapping from Java method to generated C function and two containing configuration for the Java component of the compiler;
- text files containing analysis of the Java program including string literals, referenced methods, types and classes;
- the generated, OS-independent C code representation of the program; • a copy of the Fiji runtime for the target platform;
- a generated Makefile used to build the executable, as well as build scripts to rebuild without regenerating content.

There are in effect two “main” functions, the C main function in the Fiji runtime and the generated C representation of the Java program’s main method. The runtime main invokes the generated Java main after it has completed its initial setup.

5. Cross-compiling with FijiVM


You an also use FijiVM running on your x86 machine to generate executables for other platforms. For example RTEMS running on LEON3 processor or ARM processor running on BeagleBoard. Setting up the FijiVM to cross-compile to a desired platform is very straightforward:

Example #1: adding a Mac OS X PowerPC target on OS X:
$ bin/add-target --name ppc --cc "gcc -arch ppc"

This will create a target called 'ppc' that will build a Fiji VM compiler and runtime that will generate a OS X PowerPC executables.  You can run such executables on almost all Macs, since they have a built-in emulator.  This is great for validating our PowerPC support.  Note that the argument to '--name' can be anything you like.  In many cases, the name is automatically inferred; but specifying one explicitly is often a good idea.  You can then run fivmc as follows to create a binary for PowerPC:
$ bin/fivmc --target ppc 

Example #2: adding an RTEMS target:
$ bin/add-target --rtems-build /path/to/rtems/bsp/build/dir


This will automatically infer everything it needs to know about the BSP, architecture, RTEMS version, etc.  It will also automatically name the target something like RTEMS-sis-rtems4.9-sparc-32, with useful aliases such as sis, rtems4.9, sparc, and sparc-rtems4.9.  So you can then run fivmc using any of the following --target options; whatever you like best:
$ bin/add-target --target sis 
$ bin/add-target --target sparc-rtems4.9 
$ bin/add-target --target sparc 
$ bin/add-target --target RTEMS-sis-rtems4.9-sparc-32 


And that's it. You should be now able to play with the FijiVM, target various platforms and use specific compile options to tailor the generated executables to your specific needs.

14/07/2011

FijiVM - A Real-time Java VM Overview

FijiVM is a real-time Java implementation which runs on RTEMS (a real-time OS for embedded devices) and a number of POSIX-compliant operating systems. It has the following components:
  • AOT Java2C Compiler: An ahead-of-time compiler written in Ruby and Java. This compiler takes in Java byte code and produces machine independent C. The Java component performs the code generation whilst the Ruby component acts as a harness for the Java component — providing configuration, marshalling input files, directing output to the appropriate location and finally invoking the C compiler on the generated code.
  • Fiji Runtime: A Java run-time written in C and Java. The runtime includes a real-time garbage collector as described in Section 2.5.2. The C code is invoked by the Java code by calling methods marked with Java’s native keyword.
  • FijiCore lib: A Java class library called FijiCore written in C and Java. Similarly to the run-time, C and Java code is bridged by the native keyword.
  • Real-time Garbage Collector - a set of GC algorithms offering both performance and real-time guarantees.
  • SCJ and RTSJ libraries (RTSJ is supported only partially) - SCJ and RTSJ libraries are distributed with FijiVM to offer alternatives to regular Java and Java+RTGC.
Let's look at some of these components in detail.

Garbage Collector

The key part of the FijiVM is a set of garbage collector algorithms that offer various performance characteristics and real-time guarantees. You can find more information about FijiVM's GC in Schism: Fragmentation-Tolerant Real-Time Garbage Collection. PLDI'10.

FijiVM Compilation Process


Since the FijiVM is based on an AOT compiler that translates the application from its Java byte-code to native C code, the compilation process is different from what we are used to in regular Java VMs. It is best illustrated on the following picture:




AOT Java2C Compiler

The Java2C compiler not only translates byte-code to C code but it performs number of tasks. There is several level of transformation, each introducing various code optimization techniques known from standard compilers. The byte-code is translated into Fiji's specific intermediate representation (IR) where the code is optimized further again. Until the final transformation generating the C-code, several phases of transformation+optimization is performed, each closer to the final product which is the generated C code. Again, illustrated on the following picture:



Fiji Libraries

FijiCore contains a subset of the standard Java class library, including generic collections and events from java.util, I/O and character set support from java.nio and java.io, arbitrary-sized arithmetic from java.math and all of java.lang, including annotations and reflections.

Instead of FijiCore, developers may also elect to use GNU Classpath (an open source implementation of the standard Java library). A second Fiji-specific class library called HardRTJ is currently in development. HardRTJ is intended to provide a library option with a smaller memory footprint than FijiCore, and a yet smaller feature set (note that to use any alternate library the library must be supported on the target platform).

SCJ and RTSJ support

Apart from the FijiVM libraries that replace a standard Java library known from a regular JavaVM distributions, FijiVM offers a support for extending libraries focused on real-time and safety-critical systems. The FijiVM comes with a distribution of oSCJ - an open-source Safety-critical Java implementation based on the JSR-302. Further, FijiVM offers a basic RTSJ (the JSR-1 implementation) support.


Resources
In the next post, I plan to show you how to use FijiVM to compile basic Java programs and how to use the VM in practice.

08/07/2011

Is Java ready for Real-Time?

"Is Java ready for Real-Time?" is a title of an invited talk given by Prof. Jan Vitek at MVD'10 - Midwest Verification Day, [slides].

The talk reviews advances of Java technology for hard real-time and safety-critical systems as of September 2010. Its a nice summary of the state of the art of Real-time Java and that's why I am linking it here.

20/06/2011

SCJ Checker : A new release, v2.0

We have just released a new version of the Safety-Critical Java Annotations Checker. The checker introduces an improved checking of memory-safety annotations along with a lot of other improvements and bug-fixes.

Along with the Checker, we have produced a short tutorial [PDF],  the document contains:
  • Checker installation and running instructions, 
  • the essential concepts and ideas behind the annotation system, 
  • various examples to illustrate the basic features of all the annotations, 
  • the key restrictions and rules enforced by the annotation system. 

The document is written with the motivation to give the reader the basic understanding of programming SCJ applications with the annotations.

27/05/2011

Safety-Critical Java Case Studies

We have recently put together a set of Safety-Critical Java applications. The implementation of these applications is open source, you can find them in our oSCJ repository, in directories oSCJ/examples and oSCJ/tools/checker/examples. The directories now contain more than 3O KLOC of Safety-Critical Java application code, here is a description of the most interesting case studies:

Quicksort is benchmark based on the quicksort algorithm. The application periodically sorts an array of objects that are allocated in an upper-scope, thus introducing a cross-scope manipulation of objects into the algorithm.

Thruster case-study simulates a spacecraft thruster engine. Control of the engine requires a 100-millisecond periodic activity to adjust the valve settings to avoid mechanical drift and, therefore, obtain an even fuel flow. Inspired by [Wellings-JTRES10].

Fast-MD5 implements a periodic execution of the Fast-MD5 encryption algorithm of a fixed string within its most inner memory area.

Webserver is an application handling http requests and was developed as a case study within the SquawkVM project to evaluate SCJ implementation running on SUN SPOTS embedded devices.

CDx-SCJ is an open-source family of benchmarks that can be used to measure performance of various hard and soft real-time platforms. The CDx benchmark consists of a periodic task that takes air traffic radar frames as input and predicts potential collisions.

Railsegment, developed by Kelvin Nilsen at Atego, is a complex simulator of a train control software that is responsible for collecting the data about speed and position of the train, analyzing them in real-time and adjusting the train speed according to the route plan.

Jpapabench is a SCJ benchmark based on the Paparazzi project which provides an open-source implementation of an autopilot for unmanned aerial vehicles (UAVs). The autopilot has been successfully tested on several real devices. The JPapabench is developed by Michal Malohlava at MFF UK, see the JPapabench webpage.

We believe that these applications are a representative set of SCJ case studies that demonstrate many SCJ concepts on real examples. 

02/05/2011

A family of real-time Java benchmarks

Be sure not to miss a new publication on the Collision Detector (CDx) benchmark [PDF]. Tomas Kalibera and his team put together an updated journal publication on CDx.

The article also reports on our performance comparison of the oSCJ platform running on LEON3 boards. Although the paper reports 50% overhead of the oSCJ in comparison to the C version of the benchmark, we are happy to announce that in the last few months we have been able to further decrease the overhead to ~28%.

The figure shows are new measurement of the improved performance of oSCJ. Further, our most recent experiments suggest that we can do even better. Stay tuned.

19/04/2011

JPapaBench : A new benchmark was born.

A new real-time Java benchmark - JPapabench, was developed by a team lead by Michal Malohlava at Charles University in Prague.

The most exciting facts about this benchmark are:
  • jPapabench is based on the Paparazi project which provides an actual implementation of an unmanned aerial vehicles (UAV) autopilot. Therefore, the benchmark is trully reflecting an autopilot software that is used in real life UAVs.
  • JPapabench is available in several versions: regular Java, Real-time Java, and Safety-Critical Java.
  • the project is open-source and available at http://code.google.com/p/jpapabench/.
Enjoy.

Paparazi project screenshot.

13/02/2011

Safety-Critical Java Specification : First Draft Released

The moment we all have been waiting for is here.

The first public version of the Safety-Critical Java Specification (JSR-302) was released. The draft can be downloaded from JSR-302 webpage, go to the Download Section.

To make a good picture of what SCJ is about, read the first two chapters. And if you want to know what we have been contributing to, read the Chapter 9 : Java Metadata Annotations.