Building a FLASH-Resident VxWorks System on Motorola MVME162

Building a FLASH-Resident VxWorks System on Motorola MVME162

For legacy VME-based embedded systems, a self-contained operating system image that boots directly from non-volatile memory can significantly improve startup time, reliability, and deployment simplicity. The Motorola MVME162 provides an especially useful example because its onboard FLASH can be programmed in-system and mapped into the processor’s reset address space.

This article describes how to build a standalone, FLASH-resident VxWorks image for the Motorola MVME162, customize the mv162lc board support package (BSP), generate a binary image, and program it into onboard FLASH. The workflow is based on VxWorks/Tornado 2.0 development performed for the EVLA Interim Control and Monitor system around 2002.

Although the hardware and toolchain are legacy technologies, the underlying concepts remain relevant: BSP customization, reset-vector placement, non-volatile image layout, boot-monitor configuration, and in-system FLASH programming are still fundamental techniques in embedded development.

⚡ Why Put VxWorks in FLASH?

#

A conventional MVME162 deployment typically uses a small bootstrap or the Motorola 162Bug monitor to load VxWorks over a network or from external storage. Moving the complete operating system and application image into FLASH removes that dependency from the normal boot path.

The main advantages are:

• Faster startup: The target can boot directly from local non-volatile storage rather than downloading the OS over a network.
• Improved availability: The system can start even when the development or boot server is unavailable.
• Simplified deployment: The board becomes a largely self-contained embedded controller.
• In-system programming: The MVME162 FLASH can be programmed without removing the device or using an external programmer.

For applications such as industrial controllers, instrumentation, and telescope control systems, these characteristics can be more valuable than the flexibility of network-loaded development images.

🧭 MVME162 Hardware and Memory Map

#

The MVME162-412 used in the original implementation is based on the 68LC040 processor and provides several distinct memory regions.

GP13 Determines the Boot-Memory Mapping

#

The GP13 jumper, located at J22 pins 9/10, determines whether FLASH or EPROM occupies the processor’s reset address.

This mapping is critical because the processor obtains its initial stack pointer and program counter from the reset vector at 0xFF800000.

Consequently, when FLASH is selected as the boot device, the VxWorks image must be arranged so that its initial SP/PC values are available at the beginning of the mapped FLASH region.

🧩 Selecting the Appropriate VxWorks Image

#

The VxWorks/Tornado build environment provides several image formats with different execution models.

The original implementation selected vxWorks.st_rom.

This configuration provides a useful compromise between storage efficiency and runtime performance. The compressed image resides in FLASH, is copied into RAM during boot, and is decompressed before execution. Unlike an execute-in-place ROM configuration, normal VxWorks execution does not continuously depend on the relatively slow FLASH memory interface.

🛠️ Customizing the VxWorks Build

#

The original development environment used:

• Host: magnolia
• Target: buckwheat
• VxWorks: Tornado 2.0
• Installation: /opt/local/WindRiver/Tornado/2.0
• BSP: mv162lc
• Project build area: /home/asg/vxworks/evla/cmp

A private build tree was created so project-specific BSP and configuration changes could be maintained without modifying the master Tornado installation.

Increasing the ROM Image Size

#

The default BSP configuration allocated only 256 KB for the ROM image. Since the MVME162 provides 1 MB of FLASH, the BSP Makefile was modified accordingly:

ROM_SIZE = 000100000

This allows the generated image to occupy the available 1 MB FLASH region.

Configuring config.h

#

The VxWorks configuration was then adjusted according to application requirements.

Typical changes included:

• Removing unnecessary C++ support
• Disabling BOOTP
• Enabling NFS
• Enabling FTP, TFTP, and Telnet
• Enabling security facilities
• Retaining the symbol table
• Enabling WindView support
• Setting the console baud rate to 9600
• Defining the default boot line
• Defining host and target names
• Setting the ROM size to 0x00100000

The objective was to retain the networking and diagnostic functionality required during operation without unnecessarily increasing the image footprint.

Customizing usrConfig.c

#

The most substantial changes were made to usrConfig.c.

The startup logic was modified to provide an interactive boot-parameter mechanism similar to the normal network boot ROM. This allows an operator to interrupt the startup countdown and modify boot parameters when necessary.

A built-in startup script was also embedded into the image. Rather than performing slow remote login or script retrieval operations during every boot, the startup sequence could:

1. Configure system identity.
2. Establish network routes.
3. Mount required NFS filesystems.
4. Configure the shell environment.
5. Launch the application’s normal startup script.

This approach keeps the core OS locally resident while retaining access to network-based application resources.

🔨 Building the FLASH Image

#

After configuring the BSP and application environment, the build process can generate the standalone ROM image.

The relevant environment variables include:

WIND_BASE=/opt/local/WindRiver/Tornado/2.0
WIND_HOST_TYPE=<host-type>
PATH=$WIND_BASE/host/<host-type>/bin:$PATH

The image can then be built from the BSP directory:

cd .../target/config/mv162lc
make vxWorks.st_rom
aoutToBin < vxWorks.st_rom > vxWorks.st_rom.bin

The resulting vxWorks.st_rom.bin file is the binary representation used for FLASH programming.

💾 Programming the MVME162 FLASH

#

The programming procedure uses the board’s 162Bug monitor to transfer the image into RAM and then program the FLASH device.

1. Boot into 162Bug

#

First, configure the board so that EPROM occupies the processor’s reset address.

Power the board down and remove the GP13 jumper. With this configuration, 162Bug is mapped to the boot address.

After powering on, the board should enter the 162Bug monitor.

2. Configure Network Parameters

#

Use the NIOT command to configure the network parameters required for TFTP.

When prompted to update non-volatile RAM, answer N unless the intention is specifically to replace the existing boot parameters.

This distinction is important because the NVRAM formats used by 162Bug and VxWorks are not identical.

3. Transfer the Image to RAM

#

Use NIOP to retrieve the generated binary image:

NIOP
... File Name = <path>/vxWorks.st_rom.bin
Memory Address = 00010008

The image is placed at 0x10008 so that the reset-vector information can occupy the preceding eight bytes beginning at 0x10000.

4. Initialize the Stack Pointer and Program Counter

#

The initial stack pointer and program counter must be written into the image header area.

A representative 162Bug memory modification sequence is:

MM 10000;l
00010000  ...? 00001000
00010004  ...? FF800008

The exact values depend on the generated image and BSP configuration. The important requirement is that the reset vector points to the correct runtime stack and VxWorks entry address after FLASH is mapped into the boot region.

5. Program FLASH

#

The MVME162 FLASH is programmed in 64 KB blocks, so the image size must be rounded up to the next 64 KB boundary.

For example, an image of approximately 300,992 bytes requires a programming length of 0x50000.

A representative command is:

PFLASH 10000:50000 FFA00000

The monitor will request confirmation before erasing and programming the affected FLASH blocks.

Careful size calculation is important because FLASH erase operations operate on blocks rather than individual bytes.

6. Restore FLASH Boot Mapping

#

After programming completes:

1. Power off the MVME162.
2. Reinstall the GP13 jumper.
3. Power the board back on.

FLASH is now mapped to 0xFF800000, allowing the processor to obtain its reset vector directly from the programmed VxWorks image.

A successful boot should proceed into the VxWorks startup sequence and display the configured boot-parameter countdown.

🚀 Boot-Time Behavior

#

The resulting system provides a largely self-contained VxWorks environment.

The board can:

• Boot VxWorks directly from FLASH.
• Start within a few seconds.
• Allow interactive modification of boot parameters.
• Preserve VxWorks boot parameters in NVRAM.
• Execute a built-in startup sequence.
• Establish network identity and routing.
• Mount required NFS filesystems.
• Launch the application startup script.
• Retain networking and debugging functionality.

The core operating system no longer depends on transferring the VxWorks image from a development host during every restart.

🧠 Understanding the Image Execution Model

#

It is important to distinguish between ROM-resident storage and ROM execution.

The selected vxWorks.st_rom configuration stores the compressed image in FLASH but ultimately executes the decompressed image from RAM.

This provides two separate benefits:

• FLASH supplies persistent, non-volatile storage.
• RAM provides the normal execution environment.

A pure execute-in-place image such as a ROM-resident configuration can reduce the amount of RAM required for the OS image, but execution performance can suffer because instructions and data are accessed directly from ROM/FLASH.

For the MVME162 implementation, the compressed FLASH-to-RAM approach provided a better balance between boot persistence, image size, and runtime performance.

⚠️ Important Deployment Caveats

#

Several details can easily cause problems during implementation.

FLASH Erase Granularity

#

The MVME162 FLASH is erased and programmed in 64 KB blocks. Always round the programming range upward to the next block boundary.

Programming an image length that is not block-aligned without accounting for this behavior can result in incomplete or unexpected FLASH contents.

NVRAM Format Compatibility

#

162Bug and VxWorks use different representations for boot parameters.

Switching between the two environments without considering their respective NVRAM formats can corrupt or invalidate stored boot configuration.

Reset-Vector Placement

#

The processor reads the initial stack pointer and program counter from the reset address. Therefore, the image layout, FLASH mapping, and SP/PC header must all agree.

A correctly built VxWorks image placed at the wrong physical address will not boot simply because the binary itself is valid.

Project-Specific Network Configuration

#

Hostnames, IP addresses, NFS paths, usernames, routes, and startup commands from the original implementation are application-specific.

They should be treated as examples rather than reusable production values.

Development Versus Production Images

#

Network-loaded images remain useful during development because they make iterative testing straightforward. FLASH-resident images are more appropriate when the target must operate independently from the development environment.

A practical workflow is therefore to validate the system using network boot first and transition to FLASH deployment only after the image and startup sequence are stable.

🔭 Broader Embedded-System Relevance

#

Although the MVME162 and Tornado 2.0 are legacy platforms, the engineering pattern remains broadly applicable.

A FLASH-resident embedded operating system typically requires the same fundamental pieces:

1. A customized BSP defining memory and boot behavior.
2. A correctly linked OS image.
3. A bootloader or monitor capable of programming non-volatile storage.
4. A reset-vector layout matching the processor’s startup requirements.
5. A well-defined transition from non-volatile storage to the runtime memory model.
6. A deterministic startup sequence that does not depend unnecessarily on external infrastructure.

Modern embedded platforms may use SPI NOR, eMMC, NAND, or other boot media instead of the MVME162’s parallel FLASH, and modern processors may use substantially different boot chains. Nevertheless, the underlying principles of image placement, memory mapping, boot configuration, and persistent deployment remain the same.

🏁 Final Takeaways

#

Building a FLASH-resident VxWorks system on the MVME162 transforms a development-oriented VME board into a self-contained embedded controller.

The essential workflow is:

• Customize the mv162lc BSP for the available 1 MB FLASH.
• Configure VxWorks and application startup behavior.
• Build the vxWorks.st_rom image.
• Convert it into a programmable binary.
• Boot through 162Bug and transfer the image into RAM.
• Construct the correct reset-vector header.
• Program the image into FLASH using PFLASH.
• Restore the FLASH boot mapping through GP13.
• Verify direct VxWorks startup.

The original EVLA implementation demonstrates the practical value of this approach: fast local boot, reduced dependence on network infrastructure, configurable startup behavior, and retention of the networking and debugging facilities required by an operational embedded controller.

For legacy VME systems and similar embedded architectures, understanding this complete path—from BSP configuration and linker layout through reset-vector placement and FLASH programming—is essential for producing reliable standalone VxWorks deployments.