SAMA5: Fix logic for running with data in SDRAM

4 files changed, 27 insertions, 58 deletions

diff --git a/nuttx/ChangeLog b/nuttx/ChangeLog
index 412346d1f..ced68606b 100644
--- a/nuttx/ChangeLog
+++ b/nuttx/ChangeLog
@@ -6524,8 +6524,12 @@
 	* arch/arm/include/efm32, arch/arm/src/efm32, and configs/efm32-dk360:
 	  Removed all EFM32 support.  Not yet readyto be fielded (2014-1-27).
 	* arch/arm/src/armv7-a/arm_head.S, sama5/sam_boot.c, and several other
-	  files:  Not supports execution from NOR FLASH with .data and .bss in
+	  files:  Now supports execution from NOR FLASH with .data and .bss in
 	  SDRAM.  This was not possible prior to this because .bss and .data
 	  were initialized before SDRAM was configured.  This logic is still
 	  kind buggy. (2014-1-28).
-
+	* arch/arm/src/armv7-a/arm_head.S and arm_pghead.S:  Back off to a
+	  somewhat less efficient loop for initializing .data and .bss.  The
+	  original, efficient logic violated the ARM C ABI.  It was okay when
+	  called from boot logic, but not when called from C logic.  This fixes
+	  bugginess reported on 2014-1-28. (2014-1-29).
diff --git a/nuttx/arch/arm/src/armv7-a/arm_head.S b/nuttx/arch/arm/src/armv7-a/arm_head.S
index e54770417..a2a590658 100644
--- a/nuttx/arch/arm/src/armv7-a/arm_head.S
+++ b/nuttx/arch/arm/src/armv7-a/arm_head.S
@@ -653,18 +653,15 @@ __start:
 
 arm_data_initialize:
 
-	/* zero BSS and set up the stack pointer */
+	/* Zero BSS */
 
 	adr		r0, .Linitparms
 	ldmia	r0, {r0, r1}
 
-	/* Clear the frame pointer and .bss */
-
-	mov     fp, #0
-
+	mov     r2, #0
 1:
 	cmp		r0, r1				/* Clear up to _bss_end_ */
-	strcc	fp, [r0],#4
+	strcc	r2, [r0], #4
 	bcc		1b
 
 #ifdef CONFIG_BOOT_RUNFROMFLASH
@@ -681,8 +678,8 @@ arm_data_initialize:
 	ldmia	r3, {r0, r1, r2}
 
 2:
-	ldmia	r0!, {r3 - r10}
-	stmia	r1!, {r3 - r10}
+	ldr		r3, [r0], #4
+	str		r3, [r1], #4
 	cmp		r1, r2
 	blt		2b
 #endif
diff --git a/nuttx/arch/arm/src/armv7-a/arm_pghead.S b/nuttx/arch/arm/src/armv7-a/arm_pghead.S
index 97bae3d3a..c191c24ef 100644
--- a/nuttx/arch/arm/src/armv7-a/arm_pghead.S
+++ b/nuttx/arch/arm/src/armv7-a/arm_pghead.S
@@ -705,18 +705,15 @@ __start:
 
 arm_data_initialize:
 
-	/* zero BSS and set up the stack pointer */
+	/* Zero BSS */
 
 	adr		r0, .Linitparms
 	ldmia	r0, {r0, r1}
 
-	/* Clear the frame pointer and .bss */
-
-	mov     fp, #0
-
+	mov     r2, #0
 1:
 	cmp		r0, r1				/* Clear up to _bss_end_ */
-	strcc	fp, [r0],#4
+	strcc	r2, [r0],#4
 	bcc		1b
 
 #ifdef CONFIG_BOOT_RUNFROMFLASH
@@ -733,8 +730,8 @@ arm_data_initialize:
 	ldmia	r3, {r0, r1, r2}
 
 2:
-	ldmia	r0!, {r3 - r10}
-	stmia	r1!, {r3 - r10}
+	ldr		r3, [r0], #4
+	str		r3, [r1], #4
 	cmp		r1, r2
 	blt		2b
 #endif
diff --git a/nuttx/configs/sama5d3x-ek/README.txt b/nuttx/configs/sama5d3x-ek/README.txt
index 6fb4b6e25..7e4b039a5 100644
--- a/nuttx/configs/sama5d3x-ek/README.txt
+++ b/nuttx/configs/sama5d3x-ek/README.txt
@@ -3116,60 +3116,31 @@ To-Do List
    endpoint support in the EHCI driver is untested (but works in similar
    EHCI drivers).
 
-4) The logic in "SDRAM Data Configuration" has generated some crashes.
-   Perhaps there are some issues with SDRAM when uses as the primary
-   heap?
+4) HSCMI TX DMA support is currently commented out.
 
-   UPDATE:  If I turn memory management debug on, the crash does not
-   occur:
-
-     CONFIG_DEBUG=y
-     # CONFIG_DEBUG_VERBOSE is not set
-     CONFIG_DEBUG_MM=y
-     # ...(No other debug output enabled)...
-     CONFIG_DEBUG_FULLOPT=y
-
-   Results in:
-
-     mm_initialize: Heap: start=20001228 size=268430808
-     mm_addregion: Region 1: base=20001228 size=268430800
-
-     NuttShell (NSH)
-     nsh> free
-                  total       used       free    largest
-     Mem:     268430800       6864  268423936  268423936
-     nsh>
-
-   Disabling debug and forcing either of the two debug outputs above also
-   eliminates the problem.  Replacing the debug output with a delay does
-   not solve the problem.  This needs some further investigation and a
-   little TLC.
-
-5) HSCMI TX DMA support is currently commented out.
-
-6) I believe that there is an issue when the internal AT25 FLASH is
+5) I believe that there is an issue when the internal AT25 FLASH is
    formatted by NuttX.  That format works fine with Linux, but does not
    appear to work with Windows.  Reformatting on Windows can resolve this.
    NOTE:  This is not a SAMA5Dx issue.
 
-7) CAN testing has not yet been performed due to issues with cabling.  I
+6) CAN testing has not yet been performed due to issues with cabling.  I
    just do not have a good test bed (or sufficient CAN knowledge) for
    good CAN testing.
 
-8) The NxWM example does not work well.  This example was designed to work
+7) The NxWM example does not work well.  This example was designed to work
    with much smaller displays and does not look good or work well with the
    SAMA5Dx-EKs 800x480 display.  See above for details.
 
-9) There are lots of LCDC hardware features that are not tested with NuttX.
+8) There are lots of LCDC hardware features that are not tested with NuttX.
    The simple NuttX graphics system does not have support for all of the
    layers and other features of the LCDC.
 
-10) I have a Camera, but there is still no ISI driver.  I am not sure what to
-    do with the camera.  NuttX needs something like V4L to provide the
-    definition for what a camera driver is supposed to do.
+9) I have a Camera, but there is still no ISI driver.  I am not sure what to
+   do with the camera.  NuttX needs something like V4L to provide the
+   definition for what a camera driver is supposed to do.
 
-    I will probably develop a test harness for ISI, but it is of only
-    minimal value with no OS infrastructure to deal with images and video.
+   I will probably develop a test harness for ISI, but it is of only
+   minimal value with no OS infrastructure to deal with images and video.
 
-11) GMAC has only been tested on a 10/100Base-T network.  I don't have a
+10) GMAC has only been tested on a 10/100Base-T network.  I don't have a
     1000Base-T network to support additional testing.