Difference between revisions of "Memory"
m (Generalized internal links) |
(Reorganized headings) |
||
Line 1: | Line 1: | ||
Memory on MIPS-based processors is broken into several segments, consuming the entire 32-address space. These segments are arranged as follows: | Memory on MIPS-based processors is broken into several segments, consuming the entire 32-address space. These segments are arranged as follows: | ||
− | * [[# | + | * [[#User Segment|User Segment]] (USEG), 2 GB mapped and cached, addresses <tt>0x0000 0000</tt> through <tt>0x7FFF FFFF</tt> |
− | * [[# | + | * [[#Kernel Segment 0|Kernel Segment 0]] (KSEG0), 512 MB unmapped and cached, addresses <tt>0x8000 0000</tt> through <tt>0x9FFF FFFF</tt> |
− | * [[# | + | * [[#Kernel Segment 1|Kernel Segment 1]] (KSEG1), 512 MB unmapped and uncached, addresses <tt>0xA000 0000</tt> through <tt>0xBFFF FFFF</tt> |
− | * [[# | + | * [[#Kernel Segment 2|Kernel Segment 2]] (KSEG2), 1 GB mapped and cached, addresses <tt>0xC000 0000</tt> through <tt>0xFFFF FFFF</tt> |
Note that the [[WRT54GL]] only has 16 MB of main memory, so a 1-1 mapping is not be available above <tt>0x..FF FFFF</tt>. | Note that the [[WRT54GL]] only has 16 MB of main memory, so a 1-1 mapping is not be available above <tt>0x..FF FFFF</tt>. | ||
− | + | == User Segment == | |
− | |||
− | |||
− | |||
User memory, also known as KUSEG, ranges from <tt>0x0000 0000</tt> to <tt>0x7FFF FFFF</tt> and can only be accessed when the processor is running in user-mode or (more dangerously) if the error level bit in the status register of co-processor 0 is set. While executing in kernel-mode or supervisor-mode memory references to this segment will result in TLB exceptions. | User memory, also known as KUSEG, ranges from <tt>0x0000 0000</tt> to <tt>0x7FFF FFFF</tt> and can only be accessed when the processor is running in user-mode or (more dangerously) if the error level bit in the status register of co-processor 0 is set. While executing in kernel-mode or supervisor-mode memory references to this segment will result in TLB exceptions. | ||
Since the WRT54GL routers only have 16 megabytes of RAM, it is currently assumed that <tt>0x0000 0000</tt>--<tt>0x00FF FFFF</tt> has a 1-1 mapping with physical memory. | Since the WRT54GL routers only have 16 megabytes of RAM, it is currently assumed that <tt>0x0000 0000</tt>--<tt>0x00FF FFFF</tt> has a 1-1 mapping with physical memory. | ||
− | + | As discussed above the user segment of memory occupies addresses from <tt>0x0000 0000</tt> to <tt>0x7FFF FFFF</tt>. Since physical memory is shared between each of the segments it should be noted that the first few pages of the user segment will actually be kernel code and should not be writable to user-level processes. Also the NULL pointer (<tt>0x0000 0000</tt>) could be considered a valid pointer in user-mode and this should be avoided so NULL pointer references are not ignored. | |
− | + | ||
− | + | [[Embedded XINU]] does not currently have support for user-mode operations, so not much is known about the user segment. | |
− | + | ||
− | + | == Kernel Segments == | |
− | + | Kernel memory occupies the processor memory range from 0x8000 0000 to 0xFFFF FFFF and is sub-divided into 3 smaller regions. These regions are: | |
− | + | * KSEG0 -- unmapped, cached memory (512 megabytes, starting at 0x8000 0000), | |
+ | * KSEG1 -- unmapped, uncached memory (512 megabytes, starting at 0xA000 0000), | ||
+ | * KSEG2 -- mapped memory (1 gigabyte, starting at 0xC000 0000). | ||
− | + | It is important to notice that all direct memory accesses (DMAs) occur in the unmapped, uncached region of memory since devices often produce volatile data which would be dangerous to cache. | |
− | |||
− | + | Since physical memory is shared between user and kernel processes the mapping for KUSEG is simply 1-1, KSEG0 is address - 0x8000 0000, KSEG1 is address - 0xA000 0000, and finally KSEG2 is address - 0xC000 0000. | |
− | == Kernel Segment 0 == | + | === Kernel Segment 0 === |
This segment exists from memory address <tt>0x8000 0000</tt> to <tt>0x9FFF FFFF</tt> and is cached but remains unmapped (beyond the simple address - <tt>0x8000 0000</tt> mapping). | This segment exists from memory address <tt>0x8000 0000</tt> to <tt>0x9FFF FFFF</tt> and is cached but remains unmapped (beyond the simple address - <tt>0x8000 0000</tt> mapping). | ||
Line 40: | Line 38: | ||
Kernel memory allocation will take memory addresses from the heap initialized in this segment. | Kernel memory allocation will take memory addresses from the heap initialized in this segment. | ||
− | == Kernel Segment 1 == | + | === Kernel Segment 1 === |
Beginning at <tt>0xA000 0000</tt> and ending at <tt>0xBFFF FFFF</tt>, kernel segment 1 is both unmapped and uncached memory. This means that any memory references will leave the processor and travel to the memory bus to get the most up-to-date data available. While this may be a slow process, this section of memory is important to direct memory access (DMA) devices, which may have volatile data existing in the memory system. This can be used to access kernel memory from addresses <tt>0xA000 0000</tt> to <tt>0xA0FF FFFF</tt> but more importantly can be used to access I/O mapped devices on the system. | Beginning at <tt>0xA000 0000</tt> and ending at <tt>0xBFFF FFFF</tt>, kernel segment 1 is both unmapped and uncached memory. This means that any memory references will leave the processor and travel to the memory bus to get the most up-to-date data available. While this may be a slow process, this section of memory is important to direct memory access (DMA) devices, which may have volatile data existing in the memory system. This can be used to access kernel memory from addresses <tt>0xA000 0000</tt> to <tt>0xA0FF FFFF</tt> but more importantly can be used to access I/O mapped devices on the system. | ||
Line 49: | Line 47: | ||
After these devices is [[Flash driver|Flash]] memory which begins at <tt>0xBC00 0000</tt> and is 4 megabytes in size (lasting until <tt>0xBC3F FFFF</tt>). | After these devices is [[Flash driver|Flash]] memory which begins at <tt>0xBC00 0000</tt> and is 4 megabytes in size (lasting until <tt>0xBC3F FFFF</tt>). | ||
− | === Flash Memory | + | === Kernel Segment 2 === |
+ | The last segment of MIPS memory is located at <tt>0xC000 0000</tt> and ends at <tt>0xFFFF FFFF</tt>, giving the kernel one gigabyte of fully mapped memory. Similar to the user segment, the Embedded XINU team has not looked extensively into the usefulness of this segment. | ||
+ | |||
+ | == Flash Memory == | ||
[[Image:Flash_memory.png|thumb|150px|right|Quick reference guide to Flash memory on XINU.]] | [[Image:Flash_memory.png|thumb|150px|right|Quick reference guide to Flash memory on XINU.]] | ||
Line 63: | Line 64: | ||
* <tt>0xBC06 0000</tt>: Beginning of XINU file system | * <tt>0xBC06 0000</tt>: Beginning of XINU file system | ||
* <tt>0xBC3F 8000</tt>: NVRAM variables are stored here, prefix with a padded length and checksum among other data for a 20 byte header. Each variable is stored as a name=value pair (as ASCII data) and separated by a single null character. | * <tt>0xBC3F 8000</tt>: NVRAM variables are stored here, prefix with a padded length and checksum among other data for a 20 byte header. Each variable is stored as a name=value pair (as ASCII data) and separated by a single null character. | ||
− | |||
− | |||
− | |||
== References == | == References == | ||
Sweetman, Dominic. ''See MIPS Run''. San Francisco: Morgan Kaufmann Publishers, 2007. | Sweetman, Dominic. ''See MIPS Run''. San Francisco: Morgan Kaufmann Publishers, 2007. |
Revision as of 00:07, 29 July 2009
Memory on MIPS-based processors is broken into several segments, consuming the entire 32-address space. These segments are arranged as follows:
- User Segment (USEG), 2 GB mapped and cached, addresses 0x0000 0000 through 0x7FFF FFFF
- Kernel Segment 0 (KSEG0), 512 MB unmapped and cached, addresses 0x8000 0000 through 0x9FFF FFFF
- Kernel Segment 1 (KSEG1), 512 MB unmapped and uncached, addresses 0xA000 0000 through 0xBFFF FFFF
- Kernel Segment 2 (KSEG2), 1 GB mapped and cached, addresses 0xC000 0000 through 0xFFFF FFFF
Note that the WRT54GL only has 16 MB of main memory, so a 1-1 mapping is not be available above 0x..FF FFFF.
Contents
User Segment
User memory, also known as KUSEG, ranges from 0x0000 0000 to 0x7FFF FFFF and can only be accessed when the processor is running in user-mode or (more dangerously) if the error level bit in the status register of co-processor 0 is set. While executing in kernel-mode or supervisor-mode memory references to this segment will result in TLB exceptions.
Since the WRT54GL routers only have 16 megabytes of RAM, it is currently assumed that 0x0000 0000--0x00FF FFFF has a 1-1 mapping with physical memory.
As discussed above the user segment of memory occupies addresses from 0x0000 0000 to 0x7FFF FFFF. Since physical memory is shared between each of the segments it should be noted that the first few pages of the user segment will actually be kernel code and should not be writable to user-level processes. Also the NULL pointer (0x0000 0000) could be considered a valid pointer in user-mode and this should be avoided so NULL pointer references are not ignored.
Embedded XINU does not currently have support for user-mode operations, so not much is known about the user segment.
Kernel Segments
Kernel memory occupies the processor memory range from 0x8000 0000 to 0xFFFF FFFF and is sub-divided into 3 smaller regions. These regions are:
- KSEG0 -- unmapped, cached memory (512 megabytes, starting at 0x8000 0000),
- KSEG1 -- unmapped, uncached memory (512 megabytes, starting at 0xA000 0000),
- KSEG2 -- mapped memory (1 gigabyte, starting at 0xC000 0000).
It is important to notice that all direct memory accesses (DMAs) occur in the unmapped, uncached region of memory since devices often produce volatile data which would be dangerous to cache.
Since physical memory is shared between user and kernel processes the mapping for KUSEG is simply 1-1, KSEG0 is address - 0x8000 0000, KSEG1 is address - 0xA000 0000, and finally KSEG2 is address - 0xC000 0000.
Kernel Segment 0
This segment exists from memory address 0x8000 0000 to 0x9FFF FFFF and is cached but remains unmapped (beyond the simple address - 0x8000 0000 mapping).
The first 0x1000 bytes of this segment are reserved system space and contains small amounts of code for the interrupt handler. When an interrupt or exception occurs, the MIPS processor will jump to code located at 0x8000 0180, expecting to find handler code at that location. For safety reasons that code can only consume 0x20 bytes of memory (enough to jump to a safer, more robust handler). Embedded XINU takes advantage of the space immediately after the end of interrupt handling code by loading entry vectors for the various interrupts and exceptions for speedy lookup.
After the reserved system space it is safe to load generic code, XINU code is loaded to 0x8000 1000 and begins execution at the same offset. XINU code begins with the text segment, followed by the data and BSS segments. After the compiled image is loaded into RAM, XINU allocates a specific amount of memory for the kernel stack immediately after the BSS segment. Once the kernel stack has been setup, XINU initializes the heap beginning directly above the kernel stack and continuing until the end of physical memory (0x80FF FFFF).
Kernel memory allocation will take memory addresses from the heap initialized in this segment.
Kernel Segment 1
Beginning at 0xA000 0000 and ending at 0xBFFF FFFF, kernel segment 1 is both unmapped and uncached memory. This means that any memory references will leave the processor and travel to the memory bus to get the most up-to-date data available. While this may be a slow process, this section of memory is important to direct memory access (DMA) devices, which may have volatile data existing in the memory system. This can be used to access kernel memory from addresses 0xA000 0000 to 0xA0FF FFFF but more importantly can be used to access I/O mapped devices on the system.
These devices appear to begin at 0xB800 0000 with the Broadcom I/O controller on IRQ 3 which holds the GPIO registers from 0xB800 0060 to 0xB800 006F and the two UART ports from 0xB800 0300 to <0xB800 0307/tt> and from 0xB800 0400 to 0xB800 0407.
From there, devices are seperated by 0x1000 bytes beginning with the Broadcom Ethernet 47xx (possibly 4401) device at 0xB800 1000 on IRQ 4. The MIPS 32 CPU on IRQ 5 is located at 0xB800 2000, a Broadcom USB controller on IRQ 6 is located at 0xB800 3000, a DD SDRAM Controller on IRQ 3 is found at 0xB800 4000, the Broadcom Wireless LAN controller on IRQ 2 is at 0xB800 5000, and finally the Broadcom 47xx Robo Switch core on IRQ 3 responds to addresses beginning with 0xB800 6000.
After these devices is Flash memory which begins at 0xBC00 0000 and is 4 megabytes in size (lasting until 0xBC3F FFFF).
Kernel Segment 2
The last segment of MIPS memory is located at 0xC000 0000 and ends at 0xFFFF FFFF, giving the kernel one gigabyte of fully mapped memory. Similar to the user segment, the Embedded XINU team has not looked extensively into the usefulness of this segment.
Flash Memory
Unlike other devices on the system Flash memory is fully mapped, meaning it is possible to access every location of the four megabyte range by simply dereferencing a pointer between 0xBC00 0000 and 0xBC3F FFFF. Within Flash memory there are a number of notable addresses:
- 0xBC00 1000: Generic backup NVRAM variables (if proper variables become corrupt, these are the values that will replace them).
- 0xBC00 1E00: "True" MAC address of device, this is the mac address CFE will use during the boot process. Once the system is booted, the MAC address is not necessarily the same as the value stored here. The value is stored in ASCII as 6 colon separated octets for a total of 17 bytes.
- 0xBC00 1F00: CFE Boot Version variable ("v3.7")
- 0xBC00 2000: CFE code begins
- 0xBC03 F400: Unique device ID, this is loaded into NVRAM variables as eou_device_id
- 0xBC03 F408: Private key for device, also loaded into NVRAM variables as eou_private_key
- 0xBC03 F508: Public key for device, also loaded into NVRAM variables as eou_public_key
- 0xBC04 0000: XINU code, gzipped raw binary prefixed with a TRX header containing the length and a checksum among other data.
- 0xBC06 0000: Beginning of XINU file system
- 0xBC3F 8000: NVRAM variables are stored here, prefix with a padded length and checksum among other data for a 20 byte header. Each variable is stored as a name=value pair (as ASCII data) and separated by a single null character.
References
Sweetman, Dominic. See MIPS Run. San Francisco: Morgan Kaufmann Publishers, 2007.