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