zafena development

July 10, 2015

Processing 3 is running for the first time on a Raspberry Pi using Eric Anholt’s Mesa3D VC4 driver!

Video of the Processing 3 RGB cube demo running on the Raspberry Pi using Eric Anholt’s Mesa3D VC4 OpenGL 2 driver:

Thanks to the free software Mesa3d vc4 driver, the raspberry pi suddenly turned from a mobile opengl es 2 system into a “desktop” opengl 2 system.

Processing 3 is using JogAmp JOGL to tap into OpenGL hardware acceleration on the armv6 Raspberry Pi 1 and armv7 RaspberryPi 2 systems.

Hold on what is going on here, how can I setup the free software vc4 driver on my Raspberry Pi system?

This is a collaboration with Eric Anholt, anholt, and Gottfried Haider, gohai, to get Processing 3 running on the Raspberry Pi.

Eric Anholt has worked about a year to implement a full OpenGL 2 Mesa3D driver for use on the Raspberry Pi by using the Video Core 4, VC4, GPU.

Getting Eric Anholt’s Mesa3D VC4 driver running on a Raspberry Pi is easily done thanks to the work by gohai.
gohai started out roughly following Eric’s notes here:
And then put together a buildbot in Python, to produce system images for use on the Pi or Pi2.

Kernel, Mesa, XServer packages & dependencies are from git. System image produced using gohai’s buildbot

gohai publish daily builds using his bot at:

Myself I have contributed to fix corner-cases in JogAmp JOGL OpenGL initialization to get it all running.

What was the problem using the proprietary OpenGL ES vc4 driver on the Raspberry Pi system?

The OpenGL ES standard do not cover how the native window is initialized.
When you initialize opengl es then you must pass a platform specific EGLNativeWindowType, EGLNativePixmapType and EGLNativeDisplayType depending on the OS you use.

If you read the Khronos header for eglplatform.h you will notice that the EGLNativeWindowType is different for
Windows: typedef HWND EGLNativeWindowType;
Mac: typedef void *EGLNativeWindowType;
Android: typedef struct ANativeWindow* EGLNativeWindowType;
Unix X11: typedef Window EGLNativeWindowType;

Creating an on-screen EGL rendering surface requires you to to use the eglCreateWindowSurface function, which takes a EGLNativeWindowType parameter. On the Raspberry Pi, however this is implemented as a EGL_DISPMANX_WINDOW_T struct, which is defined in eglplatform.h as:

typedef struct {
int width; /* This is necessary because dispmanx elements are not queriable. */
int height;

As you can see RaspberryPi using the properitary binary drivers uses a Broadcom unique native window type that is incompatible with X11.
This is the reason why we cant use the Processing code as is to pass a Java AWT Unix X11 Window to initialize OpenGL ES, EGL will return an error that you have passed an incompatible structure to eglCreateWindowSurface.

When using Eric Anholt’s Mesa3D vc4 driver then EGL will expect a Unix X11 Window for its EGLNativeWindowType and this is why processing will work out of the box when Erics Mesa3D vc4 driver in use. Eric’s vc4 driver also implements OpenGL 2 that can be initialized using GLX. GLX allows you to run Processing with OpenGL acceleration across remote X11 network connections!

Xerxes Rånby

August 4, 2013

JogAmp Ji Gong project announcement

“Ji Gong shall enable the VM technology across platform and devices.”

Sven Gothel Aug 04, 2013; 9:45am ”
Bug 790 <>
Bug 698 <>


Current Ji Gong Dependency
including the OpenJDK API subset, etc:


1st Milestone – Core JRT for all platforms ..


Calling for volunteers.

We are looking for sponsors!




OpenJDK and its chair decided not to go mobile?

Bug 698 was written due to the “Fear, uncertainty and doubt” (FUD)
strategy of Oracle of not giving express permission to use OpenJDK
in compliance w/ the 4 freedoms of software (FSF definition).

On the contrary, Oracle gives a patent grant for using OpenJDK for desktop only,
implying mobile use may be prohibited.

This implication is highly likely non-sense, especially in the light of
the latest Oracle vs Google case where Oracle was not able to
substantiate a patent infringement by Google’s Dalvik VM.

However .. the current situation lacks of:
OpenJDK builds for Windows, OSX, Android, ..
IcedTea-Web builds for Windows, OSX, Android, ..

As Xerxes put it: The horse is bound to a chair and is not running ..

Project Name

Ji Gong <>
“Unlike a traditional Buddhist monk, Daoji did not like following traditional monastic codes. Daoji had a penchant for openly eating meat and drinking wine; his robes were often tattered and dirty from travelling from place to place, and stumbling while intoxicated. However, Daoji was kind hearted and was always ready to lend a helping hand to ordinary people. He would often treat the sick and fight against injustice. The monks, bewildered and fed up with his behavior, expelled Daoji from the monastery. From then on, Daoji roamed the streets and helped people whenever he could.”

Hence Daoji does people good while not necessarily conforming to certain arbitrary rules,
while maintaining sanity and being kind hearted.

The character is quite popular in the Asian culture.

Project Spirit


This project shall match the kind direction of it’s name giving character,
while also serving w/ JogAmp’s goals of being a technology enabler.

Ji Gong shall enable the VM technology across platform and devices.

This project must not necessarily being maintained by the JogAmp community.
On the contrary .. we would prefer this effort to be done from the original authors,
i.e. OpenJDK and IcedTea-Web.

However, until the goals below and this spirit of a free solution is being picked
up, we may continue pushing it forward from here.

Note: Bug 698 sadly wasn’t being replied to by neither Oracle nor the OpenJDK team.
Of course, no surprise here, since for Oracle it might be a conflict of interest
due to their ‘goals’ to market their ARM hotspot proprietary solution
and the OpenJDK team consist mainly of Oracle and RedHat members.
The latter focuses on server solutions and is highly cooperating w/ Oracle.

Project Goal


– Availability of the GPLv2 based OpenJDK runtime environment (JRT/JVM)
– Desktop (Linux, Windows, OSX, ..)
– Mobile (Android, other phones and tablet OS [maybe even iOS])
– VM CPU support:
– Intel/AMD 32bit and 64bit
– ARM based CPUs [Hotspot client/server n/a at time of writing. May need to use JamVM or AvianVM, ..]

– Optional AWT/Swing/etc – maybe added at a later time

– Web Plugin based on IcedTea-Web (JWeb)
– Capable to run w/o AWT using a pluggable windowing subsystem implementation
– Optional AWT/Swing/etc – maybe added at a later time

” Quoted from:

JogAmp forum: Project: Ji Gong

February 6, 2013

I have just returned from FOSDEM where we Julen Gouesse, Sven Gothel and Xerxes Rånby presented a JogAmp freejava love talk with some live demonstrations running hardware accelerated on x86 laptop, android/meego phone/tables and GNU/LInux systems such as the AC100 and RaspberryPi.
Slides, Video and Teaser from the JogAmp FOSDEM freejava love talk are now online:

If you want to design a game then we recommend you to use JogAmp indirect through a game engine library such as libgdx or JMonkeyEngine 3. We have a forum thread inside the JogAmp community where we work on improving engine support for embedded devices such as the Raspberry Pi using said engines. By using a game engine will get you up to speed developing professional games that can be run across all devices and formfactors.
The video and teaser recordings also includes footage of the JMonkeyEngine 3 JOGL 2 backend initialized by Julien Gouesse that we for time reason never managed to show during the strict 40min talk and live demo at FOSDEM.

Inside the FOSDEM talk we ran the open-source libgdx game pax-britannica using the new libgdx JogAmp JOGL 2 port initialized by Julien Gouesse in combination with the new hardfloat fixed CACAO ARM JVM found in the new IcedTea 6 1.12 release on the Raspberry Pi.
we also ran the JogAmp Jake2 port, a port done by Sven Gothel, using the armhf JamVM from IcedTea 7 on the ac100.
Both opensource games of course rocked running using freejava!
The point that we wanted to show is that if you start to use the dedicated love using the media accelerator found in all new devices your java applications rendering will run *equally* fast regardless of the JVM implementation, since the rendering is then performed by the GPU instead of the CPU.

For demonstation purposes: I had to extend the libgdx backend with a custom mouse pointer in order for otherwise touchscreen oriented games such as pax-britannica to work on the Raspberry Pi from console, the reason why this is needed is because there is no highlevel compositing windowmanager running on the RaspPi adding the overlay mousepointer for you like what you are custom to see when running desktop applications using X11. This libgdx RaspberryPi mouse pointer branch allowed me to test all touch oriented libgdx games and demos from console using a mouse input device.

While we know that compilation of custom JVM can be tricky I have prepared a RaspberryPi armhf CACAO that you can use as an drop in replacement into any OpenJDK 6 installation (/usr/lib/jvm/java-6-openjdk-armhf/jre/lib/arm/server/ This was built using the IcedTea 6 1.12 release from inside a Raspbian chroot.
For JamVM simply install the openjdk-7-jdk package and run it using java -jamvm its already built and packaged by the Raspbian team and work great! The new CACAO armhf is found here:

The Raspberry Pi Rasbian armhf distribution have now packaged IcedTea 6 1.12.1 and included it in the distribution, this means that you can test the new armhf CACAO JVM and JamVM JVM by simply installing the openjdk-6-jdk package.

sudo apt-get update
sudo apt-get install openjdk-6-jdk
java -jamvm -version
java -cacao -version

Also a great KUDOS for Qun, our dear camera-woman!

Cheers and enjoy the love!
On behalf of the JogAmp community – Xerxes

November 11, 2012

2008: Sun Microsystems invested heavily into using hardware acceleration on mobile devices using JOGL. This was the foundation to get JavaFX 1.3 running across devices. Video of James Gosling, Ken Russell and Sven Gothel on stage at JavaOne 2008 keynote
Ken Russel later wrote his last Sun blog-post that covers the technology demonstrated in this first OpenGL ES 2 JOGL demonstration:
Later during the same year Sven Gothel demonstrated hardware accelerated OpenMAX video decoding on the same Tegra 1 mobile device using the new re-architectured JOGL 2 with stellar mobile support:

2009: The core members of the JOGL and Java3D team left Sun before Oracle took over and forked JOGL.,21516.0.html

2010: The JogAmp community was created.

2011: Oracle Gives up on Java3D (and JOGL) for RIA (Webstart and Applets)
The Oracle decision to remove all signed Java3D and JOGL builds from their servers, and hence break all existing online Java3D/JOGL applications using the SUN/Oracle builds, this have only been mentioned by Oracle inside the support forum.
Fortunately JOGL and Java3D was originally released under a BSD license so it was possible for the community to keep-on maintaining the bindings and provide JogAmp signed builds.

2012: Oracle work on flushing out its own use of JOGL in JavaFX by removing jogl-prism. Oracle no longer give programmers direct access to OpenGL using their APIs.
Oracle announced during JavaOne 2012 that Oracle would like to get help from the community to port JavaFX to new platforms under the OpenJFX project. Surely the community can help by re-implement jogl-prism and adding raw JOGL support into OpenJFX to ease future OpenJFX porting efforts.

JOGL v2 is actively maintained by the JogAmp community.

JOGL v2 now runs on the latest GPU cores and work on top of any JVM. JOGL v2 contains its own platform independent NEWT windowing toolkit. NEWT applications targeting the GL2ES2 or GL2ES1 profile, both using a common subset of OpenGL and ES calls, can be deployed across different platforms and devices from desktop to mobile without code change. – Documentation, slides, and videorecording from the latest live JogAmp demonstrations

Java3D is now also maintained by some members of the JogAmp community.
hharrison now maintain Java3D on github
Julien Gouesse: Java 3D est de retour [Java 3D is back]

August 28, 2012

Last week I stumbled across and dipped my toes into, Avian, a new small and fast JVM that included a JIT for ARM.
Avian have been developed in the open during the last 5 years, I was quite surprised that all this was for me unheard of!
Avian got support to be used in combination with the OpenJDK 7 class library’s:

Build instructions to build Avian on a Raspberry Pi running Raspbian.
sudo apt-get install openjdk-7-jdk libz-dev git

# you may change these two export to match your system
# use i386, x86_64, armhf, armel or ppc here
export ARCH=armhf
# use i386, x86_64, ppc or arm here
export JVM_ARCH=arm

# clone and build avian in combination with one existing OpenJDK 7 jdk image
# It takes about 40 minutes to perform this compilation natively on a Raspberry Pi.
git clone
cd avian
JAVA_HOME=/usr/lib/jvm/java-7-openjdk-${ARCH} make openjdk=/usr/lib/jvm/java-7-openjdk-${ARCH}

# Run the avian test suite to check that your newly built avian pass all expected functionality
JAVA_HOME=/usr/lib/jvm/java-7-openjdk-armhf/ make openjdk=/usr/lib/jvm/java-7-openjdk-armhf/ test

# Install the built avian into OpenJDK 7
sudo mkdir -p /usr/lib/jvm/java-7-openjdk-${ARCH}/jre/lib/${JVM_ARCH}/avian
sudo cp build/linux-${JVM_ARCH}-openjdk/ /usr/lib/jvm/java-7-openjdk-${ARCH}/jre/lib/${JVM_ARCH}/avian
# Add -avian KNOWN to the end of the jvm.cfg file in order to make java -avian work
sudo sh -c "echo '-avian KNOWN' >> /usr/lib/jvm/java-7-openjdk-${ARCH}/jre/lib/${JVM_ARCH}/jvm.cfg"

# hack for ubuntu and debian to let openjdk find the
sudo ln -s /usr/lib/jvm/java-7-openjdk-${ARCH}/jre/lib/${JVM_ARCH}/avian/ /usr/lib/jvm/java-7-openjdk-${ARCH}/jre/lib/${JVM_ARCH}/
# the hack/workaround is required if you see the following error when running java -avian -version
# Error: Could not create the Java Virtual Machine.
# Error: A fatal exception has occurred. Program will exit.
# The above hack is not required if you compile your own build of IcedTea or OpenJDK from upstream source directly

# Done now try run it
java -avian -version
# The output to be seen
java version "1.7.0_03"
OpenJDK Runtime Environment (IcedTea7 2.1.1) (7~u3-2.1.1-1+rpi1)
Avian (build null, null)

Avian is heavily tested by its main developers for use running Eclipse SWT applications,
users of Avian have only had working Swing and AWT running during this last month.
expect Java2D to still be a little shaky when using Avian, I expect these Java2D issues to stabilize quickly thanks to the rapid development cycle that takes pace on git hub and thanks to the internal Avian test-suite that gets run after each build.

Avian got some interesting properties:
The JIT is good, it runs at a speed similar to CACAO JIT and the Thumb 2 JIT add-on for Zero.
It is embeddable, you may use Avian to create a small standalone executable that include both the JVM and your application, Avian then uses proguard to cut out and bundle only the needed code from the large OpenJDK class library that is required to run your application, all documented in the avian build documentation. This embeddable feature would possibly allow, free and open-source, OpenJDK applications to be deployed inside walled gardens such as mobile platform application stores, some people even got it to run on webOS. Avian makes Java viable on low footprint embedded systems, a generated standalone executable can be compressed to less than 1Mb!

July 30, 2012

Robert Lougher have updated JamVM to work on the new Raspberry PI armhf “Raspbian” image, thank you Robert! You can compile and test this latest JamVM version from source on a Raspberry PI by running the following lines inside a terminal:

sudo apt-get install openjdk-6-jdk git libtool autoconf automake

git clone git:// jamvm

cd jamvm

./ –with-java-runtime-library=openjdk6


mkdir /usr/lib/jvm/java-6-openjdk-armhf/jre/lib/arm/jamvm

sudo cp src/.libs/ /usr/lib/jvm/java-6-openjdk-armhf/jre/lib/arm/jamvm/

sudo sed -i ‘s#-jamvm ERROR#-jamvm KNOWN#’ /usr/lib/jvm/java-6-openjdk-armhf/jre/lib/arm/jvm.cfg

java -jamvm -version

java version “1.6.0_24″OpenJDK Runtime Environment (IcedTea6 1.11.3) (6b24-1.11.3-2+rpi1)

JamVM (build 1.6.0-devel, inline-threaded interpreter with stack-caching)

I have update IcedTea6 1.12 and IcedTea7 2.3 release branches to include this updated version of JamVM. Distributions like Debian/Fedora/Ubuntu/Arch and Raspbian will get this new work when they update IcedTea to include the next IcedTea release or security update. This is the first JamVM + OpenJDK update in 2012, this update also include support for JamVM to run the QT-Jambi GUI toolkit.

February 15, 2012

Jim Connors at Oracle posed a interesting valentines gift, a compare of the latest open-source OpenJDK ARM JVM inside IcedTea6, 1.12pre, HEAD against their closed source Hotspot c1 and c2 implementations.

The Oracle blog antispam system in use...

I would have liked to comment directly on your blog but your spam system kept me at bay so i posed my reply to you here instead 😉

The OpenJDK Zero *mixed-mode* JVM used in Jims compare includes the now re-maintained ARM Thumb2 JIT and assembler interpreter port that got re-introduced in the IcedTea6-1.11 release.
Many of the OpenJDK JVM like CACAO and JamVM are by design tuned for embedded and client use and thus show strength in both low memory overhead and fast startup time.

When testing JVM performance on ARM its important to remember that the default optimization settings used by the compilers to build the JVM do matter.

The Debian 6.0.4 squeeze “armel” distribution use ARMv4t optimization by default. This low optimization level enable the Debian built packages run on as many kind of different ARM broads and CPU’s as possible. The trade-off are that you basically disable all VFP, floating point, optimizations and make synchronization code slower by forcing the JVM to call the Linux kernel helper instead of using faster ARMv7 atomic instructions directly.

To give OpenJDK JVM a better match i would suggest re-running the benchmark using OpenJDK built on top of Debian wheezy “armhf”, Ubuntu Precise “armhf” or Fedora F15 that by default optimize for the ARMv7 thumb2 instruction-set and make use of the VFP unit inside the CPU, also the “armhf” ABI allows better argument passing between library functions inside the CPU VFP registers. Two OpenJDK JVM, JamVM and Zero,  are already updated to support the new “armhf” hardfloat ABI.

You could also choose to run this benchmark using OpenJDK JVMs built using the Ubuntu Precise “armel” tool-chains that still use the legacy soft-float ABI while still adding ARMv7 Thumb2 and VFP optimizations. All OpenJDK JVM tested in this compare would run better by simply using a higher optimization level during the build.

All in all thank you Jim to give an introduction to the ARM OpenJDK porting effort, I look forward to the follow up article where all the JVM makers have picked their favourite GCC/Clang/Foo compiler options and suitable matching compile flags. One idea are to create a OpenJDK binary release with a custom OpenJDK installer that would ease testing of tuned OpenJDK JVM implementations.

Cheers, Xerxes

December 1, 2011

LLVM3.0 target feature matrix :

LLVM 3.0 have been released

LLVM includes the JIT that can be used to speed up OpenJDK on all platforms that currently only have support by the platform independent Zero C++ hotspot port.

The JIT in LLVM have been redesigned from the ground up to use the same code path ways as used by the static compilation in LLVM by using the new MCJIT that in turn are based on the new direct Machine Code emission back-end. LLVM will over time drop support for the old “classic” jello-JIT.

OpenJDK Shark + LLVM 3.0 patches exist on zero-dev

I have posted some LLVM 3.0 patches to zero-dev that allows OpenJDK Shark to be built using this new MCJIT. Grab them all at:

Builds and testers are needed for MIPS, PPC and ARM

Shark are known to work stable on X86 hardware where all parts of LLVM have great community support. For all other architectures please check out the LLVM Target Feature Matrix.

According to this Target Feature Matrix table, MIPS JIT support are now GREEN! MIPS devs should try the OpenJDK + Shark + LLVM 3.0 combination, it could turn out to be really good. If you have a spare MIPS machine that are online 24/7 do consider adding it to the LLVM and IcedTea buildbot network!

For ARM the MACH-o JIT backend are supposed to be working, testers of OpenJDK + Shark + LLVM 3.0 on darwin based platforms like the iPhone and iPad please step forward, this combination looks to be working, at least on paper.

All ARM Linux users have to wait until the ELF MCJIT are stable before we can expect to run Shark using LLVM 3.0 and later.

PPC testers are also needed, LLVM support for PPC have been 90% good in the past.. it could be all broken or all working, no-one really know at least the LLVM darwin PPC buildbot shows some green lights but we currently do not have any IcedTea PPC buildbots to check if Shark + PPC work at all.

May 2, 2011

My first Android window runnign on top of unmodified OpenJDK using Icedrobot.

Android window running on top of a unmodified OpenJDK 6b22 using IcedRobot.

While I was reviewing Guillaume’s graphics stack patches for IcedRobot this window poped up on my desktop. Im amazed, IcedRobot are able to run Android Activity’s on top of a GNU/Linux desktop using a unmodified OpenJDK 6b22. Android app developers prepare yourself to start see your apps migrate into GNU/Linux desktops!

If you are new to IcedRobot then check out Mario’s nice statement on the current overall progress of the project.


March 18, 2011

Thanks to the IcedRobot project, it are now possible to run Android .dex files on top of any GNU/Linux system using OpenJDK and JamVM!
xranby@babbage:/wd/daneel$ java -jamvm -showversion -cp target/daneel-0.0.1-SNAPSHOT-jar-with-dependencies.jar \
-Djava.system.class.loader=org.icedrobot.daneel.loader.DaneelClassLoader -Ddaneel.class.path=src/test/java/resources/HelloDroid.dex \

java version “1.6.0_18”
OpenJDK Runtime Environment (IcedTea6 1.8.3) (6b18-1.8.3-2+squeeze1)
JamVM (build 1.6.0-devel, inline-threaded interpreter with stack-caching)

Trying to find class ‘org.icedrobot.test.HelloDroid’ …
Hello Android!

xranby@babbage:/wd/daneel$ uname -a
Linux babbage 2.6.28-11-imx51 #42 Tue Jun 23 11:27:23 BST 2009 armv7l GNU/Linux


Older Posts »

Powered by WordPress