Hi, I am using imx6ul board which has cortex a7 processor. I am using ffmpeg .s files which has assembly code to integrate into our project to speed up the code. Here is the ffmpeg code in the file mdct_neon.S.
#include "asm.S".fpu neon
.text.global ff_imdct_half_neonfunction ff_imdct_half_neon //, export=1 push {r4-r8,lr}
mov r12, #1 ldr lr, [r0, #20] @ mdct_bits ldr r4, [r0, #24] @ tcos ldr r3, [r0, #8] @ revtab lsl r12, r12, lr @ n = 1 << nbits lsr lr, r12, #2 @ n4 = n >> 2 add r7, r2, r12, lsl #1 mov r12, #-16 sub r7, r7, #16
vld2.32 {d16-d17},[r7,:128],r12 @ d16=x,n1 d17=x,n0 vld2.32 {d0-d1}, [r2,:128]! @ d0 =m0,x d1 =m1,x
..............................
............................
I am getting bus error when the processor executes vld2.32 {d16-d17},[r7,:128],r12. I know this is a neon assembly instruction. I tried with different compilation flags like
arm-xilinx-linux-gnueabi-gcc -march=armv7-a -mfloat-abi=softfp -mfpu=neon -mno-unaligned-access
arm-xilinx-linux-gnueabi-gcc -march=armv7-a -mfpu=neon -mno-unaligned-access
arm-xilinx-linux-gnueabi-gcc -march=armv7-a -mfpu=neon
But I am unable to resolve this. Can anyone help me to solve this... Thanks
Hello,
if the mdct_bits can become 0, 1 or 2, 'add r7, r2, r12, lsl #1' will make 2, 4 or 8 byte aligned address respectively.
Therefore, I think you cannot use VLD2.32 for the base address of r7.
If it is guaranteed that mdct_bist is greater than 2, r2 should be 16 byte aligned.
Best regards,
Yasuhiko Koumoto.
how about clearing A bit (i.e. bit 1) of SCTLR (System Control Register).
The initial value of the A bit is 1 and the alignment check is always done.
If the A bit is set to 0, the alignment check might not be done.
Thanks yasuhiko for your reply...I will see whether the mdct_bits variable is creating problem. One more thing I am running this on Linux platform. How can I clear SCTLR value?
The SCTLR is only accessible to the Linux kernel, however, it is likely already set to enable unaligned accesses.
Removing the ":128" from the VLD2 assembly instructions will likely remove the "bus fault", however, you will need to ensure that the rest of the algorithm functions correctly with r7's alignment not being what was expected.
Simon.
Thanks Simon...That's solved the problem...