Robert Schusters Blog

Fedora giving FOSS graphics driver “nouveau” a try

The free and open-source graphics driver for Nvidia graphics cards “nouveau” is going to be tested in the Fedora distribution. I have to say that, as a user, I have some troubles with Fedora right now but this move makes me happy. Even of I do not have this kind of graphics boards in use any more.

Yeah, you heard right: I don’t use Nvidia hardware and I find it great that Fedora is trying ‘nouveau’. I even read the development’ teams status updates and was anticipating the day some distribution would make their support official (I know it is in Debian as well).

Let me use this nice news to point to a big adversity that is coming to the embedded Linux world (or is already there). The PowerVR SGX is a graphics chip for embedded use. It is very powerfull but requires not much power to run. It is also contained in many of the new embedded CPUs like OMAP3/4, i.MX51 etc. Soon many consumer devices running a Linux-based OS will be delivered to users (e.g. the new Nokia internet tablet and the Touch Book). If you own an Intel Atom-based system with a ‘Poulsbo’ graphics chipset you already have an SGX implementation. The new Qt version already has a GL widget which can be driven by the SGX.

And this is where the shit hits the fan: At this time the OpenGL ES drivers for the SGX are proprietary and can only be distributed through your particular vendor. It is also like when asking about Jazelle things. Everyone is extremely close-lipped. I doubt that this has something to do with a possible move towards free software (*curses NDAs*).

I can’t do anything about this but I can utter my discontent. If you are affected by the above situation you may do so, too.

My BeagleBoard also contains an SGX.

Shark bites ARM

No this post is not about a tragic accident.

It is about the half-way successful attempt to get the Shark JIT compiler, which is funded by Red Hat and developed by Gary Benson as part of the Zero (assembler) port of the Hotspot Java VM, running on devices equipped with ARM processors. If this catches your interest then you won’t be dissappointed.

The state of the union is this:

  root@beagleboard:~# ./azureus
  1       java.lang.String::equals (88 bytes)
  2       java.lang.String::hashCode (60 bytes)
  3       java.lang.String::indexOf (151 bytes)
file:/usr/share/java/Azureus2.jar ; file:/usr/share/java/swt-gtk-3.4.jar ; file:/home/root/
  4  !    sun.nio.cs.US_ASCII$Encoder::encodeArrayLoop (279 bytes)
  5       java.lang.String::lastIndexOf (156 bytes)
  6       java.lang.String::charAt (33 bytes)
  7       java.util.Properties$LineReader::readLine (452 bytes)
  8       java.util.Properties::loadConvert (505 bytes)
  9       java.lang.Object::<init> (1 bytes)
 10       java.io.UnixFileSystem::normalize (75 bytes)
 11       java.lang.String::replace (142 bytes)
 12       java.lang.String::indexOf (166 bytes)
 13       sun.net.www.ParseUtil::encodePath (336 bytes)
 14       java.lang.String::startsWith (78 bytes)
 15       java.util.jar.Manifest$FastInputStream::readLine (167 bytes)
 16  !    java.io.BufferedReader::readLine (304 bytes)
 17  !    sun.nio.cs.US_ASCII$Decoder::decodeArrayLoop (241 bytes)
 18       java.lang.String::getChars (66 bytes)
 19       sun.misc.MetaIndex::mayContain (51 bytes)
 20       java.lang.CharacterData::of (120 bytes)
 21       java.lang.CharacterDataLatin1::getProperties (11 bytes)
 22       java.lang.Math::min (11 bytes)
 23       java.util.HashMap::indexFor (6 bytes)
 24       java.lang.String::startsWith (7 bytes)
 25       java.lang.String::<init> (20 bytes)
 26       sun.misc.URLClassPath::getResource (74 bytes)
 27       java.lang.AbstractStringBuilder::append (60 bytes)
 28  !    sun.nio.cs.ISO_8859_1$Encoder::encodeArrayLoop (356 bytes)
 29       org.gudy.azureus2.core3.util.ByteArrayHashMap::hash (29 bytes)
 30       java.util.HashMap::hash (23 bytes)
 31  !    sun.nio.cs.ISO_8859_1$Decoder::decodeArrayLoop (263 bytes)
 32       java.nio.Buffer::position (42 bytes)
 33       java.nio.charset.CoderResult::isUnderflow (13 bytes)
 34  !    java.net.URL::<init> (543 bytes)
 35       java.util.HashMap::put (126 bytes)
 36       java.util.HashMap::transfer (83 bytes)
 37       java.util.HashMap::get (79 bytes)
 38       java.lang.Character::toLowerCase (9 bytes)
 39       java.lang.CharacterDataLatin1::toLowerCase (39 bytes)
 40       java.lang.String::toLowerCase (436 bytes)
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error (os_linux_zero.cpp:223), pid=1728, tid=1762903184
#  Error: caught unhandled signal 11
#
# Java VM: OpenJDK Shark VM (14.0-b08 mixed mode linux-arm )
# Distribution: Built on Debian GNU/Linux unstable (sid)
# An error report file with more information is saved as:
# /home/root/hs_err_pid1728.log
#
# If you would like to submit a bug report, please include
# instructions how to reproduce the bug and visit:
#   http://icedtea.classpath.org/bugzilla
#

This may look terrible to you, but is actually much much more than what we had the weeks before. Lets tell the story from the beginning.

As you may have read on the BugLabs blog tarent was contracted to get OpenJDK running on the Bugs. Since BugLabs uses a variant of OpenEmbedded named Poky this meant getting OpenJDK cross-compiled. This alone was an interesting and complicated thing but was eventually finished and I did a presentation at FOSDEM 2009 about this work (slides: PDF ODF).

The work on OpenJDK contained three parts:

• get it running with the Zero port
• get it running with Cacao as the VM
• get as far as possible with Zero and the Shark JIT compiler

The first two items where completed in time and showed good results. Back in February the cross-compiled Shark was based on LLVM 2.4 and could barely display “Hello World” and then crashed abruptly. In the following weeks I had no time to look at this problem. However at FOSDEM I met Xerxes Ranby who is also interested in getting OpenJDK (through IcedTea) running on his ARM devices.

This is what HelloWorld looked like:

root@beagleboard:~# java HelloWorld
Hello World!
java:
/home/rob/oe/beagle/tmp/work/armv7a-angstrom-linux-gnueabi/llvm-2.4-r0/llvm-2.4/include/llvm/CodeGen/MachineOperand.h:251:
int64_t llvm::MachineOperand::getImm() const: Assertion `isImm() &&
"Wrong MachineOperand accessor"' failed.
Aborted

Things started moving again last monday (23rd). Efforts to find out what is wrong with LLVM 2.4 eventually culminated in using the next release 2.5 since the method in which the error occured was already removed.

To my pleasure the update had the immediate result that the major Java enterprise application (aka HelloWorld) worked flawlessly:

root@beagleboard:~# java -XX:+PrintCompilation HelloWorld
  1       java.lang.String::equals (88 bytes)
Hello World!

The line above “Hello World!” indicates that Shark has compiled a method and run it. Nice!

Yet, lesser known Java applications like Azureus had a little trouble:

root@beagleboard:~# ./azureus
  1       java.lang.String::equals (88 bytes)
  2       java.lang.String::hashCode (60 bytes)
  3       java.lang.String::indexOf (151 bytes)
file:/usr/share/java/Azureus2.jar ; file:/usr/share/java/swt-gtk-3.4.jar
;   4file:/home/root/
  !    sun.nio.cs.US_ASCII$Encoder::encodeArrayLoop (279 bytes)
  5       java.lang.String::lastIndexOf (156 bytes)
  6       java.lang.String::charAt (33 bytes)
  7       java.util.Properties$LineReader::readLine (452 bytes)
  8       java.util.Properties::loadConvert (505 bytes)
Cannot yet select: 0x8ed18: i32,ch = AtomicCmpSwap 0x8e2f4, 0x8ea70,
0x8eeb0, 0xdf2a8 <0x11844c:0> <volatile> alignment=4

Aborted

This time the reason is to be found in the last line. It tells you that it cannot generate machine code for “AtomicCmpSwap”.

At first I tried my luck getting this support into LLVM. However I am not the compiler guy and had my difficulties understanding how that should be done. I am sure that someone with the neccessary knowledge could do it in a few minutes …

Nevertheless Xerxes Ranby had the cool idea to try something different. The use of the “AtomicCmpSwap” comes from the Shark implementation itself. The function is a built-in or intrinsic in LLVM and really can be considered to be like a function. Xerxes’ idea now was to replace the use of “AtomicCmpSwap” with a call to a function that does exactly the same and is implemented within Zero. When I came home today Xerxes already had a patch for me to try out. I rebuilt Shark and after installing it on my Beagleboard started Azureus. The result is what I called the state of the union above.

Since it is clear we are on a winning streak work on this is continuing right now. For all the mentioned experiments we where using IcedTea 1.4 and 1.4.1 which are more than 4 weeks old. In the meantime a lot of changes have been applied to Shark. Keep your fingers crossed that I can soon show you some nice screenshots of a Java app running on Shark.

PS: LLVM’s MIPS backend is also missing atomic operations support and our approach to it, will work there as well.