diff options
author | patacongo <patacongo@42af7a65-404d-4744-a932-0658087f49c3> | 2010-09-01 23:52:38 +0000 |
---|---|---|
committer | patacongo <patacongo@42af7a65-404d-4744-a932-0658087f49c3> | 2010-09-01 23:52:38 +0000 |
commit | abc3a0deb2e7bade521b14a4586a8d0249d85185 (patch) | |
tree | 886f43114cdefea0c9561d8414c553c508005e68 | |
parent | 8d91b3fa9d70252dbec1341af543e93ec7c32285 (diff) | |
download | nuttx-abc3a0deb2e7bade521b14a4586a8d0249d85185.tar.gz nuttx-abc3a0deb2e7bade521b14a4586a8d0249d85185.tar.bz2 nuttx-abc3a0deb2e7bade521b14a4586a8d0249d85185.zip |
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
-rw-r--r-- | nuttx/arch/arm/src/arm/pg_macros.h | 1 | ||||
-rwxr-xr-x | nuttx/arch/arm/src/arm/up_allocpage.c | 14 | ||||
-rwxr-xr-x | nuttx/configs/ea3131/src/up_fillpage.c | 9 | ||||
-rwxr-xr-x | nuttx/include/nuttx/page.h | 18 |
4 files changed, 36 insertions, 6 deletions
diff --git a/nuttx/arch/arm/src/arm/pg_macros.h b/nuttx/arch/arm/src/arm/pg_macros.h index a4d4dd522..d30adeb10 100644 --- a/nuttx/arch/arm/src/arm/pg_macros.h +++ b/nuttx/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) diff --git a/nuttx/arch/arm/src/arm/up_allocpage.c b/nuttx/arch/arm/src/arm/up_allocpage.c index 15309f61b..1db32592c 100755 --- a/nuttx/arch/arm/src/arm/up_allocpage.c +++ b/nuttx/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 */ diff --git a/nuttx/configs/ea3131/src/up_fillpage.c b/nuttx/configs/ea3131/src/up_fillpage.c index b9a97f684..2c238c9a1 100755 --- a/nuttx/configs/ea3131/src/up_fillpage.c +++ b/nuttx/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 diff --git a/nuttx/include/nuttx/page.h b/nuttx/include/nuttx/page.h index 9ca88a050..b34094462 100755 --- a/nuttx/include/nuttx/page.h +++ b/nuttx/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 |