OpenCPN Runs on Embedded ARM

[sbfreddie]

Originally Posted by stu3284

Nope, enabling it just cause the screen to have a big grey block on. It seems to run fine without it enabled and I can move freely around the charts. I have the charts on the ssd. Quilting is still enabled.

I am having problems getting the VDR plugin to work. I've put it in the directory users/lib/opencpn but it doesn't show up in the plugins list to enable it. ???? Log says file or directory does not exist.

I also think I need to get a better power supply as the whole thing just switches itself off now and again now and again and then won't boot up. If I unplug the keyboard it'll reboot then i have to plug the keyboard in. If only I can find my PSP power supply
Regards
Stu

Stu:
Don't feel bad about the OpenGL problem, I have not been able to get mine to work either, even though I know that all the OpenGL stuff is already installed on this Distribution. Did you move the Mesa stuff out of the way? Does es2gears give you about ~370 FPS? Does glmark2-es2 give you a final score of around 178?
Even though I know the OpenGL stuff is installed properly I still have not been able to get glxgears to give more than about 48 FPS. However after several days searching around the Net I have found that glxgears only works on OpenGL and not OpenGL GLESv1 (or v2).
So I am stuck in the same place you are.

Don't know what to tell you about VDR plugin as I have not installed any plugins yet.

If you are using a 120VAC wall wort for your power supply I would recommend using this one from Monoprice (its 4.2A output):

4 Port USB Wall Charger 4.2A for Apple and Android - Black - Monoprice.com

I have been using these for more than a year and not had any problems at all.

If you are using 12VDC (On the Boat) as the input voltage, I would try this one:
Mini DC-DC Buck Converter Step-Down Power Module Output 0.8V-20V
or this one:
LM2596 DC-DC Buck Converter Step-Down Power Module Output 1.25V-35V
I have been using these on my Wandboard Quad with no problem. The Wandboard Quad uses about 4-10 Watts whereas the Cubie uses about 3-6 Watts.

Thanks,
Freddie

[seandepagnier]

Originally Posted by stu3284

Nope, enabling it just cause the screen to have a big grey block on. It seems to run fine without it enabled and I can move freely around the charts. I have the charts on the ssd. Quilting is still enabled.

That is because you are using the wrong opengl libraries.

I am having problems getting the VDR plugin to work. I've put it in the directory users/lib/opencpn but it doesn't show up in the plugins list to enable it. ???? Log says file or directory does not exist.

And you compiled this plugin from source?

Originally Posted by sbfreddie

Stu:
Don't feel bad about the OpenGL problem, I have not been able to get mine to work either, even though I know that all the OpenGL stuff is already installed on this Distribution. Did you move the Mesa stuff out of the way? Does es2gears give you about ~370 FPS? Does glmark2-es2 give you a final score of around 178?
Even though I know the OpenGL stuff is installed properly I still have not been able to get glxgears to give more than about 48 FPS. However after several days searching around the Net I have found that glxgears only works on OpenGL and not OpenGL GLESv1 (or v2).
So I am stuck in the same place you are.

Keep in mind, that I am running glxgears on top of glshim which uses openglesv1. glshim provides an opengl library which sits on top of openglesv. Once this works, then you can use it with other programs including opencpn to get accelerated opengl using the openglesv1 library.

[stu3284]

Cheers Freddie, After searching through every junk box in the house including the ones in the loft, my Sony PSP power supply turned up about 1 foot away from my arm on the window sill. Not had any problems with the CT since. As for 12v, I'll be looking at something like what you suggested. As for moving the Mesa stuff, is that the 3D stuff. If it is I haven't touched it.

Originally Posted by boat_alexandra

That is because you are using the wrong opengl libraries.

Hi Sean, I'm flying blind with this as I just started using Linux the other day. I'll have a look today and try and work it out.

Originally Posted by boat_alexandra

And you compiled this plugin from source?

I just copied it to the user/lib/opencpn directory as it said in the Plugin instructions. On running idconfig it says' its for a different machine. I'll have a look after I finsihed typing this.

Originally Posted by boat_alexandra

Keep in mind, that I am running glxgears on top of glshim which uses openglesv1. glshim provides an opengl library which sits on top of openglesv. Once this works, then you can use it with other programs including opencpn to get accelerated opengl using the openglesv1 library.

I do have a team of top scientists working on this. Myself who hasn't a clue and the wife who has a phd in supplying tea. Can I just build the space shuttle? Over to you Freddie.

Enabling the opengl and the its now looking ok on a static screen but I can't drag the charts around smoothly due to the massive 'stuttering' for want of a better word. Scroll zoom is fierce but using a light touch its indeed workable.

Kind regards

Stu

PS Its easier getting permission of my wife than Linux

[bcn]

Originally Posted by stu3284

I just copied it to the user/lib/opencpn directory as it said in the Plugin instructions. On running idconfig it says' its for a different machine. I'll have a look after I finsihed typing this.

Stu

Stu,

the plug-ins from the OpenCPN site are compiled for Intel platforms.
For your ARM you need a different binary, that's what Sean is saying:
compiling the source for your target - same as OpenCPN itself.

Hubert

[stu3284]

Originally Posted by bcn

Stu,

the plug-ins from the OpenCPN site are compiled for Intel platforms.
For your ARM you need a different binary, that's what Sean is saying:
compiling the source for your target - same as OpenCPN itself.

Hubert

Hi Hubert,
Bear with me here !!! So the libvdr_i386_pi16_v03_pi.so file I downloaded for ubantu from the VDR plugins bit needs compiling? I'm definitely lost here. Am I right in thinking that I need the source code for the plugin and then have to compile it on my cubietruck for it to run?

Kind regards

Stu

[bcn]

Originally Posted by stu3284

Hi Hubert,
Bear with me here !!! So the libvdr_i386_pi16_v03_pi.so file I downloaded for ubantu from the VDR plugins bit needs compiling? I'm definitely lost here. Am I right in thinking that I need the source code for the plugin and then have to compile it on my cubietruck for it to run?

Kind regards

Stu

Yes, Sir, that's the way.
Adventure is adventure.
We will go the way together, it seems to me.
We are on an OLIMEX A20, that's a very similar device to the Cubies.

Hubert

[owlhead]

I have been trying to get glshim working on the cubieboard2 using a stock Cubian image on an SD card, following the instructions from earlier in the thread. But I am running into a problem when I try to test glxgears using glshim instead of the stock gl library.

Here is my latest attempt (edited to highlight the error):

cubie@Cubian:~/git$ git clone https://github.com/seandepagnier/glshim.git
cubie@Cubian:~/git$ cd glshim/
cubie@Cubian:~/git/glshim$ cmake .
cubie@Cubian:~/git/glshim$ make GL
cubie@Cubian:~/git/glshim$ sudo cp lib/libGL.so.1 /usr/lib
cubie@Cubian:~/git/glshim$ glxgears
227 frames in 5.0 seconds = 45.313 FPS
231 frames in 5.0 seconds = 46.116 FPS
228 frames in 5.0 seconds = 45.488 FPS
^C
cubie@Cubian:~/git/glshim$ LD_LIBRARY_PATH=/usr/lib glxgears
libGL: built on May 28 2014 01:37:27
libGL: warning, gles is NULL
Segmentation fault
cubie@Cubian:~/git/glshim$

I feel like I am missing something obvious, but not sure exactly what is causing this issue. Any thoughts? I appreciate any help you can provide.





FYI here is the full build log:

cubie@Cubian:~$ cd git
cubie@Cubian:~/git$ git clone https://github.com/seandepagnier/glshim.git
Cloning into 'glshim'...
remote: Counting objects: 3460, done.
remote: Compressing objects: 100% (1447/1447), done.
remote: Total 3460 (delta 1950), reused 3460 (delta 1950)
Receiving objects: 100% (3460/3460), 3.04 MiB | 976 KiB/s, done.
Resolving deltas: 100% (1950/1950), done.
cubie@Cubian:~/git$ cd glshim/
cubie@Cubian:~/git/glshim$ cmake .
-- The C compiler identification is GNU 4.6.3
-- The CXX compiler identification is GNU 4.6.3
-- Check for working C compiler: /usr/bin/gcc
-- Check for working C compiler: /usr/bin/gcc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Configuring done
-- Generating done
-- Build files have been written to: /home/cubie/git/glshim
cubie@Cubian:~/git/glshim$ make GL
Scanning dependencies of target GL
[  5%] Building C object src/CMakeFiles/GL.dir/gl/line.c.o
[ 11%] Building C object src/CMakeFiles/GL.dir/gl/math/eval.c.o
[ 16%] Building C object src/CMakeFiles/GL.dir/gl/texgen.c.o
[ 22%] Building C object src/CMakeFiles/GL.dir/gl/raster.c.o
[ 27%] Building C object src/CMakeFiles/GL.dir/gl/stack.c.o
[ 33%] Building C object src/CMakeFiles/GL.dir/gl/texture.c.o
[ 38%] Building C object src/CMakeFiles/GL.dir/gl/eval.c.o
[ 44%] Building C object src/CMakeFiles/GL.dir/gl/light.c.o
[ 50%] Building C object src/CMakeFiles/GL.dir/gl/pixel.c.o
[ 55%] Building C object src/CMakeFiles/GL.dir/gl/list.c.o
[ 61%] Building C object src/CMakeFiles/GL.dir/gl/array.c.o
[ 66%] Building C object src/CMakeFiles/GL.dir/gl/wrap/glstub.c.o
[ 72%] Building C object src/CMakeFiles/GL.dir/gl/wrap/gles2.c.o
[ 77%] Building C object src/CMakeFiles/GL.dir/gl/wrap/gles.c.o
[ 83%] Building C object src/CMakeFiles/GL.dir/gl/wrap/gl.c.o
[ 88%] Building C object src/CMakeFiles/GL.dir/gl/gl.c.o
[ 94%] Building C object src/CMakeFiles/GL.dir/glx/glx.c.o
[100%] Building C object src/CMakeFiles/GL.dir/glx/lookup.c.o
Linking C shared library ../lib/libGL.so.1
[100%] Built target GL
cubie@Cubian:~/git/glshim$ sudo cp lib/libGL.so.1 /usr/lib
[sudo] password for cubie: 
cubie@Cubian:~/git/glshim$ glxgears
227 frames in 5.0 seconds = 45.313 FPS
231 frames in 5.0 seconds = 46.116 FPS
228 frames in 5.0 seconds = 45.488 FPS
^C
cubie@Cubian:~/git/glshim$ LD_LIBRARY_PATH=/usr/lib glxgears
libGL: built on May 28 2014 01:37:27
libGL: warning, gles is NULL
Segmentation fault
cubie@Cubian:~/git/glshim$

[seandepagnier]

Maybe try copying to /usr/lib/libGL.so (right now you made a file in /usr/lib/libGL.so.1) or make a symlink from /usr/lib/libGL.so -> /usr/lib/libGL.so.1

Maybe try building glxgears and glxinfo from source.
You may need to use the debugger to find where the segmentation fault occurs to fix it, but I was able to run on my cubie truck without crashing.

[owlhead]

Originally Posted by boat_alexandra

Maybe try copying to /usr/lib/libGL.so (right now you made a file in /usr/lib/libGL.so.1) or make a symlink from /usr/lib/libGL.so -> /usr/lib/libGL.so.1

Maybe try building glxgears and glxinfo from source.
You may need to use the debugger to find where the segmentation fault occurs to fix it, but I was able to run on my cubie truck without crashing.

Thanks, this got me looking in the right direction. It appears that the source code in

/src/gl/gl.h

was looking for the gles library in a specific location, but the file name for that library is different on my Cubian system. The upstream git repository had an updated version of the header file, which contains a different mechanism for locating that library: I put that version of the file into your forked repository, and glshim compiled and glxgears ran without error. I'm now getting about 220 fps out of glxgears when pointed at glshim versus the stock opengl library. Quite a nice boost.

[seandepagnier]

Originally Posted by owlhead

Thanks, this got me looking in the right direction. It appears that the source code in

/src/gl/gl.h

was looking for the gles library in a specific location, but the file name for that library is different on my Cubian system. The upstream git repository had an updated version of the header file, which contains a different mechanism for locating that library: I put that version of the file into your forked repository, and glshim compiled and glxgears ran without error. I'm now getting about 220 fps out of glxgears when pointed at glshim versus the stock opengl library. Quite a nice boost.

How strange.

Anyway... now that glxgears is working, how about opencpn? Be sure it detects opengles when running cmake. Although glshim basically implements opengl on top of opengles.. in a few areas it does not, and in some places it cheats, and some extensions are different. For this reason opencpn has special code for these cases.

[owlhead]

Originally Posted by boat_alexandra

How strange.

Anyway... now that glxgears is working, how about opencpn? Be sure it detects opengles when running cmake. Although glshim basically implements opengl on top of opengles.. in a few areas it does not, and in some places it cheats, and some extensions are different. For this reason opencpn has special code for these cases.

I hope to have some time later today to build opencpn. I'll make sure to keep an eye on the cmake output to ensure it picks-up the opengles libraries.

[stu3284]

I updated my (git pull) opencpn yesterday and being useless at Linux, I can't remember if it was cmake or make but in the teminal it said opengl and a load of libraries after it but nothing after the opengles. Don't know if this is any help.

[stu3284]

It was during cmake.

-- Found OpenGL...
-- Lib: /usr/lib/arm-linux-gnueabihf/libGLU.so/usr/lib/arm-linux-gnueabihf/libGL.so/usr/lib/arm-linux-gnueabihf/libSM.so/usr/lib/arm-linux-gnueabihf/libICE.so/usr/lib/arm-linux-gnueabihf/libX11.so/usr/lib/arm-linux-gnueabihf/libXext.so
-- Include: /usr/include
-- Found OpenGLESv2
-- Found wxWidgets...
-- -L/usr/lib/arm-linux-gnueabihf...................................

[owlhead]

Originally Posted by boat_alexandra

Anyway... now that glxgears is working, how about opencpn?

opencpn picked up the opengles libraries during cmake and i was able to build it successfully. I can definitely see a significant difference in performance when using the opengles libraries. The largest performance issue at this point seems to be the relative-slowness of the SD card that I am running Cubian from, so I am curious to see what happened when i am able to move the rootfs to an SSD drive.

[seandepagnier]

Originally Posted by owlhead

opencpn picked up the opengles libraries during cmake and i was able to build it successfully. I can definitely see a significant difference in performance when using the opengles libraries. The largest performance issue at this point seems to be the relative-slowness of the SD card that I am running Cubian from, so I am curious to see what happened when i am able to move the rootfs to an SSD drive.

Also, try enabling texture compression and texture compression caching (both opengl options), then rebuilt the chart database. This should significantly speedup raster charts and reduce memory usage, and make it work well even from an sd card.