I was Googling ARM Neon optimizations, and I came across a pay-article written by someone who was talking about optimizing ECC using NEON. I didn't want to buy the article, nor would I understand it, but I was thinking about running some tests on whether or not NEON could be enabled in U-Boot.
At least for the OMAP3 boards which have HW detection and SW correction, I was wondering if the enhanced integer math might be useful for increasing NAND flash performance by helping with ECC calculations on board without HW correction.
I will admit that I don't know much about the NEON stuff or ECC, but when reading about it from GCC documentation, and it states:
"For floating-point and Advanced SIMD (Neon) instructions, the settings of the options -mfloat-abi and -mfpu must also be considered: floating-point and Advanced SIMD instructions will only be used if -mfloat-abi is not set to ‘soft’; and any setting of -mfpu other than ‘auto’ will override the available floating-point and SIMD extension instructions."
I looked through the build instructions, and it appears that we use:
arch/arm/config.mk:PLATFORM_RELFLAGS += $(call cc-option, -msoft-float) \
I wasn't sure how -msoft-float compares to mfloat-abi, but when I tried to change msoft-float to mhard-float it stopped working.
Can someone tell me if/why we still need to hard-code msoft-float?
Maybe I am wasting my time, but it seems like if the NEON has the ability to accelerate integers and not just floating points, it seems like there might be some performance enhancements depending on how the math works. I was hoping to run some simple benchmarks, but I cannot even get u-boot or SPL if I play around with the msoft-float, but some platforms disable it.
The Zynq platform seems to partially enable this, but it seems like it could be made more generic for any NEON enabled ARM.
arch/arm/mach-zynq/Makefile:AFLAGS_lowlevel_init.o := -mfpu=neon
adam