Synopsis.
Setup the loop device at <dev-path> to access the file at <file-path> as a block device.
- In the following example a 256Kb file is created (dd) and losetup is
+ In the following example a 256K file is created (dd) and losetup is
used to make the file accessible as a block device.
A FAT file system is created (mkfatfs) and mounted (mount).
Files can then be managed on the loop-mounted file.
@@ -3148,7 +3148,7 @@ endef
- The make file then defines the application name (hello), the task priority (default), and the stack size that will be allocated in the task runs (2Kb).
+ The make file then defines the application name (hello), the task priority (default), and the stack size that will be allocated in the task runs (2K).
APPNAME = hello
@@ -3160,7 +3160,7 @@ STACKSIZE = 2048
And finally, the Makefile invokes the REGISTER macro to added the hello_main() named application.
Then, when the system build completes, the hello command can be executed from the NSH command line.
- When the hello command is executed, it will start the task with entry point hello_main() with the default priority and with a stack size of 2Kb.
+ When the hello command is executed, it will start the task with entry point hello_main() with the default priority and with a stack size of 2K.
.context:
diff --git a/nuttx/Documentation/NuttX.html b/nuttx/Documentation/NuttX.html
index ed994d69b..b7026f896 100644
--- a/nuttx/Documentation/NuttX.html
+++ b/nuttx/Documentation/NuttX.html
@@ -858,9 +858,9 @@
Using a variety of technologies, NuttX can scale from the very tiny to
the moderate-size system. I have executed NuttX with some simple applications
- in as little as 32Kb total memory (code and data).
- On the other hand, typical, richly featured NuttX builds require more like 64Kb
- (and if all of the features are used, this can push 100Kb).
+ in as little as 32K total memory (code and data).
+ On the other hand, typical, richly featured NuttX builds require more like 64K
+ (and if all of the features are used, this can push 100K).
@@ -2028,8 +2028,8 @@
Micropendous 3 AT9USB64x and AT9USB6128x.
This port of NuttX to the Opendous Micropendous 3 board. The Micropendous3 is
may be populated with an AT90USB646, 647, 1286, or 1287. I have only the AT90USB647
- version for testing. This version have very limited memory resources: 64Kb of
- FLASH and 4Kb of SRAM.
+ version for testing. This version have very limited memory resources: 64K of
+ FLASH and 4K of SRAM.
- - 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. - -
- - 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 NXP LPC3131) would be sufficient for many applications. - -
- - The MCU has an MMU (again like the NXP LPC3131). - -
g_waitingforfill
- - An OS list that is used to hold the TCBs of tasks that are waiting for a page fill. -
g_pftcb
- - A variable that holds a reference to the TCB of the thread that is currently be re-filled. -
g_pgworker
- - The process ID of of the thread that will perform the page fills. -
pg_callback()
- - The callback function that is invoked from a driver when the fill is complete. -
pg_miss()
- - The function that is called from architecture-specific code to handle a page fault. -
TCB
- - Task Control Block -
-
-
g_waitingforfill. - A doubly linked list that will be used to implement a prioritized list of the TCBs of tasks that are waiting for a page fill. -
- -
-
g_pgworker. - The process ID of of the thread that will perform the page fills -
- -
- The
g_waitingforfillqueue will be initialized. -
- -
- The special, page fill worker thread, will be started.
- The
pidof the page will worker thread will be saved ing_pgworker. - Note that we need a special worker thread to perform fills; - we cannot use the "generic" worker thread facility because we cannot be - assured that all actions called by that worker thread will always be resident in memory. -
- - - Sanity checking. - This function will ASSERT if the currently executing task is the page fill worker thread. - The page fill worker thread is how the the page fault is resolved and all logic associated with the page fill worker - must be "locked" and always present in memory. - -
-
- Block the currently executing task.
- This function will call
up_block_task()to block the task at the head of the ready-to-run list. - This should cause an interrupt level context switch to the next highest priority task. - The blocked task will be marked with stateTSTATE_WAIT_PAGEFILLand will be retained in theg_waitingforfillprioritized task list. -
- -
- Boost the page fill worker thread priority.
- Check the priority of the task at the head of the
g_waitingforfilllist. - If the priority of that task is higher than the current priority of the page fill worker thread, then boost the priority of the page fill worker thread to that priority. - Thus, the page fill worker thread will always run at the priority of the highest priority task that is waiting for a fill. -
- - - Signal the page fill worker thread. - Is there a page already being filled? - If not then signal the page fill worker thread to start working on the queued page fill requests. - -
- - It is assumed that this function is called from the level of an exception handler and that all interrupts are disabled. - -
-
- The
pg_miss()must be "locked" in memory. - Callingpg_miss()cannot cause a nested page fault. -
- - - It is assumed that currently executing task (the one at the head of the ready-to-run list) is the one that cause the fault. - This will always be true unless the page fault occurred in an interrupt handler. - Interrupt handling logic must always be available and "locked" into memory so that page faults never come from interrupt handling. - -
- - The architecture-specific page fault exception handling has already verified that the exception did not occur from interrupt/exception handling logic. - -
- - As mentioned above, the task causing the page fault must not be the page fill worker thread because that is the only way to complete the page fill. - -
-
- When signaled by
pg_miss(), the page fill worker thread will be awakenend (see above), -
- -
- From
pg_callback()after completing last fill (whenCONFIG_PAGING_BLOCKINGFILLis defined... see below), or -
- - - A configurable timeout expires with no activity. - This timeout can be used to detect failure conditions such things as fills that never complete. - -
-
- Call the architecture-specific function
up_checkmapping()to see if the page fill - still needs to be performed. - In certain conditions, the page fault may occur on several threads and be queued multiple times. - In this corner case, the blocked task will simply be restarted (see the logic below for the - case of normal completion of the fill operation). -
- -
- Call
up_allocpage(tcb, &vpage). - This architecture-specific function will set aside page in memory and map to virtual address (vpage). - If all available pages are in-use (the typical case), - this function will select a page in-use, un-map it, and make it available. -
- -
- Call the architecture-specific function
up_fillpage(). - Two versions of the up_fillpage function are supported -- a blocking and a non-blocking version based upon the configuratin settingCONFIG_PAGING_BLOCKINGFILL. --
-
-
- If
CONFIG_PAGING_BLOCKINGFILLis defined, then up_fillpage is blocking call. - In this case,up_fillpage()will accept only (1) a reference to the TCB that requires the fill. - Architecture-specific context information within the TCB will be sufficient to perform the fill. - And (2) the (virtual) address of the allocated page to be filled. - The resulting status of the fill will be provided by return value fromup_fillpage(). -
- -
- If
CONFIG_PAGING_BLOCKINGFILLis defined, then up_fillpage is non-blocking call. - In this caseup_fillpage()will accept an additional argument: - The page fill worker thread will provide a callback function,pg_callback. - This function is non-blocking, it will start an asynchronous page fill. - After calling the non-blockingup_fillpage(), the page fill worker thread will wait to be signaled for the next event -- the fill completion event. - The callback function will be called when the page fill is finished (or an error occurs). - The resulting status of the fill will be providing as an argument to the callback functions. - This callback will probably occur from interrupt level. -
- -
- If
-
- Verify that
g_pftcbis non-NULL. -
- -
- Find the higher priority between the task waiting for the fill to complete in
g_pftcband the task waiting at the head of theg_waitingforfilllist. - That will be the priority of he highest priority task waiting for a fill. -
- - - If this higher priority is higher than current page fill worker thread, then boost worker thread's priority to that level. - Thus, the page fill worker thread will always run at the priority of the highest priority task that is waiting for a fill. - -
- - Save the result of the fill operation. - -
- - Signal the page fill worker thread. - -
-
- Verify consistency of state information and
g_pftcb. -
- - - Verify that the page fill completed successfully, and if so, - -
-
- Call
up_unblocktask(g_pftcb)to make the task that just received the fill ready-to-run. -
- -
- Check if the
g_waitingforfilllist is empty. - If not: --
-
-
- Remove the highest priority task waiting for a page fill from
g_waitingforfill, -
- -
- Save the task's TCB in
g_pftcb, -
- -
- If the priority of the thread in
g_pftcb, is higher in priority than the default priority of the page fill worker thread, then set the priority of the page fill worker thread to that priority. -
- -
- Call
pg_startfill()which will start the next fill (as described above). -
-
- -
- Remove the highest priority task waiting for a page fill from
-
- Otherwise,
-
-
-
-
- Set
g_pftcbto NULL. -
- - - Restore the default priority of the page fill worker thread. - -
- - Wait for the next fill related event (a new page fault). - -
- -
- Set
-
- 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 thepg_callback()function that wakes up the page fill worker thread - and whatever architecture-specific logic that callspg_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! -
- -
- 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
- - A .text region containing pages that can be assigned allocated, mapped to various virtual addresses, and filled from some mass storage medium. - -
- - And a fixed RAM space for .bss, .text, and .heap. - -
- - There is a one-to-one relationship between pages in the virtual address space and between pages of .text in the non-volatile mass storage device. - -
- - There are, however, far fewer physical pages available than virtual pages. - Only a subset of physical pages will be mapped to virtual pages at any given time. - This mapping will be performed on-demand as needed for program execution. -
- - The size of the locked, memory resident .text area is 32Kb, and - -
- - The size of the DATA area is 64Kb. - -
- - The size of one, managed page is 1Kb. - -
- - The size of the whole .text image on the non-volatile, mass storage device is 1024Kb. - -
- - In the first phase, create a partially linked objected containing all interrupt/exception handling logic, the page fill worker thread plus all parts of the IDLE thread (which must always be available for execution). - -
-
- All of the
.textand.rodatasections of this partial link should be collected into a single section. -
- - - The second link would link the partially linked object along with the remaining object to produce the final binary. - The linker script should position the "special" section so that it lies in a reserved, "non-swappable" region. -
-
-
void up_block_task(FAR _TCB *tcb, tstate_t task_state);-
- - - The currently executing task at the head of the ready to run list must be stopped. - Save its context and move it to the inactive list specified by task_state. - This function is called by the on-demand paging logic in order to block the task that requires the - page fill, and to - -
-
-
void up_unblock_task(FAR _TCB *tcb);-
- - - A task is currently in an inactive task list but has been prepped to execute. - Move the TCB to the ready-to-run list, restore its context, and start execution. - This function will be called - -
-
-
int up_checkmapping(FAR _TCB *tcb);-
- -
- The function
up_checkmapping()returns an indication if the page fill still needs to performed or not. - In certain conditions, the page fault may occur on several threads and be queued multiple times. - This function will prevent the same page from be filled multiple times. -
- -
-
int up_allocpage(FAR _TCB *tcb, FAR void *vpage);-
- -
- This architecture-specific function will set aside page in memory and map to its correct virtual address.
- Architecture-specific context information saved within the TCB will provide the function with the information needed to identify the virtual miss address.
- This function will return the allocated physical page address in
vpage. - The size of the underlying physical page is determined by the configuration settingCONFIG_PAGING_PAGESIZE. - NOTE: This function must always return a page allocation. - If all available pages are in-use (the typical case), then this function will select a page in-use, un-map it, and make it available. -
- int up_fillpage(FAR _TCB *tcb, FAR const void *vpage, void (*pg_callback)(FAR _TCB *tcb, int result));-
- The actual filling of the page with data from the non-volatile, must be performed by a separate call to the architecture-specific function, - + 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. + +
- + The MCU must have a (relatively) small block of fast SRAM from which it can execute code. + A size of, say 256K (or 192K as in the NXP LPC3131) would be sufficient for many applications. + +
- + The MCU has an MMU (again like the NXP LPC3131). + +
g_waitingforfill
+ - An OS list that is used to hold the TCBs of tasks that are waiting for a page fill. +
g_pftcb
+ - A variable that holds a reference to the TCB of the thread that is currently be re-filled. +
g_pgworker
+ - The process ID of of the thread that will perform the page fills. +
pg_callback()
+ - The callback function that is invoked from a driver when the fill is complete. +
pg_miss()
+ - The function that is called from architecture-specific code to handle a page fault. +
TCB
+ - Task Control Block +
-
+
g_waitingforfill. + A doubly linked list that will be used to implement a prioritized list of the TCBs of tasks that are waiting for a page fill. +
+ -
+
g_pgworker. + The process ID of of the thread that will perform the page fills +
+ -
+ The
g_waitingforfillqueue will be initialized. +
+ -
+ The special, page fill worker thread, will be started.
+ The
pidof the page will worker thread will be saved ing_pgworker. + Note that we need a special worker thread to perform fills; + we cannot use the "generic" worker thread facility because we cannot be + assured that all actions called by that worker thread will always be resident in memory. +
+ - + Sanity checking. + This function will ASSERT if the currently executing task is the page fill worker thread. + The page fill worker thread is how the the page fault is resolved and all logic associated with the page fill worker + must be "locked" and always present in memory. + +
-
+ Block the currently executing task.
+ This function will call
up_block_task()to block the task at the head of the ready-to-run list. + This should cause an interrupt level context switch to the next highest priority task. + The blocked task will be marked with stateTSTATE_WAIT_PAGEFILLand will be retained in theg_waitingforfillprioritized task list. +
+ -
+ Boost the page fill worker thread priority.
+ Check the priority of the task at the head of the
g_waitingforfilllist. + If the priority of that task is higher than the current priority of the page fill worker thread, then boost the priority of the page fill worker thread to that priority. + Thus, the page fill worker thread will always run at the priority of the highest priority task that is waiting for a fill. +
+ - + Signal the page fill worker thread. + Is there a page already being filled? + If not then signal the page fill worker thread to start working on the queued page fill requests. + +
- + It is assumed that this function is called from the level of an exception handler and that all interrupts are disabled. + +
-
+ The
pg_miss()must be "locked" in memory. + Callingpg_miss()cannot cause a nested page fault. +
+ - + It is assumed that currently executing task (the one at the head of the ready-to-run list) is the one that cause the fault. + This will always be true unless the page fault occurred in an interrupt handler. + Interrupt handling logic must always be available and "locked" into memory so that page faults never come from interrupt handling. + +
- + The architecture-specific page fault exception handling has already verified that the exception did not occur from interrupt/exception handling logic. + +
- + As mentioned above, the task causing the page fault must not be the page fill worker thread because that is the only way to complete the page fill. + +
-
+ When signaled by
pg_miss(), the page fill worker thread will be awakenend (see above), +
+ -
+ From
pg_callback()after completing last fill (whenCONFIG_PAGING_BLOCKINGFILLis defined... see below), or +
+ - + A configurable timeout expires with no activity. + This timeout can be used to detect failure conditions such things as fills that never complete. + +
-
+ Call the architecture-specific function
up_checkmapping()to see if the page fill + still needs to be performed. + In certain conditions, the page fault may occur on several threads and be queued multiple times. + In this corner case, the blocked task will simply be restarted (see the logic below for the + case of normal completion of the fill operation). +
+ -
+ Call
up_allocpage(tcb, &vpage). + This architecture-specific function will set aside page in memory and map to virtual address (vpage). + If all available pages are in-use (the typical case), + this function will select a page in-use, un-map it, and make it available. +
+ -
+ Call the architecture-specific function
up_fillpage(). + Two versions of the up_fillpage function are supported -- a blocking and a non-blocking version based upon the configuratin settingCONFIG_PAGING_BLOCKINGFILL. +-
+
-
+ If
CONFIG_PAGING_BLOCKINGFILLis defined, then up_fillpage is blocking call. + In this case,up_fillpage()will accept only (1) a reference to the TCB that requires the fill. + Architecture-specific context information within the TCB will be sufficient to perform the fill. + And (2) the (virtual) address of the allocated page to be filled. + The resulting status of the fill will be provided by return value fromup_fillpage(). +
+ -
+ If
CONFIG_PAGING_BLOCKINGFILLis defined, then up_fillpage is non-blocking call. + In this caseup_fillpage()will accept an additional argument: + The page fill worker thread will provide a callback function,pg_callback. + This function is non-blocking, it will start an asynchronous page fill. + After calling the non-blockingup_fillpage(), the page fill worker thread will wait to be signaled for the next event -- the fill completion event. + The callback function will be called when the page fill is finished (or an error occurs). + The resulting status of the fill will be providing as an argument to the callback functions. + This callback will probably occur from interrupt level. +
+ -
+ If
-
+ Verify that
g_pftcbis non-NULL. +
+ -
+ Find the higher priority between the task waiting for the fill to complete in
g_pftcband the task waiting at the head of theg_waitingforfilllist. + That will be the priority of he highest priority task waiting for a fill. +
+ - + If this higher priority is higher than current page fill worker thread, then boost worker thread's priority to that level. + Thus, the page fill worker thread will always run at the priority of the highest priority task that is waiting for a fill. + +
- + Save the result of the fill operation. + +
- + Signal the page fill worker thread. + +
-
+ Verify consistency of state information and
g_pftcb. +
+ - + Verify that the page fill completed successfully, and if so, + +
-
+ Call
up_unblocktask(g_pftcb)to make the task that just received the fill ready-to-run. +
+ -
+ Check if the
g_waitingforfilllist is empty. + If not: +-
+
-
+ Remove the highest priority task waiting for a page fill from
g_waitingforfill, +
+ -
+ Save the task's TCB in
g_pftcb, +
+ -
+ If the priority of the thread in
g_pftcb, is higher in priority than the default priority of the page fill worker thread, then set the priority of the page fill worker thread to that priority. +
+ -
+ Call
pg_startfill()which will start the next fill (as described above). +
+
+ -
+ Remove the highest priority task waiting for a page fill from
-
+ Otherwise,
+
-
+
-
+ Set
g_pftcbto NULL. +
+ - + Restore the default priority of the page fill worker thread. + +
- + Wait for the next fill related event (a new page fault). + +
+ -
+ Set
-
+ 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 paths.
+ 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 thepg_callback()function that wakes up the page fill worker thread + and whatever architecture-specific logic that callspg_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! +
+ -
+ All logic for all interrupt paths.
+ 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
- + A .text region containing pages that can be assigned allocated, mapped to various virtual addresses, and filled from some mass storage medium. + +
- + And a fixed RAM space for .bss, .text, and .heap. + +
- + There is a one-to-one relationship between pages in the virtual address space and between pages of .text in the non-volatile mass storage device. + +
- + There are, however, far fewer physical pages available than virtual pages. + Only a subset of physical pages will be mapped to virtual pages at any given time. + This mapping will be performed on-demand as needed for program execution. +
- + The size of the locked, memory resident .text area is 32K, and + +
- + The size of the DATA area is 64K. + +
- + The size of one, managed page is 1K. + +
- + The size of the whole .text image on the non-volatile, mass storage device is 1024K. + +
- + In the first phase, create a partially linked objected containing all interrupt/exception handling logic, the page fill worker thread plus all parts of the IDLE thread (which must always be available for execution). + +
-
+ All of the
.textand.rodatasections of this partial link should be collected into a single section. +
+ - + The second link would link the partially linked object along with the remaining object to produce the final binary. + The linker script should position the "special" section so that it lies in a reserved, "non-swappable" region. +
-
+
void up_block_task(FAR _TCB *tcb, tstate_t task_state);+
+ - + The currently executing task at the head of the ready to run list must be stopped. + Save its context and move it to the inactive list specified by task_state. + This function is called by the on-demand paging logic in order to block the task that requires the + page fill, and to + +
-
+
void up_unblock_task(FAR _TCB *tcb);+
+ - + A task is currently in an inactive task list but has been prepped to execute. + Move the TCB to the ready-to-run list, restore its context, and start execution. + This function will be called + +
-
+
int up_checkmapping(FAR _TCB *tcb);+
+ -
+ The function
up_checkmapping()returns an indication if the page fill still needs to performed or not. + In certain conditions, the page fault may occur on several threads and be queued multiple times. + This function will prevent the same page from be filled multiple times. +
+ -
+
int up_allocpage(FAR _TCB *tcb, FAR void *vpage);+
+ -
+ This architecture-specific function will set aside page in memory and map to its correct virtual address.
+ Architecture-specific context information saved within the TCB will provide the function with the information needed to identify the virtual miss address.
+ This function will return the allocated physical page address in
vpage. + The size of the underlying physical page is determined by the configuration settingCONFIG_PAGING_PAGESIZE. + NOTE: This function must always return a page allocation. + If all available pages are in-use (the typical case), then this function will select a page in-use, un-map it, and make it available. +
+ int up_fillpage(FAR _TCB *tcb, FAR const void *vpage, void (*pg_callback)(FAR _TCB *tcb, int result));+
+ The actual filling of the page with data from the non-volatile, must be performed by a separate call to the architecture-specific function,
@@ -2085,7 +2085,7 @@
Most NuttX test applications are console-oriented with lots of strings used for printf and debug output. - These strings are all stored in SRAM now due to these data accessing issues and even the smallest console-oriented applications can quickly fill a 4-8Kb memory. + These strings are all stored in SRAM now due to these data accessing issues and even the smallest console-oriented applications can quickly fill a 4-8K memory. So, in order for the AVR port to be useful, one of two things would need to be done:
-
@@ -2917,7 +2917,7 @@ if [ -x "$WINELOADER" ]; then exec "$WINELOADER" "$appname" "$@"; fi
87C52 A reduced functionality OS test for the 8052 target requires only - about 18-19Kb: + about 18-19K:
Stack starts at: 0x21 (sp set to 0x20) with 223 bytes available. diff --git a/nuttx/Documentation/NuttXDemandPaging.html b/nuttx/Documentation/NuttXDemandPaging.html index 3246e070d..c238161a8 100644 --- a/nuttx/Documentation/NuttXDemandPaging.html +++ b/nuttx/Documentation/NuttXDemandPaging.html @@ -1,675 +1,675 @@ - - -On-Demand Paging - - -
-
- On-Demand Paging->>> Under Construction <<<-Last Updated: August 12, 2010 - |
-
- -
- Table of Contents- |
-
-
|
-||||||||||||
-
|
-||||||||||||
-
|
-
- Introduction- |
-
Overview
- -- This document summarizes the design of NuttX on-demand paging. - This feature permits embedded MCUs with some limited RAM space to execute large programs from 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? -
-
-
- If the platform 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 a huge program from the small RAM. -
- -Terminology
- --
-
- NuttX Common Logic Design Description- |
-
Initialization
- -- The following declarations will be added. -
-
-
- During OS initialization in sched/os_start.c, the following steps
- will be performed:
-
-
-
- Declarations for g_waitingforfill, g_pgworker, and other
- internal, private definitions will be provided in sched/pg_internal.h.
- All public definitions that should be used by the architecture-specific code will be available
- in include/nuttx/page.h.
- Most architecture-specific functions are declared in include/nuttx/arch.h,
- but for the case of this paging logic, those architecture specific functions are instead declared in include/nuttx/page.h.
-
Page Faults
- -
- Page fault exception handling.
- Page fault handling is performed by the function pg_miss().
- This function is called from architecture-specific memory segmentation
- fault handling logic. This function will perform the following
- operations:
-
-
-
- When signaled from pg_miss(), the page fill worker thread will be awakenend and will initiate the fill operation.
-
- Input Parameters. - None -- The head of the ready-to-run list is assumed to be that task that caused the exception. - The current task context should already be saved in the TCB of that task. - No additional inputs are required. -
-- Assumptions. -
-
-
Fill Initiation
- -- The page fill worker thread will be awakened on one of three conditions: -
-
-
- The page fill worker thread will maintain a static variable called _TCB *g_pftcb.
- If no fill is in progress, g_pftcb will be NULL.
- Otherwise, it will point to the TCB of the task which is receiving the fill that is in progess.
-
-
- NOTE:
- I think that this is the only state in which a TCB does not reside in some list.
- Here is it in limbo, outside of the normally queuing while the page file is in progress.
- While here, it will be marked with TSTATE_TASK_INVALID.
-
- When awakened from pg_miss(), no fill will be in progress and g_pftcb will be NULL.
- In this case, the page fill worker thread will call pg_startfill().
- That function will perform the following operations:
-
-
-
- In any case, while the fill is in progress, other tasks may execute.
- If another page fault occurs during this time, the faulting task will be blocked, its TCB will be added (in priority order) to g_waitingforfill, and the priority of the page worker task may be boosted.
- But no action will be taken until the current page fill completes.
- 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 architecture-specific functions, up_checkmapping(), up_allocpage(tcb, &vpage) and up_fillpage(page, pg_callback)
- will be prototyped in include/nuttx/arch.h
-
Fill Complete
- -
- For the blocking up_fillpage(), the result of the fill will be returned directly from the call to up_fillpage.
-
- For the non-blocking up_fillpage(), the architecture-specific driver call the pg_callback() that was provided to up_fillpage() when the fill completes.
- In this case, the pg_callback() will probably be called from driver interrupt-level logic.
- The driver will provide the result of the fill as an argument to the callback function.
- NOTE: pg_callback() must also be locked in memory.
-
- In this non-blocking case, the callback pg_callback() will perform the following operations when it is notified that the fill has completed:
-
-
-
Task Resumption
- -
- For the non-blocking up_fillpage(), the page fill worker thread will detect that the page fill is complete when it is awakened with g_pftcb non-NULL and fill completion status from pg_callback.
- In the non-blocking case, the page fill worker thread will know that the page fill is complete when up_fillpage() returns.
-
- In this either, the page fill worker thread will: -
-
-
- Architecture-Specific Support Requirements- |
-
Memory Organization
- -- Memory Regions. - Chip specific logic will map the virtual and physical address spaces into three general regions: -
-
-
- This memory organization is illustrated in the following table. - Notice that: -
-
-
| SRAM | -Virtual Address Space | -Non-Volatile Storage | -
|---|---|---|
| - | DATA | -- |
| - | Virtual Page n (n > m) | -Stored Page n | -
| - | Virtual Page n-1 | -Stored Page n-1 | -
| DATA | -... | -... | -
| Physical Page m (m < n) | -... | -... | -
| Physical Page m-1 | -... | -... | -
| ... | -... | -... | -
| Physical Page 1 | -Virtual Page 1 | -Stored Page 1 | -
| Locked Memory | -Locked Memory | -Memory Resident | -
- Example. - 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 (m=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 (n). -
- -- Building the Locked, In-Memory Image. - One way to accomplish this would be a two phase link: -
-
-
Architecture-Specific Functions
- -
- Most standard, architecture-specific functions are declared in include/nuttx/arch.h.
- However, for the case of this paging logic, the architecture specific functions are declared in include/nuttx/page.h.
- Standard, architecture-specific functions that should already be provided in the architecture port.
- The following are used by the common paging logic:
-
-
-
- New, additional functions that must be implemented just for on-demand paging support: -
- --
-
up_fillpage().
- This will start asynchronous page fill.
- The common paging logic will provide a callback function, pg_callback, that will be called when the page fill is finished (or an error occurs).
- This callback is assumed to occur from an interrupt level when the device driver completes the fill operation.
-
-+
+ On-Demand Paging+>>> Under Construction <<<+Last Updated: August 12, 2010 + |
+
+ +
+ Table of Contents+ |
+
+
|
+||||||||||||
+
|
+||||||||||||
+
|
+
+ Introduction+ |
+
Overview
+ ++ This document summarizes the design of NuttX on-demand paging. + This feature permits embedded MCUs with some limited RAM space to execute large programs from 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? +
-
+
+ If the platform 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 a huge program from the small RAM. +
+ +Terminology
+ +-
+
+ NuttX Common Logic Design Description+ |
+
Initialization
+ ++ The following declarations will be added. +
-
+
+ During OS initialization in sched/os_start.c, the following steps
+ will be performed:
+
-
+
+ Declarations for g_waitingforfill, g_pgworker, and other
+ internal, private definitions will be provided in sched/pg_internal.h.
+ All public definitions that should be used by the architecture-specific code will be available
+ in include/nuttx/page.h.
+ Most architecture-specific functions are declared in include/nuttx/arch.h,
+ but for the case of this paging logic, those architecture specific functions are instead declared in include/nuttx/page.h.
+
Page Faults
+ +
+ Page fault exception handling.
+ Page fault handling is performed by the function pg_miss().
+ This function is called from architecture-specific memory segmentation
+ fault handling logic. This function will perform the following
+ operations:
+
-
+
+ When signaled from pg_miss(), the page fill worker thread will be awakenend and will initiate the fill operation.
+
+ Input Parameters. + None -- The head of the ready-to-run list is assumed to be that task that caused the exception. + The current task context should already be saved in the TCB of that task. + No additional inputs are required. +
++ Assumptions. +
-
+
Fill Initiation
+ ++ The page fill worker thread will be awakened on one of three conditions: +
-
+
+ The page fill worker thread will maintain a static variable called _TCB *g_pftcb.
+ If no fill is in progress, g_pftcb will be NULL.
+ Otherwise, it will point to the TCB of the task which is receiving the fill that is in progess.
+
-
+ NOTE:
+ I think that this is the only state in which a TCB does not reside in some list.
+ Here is it in limbo, outside of the normally queuing while the page file is in progress.
+ While here, it will be marked with TSTATE_TASK_INVALID.
+
+ When awakened from pg_miss(), no fill will be in progress and g_pftcb will be NULL.
+ In this case, the page fill worker thread will call pg_startfill().
+ That function will perform the following operations:
+
-
+
+ In any case, while the fill is in progress, other tasks may execute.
+ If another page fault occurs during this time, the faulting task will be blocked, its TCB will be added (in priority order) to g_waitingforfill, and the priority of the page worker task may be boosted.
+ But no action will be taken until the current page fill completes.
+ 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 architecture-specific functions, up_checkmapping(), up_allocpage(tcb, &vpage) and up_fillpage(page, pg_callback)
+ will be prototyped in include/nuttx/arch.h
+
Fill Complete
+ +
+ For the blocking up_fillpage(), the result of the fill will be returned directly from the call to up_fillpage.
+
+ For the non-blocking up_fillpage(), the architecture-specific driver call the pg_callback() that was provided to up_fillpage() when the fill completes.
+ In this case, the pg_callback() will probably be called from driver interrupt-level logic.
+ The driver will provide the result of the fill as an argument to the callback function.
+ NOTE: pg_callback() must also be locked in memory.
+
+ In this non-blocking case, the callback pg_callback() will perform the following operations when it is notified that the fill has completed:
+
-
+
Task Resumption
+ +
+ For the non-blocking up_fillpage(), the page fill worker thread will detect that the page fill is complete when it is awakened with g_pftcb non-NULL and fill completion status from pg_callback.
+ In the non-blocking case, the page fill worker thread will know that the page fill is complete when up_fillpage() returns.
+
+ In this either, the page fill worker thread will: +
-
+
+ Architecture-Specific Support Requirements+ |
+
Memory Organization
+ ++ Memory Regions. + Chip specific logic will map the virtual and physical address spaces into three general regions: +
-
+
+ This memory organization is illustrated in the following table. + Notice that: +
-
+
| SRAM | +Virtual Address Space | +Non-Volatile Storage | +
|---|---|---|
| + | DATA | ++ |
| + | Virtual Page n (n > m) | +Stored Page n | +
| + | Virtual Page n-1 | +Stored Page n-1 | +
| DATA | +... | +... | +
| Physical Page m (m < n) | +... | +... | +
| Physical Page m-1 | +... | +... | +
| ... | +... | +... | +
| Physical Page 1 | +Virtual Page 1 | +Stored Page 1 | +
| Locked Memory | +Locked Memory | +Memory Resident | +
+ Example. + As an example, suppose that the size of the SRAM is 192K (as in the NXP LPC3131). And suppose further that: +
-
+
+ Then, the size of the locked, memory resident code is 32K (m=32 pages). + The size of the physical page region is 96K (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 (n). +
+ ++ Building the Locked, In-Memory Image. + One way to accomplish this would be a two phase link: +
-
+
Architecture-Specific Functions
+ +
+ Most standard, architecture-specific functions are declared in include/nuttx/arch.h.
+ However, for the case of this paging logic, the architecture specific functions are declared in include/nuttx/page.h.
+ Standard, architecture-specific functions that should already be provided in the architecture port.
+ The following are used by the common paging logic:
+
-
+
+ New, additional functions that must be implemented just for on-demand paging support: +
+ +-
+
up_fillpage().
+ This will start asynchronous page fill.
+ The common paging logic will provide a callback function, pg_callback, that will be called when the page fill is finished (or an error occurs).
+ This callback is assumed to occur from an interrupt level when the device driver completes the fill operation.
+
+CONFIG_P14201_FRAMEBUFFER:
If defined, accesses will be performed using an in-memory copy of the OLEDs GDDRAM.
- This cost of this buffer is 128 * 96 / 2 = 6Kb.
+ This cost of this buffer is 128 * 96 / 2 = 6K.
If this is defined, then the driver will be fully functional.
If not, then it will have the following limitations:
-
diff --git a/nuttx/Documentation/NxWidgets.html b/nuttx/Documentation/NxWidgets.html
index cef99d494..1678d9ebe 100755
--- a/nuttx/Documentation/NxWidgets.html
+++ b/nuttx/Documentation/NxWidgets.html
@@ -33,7 +33,7 @@
- Small Footprint. NXWidgets is tailored for use MCUs in embedded applications. It is ideally suited for mid- and upper-range of most MCU families. - A complete NXWidgets is possible in as little as 40Kb of FLASH and maybe 4Kb of SRAM. + A complete NXWidgets is possible in as little as 40K of FLASH and maybe 4K of SRAM.
- Output Devices.
NXWidgets will work on the high-end frame buffer devices as well as on LCDs connected via serial or parallel ports to a small MCU.
diff --git a/nuttx/ReleaseNotes b/nuttx/ReleaseNotes
index 8c6ae0ccb..26af0e38d 100644
--- a/nuttx/ReleaseNotes
+++ b/nuttx/ReleaseNotes
@@ -1668,7 +1668,7 @@ Important bugfixes included:
And feature enhancements:
* The LPC176x Ethernet driver was using all of AHB SRAM Bank0 for
- Ethernet packet buffers (16Kb). An option was added to limit
+ Ethernet packet buffers (16K). An option was added to limit
the amount of SRAM used for packet buffering and to re-use any
extra Bank0 memory for heap.
@@ -2022,7 +2022,7 @@ and is available for download from the SourceForge website. The
* A PCI-based E1000 Ethernet driver (contributed by Yu Qiang)
* New C library functions: inet_addr() (contributed by Yu Qiang),
strndup(), asprintf()
- * Reduced memory allocation overhead for MCUs with small heaps (<64Kb).
+ * Reduced memory allocation overhead for MCUs with small heaps (<64K).
* fdopen() now works with socket descriptors allowing standard
buffered C functions to be used for network communications.
* The NSH ifconfig command can now be used to set or change the
@@ -2062,7 +2062,7 @@ they are, ordered from the least to the most complete:
This port of NuttX to the Amber Web Server from SoC Robotics
(http://www.soc-robotics.com/index.htm). Is only partially in
place. The Amber Web Server is based on an Atmel ATMega128
- (128Kb FLASH but only 4Kb of SRAM).
+ (128K FLASH but only 4K of SRAM).
STATUS: Work on this port has stalled due to toolchain issues. It
is complete, but untested.
@@ -2073,7 +2073,7 @@ they are, ordered from the least to the most complete:
Micropendous3 may be populated with an AT90USB646, 647, 1286,
or 1287. See http://code.google.com/p/opendous/. I have only
the AT90USB647 version for testing. This version has very
- limited memory resources: 64Kb of FLASH and 4Kb of SRAM.
+ limited memory resources: 64K of FLASH and 4K of SRAM.
STATUS: The basic port was released in NuttX-6.5. This basic
port consists only of a "Hello, World!!" example that demonstrates
@@ -2085,8 +2085,8 @@ they are, ordered from the least to the most complete:
This is a port of NuttX to the PJRC Teensy++ 2.0 board. This
board was developed by PJRC (http://pjrc.com/teensy/). The
- Teensy++ 2.0 is based on an Atmel AT90USB1286 MCU with 128Kb
- of FLASH and 8Kb of SRAM; a little more room to move than the
+ Teensy++ 2.0 is based on an Atmel AT90USB1286 MCU with 128K
+ of FLASH and 8K of SRAM; a little more room to move than the
AT90USB647.
STATUS: The basic port was released in NuttX-6.5. This basic
@@ -2109,7 +2109,7 @@ integrated into the normal, general purpose OS.
Most NuttX test applications are console-oriented with lots of
strings used for printf and debug output. These strings are all
stored in SRAM now due to these data accessing issues and even the
-smallest console-oriented applications can quickly fill a 4-8Kb
+smallest console-oriented applications can quickly fill a 4-8K
memory. So, in order for the AVR port to be useful, one of two
things would need to be done:
diff --git a/nuttx/TODO b/nuttx/TODO
index 7ffcb9ca8..f9fc558ea 100644
--- a/nuttx/TODO
+++ b/nuttx/TODO
@@ -1819,7 +1819,7 @@ o mc68hc1x (arch/hc)
Description: There is no script for building in banked mode (more correctly, there
is a script, but logic inside the script has not yet been implemented).
It would be necessary to implement banked mode to able to access more
- the 48Kb of FLASH.
+ the 48K of FLASH.
Status: Open.
Priority: Medium/Low
diff --git a/nuttx/arch/arm/src/lpc43xx/lpc43_usb0dev.c b/nuttx/arch/arm/src/lpc43xx/lpc43_usb0dev.c
index 40233ec0f..2ce19a325 100644
--- a/nuttx/arch/arm/src/lpc43xx/lpc43_usb0dev.c
+++ b/nuttx/arch/arm/src/lpc43xx/lpc43_usb0dev.c
@@ -69,9 +69,7 @@
#include "up_arch.h"
#include "up_internal.h"
-#include "lpc43_usbotg.h"
-#include "lpc43_evntrtr.h"
-#include "lpc43_syscreg.h"
+#include "lpc43_usb0dev.h"
/*******************************************************************************
* Definitions
diff --git a/nuttx/arch/arm/src/lpc43xx/lpc43_usb0dev.h b/nuttx/arch/arm/src/lpc43xx/lpc43_usb0dev.h
new file mode 100644
index 000000000..97076cd80
--- /dev/null
+++ b/nuttx/arch/arm/src/lpc43xx/lpc43_usb0dev.h
@@ -0,0 +1,98 @@
+/************************************************************************************
+ * arch/arm/src/lpc43xx/lpc43_usbdev.h
+ *
+ * Copyright (C) 2009, 2011 Gregory Nutt. All rights reserved.
+ * Author: Gregory Nutt
+#include +#include + +#include "chip.h" +#include "chip/lpc43_usb0.h" + +/************************************************************************************ + * Public Functions + ************************************************************************************/ + +#ifndef __ASSEMBLY__ + +#undef EXTERN +#if defined(__cplusplus) +#define EXTERN extern "C" +extern "C" { +#else +#define EXTERN extern +#endif + +/************************************************************************************ + * Name: lpc43_usbpullup + * + * Description: + * If USB is supported and the board supports a pullup via GPIO (for USB software + * connect and disconnect), then the board software must provide lpc43_pullup. + * See include/nuttx/usb/usbdev.h for additional description of this method. + * Alternatively, if no pull-up GPIO the following EXTERN can be redefined to be + * NULL. + * + ************************************************************************************/ + +EXTERN int lpc43_usbpullup(FAR struct usbdev_s *dev, bool enable); + +/************************************************************************************ + * Name: lpc43_usbsuspend + * + * Description: + * Board logic must provide the lpc43_usbsuspend logic if the USBDEV driver is + * used. This function is called whenever the USB enters or leaves suspend mode. + * This is an opportunity for the board logic to shutdown clocks, power, etc. + * while the USB is suspended. + * + ************************************************************************************/ + +EXTERN void lpc43_usbsuspend(FAR struct usbdev_s *dev, bool resume); + +#undef EXTERN +#if defined(__cplusplus) +} +#endif + +#endif /* __ASSEMBLY__ */ +#endif /* __ARCH_ARM_SRC_LPC43XX_LPC32_USB0DEV_H */ +