diff options
author | patacongo <patacongo@42af7a65-404d-4744-a932-0658087f49c3> | 2010-09-01 17:41:12 +0000 |
---|---|---|
committer | patacongo <patacongo@42af7a65-404d-4744-a932-0658087f49c3> | 2010-09-01 17:41:12 +0000 |
commit | 6814cba4709369f643ed97cad2c09793f84a9482 (patch) | |
tree | 1ae7ebffda4d7bbca3202ab0a43064c81197629c /nuttx/configs/ea3131 | |
parent | 3aa9357408b29188003811fbfde3217f8fbd2079 (diff) | |
download | px4-nuttx-6814cba4709369f643ed97cad2c09793f84a9482.tar.gz px4-nuttx-6814cba4709369f643ed97cad2c09793f84a9482.tar.bz2 px4-nuttx-6814cba4709369f643ed97cad2c09793f84a9482.zip |
Misc. paging fixes
git-svn-id: svn://svn.code.sf.net/p/nuttx/code/trunk@2906 42af7a65-404d-4744-a932-0658087f49c3
Diffstat (limited to 'nuttx/configs/ea3131')
-rwxr-xr-x | nuttx/configs/ea3131/README.txt | 112 |
1 files changed, 112 insertions, 0 deletions
diff --git a/nuttx/configs/ea3131/README.txt b/nuttx/configs/ea3131/README.txt index 0cb159617..f81270aae 100755 --- a/nuttx/configs/ea3131/README.txt +++ b/nuttx/configs/ea3131/README.txt @@ -15,6 +15,7 @@ Contents o Image Format o Image Download to ISRAM o Using OpenOCD and GDB + o On-Demand Paging o ARM/EA3131-specific Configuration Options o Configurations @@ -272,6 +273,117 @@ Using OpenOCD and GDB (gdb) symbol-file nuttx (gdb) load nuttx +On-Demand Paging +^^^^^^^^^^^^^^^^ + + There is a configuration that was used to verify the On-Demand Paging + feature for the ARM926 (see http://nuttx.sourceforge.net/NuttXDemandPaging.html). + That configuration is contained in the pgnsh sub-directory. The pgnsh configuration + is only a test configuration, and lacks some logic to provide the full On-Demand + Paging solution (see below). + + Page Table Layout: + ------------------ + + The ARM926 MMU uses a page table in memory. The page table is divided + into (1) a level 1 (L1) page table that maps 1Mb memory regions to level 2 + page tables (except in the case of 1Mb sections, of course), and (2) a level + 2 (L2) page table that maps the 1Mb memory regions into individual 64Kb, 4kb, + or 1kb pages. The pgnsh configuration uses 1Kb pages: it positions 48x1Kb + pages at beginning of SRAM (the "locked" memory region), 16x1Kb pages at + the end of SRAM for the L1 page table, and 44x1Kb pages just before the + L1 page table. That leaves 96x1Kb virtual pages in the middle of SRAM for + the paged memory region; up to 384x1kb of physical pages may be paged into + this region. Physical memory map: + + 11028000 "locked" text region 48x1Kb + 11034000 "paged" text region 96x1Kb + 1104c000 "data" region 32x1Kb + 11054000 L1 page table 16x1Kb + -------- --------------------- ------ + 11058000 192x1Kb + + The virtual memory map allows more space for the paged region: + + 11028000 "locked" text region 48x1Kb + 11034000 "paged" text region 384x1Kb + 11094000 "data" region 32x1Kb + 1109c000 L1 page table 16x1Kb + -------- --------------------- ------ + 110a0000 480x1Kb + + The L1 contains a single 1Mb entry to span the entire LPC3131 SRAM memory + region. The virtual address for this region is 0x11028000. The offset into + the L1 page table is given by: + + offset = ((0x11028000 >> 20) << 2) = 0x00000440 + + The value at that offset into the L1 page table contains the address of the + L2 page table (0x11056000) plus some extra bits to specify that that entry + is valid and and points to a 1Kb L1 page table: + + 11054440 11056013 + + Why is the address 11056000 used for the address of the L2 page table? Isn't + that inside of the L1 page table? Yes, this was done to use the preceious + SRAM memory more conservatively. If you look at the LPC313x virtual memory + map, you can see that no virtual addresses above 0x60100000 are used. That + corresponds to L1 page table offset 0x0001800 (physical address 0x11055800). + The rest of the L1 page table is unused and so we reuse it to hold the L2 page + table (or course, this could cause some really weird addressing L1 mapping + issues if bad virtual addresses were used in that region -- oh well). The + address 0x11056000 is then the first properly aligned memory that can be used + in that L2 page table area. + + Only only L2 page table will be used to span the LPC3131 SRAM virtual text + address region (480x1Kb). That one entry maps the virtual address range of + 0x11000000 through 0x110ffc00. Each entry maps a 1Kb page of physical memory: + + PAGE VIRTUAL ADDR L2 OFFSET + --------- ------------ --------- + Page 0 0x11000000 0x00000000 + Page 1 0x11000400 0x00000004 + Page 2 0x11000800 0x00000008 + ... + Page 1023 0x110ffc00 0x00000ffc + + The "locked" text region begins at an offset of 0x00028000 into that region. + The 48 page table entries needed to make this region begin at: + + offset = ((0x00028000 >> 10) << 2) = 0x00000280 + + Each entry contains the address of a physical page in the "locked" text region + (plus some extra bits to identify domains, page sizes, access privileges, etc.): + + 0x11000280 0x1102800b + 0x11000284 0x1102840b + 0x11000288 0x1102880b + ... + + The locked region is initially unmapped. But the data region and page table + regions must be mapped in a similar manner. + + data offset = ((0x00094000 >> 10) << 2) = 0x00000940 + L1 offset = ((0x0009c000 >> 10) << 2) = 0x000009c0 + + Build Sequence: + --------------- + + This example uses a two-pass build. The top-level Makefile recognizes the + configuration option CONFIG_BUILD_2PASS and will execute the Makefile in + configs/ea3131/locked/Makefile to build the first pass object, locked.r. + This first pass object contains all of the code that must be in the locked + text region. The Makefile in arch/arm/src/Makefile then includes this 1st + pass in build, positioning it as controlled by configs/ea3131/pgnsh/ld.script. + + Finishing the Example: + ---------------------- + + This example is incomplete in that it does not have any media to reload the + page text region from: The file configs/ea3131/src/up_fillpage.c is only + a stub. That logic to actually reload the page from some storage medium + would have to be implemented in order to complete this example. + ARM/EA3131-specific Configuration Options ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ CONFIG_ARCH - Identifies the arch/ subdirectory. This should |