m1/patches/rtems/: pending RTEMS patches (relative to latest CVS)

m1/patches/rtems/lm32-stack-alignment.patch

@@ -0,0 +1,48 @@
+This patch is under review:
+https://www.rtems.org/bugzilla/show_bug.cgi?id=1956
+
+The comments in cpukit/score/cpu/lm32/rtems/score/cpu.h state that
+CPU_STACK_ALIGNMENT should either be 0 or >= CPU_ALIGNMENT. The
+latter was 8, the former is 4.
+
+Further investigation revealed that, contrary to what the comment
+says, 0 is not a valid value for CPU_STACK_ALIGNMENT.
+
+This patch sets CPU_ALIGNMENT to 4, since we don't have any machine
+word larger than that. (doubles and long longs are handled by
+software and either extremely slow already or rare.)
+
+The patch also corrects the misleading comment before
+CPU_STACK_ALIGNMENT.
+
+I'm not sure if this fix has any real-life impact on M1 behaviour,
+but I guess it can't hurt.
+
+- Werner
+
+Index: rtems/cpukit/score/cpu/lm32/rtems/score/cpu.h
+===================================================================
+--- rtems.orig/cpukit/score/cpu/lm32/rtems/score/cpu.h	2011-11-12 03:01:35.000000000 -0300
++++ rtems/cpukit/score/cpu/lm32/rtems/score/cpu.h	2011-11-12 03:03:46.000000000 -0300
+@@ -637,7 +637,7 @@
+  *
+  *  XXX document implementation including references if appropriate
+  */
+-#define CPU_ALIGNMENT              8
++#define CPU_ALIGNMENT              4
+ 
+ /**
+  *  This number corresponds to the byte alignment requirement for the
+@@ -687,9 +687,10 @@
+  *  stack.  This alignment requirement may be stricter than that for the
+  *  data types alignment specified by @ref CPU_ALIGNMENT.  If the
+  *  @ref CPU_ALIGNMENT is strict enough for the stack, then this should be
+- *  set to 0.
++ *  set to @ref CPU_ALIGNMENT.
+  *
+- *  @note This must be a power of 2 either 0 or greater than @ref CPU_ALIGNMENT.
++ *  @note This must be a power of 2 either equal to or greater than
++ *  @ref CPU_ALIGNMENT.
+  *
+  *  Port Specific Information:
+  *