Flat RTP Virtual Memory for 32-Bit VxWorks

32-bit VxWorks optionally can be configured with flat RTP virtual memory. With this configuration each VxWorks RTP has its own region of virtual memory—RTPs do not overlap in virtual memory. Flat RTP virtual memory provides the following advantages:

■ Speed—context switching is fast.

Figure 2-3 Virtual Memory Layout With Default RTP Overlapped Virtual Memory

Shared Data 1

Heap

Shared Data 1

RTP A RTP B RTP C

Code Heap Heap

Code Code

Kernel Code Kernel Heap I/O Region 1 I/O Region 3

I/O Region 2

Reserved

NOTE: While using the default for RTP overlapped virtual memory is convenient, Wind River recommends taking the additional steps required for using RTP overlapped virtual memory with absolutely-linked executables. For information about the advantages, see 2.5.1 About Overlapped RTP VM for Absolutely-Linked Executables, p.19.

■ Ease of debugging—the addresses for each process are unique.

■ A flexible programming model that provides the same process-model regardless of MMU support. VxWorks’ application memory model allows for running the same applications with and without an MMU. Hard real-time determinism can be facilitated by using the same programming model, and by disabling the MMU.

Systems can be developed and debugged on targets with an MMU, and then shipped on hardware that does not have one, or has one that is not enabled for deployment. The advantages of being able to do so include facilitating debugging in development, lower cost of shipped units, as well as footprint and performance advantages of targets without an MMU, or with one that is not enabled. (For information in this regard, see Using RTPs Without MMU Support, p.33.)

With flat RTP virtual memory, however, executable files must be relocated, which means that their loading time is slower than when RTP overlapped virtual memory is used with absolutely-linked executables.

In addition, flat RTP virtual memory does not allow for selection of the specific virtual memory area into which the RTP application's text, data, and bss segments are installed. Instead a best-fit algorithm automatically selects the most

appropriate area of free virtual memory, based on the memory's current usage, where those segments are to be loaded.

System Memory Map with RTPs Running

A VxWorks system configured for RTPs may have one or more applications executing as RTPs at run-time. It may also have shared libraries and shared data regions instantiated. The kernel, each of the RTPs, shared libraries, and shared data regions occupy a discrete space in virtual memory.

The virtual space assigned to a RTP is not necessarily composed of one large contiguous block of virtual memory. In some cases it will be composed of several smaller blocks of virtual space which are discontinuous from each other.

Figure 2-4 illustrates the memory map of a system with the kernel areas (RAM and I/O), two different RTPs (RTP A and RTP B), as well as one shared library, and one shared data region.

2 Real-Time Processes: RTPs 2.7 Other RTP Virtual Memory Options for 32-Bit VxWorks

Each RTP has its own virtual memory context, defined by its MMU translation table used to map virtual and physical memory, and other information about each page of memory. This memory context describes the virtual space that all of the tasks in a the RTP can access. In other words, it defines the memory view of an RTP.

The kernel space is mapped with supervisor access privilege in the memory context of each RTP (but not with user mode privilege). Therefore tasks executing in an RTP can access kernel memory space only in system calls, during which the execution is switched to supervisor mode.

A shared library or shared data region is mapped into the virtual context of an RTP only when the RTP’s application code opens or creates it, and it effectively disappears from the RTP’s memory view when the application closes or deletes the shared library or shared data region.

Figure 2-4 Fig 5-3: Memory Map of a System With Two RTPs

Kernel Code

+ Kernel Heap

+

Kernel Task Stacks +

Kernel Object Modules RTP A Code RTP B Heap RTP B Task Stacks

RTP A Heap Shared Library

RTP B Code RTP A Tasks Stacks Shared Data Region

I/O Region 2 I/O Region 1

Kernel Memory Space RTP A Memory Space

RTP B Memory Space Shared Library and Shared Data Memory Space

Figure 2-5 illustrates the different memory views of a system with two RTPs (RTP A and RTP B), a shared library that both RTP A and RTP B opened, as well as a shared data region that both a kernel application and RTP B opened.

The first memory view corresponds to the memory space accessible by kernel tasks. The second and third memory views correspond to the memory space accessible by tasks executing in RTP A, respectively RTP B. Note that the grayed areas are only accessible during system calls.

Note that on system without an MMU, or with the MMU disabled, there is only one memory view shared by the kernel and all RTP tasks. This memory view corresponds to Figure 2-4. Any task in the system, whether it is a kernel or a task executing in an RTP, has access to all the memory: kernel space, I/O regions, any

Figure 2-5 Fig 5-4: System Memory Views

Kernel Code

Memory View Memory View Memory View

Kernel Code

2 Real-Time Processes: RTPs 2.7 Other RTP Virtual Memory Options for 32-Bit VxWorks

RTPs’ memory, shared libraries, and shared data regions. In other words, such configurations do not provide any memory protection.

Using Flat RTP Virtual Memory

In order to use flat RTP virtual memory with 32-bit VxWorks, the INCLUDE_RTP component parameter RTP_OVERLAPPED_ADDRESS_SPACE must be set to FALSE.

When VxWorks is configured for flat RTP virtual memory, applications are relocated, regardless of whether or not they are built as absolutely-linked

executables, and each application is installed in a unique space in virtual memory.

Using RTPs Without MMU Support

32-Bit VxWorks can be configured to provide support for real-time processes on a system based on a processor without an MMU, or based on a processor with MMU but with the MMU disabled. VxWorks must, however, be configured with the INCLUDE_RTP component parameter RTP_OVERLAPPED_ADDRESS_SPACE set to FALSE (as with the flat RTP virtual memory configuration; see 2.7.2 Flat RTP Virtual Memory for 32-Bit VxWorks, p.29 and Using Flat RTP Virtual Memory, p.33).

With this configuration, a software simulation-based memory page management library keeps track of identity mappings only. This means that there is no address translation, and memory page attributes (protection attributes and cache

attributes) are not supported.

The advantages of a configuration without MMU support are that it:

■ Enables the process environment on systems without an MMU. It provides private namespace for applications, for building applications independently from the kernel, and for simple migration from systems without an MMU to those with one.

■ Allows application code be run in non-privileged (user) mode.

■ Under certain conditions, it may provide increased performance by

eliminating overhead of the TLB miss and reload. This assumes, however, that there is no negative impact due to the changed cache conditions.

The limitations of this configuration are:

■ Depending on the processor type, BSP configuration, drivers and OS facilities used, disabling the MMU may require disabling the data cache as well.

Disabling the data cache results in significant performance penalty that is much greater than the benefit derived from avoiding TLB misses.

! ^CAUTION: To use RTPs without MMU support the INCLUDE_RTP component parameter RTP_OVERLAPPED_ADDRESS_SPACE must be set to FALSE. In addition, for the MIPS architecture, the INCLUDE_MAPPED_KERNEL component must be removed.

! ^CAUTION: Neither VxWorks SMP nor 64-bit VxWorks support MMU-less configurations. For information about VxWorks SMP (which does support RTPs), see the VxWorks Kernel Programmer’s Guide: VxWorks SMP.

■ There is no memory protection. That is, memory cannot be write-protected, and neither the kernel or any process are protected from other processes.

■ The address space is limited to the available system RAM, which is typically smaller than it would be available on systems with MMU-based address translation enabled. Because of the smaller address space, a system is more likely to run out of large contiguous blocks of memory due to fragmentation.

■ Not all processors and target boards can be used with the MMU disabled. For the requirements of your system see the hardware manual of the board and processor used.

For information about architecture and processor-specific limitations, see the VxWorks Architecture Supplement.

Configuration With RTP Support and Without an MMU

There are no special components needed for the process environment with software-simulated paging. As with any configurations that provide process support, the INCLUDE_RTP component must be added to the kernel.

The steps required to enable software-simulated paging are:

1. Add the INCLUDE_RTP component to include process support. This automatically includes all dependent subsystems, among them INCLUDE_MMU_BASIC.

2. Change the SW_MMU_ENABLE parameter of the INCLUDE_MMU_BASIC component to TRUE (the default value is FALSE).

In addition, the following optional configuration steps can reduce the footprint of the system:

3. Change the VM_PAGE_SIZE parameter of the INCLUDE_MMU_BASIC

component. The default is architecture-dependent; usually 4K or 8K. Allowed values are 1K, 2K, 4K, 8K, 16K, 32K, 64K. Typically, a smaller page size results in finer granularity and therefore more efficient use of the memory space.

However, smaller page size requires more memory needed for keeping track the mapping information.

4. Disable stack guard page protection by changing the

TASK_STACK_OVERFLOW_SIZE and TASK_STACK_UNDERFLOW_SIZE configuration parameters to zero. Without protection provided by an MMU, stack overflow and underflow cannot be detected, so the guard pages serve no purpose.

5. Remove the following components from the VxWorks configuration:

INCLUDE_KERNEL_HARDENING, INCLUDE_PROTECT_TEXT,

INCLUDE_PROTECT_VEC_TABLE, INCLUDE_PROTECT_TASK_STACK, INCLUDE_TASK_STACK_NO_EXEC, and

INCLUDE_PROTECT_INTERRUPT_STACK. Without an MMU, these features do not work. Including them only results in unnecessary consumption of resources.

3