uclibc build error with cortex-m3 toolchain
Sergei Poselenov
sposelenov at emcraft.com
Fri Apr 29 14:33:47 UTC 2011
Hello all,
I've ran into the same problem when building uClibc threads for
the Cortex-M3 target.
The correct solution would be to write a proper version, using the
Cortex-M3 instructions for exclusive access (ldrex/strex).
However, on my target (A2F SmartFusion) these instructions don't work
due to device errata, so I'm inclined to implement testandset() via a
new kernel service.
Are there any other alternatives to this approach exist?
I'm thinking to introduce a new ARM syscall to
linux/arch/arm/include/asm/unistd.h:
/*
* The following SWIs are ARM private.
*/
#define __ARM_NR_BASE (__NR_SYSCALL_BASE+0x0f0000)
#define __ARM_NR_breakpoint (__ARM_NR_BASE+1)
#define __ARM_NR_cacheflush (__ARM_NR_BASE+2)
#define __ARM_NR_usr26 (__ARM_NR_BASE+3)
#define __ARM_NR_usr32 (__ARM_NR_BASE+4)
#define __ARM_NR_set_tls (__ARM_NR_BASE+5)
+#define __ARM_NR_atomicops (__ARM_NR_BASE+0x800)
From the uClibc side, this would look like the existing implementation
for the
Xtensa, see ./libpthread/linuxthreads.old/sysdeps/xtensa/pt-machine.h.
What do you think?
Are there any other alternatives to this system call approach exist?
I know about the kernel's __kuser_cmpxchg(), but it seems only exists
for MMU-enabled CPU's (our doesn't have MMU).
Any thoughts would be appreciated.
Regards,
Sergei
More information about the uClibc
mailing list