ARMv7 support

[Chris]

Hi All,

as much as i know is ARMv7 and hardware floating point supported by
the new NDKr4. According to the documentation fo the NDKr4 the code
will be compiled with ARMv7 support if I add the "Application.mk" file
to the projects jni folder. The file has to contain the line
"APP_ABI := armeabi armeabi-v7a" and the compiler should build two
shared libraries. When i compile my floating point unit test with the
NDK compiler with AMRv7 support it builds two versions of the
binaries. One of the shared libraries is in the folder "armeabi" and
the other one in "armeabi-v7a". According to the documentation the
package manager should only unpack the most appropriate machine code
for the target device but in my case the execution time of the
floating point test is allways the same. If i add the line "APP_ABI :=
armeabi-v7a" to the "Application.mk" file the applications crashes.

My assumption is, that Android always uses the shared lib that is
compiled for armeabi but not the one that is for armeabi-v7a but I do
not know why that happens...

A similar problem accours when i compile and run the hello-neon
application from the NDKr4 samples. The program shows the Line "Neon
version: Program not compiled with ARMv7 support" but the
"Application.mk" file contains the line "APP_ABI := armeabi armeabi-
v7a" and the processor on the board is an Cortex-A8. In my oppinion it
should work but I do not know why it doesn't.

Does anyone know a solution for that problems?

I'm running the code on a "Freescale i.MX51 Evaluation Kit with
Android"
The kernel version is 2.6.28-00554-gdc33474-dirty lmx@ubuntu #2
The Android firmware version is 1.6
NDKv4 is used to compile the code with the ndk-build command.

Thank's for every response and help...
Cheers
Chris from Austria (Tirol)

[Divkis]

Hi Chris,
though I have not tried using NDKr-4 but since I needed
to generate ARMv7 compiled code, I have used adhock mechanism for
passing the compiler the options to build the code with ARMv7 specific
instructions. Thus the following comments may or may not help you.

> If i add the line "APP_ABI :=
> armeabi-v7a" to the "Application.mk" file the applications crashes.

That could be because with the flag above the compiler could be
generating code for hard floating point ABI. From what I am aware the
whole system and the APPs should be generated using hard floating ABI.
Mix and match with hard floating point ABI wouldn't work.

You need to post the exact build command that is being issued by the
NDK build system when compiling the application. Also specifying the
exact crash signal (SIGILL or SIGSEGV) that is sent to your
application might help predict what is wrong.


Hope that helps,
Regards,
DivKis

[David Turner]

It really looks like that the PackageManager thinks your board/build only supports armeabi,

and not armeabi-v7a.

To properly support ARMv7 NDK executables, you will need two lines in your BoardConfig.mk:

TARGET_CPU_ABI : = armeabi-v7a

TARGET_CPU_ABI2 := armeabi

The first one tells the system that armeabi-v7a is your main system ABI

The second one tells it that you also support armeabi binaries.

Both lines are necessary if you later want the Market to list packages containing either ARMv5TE and ARMv7 machine code

for your system.

By default, only "armeabi" is assumed, which is why only the "armeabi" binaries are extracted from the .apk at installation time.

--
You received this message because you are subscribed to the Google Groups "android-ndk" group.
To post to this group, send email to andro...@googlegroups.com.
To unsubscribe from this group, send email to android-ndk...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/android-ndk?hl=en.

[Piotr Buła]

I have the exact same problem with my Motorola Milestone. I know that
it's arm7 and supports VFP and NEON. However, the 'hello-neon' sample
app behaves exactly like Chris described. I also tried removing
armeabi from Application.mk, but that only resulted in application not
launching (with Resource not found or some such errors in the logs).
So it looks like Milestone totally ignores armeabi-v7a. Is that
normal?

And more importantly, is there a way around this problem?

Thanks,
Piotr

On Jun 20, 4:53 pm, David Turner <di...@android.com> wrote:
> It really looks like that the PackageManager thinks your board/build only
> supports armeabi,
> and not armeabi-v7a.
>
> To properly support ARMv7 NDK executables, you will need two lines in your
> BoardConfig.mk:
>
> TARGET_CPU_ABI : = armeabi-v7a
> TARGET_CPU_ABI2 := armeabi
>
> The first one tells the system that armeabi-v7a is your main system ABI
> The second one tells it that you also support armeabi binaries.
>
> Both lines are necessary if you later want the Market to list packages
> containing either ARMv5TE and ARMv7 machine code
> for your system.
>
> By default, only "armeabi" is assumed, which is why only the "armeabi"
> binaries are extracted from the .apk at installation time.
>

> > android-ndk...@googlegroups.com<android-ndk%2Bunsu...@googlegroups.com>
> > .

[Christian Kuen]

Hi David,

thank's for your quick response. I asked Freescale who is the manufacturer of the board (http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=MCIMX51EVKJ) if their Android version supports ARMv7 or not and the answer was NO. The BoardConfig.mk does not include the line "TARGET_CPU_ABI : = armeabi-v7a" and therefore it does only work with armeabi.

thank's again for your help...
Chris

 

[Christian Kuen]

Hi David,

the board I use does not support ARMv7 and hardware VFP because of the BoardConfig.mk, so my FPU test code written in C++ is quite slow because the calculations are emulated in software. If i run the same test in Java it is slower what I expected but it is so so MUCH slower (30 times slwoer) what I did not expect.

Is this because Dalvik does not use ARMv7 code and hardware FPU?

Do you think, changing the BoardConfig.mk would improve the Java perfomance?

thank's for your answers
Cheers,
Chris

[fadden]

On Jun 28, 12:28 am, Christian Kuen <christian.k...@gmail.com> wrote:
> Is this because Dalvik does not use ARMv7 code and hardware FPU?

The VM is built for a specific target. If you build it for armv7-a,
it will use ARMv7-A and VFP instructions. If you build it for
ARMv5TE, it'll use the software implementation. There is no run-time
detection.

[Olivier Guilyardi]

On 06/21/2010 03:01 PM, Piotr Buła wrote:
> I have the exact same problem with my Motorola Milestone. I know that
> it's arm7 and supports VFP and NEON. However, the 'hello-neon' sample
> app behaves exactly like Chris described. I also tried removing
> armeabi from Application.mk, but that only resulted in application not
> launching (with Resource not found or some such errors in the logs).
> So it looks like Milestone totally ignores armeabi-v7a. Is that
> normal?
>
> And more importantly, is there a way around this problem?

I have the same problem here on a Motorola Milestone running Android 2.1-update1.

I'm compiling for both ABIs with this in Application.mk:
APP_ABI := armeabi armeabi-v7a

I can see that the armeabi-v7a libs are built, and that my apk is now double
sized (sigh..).

But, when installing the app, I get this in logcat:
D/PackageManager( 1278): Caching shared lib lib/armeabi/librecorderenginejni.so

D/PackageManager( 1278): Caching shared lib lib/armeabi/libsndfile.so

D/PackageManager( 1278): Caching shared lib lib/armeabi/libavcodec-resample.so

Which seems to mean that the armeabi-v7a libs are ignored, and anyway it doesn't
run faster.

Is this a problem with the way Motorola built Android?

Would it work on, say, a Nexus One or an HTC Desire?

--
Olivier

[David Turner]

Yes, and we already informed Motorola about that, afaik

 

Would it work on, say, a Nexus One or an HTC Desire?

Yes for the Nexus One, I don't know about the HTC Desire.

 

--
 Olivier

--
You received this message because you are subscribed to the Google Groups "android-ndk" group.
To post to this group, send email to andro...@googlegroups.com.

To unsubscribe from this group, send email to android-ndk...@googlegroups.com.

[Olivier Guilyardi]

On 07/09/2010 09:08 PM, David Turner wrote:
>
> On Fri, Jul 9, 2010 at 11:57 AM, Olivier Guilyardi <li...@samalyse.com

> <mailto:li...@samalyse.com>> wrote:

[...]

> Which seems to mean that the armeabi-v7a libs are ignored, and
> anyway it doesn't
> run faster.
>
> Is this a problem with the way Motorola built Android?
>
> Yes, and we already informed Motorola about that, afaik
>
> Would it work on, say, a Nexus One or an HTC Desire?
>
> Yes for the Nexus One, I don't know about the HTC Desire.

I see, but all in all it means that very few of my users will benefit of this
currently. And since it's about audio codecs, it's a bit critical. And I can't
even test it right now, since I don't have a Nexus One or so.

I guess fixed-point is still the way...

Thanks

--
Olivier

[Olivier Guilyardi]

Alright, I changed my code to fixed point, and am using the following ARM asm:
http://svn.xiph.org/trunk/Tremor/asm_arm.h

It states "arm7 and later" but I'm unsure if that means ARMv7..

And these asm routines appear to work on the following devices:
- Samsung i7500 Galaxy
- HTC Magic 32B
- Motorola Milestone

Do you think that this is safe for ARMv5, in an armeabi lib?

--
Olivier

[fadden]

On Jul 9, 5:45 pm, Olivier Guilyardi <l...@samalyse.com> wrote:
> Alright, I changed my code to fixed point, and am using the following ARM asm:http://svn.xiph.org/trunk/Tremor/asm_arm.h
>
> It states "arm7 and later" but I'm unsure if that means ARMv7..

All the stuff in there looks pretty basic. I think they meant arm7,
which means it'll run on basically any ARM CPU that isn't totally
obsolete.

[Olivier Guilyardi]

Thanks for confirming this. These asm routines provide 1.5x speed improvement,
which is very appreciable in my case.

--
Olivier

[Tristan Miller]

Yeah.  It means arm7 the processor, not the ISA.  I remember using Tremor on hacked original iPods which are just simple little ARM7TDMIs.  It'll be safe to use on any Android ARM device.

Tristan Miller

On Jul 13, 2010 5:21 AM, "Olivier Guilyardi" <li...@samalyse.com> wrote:

On 07/13/2010 12:31 AM, fadden wrote:

> On Jul 9, 5:45 pm, Olivier Guilyardi <l...@samalyse.com> wro...

Thanks for confirming this. These asm routines provide 1.5x speed improvement,
which is very appreciable in my case.

--
 Olivier

--
You received this message because you are subscribed to the Google Groups "android-ndk" group.

...

[Olivier Guilyardi]

Okay, thanks.

By the way, have you ever used the Rockbox version of Tremor? Is this really faster?

Olivier

On 07/13/2010 11:38 PM, Tristan Miller wrote:
> Yeah. It means arm7 the processor, not the ISA. I remember using
> Tremor on hacked original iPods which are just simple little ARM7TDMIs.
> It'll be safe to use on any Android ARM device.
>
> Tristan Miller
>
>> On Jul 13, 2010 5:21 AM, "Olivier Guilyardi" <li...@samalyse.com

>> <mailto:li...@samalyse.com>> wrote:
>>
>> On 07/13/2010 12:31 AM, fadden wrote:
>> > On Jul 9, 5:45 pm, Olivier Guilyardi <l...@samalyse.com

>> <mailto:l...@samalyse.com>> wro...

>>
>> Thanks for confirming this. These asm routines provide 1.5x speed
>> improvement,
>> which is very appreciable in my case.
>>
>> --
>> Olivier
>>
>>
>> --
>> You received this message because you are subscribed to the Google
>> Groups "android-ndk" group.
>> ...
>>
> --
> You received this message because you are subscribed to the Google
> Groups "android-ndk" group.

[Tristan Miller]

No, I haven't used it, but I believe their performance claims.  They have both the incentive and the means to get there.  But to be sure you should benchmark the two.

Tristan Miller

On Jul 14, 2010 7:11 PM, "Olivier Guilyardi" <li...@samalyse.com> wrote:

Okay, thanks.

By the way, have you ever used the Rockbox version of Tremor? Is this really faster?

Olivier

On 07/13/2010 11:38 PM, Tristan Miller wrote:

> Yeah. It means arm7 the processor, not the ISA. I...

>> <mailto:li...@samalyse.com>> wrote:
>>
>> On 07/13/2010 12:31 AM, fadden wrote:

>> > On Jul 9, 5:4...

>> <mailto:l...@samalyse.com>> wro...

>>
>> Thanks for confirming this. These asm routines provide 1.5x speed
>> improvement,

>> which is ...

> To post to this group, send email to andro...@googlegroups.com.

> To unsubscribe from this grou...

--
You received this message because you are subscribed to the Google Groups "android-ndk" group.

To post to this group, send email to andro...@googlegroups.com.

To unsubscribe from this group, s...