NEON support in Linux Kernel 2.6.22.18-omap3 in OMAP3503 SDK v1.0.0

Is this kernel available through TI?

Kernel version 2.6.22-18 is the latest kernel version available thru TI.

What's the best solution to this problem?

Since you are looking at upgrading only the NEON related infrastructure of your kernel, you may want to look at the ARM Ltd. linux-arm Git available here.

You will notice that the tree is still on 2.6.24; but the NEON related patches should mostly be kernel version agnostic & can easily be applied on 2.6.22 kernel. Manual merge may be required for the unified instruction support; but it is significantly less (and controlled) work than migrating to a newer kernel.

Would be useful, if you could share back your experience.

I could not say if the kernel update is required, I can say that we do not have that kernel version available with the SDK package, and that internally there have been several benchmarks run using NEON enabled code without running into this issue.

The first thing that comes to mind here is some sort of version difference in the compiler you are using, we validated the SDK with the Code Sourcery 2007q3 toolset, if you are using a newer toolset that difference could be bringing out these sorts of errors, the only place I have heard of any similar issue was with a newer toolset, not the 2007q3 that TI validated the SDK with.

Hi Bernie,

Bernie Thompson said:

I could not say if the kernel update is required, I can say that we do not have that kernel version available with the SDK package, and that internally there have been several benchmarks run using NEON enabled code without running into this issue.

Are you saying that the kernel version 2.6.22-18 that I'm seeing is wrong?

Bernie Thompson said:

The first thing that comes to mind here is some sort of version difference in the compiler you are using, we validated the SDK with the Code Sourcery 2007q3 toolset, if you are using a newer toolset that difference could be bringing out these sorts of errors, the only place I have heard of any similar issue was with a newer toolset, not the 2007q3 that TI validated the SDK with.

Well, I didn't even rebuild the kernel from the source, I simply flashed the pre-built 'pristine' kernel image that comes with the SDK 1.0.0 at: OMAP35x_SDK_1.0.0/bin/OMAP35x/uImage

And I'm pretty sure I stuck with Code Sourcery 2007q3 on my Linux machine where I've installed the SDK anyway, but as I didn't actually rebuild the kernel from source, that shouldn't come into it.

Unless you're suggesting that I should backtrack to Code Sourcery 2007q3 for the purpose of building the software executable that I'm trying to run under Linux as well...? (ARM's Application Note 178 advise us to use anything later than 2006-q1)

I believe Bernie was suggesting we do not provide 1.6.25 kernel; Kernel 2.6.22-18 is what we include with our SDK and you are doing the right thing by first trying things out with the pre-built binary as oppossed to building your own.

The other suggestion Bernie made was to use to same version of Code Sourcery tool-chain we use (2007q3) since this is what we have tested then benchmarks with and have not encountered any issues. 

Additionaly, can you tell us which compiler flags you are using to build?  I believe if you have -mfpu=neon, you also need to have -O3 to get NEON instructions.

Hi Juan,

Juan Gonzales said:

The other suggestion Bernie made was to use to same version of Code Sourcery tool-chain we use (2007q3) since this is what we have tested then benchmarks with and have not encountered any issues. 

Additionaly, can you tell us which compiler flags you are using to build?  I believe if you have -mfpu=neon, you also need to have -O3 to get NEON instructions.

OK, I can try to installing 2007q3 on my ARM development machine and see if that makes any difference.  I'll let you know what I find.  I've currently got 2008-q1 for building the Linux executables for ARM.

As far as the compiler flags, I'm using armcc (ARM's tools, rather than Code Sourcery's), so there's no -mfpu option.  I am specifying -O3 -Otime.  Also, the --vectorize option to ask the compiler to perform vectorization (generate NEON code) where possible.

Command looks like this:

armcc -c --diag_style=ide --depend="$(@:%.o=%.d)" --depend_format=unix_escaped --no_depend_system_headers --c99 --debug --gnu --cpu=Cortex-A8 --apcs=/interwork -O3 -Otime --diag_warning=optimizations -I"../../../../../code/DSPLib/target_ARM" -I"../../../../../code/TDAS" -I"../../../../../code/DSPLib/compiler_ARM_RVDS3.1" -I"../../../../../code/TDAS/bundle_dolbymobile_2" -I"../../../../../code/DSPLib" -J"../../common/include" -J"C:\Program Files\CodeSourcery\Sourcery G++ Lite/lib/gcc/arm-none-linux-gnueabi/4.2.3/include" -J"C:\Program Files\CodeSourcery\Sourcery G++ Lite/arm-none-linux-gnueabi/libc/usr/include" -J"C:\Program Files\CodeSourcery\Sourcery G++ Lite/arm-none-linux-gnueabi/include/c++/4.2.3" -J"C:\Program Files\CodeSourcery\Sourcery G++ Lite/arm-none-linux-gnueabi/include/c++/4.2.3/arm-none-linux-gnueabi" -DCLOCK_PROFILER -DTI_OMAP3503 --vectorize --dwarf2 --enum_is_int --library_interface=aeabi_glibc --no_hide_all --wchar32 --preinclude linux_rvct.h --bss_threshold=0 --asm

Juan Gonzales said:

The other suggestion Bernie made was to use to same version of Code Sourcery tool-chain we use (2007q3) since this is what we have tested then benchmarks with and have not encountered any issues. 

OK, I've tried both 2007q3 and the latest one (2008q3).  The problem still happens in either case.

Well, I have a dig around the 1.0.0 SDK, and tried running 'make omap3evm_defconfig' and 'make menuconfig'.

There's a whole section in the kernel configuration called "Floating point emulation".

The section looks something like this:

[*] NWFPE math emulation

[] Support extended precision

[] FastFPE math emulation (EXPERIMENTAL)

[*] VFP-format floating point maths

[] NEON Advanced SIMD Extension support

Would it be worth my while checking the NEON option and rebuilding the kernel?

Well, I didn't even rebuild the kernel from the source, I simply flashed the pre-built 'pristine' kernel image that comes with the SDK 1.0.0 at: OMAP35x_SDK_1.0.0/bin/OMAP35x/uImage

The NEON support may not be "pre-built" into the linux kernel contained into the SDK. This is evident from the 'make menuconfig' options that you have listed above.

Refer to the FAQ "How to enable the NEON coprocessor?" here.

armcc -c --diag_style=ide --depend="$(@:%.o=%.d)" --depend_format=unix_escaped --no_depend_system_headers --c99 --debug --gnu --cpu=Cortex-A8 --apcs=/interwork -O3 -Otime --diag_warning=optimizations -I"../../../../../code/DSPLib/target_ARM" -I"../../../../../code/TDAS" -I"../../../../../code/DSPLib/compiler_ARM_RVDS3.1" -I"../../../../../code/TDAS/bundle_dolbymobile_2" -I"../../../../../code/DSPLib" -J"../../common/include" -J"C:\Program Files\CodeSourcery\Sourcery G++ Lite/lib/gcc/arm-none-linux-gnueabi/4.2.3/include" -J"C:\Program Files\CodeSourcery\Sourcery G++ Lite/arm-none-linux-gnueabi/libc/usr/include" -J"C:\Program Files\CodeSourcery\Sourcery G++ Lite/arm-none-linux-gnueabi/include/c++/4.2.3" -J"C:\Program Files\CodeSourcery\Sourcery G++ Lite/arm-none-linux-gnueabi/include/c++/4.2.3/arm-none-linux-gnueabi" -DCLOCK_PROFILER -DTI_OMAP3503 --vectorize --dwarf2 --enum_is_int --library_interface=aeabi_glibc --no_hide_all --wchar32 --preinclude linux_rvct.h --bss_threshold=0 --asm

I see that compiler is armcc, but the see too many "-J" options pointing to Code Sourcery G++ headers.

You should certainly have NEON support enabled in your kernel to use NEON instructions in your code, you are correct that it is not enabled by the default OMAP3503 build that comes with the SDK, but if you change to a OMAP3530 build (another option in menuconfig) it will force NEON support, I apologize I was assuming you were using this option since your original post was talking about kernel versions and their NEON support (and I did not know what happens if you tried running NEON code in a non NEON kernel). Please let us know if you no longer get the errors when you use a rebuilt kernel with NEON support and the 2007q3 tools (or even the newer tools with the rebuilt kernel), hopefully this resolves the issue, and at the least it is one step closer.

Hi everyone,

Well the good news is that enabling the NEON config option and rebuilding the kernel seems to have fixed my problem!  Phew!

Sanjeev Premi said:

Refer to the FAQ "How to enable the NEON coprocessor?" here.

I wasn't aware of this page.  Thanks for letting me know about it!

Bernie Thompson said:

You should certainly have NEON support enabled in your kernel to use NEON instructions in your code, you are correct that it is not enabled by the default OMAP3503 build that comes with the SDK, but if you change to a OMAP3530 build (another option in menuconfig) it will force NEON support, I apologize I was assuming you were using this option since your original post was talking about kernel versions and their NEON support (and I did not know what happens if you tried running NEON code in a non NEON kernel). Please let us know if you no longer get the errors when you use a rebuilt kernel with NEON support and the 2007q3 tools (or even the newer tools with the rebuilt kernel), hopefully this resolves the issue, and at the least it is one step closer.

I rebuilt it with CodeSourcery 2007q3, didn't try it with newer versions.

I'm a bit bemused as to why the default kernel would not have NEON support enabled automatically.  The OMAP3503 has a Cortex-A8 core on it, which is NEON-enabled.  At the very least, the fact that it is not enabled by default (and therefore you'll need to do a kernel reconfig/rebuild if you want to write NEON code to run on it) should be made very clear and obvious somewhere.  I don't believe I've seen anything that says this, unless I've missed it somewhere...?

I am happy to hear this has fixed the issue. 

With regards to NEON being disabled by default; the only reason I can see for doing this is that we wanted some time to run internal tests and benchmarks before enabling this feature by default.  We always welcome customer feedback to help us improve our offering and if you see this as detrimental, we like to hear this feedback so we can change this in future releases.  I can see that this caused some confusion with regards to this issue, so I will provide this feedback to our product teams for consideration.

Quang Thai said:

I'm a bit bemused as to why the default kernel would not have NEON support enabled automatically. 

There would be good number of users who do not (and possibly would not) use NEON. It is difficult to make decision on default configuration in these 50:50 cases.

At the same time, later versions of the Linux releases have NEON enabled by default.

I am also dealing with a similar issue on my Cortex-A8 (3430) board running TI BSP (Linux 2.6). I have enabled Neon support in config and recompiled (CS 2007Q1) the kernel. However, I still get illegal instruction exception when I run my app that uses Neon intrinsics. I was wondering if you can suggest additional mechanisms to check/ensure that Neon SIMD support is enabled in my build. (BTW, I also tried to look what additional code gets enabled by CONFIG_NEON=y option in kernel src, but could not come up with much that could enhance my understanding of this issue. Please add if you have any details on this as well)

Also, I noticed something interesting in ARM CortexA8 documents that if Neon is not enabled on CPU you will get undefined instruction exceptions ( http://infocenter.arm.com/help/topic/com.arm.doc.ddi0344i/Cacigieh.html ), so I was wondering how one could configure (enable/disable) this NEON option on a Cortex-A8 processor.

I will appreciate any help on above questions. Thanks.