Which branch of the s@h source should I check out to try to compile for 32-bit ARM on Ubuntu? Specifically, an Nvidia Tegra TK1 "Jetson" development kit. I obviously don't want to use something with embedded SSEx instructions, as I believe some branches provide.
Over on the main site, I've reported complete success compiling and running the Xbranch CUDA code (but no luck yet getting boincmgr compiled due to problems with wxWidgets). This leaves me with four ARM cores (the 5th, smaller core doesn't seem to be visible to Ubuntu) mostly idle (top usually shows 10-20% CPU usage for each of two instances), so I'd like to see how much they could add to the RAC.
Thanks.

Eric's SETI@home v7 ARM Android builds are from the seti_boinc source code, and so are generic Linux builds.

                                                                   Joe

Eric's SETI@home v7 ARM Android builds are from the seti_boinc source code, and so are generic Linux builds.

                                                                   Joe

Thanks. I checked that out and came up with the ld errors that Jackyman38 had elsewhere. I think I deciphered his patches OK and it compiled -- a few unrelated errors (couldn't find ../boinc/api !) but the executable is there and currently running manually on one of the WUs dished out to the GPU. It looks like it'll take 350-400 minutes to finish; the GPU validated a WU from the same tape in 100 mins, running two-at-once. If that pans out I'll try adding it to my app_info.xml and see if it returns valid results. Indications are that 4X CPUs will produce ~half the results of 2X instances on the GPU.
Ultimately I'll try 3X GPU instances as there seems to be a bottleneck; running two instances takes 50% more real-time but only 50% CPU time each compared to a single job.

If that pans out I'll try adding it to my app_info.xml and see if it returns valid results.

Unfortunately, it produced sigabort when running under BOINC.

Work Unit Info:
...............
WU true angle range is :  0.420966
features: swp half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt 
Optimal function choices:
--------------------------------------------------------
                            name   timing   error
--------------------------------------------------------
                v_BaseLineSmooth (no other)
           neon_GetPowerSpectrum 0.000247 0.00000 
*** Error in `../../projects/setiathome.berkeley.edu/seti_boinc': free(): invalid pointer: 0xb26da080 ***
*** Error in `../../projects/setiathome.berkeley.edu/seti_boinc': free(): invalid pointer: 0xb1ed9080 ***
SIGABRT: abort called
Stack trace (3 frames):
[0xa7f88]
[0x234210]
[0x22e906]

Looks similar to my attempt on the Parallella:

http://setiweb.ssl.berkeley.edu/beta/forum_thread.php?id=2164&postid=51071

Rather than using the Berkeley source, you could try using the Debian source,
But, my running of the locutusofborg-ppa Boinc and Seti builds are only producing invalids,
The earlier repository Boinc 7.2.42 and the r1951 did the same.

Not had a chance to build the Debian Seti app yet

https://packages.qa.debian.org/b/boinc-app-seti.html

Claggy

I edited in the patch (only for two functions, there was mention of three at one point) and the linking problems went away. I'd first configured with --disable-neon after seeing the link errors, and that ran OK manually albeit with

shmget in attach_shmem: Invalid argument
02:47:50 (21437): Can't set up shared mem: -1. Will run in standalone mode.

(that didn't appear in the stderr in the task report). I reconfigured without --disable-neon and it ran somewhat faster, but when I added it in my app_info.xml file I got the above errors.

I edited in the patch (only for two functions, there was mention of three at one point) and the linking problems went away. I'd first configured with --disable-neon after seeing the link errors, and that ran OK manually albeit with

shmget in attach_shmem: Invalid argument
02:47:50 (21437): Can't set up shared mem: -1. Will run in standalone mode.

(that didn't appear in the stderr in the task report). I reconfigured without --disable-neon and it ran somewhat faster, but when I added it in my app_info.xml file I got the above errors.