Chart Problems on Raspberry Pi

[nsweeting]

The 2011 version of CM93 just has directories with numbers - there is no reference to the location....

I compiled the latest OpenCPN beta with the malloc code change, but the CM93 maps crash opencpn upon trying to load them. Unsure as to what the difference could be.

Looked into the whole ARM - malloc thing. Googling 'arm malloc' gets lots of hits in reference to problems. Seems like embedded devices dont like malloc? I wonder if restructuring the cm93 file to be more arm compatible would help things run better...

[bdbcat]

Hi folks...

OK, finally got some mental bandwidth to start looking at arm for OCPN.

I have a generic 7" tablet, was 'Droid 3.2, rooted and ported Debian Squeeze, which gives me the armel ABI, not the armhf. Desktop is LXDE.
Ram is 512MB, Speed is 800MHz.

$cat /proc/cpuinfo
Processor : ARMv7 Processor rev 1 (v7l)
BogoMIPS : 1661.88
Features : swp half thumb fastmult vfp edsp neon vfpv3
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x1
CPU part : 0xc09
CPU revision : 1

Hardware : AMLOGIC MESON-M1 8726M SZ
Revision : 0020
Serial : 000000000000000b

Note that this hardware would run armhf, (vfp) if I was to reload Wheezy instead of Squeeze, or try to port Raspian to it.

On to OpenCPN....
I compiled and built the latest Beta (3.1.1224) natively using standard gnu tools from the Debian repos. No build errors after deps were satisfied.

Ran OpenCPN.
No faults, no crashes. BSB, cm93, and NOAA ENCs all load and display without error. It is too slow a platform to be usable, but it runs OK so far.

Preliminary conclusions:
Something is broken with Wheezy armhf port or toolchain

Which leads us back to:
The sizeof(double) problem which started this thread.

Next step:
We need one of the armhf (Raspberry PI) users here to add some simple code at the top of OpenCPN to prove the sizeof() issue;

In chart1.cpp, find and insert the following patch.
Note the two printf lines.

bool MyApp::OnInit()
{
    if( !wxApp::OnInit() ) return false;
    printf("sizeof(double) is %d\n", sizeof(double) );
    printf("sizeof(float) is %d\n", sizeof(float) );

Build O, and run from command line. Report results.
On armel, we get:

sizeof(double) is 8
sizeof(float) is 4

as we would expect. What do we get on armhf?

Dave

[bdbcat]

Contnued...

Does anyone have a recipe to run armhf (Wheezy or Raspian) on qemu? Anyone tried that and succeeded? Would save me some time if anyone has....

Thanks
Dave

[Alisdair]

Originally Posted by bdbcat

sizeof(double) is 8
sizeof(float) is 4

as we would expect. What do we get on armhf?

Dave

The same on RPi; double is 8, float is 4.

Alisdair

[bdbcat]

Hey guys...

OK, I got armhf running in qemu, using the Wheezy images in archive.raspbian.org. Network config to allow apt-get etc. was the toughest part.

I'm running X over an ssh session, since qemu does not provide an X compatible display GUI, AFAICT. It is slow, (~250 bogoMIPS, 256 MB RAM), but fully functional. Compile of O took about 3 hours.

I built OpenCPN from latest git sources. No errors.
I run OpenCPN with cm93, Canadian ENC, and BSB raster charts.

No crashes, no troubles, everything works as it should. It is too slow to be useful, however.

So, what do we conclude from this?

Possible sources of the chart errors observed elsewhere in this thread:

a. Problem with RPI hardware. Unlikely, since the error is seen by several users.

b. Problem with RPI gtk display driver stack. Maybe. I cannot test this without hardware.

c. Problem in RPI memory model. I'm leaning this way, since all failures look suspiciously like out-of-memory troubles. O does not religiously check the return of malloc() for heap allocation failures. Maybe we should, although it adds a lot of overhead, and really, there is nothing that can be done if malloc() returns NULL except terminate the application.

d. Other ideas?

It would be useful for some RPI user experiencing vector chart problems to try to run OCPN over an ssh X session. By this I mean to get a network connection to the RPI from another computer, and run a remote shell from that computer, viz:

$ssh -X 192.168.xx.xx -l raspbian

This would closely emulate my qemu setup.

Also, I would be interested to know the bogoMiIPS of a real RPI, as reported by

$cat /proc/cpuinfo

All feedback solicited.
Thanks
Dave

[stuartb]

This from latest Pi h'ware 512MB ram.

pi@raspberrypi ~ $ cat /proc/cpuinfo
Processor : ARMv6-compatible processor rev 7 (v6l)
BogoMIPS : 697.95
Features : swp half thumb fastmult vfp edsp java tls
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x0
CPU part : 0xb76
CPU revision : 7

Hardware : BCM2708
Revision : 000f
Serial : 00000000b41f593d
pi@raspberrypi ~ $

[stuartb]

I have O working as per Alisdair's instructions. In some areas I can zoom right in but but in others Opencpn crashes every time. Fortunately my boat is in a place that works. The UK definitely doesn't work but it's far to cold to sail there so who cares?
I have some strange chart colours and sometimes heavy contour lines.
Next step must be to try a GPS again.

[ephyraboater]

Originally Posted by bdbcat

Hey guys...

.....

d. Other ideas?

It would be useful for some RPI user experiencing vector chart problems to try to run OCPN over an ssh X session. By this I mean to get a network connection to the RPI from another computer, and run a remote shell from that computer, viz:

$ssh -X 192.168.xx.xx -l raspbian

This would closely emulate my qemu setup.

Also, I would be interested to know the bogoMiIPS of a real RPI, as reported by

$cat /proc/cpuinfo

All feedback solicited.
Thanks
Dave

Dave - I will do the ssh (perhaps an evening this week, but at least by Sunday) and let you know what I get - stuartb replied w/ the cpuinfo already.
-carl

[Alisdair]

Originally Posted by bdbcat

Compile of O took about 3 hours.

less than half an hour on slightly overclocked Pi

Originally Posted by bdbcat

I built OpenCPN from latest git sources. No errors.

git clone -b beta31_stable https://github.com/OpenCPN/OpenCPN.git


changed armel to armhf in CMakeLists.txt

A few build messages, such as uninitialised variables, but no errors

Originally Posted by bdbcat

..


It would be useful for some RPI user experiencing vector chart problems to try to run OCPN over an ssh X session. By this I mean to get a network connection to the RPI from another computer, and run a remote shell from that computer, viz:

$ssh -X 192.168.xx.xx -l raspbian

This would closely emulate my qemu setup.

I've run it using Putty/ssh/Xming on Windows but continue to have the same failures. I've tried with the Pi running with and without a window manager concurrently.

Originally Posted by bdbcat

Also, I would be interested to know the bogoMiIPS of a real RPI, as reported by

$cat /proc/cpuinfo

BogoMIPS : 697.95

same value irrespective of overclocking settings.

Errors are "Bus Error" when ingesting charts (Oregon ENC charts are all that are installed)

I'll try again tomorrow and see if I can provide useful deubug/backtrace information, rather than just "it doesn't work"



Alisdair

[bdbcat]

Alisdair...

Could you edit CMakeLists.txt to enable verbose make output:

SET(CMAKE_VERBOSE_MAKEFILE ON)

Then
$make clean
$make

and capture the build output. I would like to inspect/compare the compiler command lines. Also, the output of

$cmake ..

may show some differences between your build and mine.

Thanks
Dave

[stuartb]

Interesting. I just put the SD card back into my 256 Ram Pi. Opencpn ran the same, if there was any difference in speed opening the program or in zooming ( as compared with 512 MB ) then I didn't notice it. Opencpn still crashed or worked in the same areas. So is it likely that we don't have a problem with the amount of ram but just the way Opencpn is using it?
Cheers

[Alisdair]

Originally Posted by bdbcat

Alisdair...

Could you edit CMakeLists.txt to enable verbose make output:

SET(CMAKE_VERBOSE_MAKEFILE ON)

Then
$make clean
$make

and capture the build output. I would like to inspect/compare the compiler command lines. Also, the output of

$cmake ..

may show some differences between your build and mine.

Thanks
Dave

I updated my pi (apt-get dist-upgrade)

then I pulled a fresh copy of the source:

git clone git://github.com/OpenCPN/OpenCPN.git

Two changes were made to CMakeLists.txt: Updated with the VERBOSE option, and armel changed to armhf (without this change the compile wouldn't find various version.h files and similar infomation without editing the source)

output from cmake .. is here: OCPN cmake - Pastebin.com

output from make is here: OCPN make - Pastebin.com

opencpn.conf was updated with small (<=10) values for NCacheLimit and MEMCacheLimit

The Oregon NOAA ENC charts were loaded, and OCPN crashed when the smallest of these charts was ingesting.

output from gdb and bt is here: OCPN gdb - Pastebin.com

There's an opencpn.log file here: opencpn.log - Pastebin.com
This log is a session with an empty chart database;ENCs added;crash on ingestion.

There are errors reading TXT ENC, though the files look OK.


I hope that sheds some light


Alisdair

[bdbcat]

Alisdair....

Currently stumped.
All the build logs look virtually identical. I did not need to set arch=armhf, as the include files were found correctly.

The little chart US1PO02M loads and displays just fine for me.

You seem to have a repeatable failure spot. Let's chase this one for a bit.
It seems to be either a memory malloc() problem, or a double->float conversion problem.

s57chart.cpp, line 4985.

Please make the following change:

 
               printf("%d %d %d\n", wkb_len, nq_len, sb_len);
                float east = easting * 1.0;
                float north = northing * 1.0;
                *pdf++ = east;
                *pdf = north;
/*                
                *pdf++ = easting;
                *pdf = northing;
*/

We may chase our tails on this, but we need to try something....

Thanks
Dave

[Alisdair]

change made.

Ingestion progresses e.g. DAYMAR 34/1139
At the same time, 39 lines are output:
25 4 13

..then the bus error.

--

I copied the SENC directory that was created under .opencpn, cleared the ENC charts, and pointed OCPN at the SENC directory. Exactly the same behaviour, i.e. ingestion with 39 x "25 4 13" followed by the bus error.

[bdbcat]

Alisdair....

I'm now pretty sure that this is an alignment issue. I found the following (unattributed) quote online:

On all ARM floating-point architecture versions, float and double must  be size-aligned.  I don't think there has ever been any exception to  this rule, nor is any exception likely in the forseeable future IIUC.

Makes sense to me for a low-end minimal die-size CPU design.

I'll start taking a look at s57chart.cpp, which contains most of the float data conversion stuff. I think it will require some iteration to track down and kill all of these cases, especially since I can't seem to reproduce on the qemu emulator. IMHO, this is a serious fault in qemu, by the way.

More later
Dave