diff --git a/Documentation/NuttXDemandPaging.html b/Documentation/NuttXDemandPaging.html index d6a6c340c3..cf4bb0ce42 100755 --- a/Documentation/NuttXDemandPaging.html +++ b/Documentation/NuttXDemandPaging.html @@ -30,7 +30,19 @@ - Terminolgy + Introduction + + + +   + + Overview + + + +   + + Terminology @@ -41,54 +53,36 @@ + + + + -
+ NuttX Common Logic Design Description +
  Initialization
- - - - - - + -
  Page Faults
- - - - - - + -
  Fill Initiation
- - - - - - + -
  Fill Complete
- - - - - - + @@ -96,15 +90,72 @@
  Task Resumption
+ + + + + + + + + + + + + + + +
+ Architecture-Specific Support Requirements +
  + Memory Organization +
  + Architecture-Specific Functions +
+ + +
-

Terminolgy

+

Introduction

+

Overview

+ +

+ This document summarizes the design of NuttX on-demand page. + This feature permits embedded MCUs with some limited RAM space to execute large programs some some non-random access media. + This feature was first discussed in this email thread: + http://tech.groups.yahoo.com/group/nuttx/message/213. +

+

+ What kind of platforms can support NuttX on-demang paging? +

    +
  1. + The MCU should have some large, probably low-cost non-volatile storage such as serial FLASH or an SD card. + This storage probably does not support non-random access (otherwise, why not just execute the program directly on the storage media). + SD and serial FLASH are inexpensive and do not require very many pins and SPI support is prevalent in just about all MCUs. + This large serial FLASH would contain a big program. Perhaps a program of several megabytes in size. +
  2. +
  3. + The MCU must have a (relatively) small block of fast SRAM from which it can execute code. + A size of, say 256Kb (or 192Kb as in the ea3131) would be sufficient for many applications. +
  4. +
  5. + The MCU has an MMU (again like the ea3131). +
  6. +
+

+

+ If the platforms meets these requirement, then NuttX can provide on-demand paging: + It can copy .text from the large program in non-volatile media into RAM as needed to execute the huge program from the small RAM. +

+ +

Terminology

g_waitingforfill
@@ -124,11 +175,14 @@
-

Initialization

+

NuttX Common Logic Design Description

+ +

Initialization

+

The following declarations will be added.

@@ -266,13 +300,7 @@

- - - - -
-

Fill Initiation

-
+

Fill Initiation

The page fill worker thread will be awakened on one of two conditions: @@ -298,48 +326,49 @@ That function will perform the following operations:

While the fill is in progress, other tasks may execute. If another page fault occurs during this time, the faulting task will be blocked and its TCB will be added (in priority order) to g_waitingforfill. But no action will be taken until the current page fill completes. - NOTE: The IDLE task must also be fully locked in memory. + NOTE: The IDLE task must also be fully locked in memory. The IDLE task cannot be blocked. It the case where all tasks are blocked waiting for a page fill, the IDLE task must still be available to run.

- The chip-specific functions, up_allocpage(vaddr, &page) and up_fillpage(page, pg_callback) + The chip-specific functions, up_allocpage(tcb, &vpage) and up_fillpage(page, pg_callback) will be prototyped in include/nuttx/arch.h

- - - - -
-

Fill Complete

-
+

Fill Complete

When the chip-specific driver completes the page fill, it will call the pg_callback() that was provided to up_fillpage. pg_callback() will probably be called from driver interrupt-level logic. The driver ill provide the result of the fill as an argument. - NOTE: pg_callback() must also be locked in memory. + NOTE: pg_callback() must also be locked in memory.

When pg_callback() is called, it will perform the following operations: @@ -356,13 +385,7 @@

- - - - -
-

Task Resumption

-
+

Task Resumption

When the page fill worker thread is awakened and g_pendingfill is non-NULL (and other state variables are in concurrence), @@ -412,6 +435,197 @@

+ + + + + +
+

Architecture-Specific Support Requirements

+
+ +

Memory Organization

+ +

+ Chip specific logic will map the virtual and physical address spaces into three general regions: +

    +
  1. + A .text region containing "locked-in-memory" code that is always avaialable and will never cause a page fault. + This locked memory is loaded at boot time and remains resident for all time. + This memory regions must include: +
      +
    • + All logic for all interrupt pathes. + All interrupt logic must be locked in memory because the design present here will not support page faults from interrupt handlers. + This includes the page fault handling logic and pg_miss() that is called from the page fault handler. + It also includes the pg_callback() function that wakes up the page fill worker thread + and whatever chip-specific logic that calls pg_callback(). +
    • +
    • + All logic for the IDLE thread. + The IDLE thread must always be ready to run and cannot be blocked for any reason. +
    • +
    • + All of the page fill worker thread must be locked in memory. + This thread must execute in order to unblock any thread waiting for a fill. + It this thread were to block, there would be no way to complete the fills! +
    +
  2. +
  3. + A .text region containing pages that can be assigned allocated, mapped to various virtual addresses, and filled from some mass storage medium. +
  4. +
  5. + And a fixed RAM space for .bss, .text, and .heap. +
  6. +
+

+

+ This memory organization is illustrated in the following table. + Notice that: +

+

+ +
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
SRAMVirtual Address SpaceNon-Volatile Storage
 DATA 
 Virtual Page n (n > m)Stored Page n
 Virtual Page n-1Stored Page n-1
DATA......
Physical Page m (m < n)......
Physical Page m-1......
.........
Physical Page 1Virtual Page 1Stored Page 1
Locked MemoryLocked MemoryMemory Resident
+ +

+ As an example, suppose that the size of the SRAM is 192Kb (as in the NXP LPC3131). And suppose further that: +

+

+ Then, the size of the locked, memory resident code is 32Kb (32 pages). + The size of the physical page region is 96Kb (96 pages), and the + size of the data region is 64 pages. + And the size of the virtual paged region must then be greater than or equal to (1024-32) or 992 pages (m). +

+ +

Architecture-Specific Functions

+ +

+ Standard functions that should already be provided in the architecture port: +

+ + +

+ New, additional functions that must be implemented just for on-demand paging support: +

+ + - \ No newline at end of file +