OpenCPN Runs on Embedded ARM

[NahanniV]

Originally Posted by boat_alexandra

Probably ran out of memory for textures. Now, this is our bug of course.. we need to check opengl errors which we currently don't... How much ram is opencpn using when it crashes?

I will check ram usage tonight when I am back on the boat.

Originally Posted by boat_alexandra

For this one, I think the fastest way to fix it is to sync to a time when s57 charts did work, then use git bisect to determine the offending commit. It's probably something to do with unaligned floating point memory access.

Git bisect would be difficult, because wxWidgets also changed somewhere in that timeframe.
The "SIGBUS, Bus error." in the trace I supplied seems to support your theory of unaligned access. The code in this routine already has several conditionals for ARMHF. Perhaps a walkthrough by someone who understands alignment issues (not me unfortunately) could be quicker.

Cheers,
JM.

[NahanniV]

Originally Posted by boat_alexandra

Probably ran out of memory for textures. Now, this is our bug of course.. we need to check opengl errors which we currently don't... How much ram is opencpn using when it crashes?

Only one chart loaded, only OpenGL changed in configuration (no texture caching).

See attached images: first is before selecting chart, next are after.

Here is the log file:

18:00:04 EDT: 

________
18:00:04 EDT: 2015-08-21
18:00:04 EDT:  ------- Starting OpenCPN -------
18:00:04 EDT: Version 4.1.818 Build 2015-08-18
18:00:06 EDT: wxWidgets version: wxWidgets 3.0.2 Linux 32 bit wxGTK
18:00:06 EDT: MemoryStatus:  mem_total: 1838 mb,  mem_initial: 12 mb
18:00:06 EDT: SData_Locn is /usr/local/share/opencpn/
18:00:06 EDT: PrivateDataDir is /home/aruntu/.opencpn
18:00:06 EDT: Creating new Config_File: /home/aruntu/.opencpn/opencpn.conf
18:00:06 EDT: Setting Viewpoint Lat/Lon 33.358, -79.282
18:00:06 EDT: Setting Ownship Lat/Lon 33.358, -79.282
18:00:06 EDT: Styles loading from /usr/local/share/opencpn/uidata/styles.xml
18:00:06 EDT: No styles found at: /home/aruntu/
18:00:06 EDT: No styles found at: /home/aruntu/.opencpn/
18:00:06 EDT: Detected display size (horizontal): 508 mm
18:00:06 EDT: System default Language:  en_US
18:00:06 EDT: Opencpn language set to:  en_US
18:00:10 EDT: Creating MyFrame...size(1344, 731)  position(0, 0)
18:00:10 EDT: Creating glChartCanvas
18:00:11 EDT: ChartDB Cache policy:  Application target is 913 MBytes
18:00:11 EDT: Chartlist file not found, config chart dir array is empty.  Chartlist target file is:/home/aruntu/.opencpn/chartlist.dat
18:00:11 EDT: GPS Watchdog Timeout is: 6 sec.
18:00:11 EDT: OpenCPN Initialized in 7382 ms.
18:00:11 EDT: Loading World Chart Q=0 in 0 ms.
18:00:11 EDT: Background world map loaded from GSHHS datafiles found in: /usr/local/share/opencpn/gshhs/
18:00:11 EDT: Looking for UserIcons at /home/aruntu/.opencpn/UserIcons
18:00:11 EDT: Loading navobjects from navobj.xml
18:00:11 EDT: Done loading navobjects
18:00:11 EDT: PlugInManager searching for PlugIns in location /usr/local/lib/opencpn
18:00:12 EDT: LOGBOOK:  2015-08-21 22:00:12 UTC  DR Lat   33.35800 Lon  -79.28200
18:00:13 EDT:    ***GPS Watchdog timeout at Lat:33.358   Lon: -79.282
18:00:16 EDT: ChartSymbols loaded from /usr/local/share/opencpn/s57data/chartsymbols.xml
18:00:17 EDT: Using s57data in /usr/local/share/opencpn/s57data
18:00:19 EDT: Detected display size (horizontal): 508 mm
18:00:54 EDT: Chart cache purge
18:00:55 EDT:    
18:00:55 EDT: Starting chart database Update...
18:00:55 EDT: Searching directory: /home/aruntu/Charts/US_RNC_NY/BSB_ROOT/14815 for *.kap
18:00:55 EDT: Loading chart data for /home/aruntu/Charts/US_RNC_NY/BSB_ROOT/14815/14815_1.KAP
18:00:55 EDT:    Adding chart file: /home/aruntu/Charts/US_RNC_NY/BSB_ROOT/14815/14815_1.KAP
18:00:55 EDT: Loading chart data for /home/aruntu/Charts/US_RNC_NY/BSB_ROOT/14815/14815_2.KAP
18:00:55 EDT:    Adding chart file: /home/aruntu/Charts/US_RNC_NY/BSB_ROOT/14815/14815_2.KAP
18:00:55 EDT: Searching directory: /home/aruntu/Charts/US_RNC_NY/BSB_ROOT/14815 for *.geo
18:00:55 EDT: Searching directory: /home/aruntu/Charts/US_RNC_NY/BSB_ROOT/14815 for *.000
18:00:55 EDT: Searching directory: /home/aruntu/Charts/US_RNC_NY/BSB_ROOT/14815 for *.s57
18:00:55 EDT: Searching directory: /home/aruntu/Charts/US_RNC_NY/BSB_ROOT/14815 for 00300000.a
18:00:55 EDT: Finished chart database Update
18:00:55 EDT:    
18:00:55 EDT: Chart cache purge
18:00:55 EDT: Chart cache purge
18:04:34 EDT: Initializing Chart /home/aruntu/Charts/US_RNC_NY/BSB_ROOT/14815/14815_1.KAP
18:04:35 EDT: Warning: Color not found CHDRD
18:09:42 EDT: Detected display size (horizontal): 508 mm
18:10:17 EDT: Chart cache purge
18:10:17 EDT: Initializing Chart /home/aruntu/Charts/US_RNC_NY/BSB_ROOT/14815/14815_1.KAP
18:10:18 EDT: OpenGL-> Renderer String: Mali-400 MP
18:10:18 EDT: OpenGL-> Version reported:  1.4 glshim wrapper
18:10:18 EDT: OpenGL-> Texture rectangle format: de1
18:10:18 EDT: OpenGL-> glGenerateMipmap unavailable
18:10:18 EDT: OpenGL-> Using Vertexbuffer Objects
18:10:18 EDT: OpenGL-> Framebuffer Objects unavailable
18:10:18 EDT: OpenGL-> Using Depth buffer clipping
18:10:18 EDT: OpenGL-> Not Using compression
18:10:18 EDT: OpenGL-> Minimum cartographic line width:  1.0
18:10:18 EDT: OpenGL-> Minimum symbol line width:  1.0

[did-g]

Hi,

Originally Posted by NahanniV

Next Problem:

I can't use S57 ENCs at all.

If I start with a clean system (delete .opencpn: .config, .log, .xml, /senc/*.*).

Then add s57 chart directory (current US ENCs for NY).
OpenGL not configured and no other configuration changed.

When I pan and zoom to display the first chart I get the window showing the chart being processed but the program aborts before it is displayed.

Any Ideas ?

Cheers,
JM.

Can you try the attached patch?
It remove the ARM ifdef and align the buffer on a double word (32bits) for floats.
Not pretty but should work, and should be faster.

Didier

[NahanniV]

Originally Posted by did-g

Hi,

Can you try the attached patch?
It remove the ARM ifdef and align the buffer on a double word (32bits) for floats.
Not pretty but should work, and should be faster.

Didier

Thank you Didier !

I was able to to load all the ENC charts for New York State without a crash (using -unit_test_1).
The only problem during that test was a bunch of identical messages in the terminial window:
"(opencpn:2622): Gtk-CRITICAL **: IA__gtk_widget_get_direction: assertion 'GTK_IS_WIDGET (widget)' failed"

Can you do a pull request for these changes ?

I think maybe an operating system upgrade may have enabled checking for alignment errors, since these charts seemed to work in the past? Could that be the case?

Cheers,
JM.

[NahanniV]

Further to the alignment issue:

Is the ARMHF code in Osenc.cpp and CM93.cpp correct ?

Cheers,
JM.

[bdbcat]

jm...

I don't think you are experiencing alignment problems, since this code runs just fine on Android (ArmV7).

Must be something else.

I will shortly have the mental bandwidth to come up on RPI2. Anything you can do to move along in the meantime is appreciated.

You may want to try a build without gcc optimization (-O0). This will make your ddd/gdb backtraces more readable.

Dave

[NahanniV]

Originally Posted by bdbcat

jm...

I don't think you are experiencing alignment problems, since this code runs just fine on Android (ArmV7).

Must be something else.

I will shortly have the mental bandwidth to come up on RPI2. Anything you can do to move along in the meantime is appreciated.

You may want to try a build without gcc optimization (-O0). This will make your ddd/gdb backtraces more readable.

Dave

Ok, I only know enough about this to be dangerous.

Didier's changes did fix the problem I was having.

A bit of reading seems to say that the handling of alignment is somewhat configurable.

I will use those switches when compiling.

I think the RPi2 will probably be the most popular platform due to price, availability and unfortunately hype. I would be fine with switching to it once the video acceleration is made to work; but I would miss the built-in SATA and WiFi on the CubieTruck.

Cheers,
JM.

[did-g]

Hi,

Originally Posted by bdbcat

jm...

I don't think you are experiencing alignment problems, since this code runs just fine on Android (ArmV7).

Must be something else.


Dave

Without JM old and new executables I have no idea why it was working before on his raspberry, moreover I have zero knowledge about ARM assembler but an objdump -d libopencpn.so (latest android beta) and searching for S57Obj returns:

  69f9e8:       e51b304c        ldr     r3, [fp, #-76]  ; 0xffffffb4
  69f9ec:       e2832004        add     r2, r3, #4
  69f9f0:       e50b204c        str     r2, [fp, #-76]  ; 0xffffffb4
  69f9f4:       e5933000        ldr     r3, [r3]
  69f9f8:       e50b30c8        str     r3, [fp, #-200] ; 0xffffff38
  69f9fc:       e51b304c        ldr     r3, [fp, #-76]  ; 0xffffffb4
  69fa00:       e2832004        add     r2, r3, #4
  69fa04:       e50b204c        str     r2, [fp, #-76]  ; 0xffffffb4
  69fa08:       e5933000        ldr     r3, [r3]
  69fa0c:       e50b30cc        str     r3, [fp, #-204] ; 0xffffff34
  69fa10:       e51b304c        ldr     r3, [fp, #-76]  ; 0xffffffb4
  69fa14:       e2832004        add     r2, r3, #4
  69fa18:       e50b204c        str     r2, [fp, #-76]  ; 0xffffffb4
  69fa1c:       e5933000        ldr     r3, [r3]
  69fa20:       e50b30d0        str     r3, [fp, #-208] ; 0xffffff30
  69fa24:       e51b304c        ldr     r3, [fp, #-76]  ; 0xffffffb4
  69fa28:       e5933000        ldr     r3, [r3]
  69fa2c:       e50b30d4        str     r3, [fp, #-212] ; 0xffffff2c
  69fa30:       e51b3210        ldr     r3, [fp, #-528] ; 0xfffffdf0
  69fa34:       e2836050        add     r6, r3, #80     ; 0x50
  69fa38:       e51b00cc        ldr     r0, [fp, #-204] ; 0xffffff34
  69fa3c:       ebf288c9        bl      341d68 <__aeabi_f2d@plt>
  69fa40:       e1a04000        mov     r4, r0
  69fa44:       e1a05001        mov     r5, r1
  69fa48:       e51b00d4        ldr     r0, [fp, #-212] ; 0xffffff2c
  69fa4c:       ebf288c5        bl      341d68 <__aeabi_f2d@plt>
  69fa50:       e1a02000        mov     r2, r0
  69fa54:       e1a03001        mov     r3, r1
  69fa58:       e1cd20f0        strd    r2, [sp]
  69fa5c:       e1a00006        mov     r0, r6
  69fa60:       e1a02004        mov     r2, r4
  69fa64:       e1a03005        mov     r3, r5
  69fa68:       ebf3da5f        bl      3963ec <_ZN13wxBoundingBox6SetMinEdd>

It doesn't use FPU registers so it doesn't care about alignment.
For me that's emulated soft FPU code, not hardware FPU code.

Didier

[NahanniV]

Originally Posted by did-g

Hi,

Without JM old and new executables I have no idea why it was working before on his raspberry,
...............

I should clarify. When I say Working (on CubieTruck), ENC charts were never working 100%. There were always problems with inconsistent and incorrect display of the charts. But it was not crashing OpenCPN. Other users with the same hardware experienced the same problems.

If you think it's important I can try to re-create that older environment; Otherwise, I am happy with your fix and would like to move forward.

Cheers,
JM.

[verkerkbr]

JM,

compiled the Beta version 4.1.818 without any problem on my BananaPi.

Changed the OS to Debian 8 Jessie (BananaPi version from the Cubie site).

OpenCPN is now running the Dutch ENC charts without errors.

However still no hardware acceleration tried.

GLXgears running at 53 FPS without program loaded.

Regards,


Bram

[NahanniV]

Hi Bram,

Originally Posted by verkerkbr

....
However still no hardware acceleration tried.
....

I'm not sure what you are saying here? Did you try it and it didn't work? If so, what happened, can you post the logfile?

Originally Posted by verkerkbr

....
GLXgears running at 53 FPS without program loaded.
....

GLShim is now included in OpenCPN, I don't think it's available to other programs like GLXgears, so that's no longer a valid test.

Cheers,
JM.

[verkerkbr]

Good afternoon JM,

my reply was to your remarks about the ENC charts.

OpenCpn 4.1.818 is now running fine on the BananaPi with Debian 8 Jessie which a got form Cubie site.

Next fases are the hardware graphics acceleration and the touchscreen setting for the monitor.

I understand that GLShim is now included in the beta 4.1.818.

Any advise how to proceed with GLShim already in the beta ? Or just follow the text of your instructions.

Thanks for all you efforts,

Bram

[NahanniV]

Originally Posted by verkerkbr

Good afternoon JM,

my reply was to your remarks about the ENC charts.

OpenCpn 4.1.818 is now running fine on the BananaPi with Debian 8 Jessie which a got form Cubie site.

Next fases are the hardware graphics acceleration and the touchscreen setting for the monitor.

I understand that GLShim is now included in the beta 4.1.818.

Any advise how to proceed with GLShim already in the beta ? Or just follow the text of your instructions.

Thanks for all you efforts,

Bram

My instructions are not up to date.
I don't think there are any special instructions needed now.

When you run cmake check the output to be sure it is using OpenGLes that will confirm that GLShim is being included in your build. If you only see OpenGL it will be using the slow software version.
You can also check the log file after configuring accelerated graphics.

Cheers,
JM.

[verkerkbr]

Good Morning JM,

I still had the "Software Rasterizer" in the log with the latest Git file. As always I had put on the video acceleration button.

Now if I switch this button to off. There is no longer "Software Rasterizer" in the log.

And the O screens are moving quicker then before. Does this mean that GLshim is only working if you put acceleration tab to "off" ?

Regards,

Bram

[seandepagnier]

Originally Posted by verkerkbr

Good Morning JM,

I still had the "Software Rasterizer" in the log with the latest Git file. As always I had put on the video acceleration button.

Now if I switch this button to off. There is no longer "Software Rasterizer" in the log.

And the O screens are moving quicker then before. Does this mean that GLshim is only working if you put acceleration tab to "off" ?

Regards,

Bram

the accleration check box enables opengl (or opengles or glshim) If you have software rasterizer in the log, then opengl is being performed in software which is usually slow.

If you want to get good acceleration you need to have acceleration enabled, and the log file must not read software rasterizer. It's probably because either you compiled opencpn without glshim support (did not detect openGLES) or you did not install hardware accelerated openGLES libraries and so it is using softare openGLES which is actually very slow.

I suggest you try running es2_info and es2gears.