64 bit ARM serial

Tonight I managed to find a C2 to continue to experiment with. I followed the 7 steps outlined previously to make sure the steps and the .so file are still good on another machine, and am happy to say there are no problems.

I hope to give the nrjavaserial jar another go in the coming days.

https://github.com/xsnrg/ARM64/blob/master/nrjavaserial-3.12.0.jar

New jar to try. I will try to test it myself later, but need to run for a bit.

I also get this with that new version:

openhab | openhab> java.lang.UnsatisfiedLinkError: Can't load library: /opt/libNRJavaSerial.so thrown while loading gnu.io.RXTXCommDriver openhab | java.lang.NoClassDefFoundError: Could not initialize class gnu.io.RXTXCommDriver thrown while loading gnu.io.RXTXCommDriver

Sorry, no, seems to work now! Pine64 @ xenial

Hey Guys,

just dropped into this thread while failing to set up my ComfoAir-binding with OH 1.8.3 on my pine64 (not openHAB-edition but plain KS board).

I went a long way of HW-debugging to get the serial wiring correct and am now using ComfoAir -> MAX3232 TTL -> uart2 on PINE (RPi2-Bus pins 8/10). Now I can read (manually using a small python script) incoming data on /dev/ttyS2 (after enabling the uart2 in the device tree blob). But OpenHab’s comfoair binding said, it did not know about /dev/ttyS2 and I have no serial ports.

Enabling the debug-log led me to the actual exception, namely java.lang.UnsatisfiedLinkError: /tmp/libNRJavaSerial_ubuntu_0/libNRJavaSerial.so: /tmp/libNRJavaSerial_ubuntu_0/libNRJavaSerial.so: wrong ELF class: ELFCLASS32 (Possible cause: architecture word width mismatch) and this seems exactly what this thread is about.

So: what do I need to do? Does a current nightly build of OpenHab already contain a fix? Do I have to download the .so manually and point OH to it? Any advice?

If someone comes across this thread because he/she has the same issues as me:

As @Kai pointed out in https://github.com/openhab/openhab/issues/4413 the 32/64-bit problem can be solved by running OpenHAB using a 32-bit JVM.

On a PINE A64+ with Ubuntu 16.04 this can be done as follows:

sudo dpkg --add-architecture armhf
sudo apt-get update
sudo apt-get install openjdk-8-jre-headless:armhf

This will install a 32-bit JVM in /usr/lib/jvm/java-1.8.0-openjdk-armhf which you need to call in startup.sh so it is used instead of the default JVM. Then, the serial library works flawlessly.

Just want to add: the 32-bit JVM makes sense even if you do not use any serial connectors: I noticed that the 64-bit JVM is terrible slow on the PINE, the 32-bit is about 50% faster. I assume that all optimizations that Oracle has done for ARM embedded are only contained in the 32-bit version, while the 64-bit version is optimized for large servers instead.

1 Like

I just got a brand new RPi3, which has also a 64Bit CPU. So this is also relevant for me? I installed the latest raspbian OS with NOOBS, which has JVM included. When I type “java --version”, I can’t see any details if this is the 32-bit JVM or the 64-bit JVM. At least it’s the Oracle JVM.

Any suggestions how I can make sure I have a 32-bit JVM?

Thanks!

The RPi3 just uses 32-bit as the rest of the RPis, so no need to worry.

Java on the Odroid C2 is much faster on the 64 bit version than on the 32 bit version of Java. Is there still going some effort in fixing this issue, apart from not running the 64 bit version of Java?

It’s worth noting that the Oracle Java versions are much faster than the OpenJDK versions.

You shouldn’t use OpenJDK anyway, there are several issues related to OpenJDK when using openHAB.

1 Like

The work-around I posted does work, but it is more of a hack. The real work needs to happen in the nrjavaserial project where the corresponding tickets are noted above. Until that happens, @Kai has chosen to use the 32 bit version as it works.

Do you have any performance comparison figures on that? I’d be interested to find out why this should be the case on the C2, while it does not apply to the Pine64?

i will try to time the startup time with the different versions of Java.

I’ve tested the different versions of Java on my Odroid C2 with SciMark 2.0a and scripted the test. These are the outputs of the different JAVA versions on my system. Maybe i’m testing incorrectly for Openhab. If i need to run another test, please let me know.

However, it turns out that the armhf version of Oracle JAVA is indeed a little bit faster than the arm64 bit versions. I guess i was wrong.

SciMark 2.0a

Composite Score: 194.0942219779302
FFT (1024): 133.43334608804489
SOR (100x100): 354.2196668623875
Monte Carlo : 116.60967787313044
Sparse matmult (N=1000, nz=5000): 150.24300818876543
LU (100x100): 215.9654108773228

java.vendor: Oracle Corporation
java.version: 1.8.0_101
os.arch: aarch64
os.name: Linux
os.version: 3.14.65-75

SciMark 2.0a

Composite Score: 191.17699636633853
FFT (1024): 132.13944433360598
SOR (100x100): 359.1045688073317
Monte Carlo : 115.35688320640973
Sparse matmult (N=1000, nz=5000): 146.3510597988765
LU (100x100): 202.93302568546878

java.vendor: Oracle Corporation
java.version: 9-ea
os.arch: aarch64
os.name: Linux
os.version: 3.14.65-75

ARM’s NEXT

SciMark 2.0a

Composite Score: 199.82468291329343
FFT (1024): 138.6959772877976
SOR (100x100): 368.0204326848387
Monte Carlo : 122.5173244497791
Sparse matmult (N=1000, nz=5000): 146.94171848921295
LU (100x100): 222.94796165483876

java.vendor: Oracle Corporation
java.version: 1.8.0_101
os.arch: arm
os.name: Linux
os.version: 3.14.65-75

SciMark 2.0a

Composite Score: 115.21403693690618
FFT (1024): 98.74549905759017
SOR (100x100): 224.90138235680308
Monte Carlo : 32.23288349984912
Sparse matmult (N=1000, nz=5000): 88.29964483407487
LU (100x100): 131.89077493621366

java.vendor: Oracle Corporation
java.version: 9-ea
os.arch: arm
os.name: Linux
os.version: 3.14.65-75

[quote=“xpomul, post:40, topic:8493”]
This will install a 32-bit JVM in /usr/lib/jvm/java-1.8.0-openjdk-armhf which you need to call in startup.sh so it is used instead of the default JVM.[/quote]

Thanks for the instructions. I’ve got the new JVM installed, but can you explain a tad more about how to "call in startup.sh"? What startup.sh file are you referring to, exactly? And how would one edit it to point to the new JVM?
Thanks in advance if you’re able to help.

Hi,

it depends on the OpenHAB-Version you are using.
If you are still using OpenHAB1, then there is a startup.sh (or was it called start.sh?) script in the OpenHAB directory which you use to start OpenHAB. This script contains a java command which you’d need to modify to point to the correct java executable.

That said, I am using OpenHAB2 now. There, things work differently (and better ;-))

  • If you have installed it via the package manager on Ubuntu, then you’d just need to set the correct java in update-alternatives --config java and everything should work fine.
  • If you have installed it manually, then you should set the JAVA_HOME environment variable correctly before starting OH2 to point to your JVM home (typically somewhere under /usr/lib/jvm)

Hope that helps.

Best,
Stefan

1 Like

Hi,

I’m really noob at this. I’ve been trying for hours to see the zwave module bought from Pine64 shown as online in Things, but still it shows “offline” “Bridge offline”, even after giving all the permissions by using chmod 777 on ttyS2 and changing the Java version for a 32 bit version (I’ve followed the instructions shwon a little bit above). I was wondering what could be wrong in that case?

Thank you very much for your time, and your hard work!

Hi all.
I’m reviving this old topic to check what the current recommendations are. I’ve been struggling for quite a while (months actually, though not very active) trying to get OH to work on my Rock64. I’m using both z-wave and Tellstick devices.

OH itself seems to run fine both under 32 and 64 bits JVM, but under 64 bits I can’t get the communication with the controllers working (not exactly sure why, but I guess it corresponds with the recommendations about using 32 bits JVM).

Under 32 bits JVM I’ve got the problem that the Tellstick binding needs 32 bit version of telldus-core libs which I then need to compile myself and from what I can understand it’s not even possible compiling armhf executables on arm64? link

So I’m kinda stuck. I guess arm64 will be a growing platform so it’s definitely something that will need to work somehow.

The NRJavaSerial library finally got “AARCH64” support several weeks ago.

Commits on Nov 22, 2018

  1. [Add support for arm64](Merge pull request #249 from dbsystel/fix-segfault · NeuronRobotics/nrjavaserial@b1da316 · GitHub /e07da186488655e8de69faf574c3b73f8ea8b70d)

@wborn

[wborn] committed on 22 Nov

I did build the version from the official git repository on my Odroid C2 (which worked in general) and replaced the existing NRJavaSerial version inside openHAB 2.4 (release) package with my own build (kept the original NRJavaSerial filename).
While it did load the library to some extend it wasn’t to 100% successful.

I assume the issue is related to:

  • my Odroid C2 setup (on the device I tested I’m still running ARMBIAN Ubuntu 16.04.1 LTS). I didn’t have time to check it on a C2 with a current Ubuntu 18.04 LTS yet.
  • the fact that openHAB uses a modified version of the library (at least it is stripped down - that was what I read somewhere…I didn’t do a comparison yet).

Still, with a new build using the brand new version of the NRJavaSerial Library I think 64-Bit ARM should finally work out of the box.