OpenCPN Runs on Embedded ARM

[NahanniV]

Originally Posted by mattkab

I can also confirm that Aruntu 1.001 (Peace Edition) does work with OpenCPN 3.3.2410. Just simply follow the instructions on OpenCPN.com for installing on a CubieTruck.

I'm seeing some odd artifacts and display behavior, but it does run in OpenGL mode. No black screens or completely wrong rendering. I'm going to try some other charts and play with building up the texture cache.

The OS image appears fairly stable, and even works with my wireless keyboard without installing any drivers. You do need to expand the file system on first run -- I only had about 100MB of free space before doing so. I also get glxgears framerates between 60 and 250 FPS after installing glshim. But it is not very lean and has a ton of extra apps included that I don't like -- I am going to spend some time uninstalling those.

So, what's the difference ? Between Mattkab's (working) and GHammond's (black screen) system ?

[GHammond]

Probably my over-installing various bits (specifically, updating the sources early in the process). Also I suspect I messed up the include library locations.

I'll report after I do a minimal install on cubian. When in doubt assume Matt is right -- I have a gift for creating linux havoc...

Best

Pete

[GHammond]

Correction to earlier post. And apology.

Have now confirmed O works fine with the older Cubian release as per Matt's post above.

My foolish error was not in the Linux libraries as I thought but in O. After installing O I assumed it was not working because I got a black screen when enabling openGL. What I failed to understand is that you MUST build the texture cache first. After building the texture cache the vector charts work fine.

Therefore it is probably safe to assume that my installation of aRuntu Peace was working as well since the behaviour was exactly the same.

Apologies for misleading earlier posts.

By the way, the Cubian image is faster than the aRuntu. And more suitable for O since it has far less stuff preloaded.

Now...next task is to figure out how to create an image with the correct updated drivers for the mali 400: ie r3p2 which has better graphics performance. The driver in both the Cubian and aRuntu image is the older r3p0 which only uses one of the cores.

Best

Pete

[rgleason]

What I failed to understand is that you MUST build the texture cache first. After building the texture cache the vector charts work fine.

GHammond thanks very much for your posts. How do you "build the texture cache" do you have access to the Options > Charts > Advanced > Opengl menus so that you can build the texture cache? or do you issue a command line on starting opencpn to build the cache?

[GHammond]

I have full access to the gui so I did it all through the menus. The only anomaly I see is that when O first starts it goes to a black screen BUT the controls are still all available - it is only the chart display that is black until the texture cache is built.

hth

Pete

[mattkab]

Originally Posted by GHammond

When in doubt assume Matt is right -- I have a gift for creating linux havoc...

This is very very dangerous advice, LOL!

Glad other people are seeing the same results. These single-board computers are truly wonderful devices but they sure can trip you up.

[rgleason]

Are these boards too temperamental for mortals?

[NahanniV]

Originally Posted by rgleason

Are these boards too temperamental for mortals?

Once it's all sorted out, the image could be made available, or some enterprising person could offer SD cards pre-programmed. Not sure about the legal aspects, but it would be possible to distribute all the RNCs for the US already compressed in an image file (possibly by torrent) or SD card.

Cheers,
JM.

[NahanniV]

Originally Posted by GHammond

Correction to earlier post. And apology.

Have now confirmed O works fine with the older Cubian release as per Matt's post above.

My foolish error was not in the Linux libraries as I thought but in O. After installing O I assumed it was not working because I got a black screen when enabling openGL. What I failed to understand is that you MUST build the texture cache first. After building the texture cache the vector charts work fine.

Therefore it is probably safe to assume that my installation of aRuntu Peace was working as well since the behaviour was exactly the same.

Apologies for misleading earlier posts.

By the way, the Cubian image is faster than the aRuntu. And more suitable for O since it has far less stuff preloaded.

Now...next task is to figure out how to create an image with the correct updated drivers for the mali 400: ie r3p2 which has better graphics performance. The driver in both the Cubian and aRuntu image is the older r3p0 which only uses one of the cores.

Best

Pete

Thanks for the information. Especially about the drivers.

But, there is still a bug here. The screen should never be black.
I don't think vector charts get compressed by texture caching.
There is a conversion or database addition that happens for vector charts as they are encountered. This can be done in a batch by starting the program with the - unit_test_1 command line arg. which will sequentially display all the charts.

It seems like there is some nasty little bug here that is not easily repeatable. Some times my installation will work without a problem for a long time.

Do you have some Raster charts installed ?

Merry Christmas,
JM.

[rgleason]

Maybe you do not have the gshhs land outlines installed?
Background Chart gshhs
Chart Sources | Official OpenCPN Homepage

A more detailed version of the built in background map is available here.
It is a big file, 230 mb(unzipped) compared to the standard 26mb, and may slow your computer down. The presentation is better when zoomed in, but most users don't need it.
Install by unzipping and placing the files in the <install_dir>/gshhs .
<install_dir> is normally ...Program Files/OpenCPN on Windows and /usr/share/opencpn/ on a Linux default installation.

[akopac]

Hey Matt. I know you mentioned the version previously. But I wanted confirm I have the right one.
Release 7.7
Kernel 3.4.79-sun7i
Mate 1.8.1



Sent from my iPhone using Cruisers Sailing Forum

[mattkab]

Originally Posted by akopac

Hey Matt. I know you mentioned the version previously. But I wanted confirm I have the right one.
Release 7.7
Kernel 3.4.79-sun7i
Mate 1.8.1

This is the version I'm currently running at 720p via HDMI. I have OpenCPN running vector charts with hardware acceleration. I have an unpowered USB hub, connecting a Logitech wireless keyboard, GPS puck, and an rtl-sdr dongle sending AIS NMEA signals.

With everything running, I'm consuming about 50% CPU

[GHammond]

A few random points about O on the Cubietruck.

Can someone with a Cubietruck confirm that CM93 works properly with opengl off but that with opengl on it loses detail as you zoom in. To be precise, if you pick a harbour with more than two layers of detail total (eg Boston or Los Angeles) it will grey out as you come down to the finer detail. It will also drop soundings. It does better if you pick a section of coast with only 2 layers of detail. This does not happen with openGL turned off -- all layers of detail show up at the appropriate zoom level.

Second point about the black screen: the ARM build by default does not build the background map. The makefile drops it deliberately (presumably to save space). Therefore the black screen might well be linked to that omission.

Third: I did get raster charts working more or less ok with openGL enabled after letting the Cubietruck spend 7 hours working through the texturizing process - I picked, at random, the RNC collection for California (384mb). Zooming in and out was fairly fast. It did, however, lead to random aborts (ie, O shutting down). The raster charts did not play well with CM93 -- screen would black out changing back and forth between them. ENC seemed to work ok.

Fourth point: Rick asked if this was suitable for mortals, which I take to mean is it worth the learning curve and can it be made to work properly? After messing around with this for a couple of weeks I think it could be an entertaining hobby if you're so inclined and the Cubietruck is a very nice little board. But...the Mali drivers are awful, many months out of date, each new revision of the binary drivers has new bugs, the images for the board are flakey (except the headless Wheezy/Jessie image which unfortunately does not have userspace Mali binary drivers and you cannot install them due to an UMP incompatibility) and openGL will never work properly (partly because of the driver support and partly because it's not a feature of the chip). And so, pausing for breath, I would absolutely NOT use this for real navigation. I think, on balance, I would use something with an Intel processor (essentially the least common denominator in the Linux world) so that openGL really works out of the box with no shimming or fairy dust and you can use a current version of normal linux rather than the specialized and out of date kernel that the arm boards require. Minnowboard Max maybe? Or a cheap intel compatible motherboard and one of their least powerhungry CPU's. Or an Intel NUC. Total price is not hugely more. The Cubie is compelling because it uses so little power but I do not think it is stable enough. In fact, I'd say it was solely compelling due to it's power usage -- you really want it to work but...

Last point: can someone explain the difference between building O with embedded GL ES v1 or v2 on something like the Cubietruck. If I install the binary Mali drivers I end up with a GLES2 folder in /usr/include. This means the O build routine assumes it should build with GL2. If I use the stock Cubian image it doesn't have a GLES2 folder so O builds with embedded GL1. I've built O both ways -- both seem equally unstable so I'm not sure if there's a real difference here...?

Hope this helps someone spend less time on this...

Pete

[rgleason]

Pete,
You are a real champ on this! I read this part with some real understanding of what you've been working on, and appreciate your efforts and excellent reports!

I think, on balance, I would use something with an Intel processor (essentially the least common denominator in the Linux world) so that openGL really works out of the box with no shimming or fairy dust and you can use a current version of normal linux rather than the specialized and out of date kernel that the arm boards require. Minnowboard Max maybe? Or a cheap intel compatible motherboard and one of their least powerhungry CPU's. Or an Intel NUC. Total price is not hugely more. The Cubie is compelling because it uses so little power I think, on balance, I would use something with an Intel processor (essentially the least common denominator in the Linux world) so that openGL really works out of the box with no shimming or fairy dust and you can use a current version of normal linux rather than the specialized and out of date kernel that the arm boards require. Minnowboard Max maybe? Or a cheap intel compatible motherboard and one of their least powerhungry CPU's. Or an Intel NUC. Total price is not hugely more. The Cubie is compelling because it uses so little power...

I hope someone can answer your last questions..

[mattkab]

Originally Posted by GHammond

Can someone with a Cubietruck confirm that CM93 works properly with opengl off but that with opengl on it loses detail as you zoom in. To be precise, if you pick a harbour with more than two layers of detail total (eg Boston or Los Angeles) it will grey out as you come down to the finer detail. It will also drop soundings. It does better if you pick a section of coast with only 2 layers of detail. This does not happen with openGL turned off -- all layers of detail show up at the appropriate zoom level.

Confirmed. I did not notice this myself, as I set and leave my zoom level pretty far out, but tested on the boat over the holiday weekend and saw the same effect. And this sucks.

Originally Posted by GHammond

Second point about the black screen: the ARM build by default does not build the background map. The makefile drops it deliberately (presumably to save space). Therefore the black screen might well be linked to that omission.

Will try this weekend. Didn't get around to it yesterday. This is an interesting theory.

Originally Posted by GHammond

Fourth point: Rick asked if this was suitable for mortals, which I take to mean is it worth the learning curve and can it be made to work properly? After messing around with this for a couple of weeks I think it could be an entertaining hobby if you're so inclined and the Cubietruck is a very nice little board.

Agree...

Originally Posted by GHammond

But...the Mali drivers are awful, many months out of date, each new revision of the binary drivers has new bugs, the images for the board are flakey (except the headless Wheezy/Jessie image which unfortunately does not have userspace Mali binary drivers and you cannot install them due to an UMP incompatibility) and openGL will never work properly (partly because of the driver support and partly because it's not a feature of the chip). And so, pausing for breath, I would absolutely NOT use this for real navigation.

I agree with all of this, today. But I don't know that this will continue to be the case in a few months, as all this stuff is currently being actively developed.

I'm not sure that I would ever suggest a DIY solution for "real" navigation, but at the same time the capabilities that this board provides, at around a $300 price point, with features that rival $3000 off-the-shelf navigation systems, it's still very enticing.

Further, the struggles and difficulties that we are all running into happen during experimentation, build-out, and testing. Once you have an instance set up that you are satisfied with, I've found it to be a very stable platform from that point on.

I wouldn't want anyone reading this thread to be discouraged to try it if they are at all interested.

Originally Posted by GHammond

I think, on balance, I would use something with an Intel processor (essentially the least common denominator in the Linux world) so that openGL really works out of the box with no shimming or fairy dust and you can use a current version of normal linux rather than the specialized and out of date kernel that the arm boards require. Minnowboard Max maybe? Or a cheap intel compatible motherboard and one of their least powerhungry CPU's. Or an Intel NUC. Total price is not hugely more. The Cubie is compelling because it uses so little power but I do not think it is stable enough. In fact, I'd say it was solely compelling due to it's power usage -- you really want it to work but...

I understand your point, and while I do agree in a sense, I came from that platform, and I won't go back.

I'm a Windows PC guy and have been for years. My boat PC was originally a laptop, and then moved to a micro-ATX buildout.

But today, for O on a boat, I'm a Linux single-board guy all the way. It just makes more sense in that environment to me. Even at home, my HTPC is a Raspberry Pi now.

Originally Posted by GHammond

Last point: can someone explain the difference between building O with embedded GL ES v1 or v2 on something like the Cubietruck. If I install the binary Mali drivers I end up with a GLES2 folder in /usr/include. This means the O build routine assumes it should build with GL2. If I use the stock Cubian image it doesn't have a GLES2 folder so O builds with embedded GL1. I've built O both ways -- both seem equally unstable so I'm not sure if there's a real difference here...?

I don't know, but I'm curious about this as well.

Originally Posted by GHammond

Hope this helps someone spend less time on this...

I enjoy spending the time. ;-)