VxWorks & Memory Management

reelingripehalfΛογισμικό & κατασκευή λογ/κού

14 Δεκ 2013 (πριν από 3 χρόνια και 7 μήνες)

59 εμφανίσεις

VxWorks & Memory

Group A7



General Overview

High level overview of how VxWorks
thinks about memory

Virtual Memory


Specific example of how VxWorks
allocates memory on a Synergy
Dual Processor

General Overview

In basic VxWorks, all memory can
be conceived as a singular linear
array of words*.

All processes (theoretically) can
access all words.

*=Or what ever the appropriate
addressing unit is: byte, word, long

Memory Layout (VxWorks on

Interrupt Vector Table

Exception/Interrupt vectors

Shared Memory Anchor (if

Boot Line

ASCII string of boot parameters

Exception Message

ASCII string of the(prior) fatal
exception message

Memory Layout, II

Initial Stack

Initial stack for usrInit
( )
, until usrRoot

allocates the real stack.

System Image

VxWorks itself (three sections: text,
data, bss). The entry point for VxWorks
is at the start of this region, which is
BSP dependent. The entry point for
each BSP is as follows:

Memory Layout, III

Host Memory Pool

Memory allocated by host tools. The
size depends on the the macro

Applications downloaded to processor
are allocated space here.

Interrupt Stack

Size is defined by ISR_STACK_SIZE

Memory Layout, IV

System Memory Pool

Size and location depend on the size of
the system image. Malloc() allocates
space from here.

Many of these items can be changed
by modifying various macros
WDB_POOL_SIZE are just two) and
then recompiling VxWorks.

Memory Access (Translations)

Untranslated: physical address is used
unchanged (physical == virtual)

The processors usually boot into this mode
until MMU hardware is initialised

BAT Registers

Set of four/eight registers which define (large)
blocks of memory

Each logical address is converted by BAT

Responsibility of user to correctly set BAT

Memory Access, II

Page mode

As you would expect: logical addresses are decoded
through segment registers and TLB page tables to
construct physical address

Be careful on size: mapping 1GB => 16MB of page
table space!

User must correctly set
up page table entries for
certain (non
standard) memory locations.

Usually a combination of BAT and Page is used,
depending on size of memories to map (VME /
PCI / IO, etc). Page mode is preferred for use
with Virtual Memory and Caching.

Virtual Memory

VxWorks does not require a Memory
Management Unit (MMU)

Not all systems have a MMU

System performance is best when a MMU
is used

vmBaseLib allows 1 global Virtual
Memory mapping for the system

vmBaseLib allows user to set cacheable /
uncacheable memory blocks

VxWorks Memory, ctd

Extensive Virtual Memory support
available is separate product (VxMI, aka

Allows private virtual memory contexts

User could set up each task with a
separate VM context

But: increased context switch time,
user must manage contexts correctly

Not normally used in my company’s
embedded products

VxWorks and Caching

VxWorks is designed to the worst
case scenario (greatest number of
coherency issues):

Harvard architecture (separate
Instruction and Data caches)

back mode

DMA transfers and devices

Multiple bus masters

No Hardware support

More on Caching

VxWorks supplies the functions to control cache settings
through/ copy

It is the responsibility of the user to handle the intricacies
of cache / dma / virtual memory.

User must indicate whether memory buffers are cacheable /

User must handle cache invalidation / cache flushing to
maintain cache coherency

User must correctly set up DMA transfers with the use of the
MMU and cache

Most of the time, the default settings are fine. Only when
accessing other devices does this become some thing that
must be fully analyzed.

VxWorks / BSP supply the functions, the user supplies
how/when to use them.

How does VxWorks allocate

VxWorks starts at address 0:

includes exception vector, etc.

During kernel initialisation, kernelLib will use memLib to allocate the
system memory partition.

Malloc() will use the system memory partition for kernel memory

User can create memory partitions by calling
memPartCreate() in memPartLib.

This allows user to maintain different pools of memory, each of a
different size, and allocate from those pools.

Generally these allocates are pulled from the system memory

User can add more memory to the partition, and it need not be

With appropriate number and appropriately sized partitions (a priori
analysis) the effects of memory fragmentation can be reduced.

One problem with VxWorks

PPC’s addresses are 24 bits

all code
(VxWorks & application) must be within
32 MB.

There are several methods of dealing
with this problem:

Add memory to global memory pool _AFTER_
all application code is loaded;

Compile code w/
mlongcall option (reduced
efficiency in code due to extra instructions to
handle long calls)

User manages extra memory (not visible to
VxWorks malloc())

Specifics of VxWorks

vmLib.h: handles the physical to
virtual memory mapping

Data structure: sysPhysMemDesc

Partly filled in by VxWorks at system
configuration (boot time)

Filled in by user prior to VxWorks
compilation to add other memory
(memory mapped devices)

Example sysPhysMemDesc[]
(Synergy Dual processor board)

This is essentially the first page
table in the system (it contains the
first set of Page Table Entries)

It is an array of records:

Virtual Address, Physical Address,
Length in Bytes; Virtual Memory Mask,
Virtual Memory Enable

Note: This is a dual processor board, with all of RAM accessible
to both processors. Different board configurations will yield
different physical memory layouts.

sysPhysMemDesc[], ctd

The following are generally completed by the
BSP vendor:

Element 0: Maps mailboxes, starts at address 0, and
should be uncached.*/

Element 1: Maps gemini registers and ethernet data
arrays. Starts at 0xF000000

Element 2: Define the space for VxWorks kernel
(processor 1). Modified by kernel at run time.

Element 3: Define the space for VxWorks kernel
(processor 2). Modified at run time.

Element 4: Shared Memory. Starts at 0x2000000

Element 5: Processor 1’s RAM. Modified at run time.

Element 6: Processor 2’s RAM. Modified at run time.

Element 7: Page tables space. Modified at run time.

sysPhysMemDesc[], ctd

These elements are the
responsibility of the user to modify
prior to compiling:


8 entries

initially zero (so if they are not used, no memory is

my current project has a mapping here to a device on the
PCI bus


last 8 entries

Describe the VME master ports for the architecture

Initially zero (like PCI maps)

We will add a mapping to a VME device here as well

The base system is untranslated, physical = virtual

What about the BAT registers?

BAT registers can conflict with the
routines in cacheLib and vmBaseLib

ie, OS and HW may not play well

BAT registers map memory outside of
the processors (Flash, PROM, etc)

Locations where fine
grained control is
not necessary


VxWorks offers much power to the
user (application / system
programmer) to control exactly how
memory is addressed, allocated,

With power comes responsibility:

user must not rely on VxWorks to perfectly implement
an application’s memory needs.

User will need to consider caching (flushing,
disabling), DMA accesses, etc. as part of design.


Board Support Package (BSP): The
extensions to the generic VxWorks that
apply to a specific processor and its

back: Only write to memory when

Direct Memory Access (DMA):
Transfering data withou processor

through: Write to cache and then
into memory


VxWorks Reference Manual

Synergy User Guide for Dual

VxWorks on
line documentation

VxWorks source code (all the libs)