This has me wondering if the liblockdev version that installed is 32 bit?
ldd <install path to liblockdev1.so>
Also, the JDK is the 64 bit version, correct?
java -version
One more thing you could look at would be to run ldd against the NR .so to make sure it is pulling in 64 bit libraries:
ldd /home/pine64user/openhab/lib/libNRJavaSerial.so
edited: Did you try Xenial with the lockdev package added manually ?
Did you try Xenial with the lockdev package added manually ?
I tried to install the package, but it complained about too many missing dependencies and I gave up after a while.
I am now a step further and have installed the Docker container on Debian Jessie and will check how it behaves in there.
Here are links to both the packages needed. I should have just done that in the first place 
http://launchpadlibrarian.net/230433667/liblockdev1_1.0.3-1.6build2_arm64.deb
http://launchpadlibrarian.net/230433664/liblockdev1-dev_1.0.3-1.6build2_arm64.deb
Install the non-dev package first, and that should satisfy the dependencies for the dev package. Actually, with the pre-built .so, you may not even need the -dev package. That should only be needed for compile.
Good news! I managed to install liblockdev1 and your .so library seems to work on the Pine64 (on Debian)!
Unfortunately, it looks as if the ZWave.me dongle isnāt supported by the kernel (yet)ā¦ So still some work to do.
But regarding the compilation of a new JAR for io.transport.serial, I think we could go ahead. Is this something you would know how to do it (especially adding the lib for the arm64 architecture)? Such a new jar should definitely also include https://github.com/NeuronRobotics/nrjavaserial/issues/44, so that it is not bigger than needed.
Congratulations!
What is the comfort level with using a shared library compiled against another shared library that is no longer available in standard repositories for new operating systems? To ensure it works beyond tomorrow, we might have to include the shared library for liblockdev1.
I would rather it be cleaner, things that are temporary live forever.
Iād hope that the clean solution is going to be done in the nrjavaserial project itself; I am for now only interested in a temporary solution that makes the serial access working on the Pine64 (as the IoT package is going to be shipped very soon and thus we will have 2000 openHAB users on the Pine64 very soon). For this reason, I exceptionally vote for a quick working solution instead of a clean and future-proof one For the Pine image, I will make sure that liblockdev1 is available.
The quickest path then would be to edit the setenv in karaf/bin. There is already a section in there for ARM arch. Add ARM64 and the -D command line flag for the libNRjavaserial and you are done as long as liblockdev1 is also installed. This falls apart if setenv is actually a karaf file that we donāt have control over.
I donāt think I will have time to try to adjust the jar with timing that makes sense to get the boards shipped, unfortunately.
@Kai @xsnrg , thanks for sharing the library and the insights. Got it working with OH1.8 on Pine64 with Aeon USB stick (gen 2) and Debian. Will need to run it for a while to rule out possible issues and stability, but at least basic init of all nodes seems good in the logs.
@vgoldman This is great news! So it is just me ZWave.me dongle, which is not known to the kernel the AeonLabs dongle works!
@xsnrg One more reason to create an updated jar - can I count on you?
First pass at a FAT jar to see if it even works.
https://github.com/xsnrg/ARM64/blob/master/nrjavaserial-3.12.0.jar
I donāt have any ability to test it for a few days (no 64 bit ARM here). It contains the new native library, but not sure of the native selection processā¦ It seemed too easy. If the 64 bit works, please check on a 32 bit ARM as well.
Thanks @xsnrg! I successfully tested it on Mac OS and RaspPi2. Unfortunately, it fails on the Pine64 with:
java.lang.UnsatisfiedLinkError: /home/openhabuser/oh/userdata/tmp/libNRJavaSerial_openhabuser_0/libNRJavaSerial.so: /home/openhabuser/oh/userdata/tmp/libNRJavaSerial_openhabuser_0/libNRJavaSerial.so: wrong ELF class: ELFCLASS32 (Possible cause: can't load IA 32-bit .so on a ARM-bit platform)
If I look at the extracted lib, I see that it is the binary from the folder native/linux/x86_32, so somehow it picks the wrong one. How does the lib do the selection of which binary to use?
It uses a system call to return the arch type, and then matches it against a list. This likely means I did not get the arch type correct for it to match on. I did not have a board to test it with when I created the jar, so that wasnāt helpful.
Could the openhab-transport-serial bundle be changed to use OSGIās Bundle-NativeCode plus an optional variant property for those that fall outside standard platforms, like in this PR?
I suspect it could with some work. All the current one seems to be doing is using the system call to return the arch type and then looking in the right folder for the library. There is even some chance involved, because there are multiple libraries in each arch folder. It starts loading them in the order of newest arch to oldest so that the most feature rich library supported by the hardware is loaded, but this is really inefficient, and I could see it causing problems if it does not already.
The native code libraries still need to be part of the jar as it is right now, so any new arch types would need a rebuild of the jar instead of just adding a new native library. The whole of this could stand to be re-factored, but without a lot of time to give it, I was trying to get a working jar that had the 64 bit lib in it for now. We really need the NRjavaserial folks to take this one on. There are a lot of good ideas on their forum, and some PRs as well, but I understand the time and commitment OSS takes, and it doesnāt put food on the table for most.
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.