Initial allocated page must be read/write/non-cacheable

git-svn-id: svn://svn.code.sf.net/p/nuttx/code/trunk@2909 42af7a65-404d-4744-a932-0658087f49c3

arch/arm/src/arm/pg_macros.h

@@ -93,6 +93,7 @@
 #  define MMU_L2_TEXTFLAGS      (PTE_TYPE_TINY|PTE_EXT_AP_UNO_SRO|PTE_CACHEABLE)
 #  define MMU_L1_DATAFLAGS      (PMD_TYPE_FINE|PMD_BIT4)
 #  define MMU_L2_DATAFLAGS      (PTE_TYPE_TINY|PTE_EXT_AP_UNO_SRW|PTE_CACHEABLE|PTE_BUFFERABLE)
+#  define MMU_L2_ALLOCFLAGS     (PTE_TYPE_TINY|PTE_EXT_AP_UNO_SRW)
 #  define MMU_L1_PGTABFLAGS     (PMD_TYPE_FINE|PMD_BIT4)
 #  define MMU_L2_PGTABFLAGS     (PTE_TYPE_TINY|PTE_EXT_AP_UNO_SRW)
 

arch/arm/src/arm/up_allocpage.c

@@ -133,12 +133,19 @@ static bool g_pgwrap;
  *  available pages are in-use (the typical case), then this function will
  *  select a page in-use, un-map it, and make it available.
  *
- *  NOTE 2: Allocating and filling a page is a two step process.  up_allocpage()
+ *  NOTE 2: If an in-use page is un-mapped, it may be necessary to flush the
+ *  instruction cache in some architectures.
+ *
+ *  NOTE 3: Allocating and filling a page is a two step process.  up_allocpage()
  *  allocates the page, and up_fillpage() fills it with data from some non-
  *  volatile storage device.  This distinction is made because up_allocpage()
  *  can probably be implemented in board-independent logic whereas up_fillpage()
  *  probably must be implemented as board-specific logic.
  *
+ *  NOTE 4: The initial mapping of vpage should be read-able and write-
+ *  able (but not cached).  No special actions will be required of
+ *  up_fillpage() in order to write into this allocated page.
+ *
  * Input Parameters:
  *   tcb - A reference to the task control block of the task that needs to
  *         have a page fill.  Architecture-specific logic can retrieve page
@@ -210,11 +217,12 @@ int up_allocpage(FAR _TCB *tcb, FAR void **vpage)
 
   /* Now setup up the new mapping.  Get a pointer to the L2 entry
    * corresponding to the new mapping.  Then set it map to the newly
-   * allocated page address.
+   * allocated page address.  The inital mapping is read/write but
+   * non-cached (MMU_L2_ALLOCFLAGS)
    */
 
   pte = up_va2pte(vaddr);
-  *pte = (paddr | MMU_L2_TEXTFLAGS);
+  *pte = (paddr | MMU_L2_ALLOCFLAGS);
 
   /* And save the new L1 index */
  

configs/ea3131/src/up_fillpage.c

@@ -77,12 +77,19 @@
  *  This callback is assumed to occur from an interrupt level when the
  *  device driver completes the fill operation.
  *
- *  NOTE: Allocating and filling a page is a two step process.  up_allocpage()
+ *  NOTE 1: Allocating and filling a page is a two step process.  up_allocpage()
  *  allocates the page, and up_fillpage() fills it with data from some non-
  *  volatile storage device.  This distinction is made because up_allocpage()
  *  can probably be implemented in board-independent logic whereas up_fillpage()
  *  probably must be implemented as board-specific logic.
  *
+ *  NOTE 2: The initial mapping of vpage will be read-able, write-able,
+ *  but non-cacheable.  No special actions will be required of
+ *  up_fillpage() in order to write into this allocated page.  If the
+ *  virtual address maps to a text region, however, this function should
+ *  remap the region so that is is read/execute only.  It should be made
+ *  cache-able in any case.
+
  * Input Parameters:
  *   tcb - A reference to the task control block of the task that needs to
  *         have a page fill.  Architecture-specific logic can retrieve page

include/nuttx/page.h

@@ -364,12 +364,19 @@ EXTERN bool up_checkmapping(FAR _TCB *tcb);
  *  available pages are in-use (the typical case), then this function will
  *  select a page in-use, un-map it, and make it available.
  *
- *  NOTE 2: Allocating and filling a page is a two step process.  up_allocpage()
+ *  NOTE 2: If an in-use page is un-mapped, it may be necessary to flush the
+ *  instruction cache in some architectures.
+ *
+ *  NOTE 3: Allocating and filling a page is a two step process.  up_allocpage()
  *  allocates the page, and up_fillpage() fills it with data from some non-
  *  volatile storage device.  This distinction is made because up_allocpage()
  *  can probably be implemented in board-independent logic whereas up_fillpage()
  *  probably must be implemented as board-specific logic.
  *
+ *  NOTE 4: The initial mapping of vpage should be read-able and write-
+ *  able (but not cached).  No special actions will be required of
+ *  up_fillpage() in order to write into this allocated page.
+ *
  * Input Parameters:
  *   tcb - A reference to the task control block of the task that needs to
  *         have a page fill.  Architecture-specific logic can retrieve page
@@ -404,12 +411,19 @@ EXTERN int up_allocpage(FAR _TCB *tcb, FAR void **vpage);
  *  This callback is assumed to occur from an interrupt level when the
  *  device driver completes the fill operation.
  *
- *  NOTE: Allocating and filling a page is a two step process.  up_allocpage()
+ *  NOTE 1: Allocating and filling a page is a two step process.  up_allocpage()
  *  allocates the page, and up_fillpage() fills it with data from some non-
  *  volatile storage device.  This distinction is made because up_allocpage()
  *  can probably be implemented in board-independent logic whereas up_fillpage()
  *  probably must be implemented as board-specific logic.
  *
+ *  NOTE 2: The initial mapping of vpage will be read-able, write-able,
+ *  but non-cacheable.  No special actions will be required of
+ *  up_fillpage() in order to write into this allocated page.  If the
+ *  virtual address maps to a text region, however, this function should
+ *  remap the region so that is is read/execute only.  It should be made
+ *  cache-able in any case.
+ *
  * Input Parameters:
  *   tcb - A reference to the task control block of the task that needs to
  *         have a page fill.  Architecture-specific logic can retrieve page