VxWorks Fast Boot with NOR Flash: Redundant Boot Parameters

VxWorks Fast Boot with NOR Flash: Redundant Boot Parameters

📋 Abstract

#

Persistent boot configuration is essential for reliable startup in embedded systems. VxWorks traditionally uses nonvolatile RAM (NVRAM) or equivalent persistent storage to retain boot parameters, including network addresses, host information, boot device settings, and target configuration.

However, many embedded boards do not include dedicated NVRAM hardware. This creates a practical challenge: how can VxWorks retain boot parameters across power cycles without requiring additional memory devices or manual configuration during every startup?

This article presents a NOR Flash-based NVRAM replacement and fast-boot design for VxWorks, developed around a PowerPC embedded switch-board platform using Wind River Workbench 3.1.

The solution implements the standard VxWorks sysNvRamGet() and sysNvRamSet() interfaces using reserved NOR Flash storage. Sequentially allocated parameter records reduce repeated sector erasures, while a dual-sector redundancy mechanism improves resilience against Flash failures.

The design provides several advantages:

• Persistent boot configuration without dedicated NVRAM.
• Automatic retrieval of previously saved boot parameters.
• Reduced NOR Flash erase frequency.
• Primary and backup parameter storage.
• Compatibility with existing VxWorks boot-line interfaces.
• Improved recovery from damaged configuration storage.
• Lower hardware complexity for boards already equipped with NOR Flash.

The original engineering implementation demonstrated successful automatic startup, persistent parameter read/write operations, and recovery using a backup Flash region.

This article also discusses important production considerations, including erase-block alignment, data integrity validation, power-loss-safe updates, Flash endurance, and BSP integration.

Keywords: VxWorks fast boot, NOR Flash, NVRAM replacement, boot parameters, sysNvRamGet(), sysNvRamSet(), Flash redundancy, PowerPC BSP.

🎯 1. Introduction to VxWorks Fast Boot and Persistent Configuration

#

1.1 Why Embedded Systems Need Persistent Boot Parameters

#

Embedded devices such as switches, routers, industrial controllers, communication terminals, and portable equipment require configuration information during startup.

Typical VxWorks boot parameters include:

• Boot device name.
• Host name.
• Target name.
• Host IP address.
• Target IP address.
• Gateway address.
• Boot image path.
• User name.
• Optional authentication information.
• Network interface configuration.
• Boot flags.

These parameters determine how the system locates its operating-system image and initializes the runtime environment.

If the configuration disappears after power loss, an operator may need to enter the information manually during the next startup.

For unattended equipment, this behavior is unacceptable.

A persistent configuration mechanism enables the device to restore its previous settings automatically.

1.2 Conventional NVRAM-Based Boot Configuration

#

Many embedded platforms provide NVRAM or battery-backed memory for storing boot parameters.

A simplified architecture is:

+----------------------------------+
|          Power-On Reset          |
+----------------+-----------------+
                 |
                 v
+----------------------------------+
|         VxWorks Bootloader       |
+----------------+-----------------+
                 |
                 v
+----------------------------------+
|         Read Boot Parameters     |
|             from NVRAM           |
+----------------+-----------------+
                 |
                 v
+----------------------------------+
|          Parse Boot Line         |
+----------------+-----------------+
                 |
                 v
+----------------------------------+
|       Load VxWorks Image         |
+----------------+-----------------+
                 |
                 v
+----------------------------------+
|       Start Operating System     |
+----------------------------------+

NVRAM provides a convenient solution because configuration data can be updated without the erase-block management required by NOR Flash.

However, dedicated NVRAM increases component count, board complexity, and potentially hardware cost.

For platforms already containing NOR Flash, using a small portion of that Flash as persistent configuration storage can eliminate the need for a separate NVRAM device.

1.3 Why NOR Flash Can Replace NVRAM

#

NOR Flash retains data without external power and supports random read access.

Its major characteristics include:

• Nonvolatile data retention.
• Memory-mapped read access on compatible platforms.
• Block-based erase operations.
• Byte, word, or buffered programming depending on the device.
• Finite program/erase endurance.
• Relatively slow erase operations compared with ordinary RAM writes.

For boot parameters that change infrequently, these characteristics are generally acceptable.

The primary limitation is that NOR Flash cannot be updated like conventional RAM.

In a typical NOR Flash device, programming changes bits from the erased state of 1 toward 0. Restoring programmed bits to 1 requires erasing the containing block.

Therefore, repeatedly updating configuration at a fixed address can unnecessarily consume Flash erase cycles.

A better design spreads successive updates across multiple records.

1.4 Limitations of Basic Flash-Based NVRAM Emulation

#

Classic VxWorks environments include BSP-level NVRAM interfaces, and some releases provide Flash-backed implementations such as nvRamToFlash.

A basic implementation may reserve a fixed Flash location for boot parameters.

However, this approach has limitations:

Repeated Sector Erasure

If each update rewrites the same location, the corresponding Flash erase block may be erased frequently.

Single-Point Storage Failure

If the configuration resides in only one sector, corruption of that sector can make the stored boot parameters unusable.

Power-Loss Vulnerability

An interrupted erase or programming operation can leave the stored configuration incomplete.

Limited Recovery Capability

Without another valid configuration copy, the bootloader may have to fall back to default parameters.

The proposed method addresses these limitations through sequential record storage and dual-sector redundancy.

🏗️ 2. Hardware Platform and NOR Flash Memory Architecture

#

2.1 Target Hardware Configuration

#

The original implementation targets an embedded switch line card based on a Freescale PowerPC communications processor.

The reported hardware configuration is:

The reported memory sizes and erase geometry describe the original board configuration.

The exact M29EW device part numbers, bus organization, and Flash geometry should be verified against the board schematic, device markings, and Common Flash Interface (CFI) data.

In particular, physical Flash capacity is often specified in megabits rather than megabytes. Two interleaved Flash chips may also form a logical erase unit larger than an individual chip’s physical erase block.

2.2 NOR Flash Address Space

#

The platform maps NOR Flash into the processor’s address space:

Flash Base Address:
    0xE0000000

Flash End Address:
    0xEFFFFFFF

Total Address Space:
    256 MB

The Flash contains firmware and other persistent data, while a small region near the end of the address space is reserved for boot-parameter storage.

The design uses two logical erase blocks for redundancy.

2.3 Correctly Aligning the Redundant Flash Blocks

#

With a logical erase-block size of 256 KB:

Erase Block Size = 0x00040000 bytes

The final two erase blocks in the stated address range are:

The corresponding data-region starting addresses, after reserving a 256-byte header area, are:

Primary Data Base:
    0xEFF80100

Backup Data Base:
    0xEFFC0100

Important: The originally supplied spare address 0xEFFB0100 falls inside the primary 256 KB erase block. It cannot serve as an independent backup block under this erase geometry.

A backup based on that address could be erased together with the primary configuration.

The corrected address map ensures that both logical sectors can be erased independently, assuming the reported hardware erase geometry is accurate.

2.4 Flash Storage Layout

#

The storage architecture is:

+--------------------------------------+
|          NOR Flash Memory            |
|        0xE0000000–0xEFFFFFFF         |
+--------------------------------------+
|                                      |
|       Firmware / Other Storage       |
|                                      |
+--------------------------------------+
| Primary Configuration Block          |
| 0xEFF80000–0xEFFBFFFF                |
|                                      |
| Header / Block Metadata              |
| Boot Record 0                        |
| Boot Record 1                        |
| Boot Record 2                        |
| ...                                  |
+--------------------------------------+
| Backup Configuration Block           |
| 0xEFFC0000–0xEFFFFFFF                |
|                                      |
| Header / Block Metadata              |
| Backup Boot Records                  |
| ...                                  |
+--------------------------------------+

The primary and backup regions provide the foundation for fault-tolerant configuration storage.

However, reserving two blocks does not automatically guarantee data redundancy. The write protocol must ensure that a valid configuration survives interruption or failure of either block.

⚙️ 3. VxWorks Boot Parameter Initialization

#

3.1 BOOT_LINE and DEFAULT_BOOT_LINE

#

Classic VxWorks bootloaders use a boot-line string to describe startup parameters.

The current configuration is stored in a boot-line buffer, commonly represented through the BOOT_LINE convention and the BSP’s boot-line storage.

The default configuration is typically defined using:

DEFAULT_BOOT_LINE

For example:

#define DEFAULT_BOOT_LINE \
    "fei(0,0)host:vxWorks " \
    "h=192.168.1.10 " \
    "e=192.168.1.20 " \
    "u=target"

This example is illustrative and must be adapted to the BSP’s device names and boot requirements.

The classic boot-line format may include authentication-related fields. Where possible, production systems should avoid storing sensitive credentials in an unprotected plaintext Flash record.

3.2 Boot-Line Buffer Size

#

The source implementation uses a boot-line storage convention of approximately 255 characters plus a null terminator.

Its Flash storage unit is 256 bytes.

The basic representation is:

+----------------------------------+
|         Boot Parameter Slot      |
+----------------------------------+
|                                  |
| Boot-Line Character Data         |
|                                  |
| Null Terminator                  |
|                                  |
| Unused Bytes                     |
+----------------------------------+

A 256-byte data slot can hold a maximum 255-character string when one byte is reserved for '\0'.

The actual BOOT_LINE_SIZE configuration should be checked in the target VxWorks BSP.

The Flash record format must not assume more space than the configured boot-line buffer and metadata layout permit.

3.3 usrBootLineInit() Startup Flow

#

In classic VxWorks boot configurations, the boot-line initialization process involves a routine such as:

usrBootLineInit()

The implementation is associated with boot initialization code, including usrNet.c in certain legacy configurations.

The startup process generally follows this sequence:

1. Initialize the required hardware.
2. Attempt to read saved parameters through sysNvRamGet().
3. Validate the returned boot-line string.
4. Copy valid parameters into the active boot-line buffer.
5. If the stored configuration is unavailable, use DEFAULT_BOOT_LINE.
6. Allow an operator to modify configuration if the bootloader supports interactive editing.
7. Continue the boot process using the selected parameters.

The original platform provides a seven-second autoboot interruption window.

An operator can enter:

c

to access the interactive boot-parameter modification procedure.

The precise prompt behavior and timeout depend on the bootloader build.

3.4 Automatic Boot Behavior

#

The intended startup sequence is:

Power-On
    |
    v
Hardware Initialization
    |
    v
Read Flash Boot Parameters
    |
    v
+--------------------------+
| Valid Configuration?     |
+------------+-------------+
             |
      +------+------+
      |             |
     Yes            No
      |             |
      v             v
Use Saved       Use Default
Boot Line       Boot Line
      |             |
      +------+------+
             |
             v
Optional Interactive Window
             |
             v
Automatic Image Loading
             |
             v
VxWorks Startup

This eliminates the need to manually enter boot parameters after every power cycle.

It should be understood as automatic configuration recovery and unattended boot, not necessarily a reduction in the underlying kernel initialization time.

The seven-second interactive timeout also remains part of startup unless it is separately optimized.

💾 4. NOR Flash-Based NVRAM Emulation

#

4.1 Standard VxWorks NVRAM Interfaces

#

The design implements two conventional BSP interfaces:

    STATUS sysNvRamGet
        (
        char *string,
        int strLen,
        int offset
        );

    STATUS sysNvRamSet
        (
        char *string,
        int strLen,
        int offset
        );

These functions allow the existing bootloader code to access persistent configuration without directly depending on Flash-specific operations.

The application-facing interface remains unchanged.

Internally, the BSP translates NVRAM read and write requests into NOR Flash operations.

4.2 Interface Compatibility Requirements

#

The parameters have the following meanings:

The original boot-line implementation primarily uses a single configuration string.

However, the conventional interface includes an offset parameter.

A correct replacement must either support the offset semantics expected by the BSP or explicitly reject unsupported ranges.

Silently ignoring offset can break other components that use the NVRAM interface.

4.3 Sequential Storage Instead of Fixed-Address Rewriting

#

A fixed-address implementation may repeatedly erase and reprogram the same Flash block.

The proposed design instead uses sequential records.

Conceptually:

Primary Flash Block

+------------------------------+
| Header                       |
+------------------------------+
| Record 0: Initial Config     |
+------------------------------+
| Record 1: Updated Config     |
+------------------------------+
| Record 2: Updated Config     |
+------------------------------+
| Record 3: Current Config     |
+------------------------------+
| Free Record                  |
+------------------------------+
| Free Record                  |
+------------------------------+
| ...                          |
+------------------------------+

Each configuration update uses a previously erased slot.

The Flash block is erased only when the available record space has been exhausted or when a controlled recovery operation requires it.

This reduces erase frequency substantially when compared with erasing the block after every update.

4.4 Original 256-Byte Slot Convention

#

The original method uses 256-byte aligned storage slots.

A basic free-slot check can examine whether a selected marker byte remains in the erased state.

NOR Flash normally reads as:

0xFF

after erasure.

A programmed slot can be identified using a marker changed to an appropriate programmed value.

For example:

    Erased Slot:
        marker = 0xFF

    Committed Slot:
        marker = 0x00

However, checking only the final byte is insufficient for a power-loss-safe design.

An interrupted write could produce a partially programmed record that appears occupied but contains invalid data.

For production use, record integrity and commit status should be verified separately.

🔄 5. Dual-Sector Redundancy and Flash Wear Reduction

#

5.1 Primary and Backup Configuration Blocks

#

The design reserves two independent Flash erase blocks.

One serves as the active storage area, while the other provides a recovery location.

The logical organization is:

+--------------------------------+
| Primary Flash Block            |
|                                |
| Active Configuration Records   |
+--------------------------------+

              Redundancy

+--------------------------------+
| Backup Flash Block             |
|                                |
| Valid Configuration Copy       |
+--------------------------------+

The redundancy mechanism must be designed so that a recoverable configuration remains available during block migration.

5.2 Why Redundancy Improves Reliability

#

A single configuration block is vulnerable to:

• Flash programming errors.
• Erase failures.
• Power interruption.
• Corrupted configuration records.
• Unreadable memory regions.
• Incorrect metadata updates.

With two independently erasable blocks, the system can select a valid backup when the primary record or block becomes unusable.

However, a backup sector that contains no valid configuration does not provide meaningful redundancy.

The implementation must explicitly maintain recoverable state across both sectors.

5.3 Avoid Rewriting the Offset Header

#

The original design stores the current record offset in a sector header.

Although straightforward, repeatedly updating an integer offset in NOR Flash can be problematic.

Flash programming typically permits changes from 1 to 0, but changing bits back to 1 requires an erase.

Therefore, incrementing an ordinary binary offset in place cannot be assumed safe.

A more robust approach is to derive the latest valid record from sequentially written metadata.

For example, each committed record can contain:

• Record signature.
• Format version.
• Sequence number.
• Payload length.
• CRC32 checksum.
• Commit marker.

The latest valid record is selected using the sequence number and validation results.

This avoids rewriting a mutable offset header after every update.

5.4 Production-Oriented Record Format

#

The original 256-byte slot can hold an entire 255-character boot line only when nearly all bytes are dedicated to payload data.

Adding metadata within that same slot reduces the maximum permitted string length.

A practical enhancement is to use a 512-byte logical record composed of two 256-byte units:

+--------------------------------------+
|       Logical Record: 512 Bytes      |
+--------------------------------------+
|                                      |
| Unit 0: Boot-Line Payload            |
|                                      |
| 256 Bytes                            |
| Maximum 255 Characters + NUL         |
|                                      |
+--------------------------------------+
|                                      |
| Unit 1: Metadata                     |
|                                      |
| Signature                            |
| Format Version                       |
| Sequence Number                      |
| Payload Length                       |
| CRC32                                 |
| Commit Marker                        |
| Reserved Bytes                       |
|                                      |
+--------------------------------------+

This format preserves the original 256-byte boot-line capacity while adding integrity and recovery metadata.

It is an enhanced design option rather than a claim about the exact original on-Flash record structure.

Using a 256-byte sector header and 512-byte logical records, each 256 KB erase block can accommodate 511 records.

The precise number depends on the metadata and alignment requirements selected for the implementation.

5.5 Power-Loss-Safe Commit Sequence

#

A safer write protocol uses a commit marker programmed last.

The procedure is:

1. Select an erased record.
2. Program the boot-line payload.
3. Program metadata, including length, sequence number, and CRC.
4. Read back and verify the programmed data.
5. Program the final commit marker.
6. Confirm the committed record is readable and valid.
7. Retain the previous valid record until the new record is committed.

Conceptually:

Write New Payload
       |
       v
Write Record Metadata
       |
       v
Verify Data and CRC
       |
       v
Program Commit Marker
       |
       v
New Record Becomes Valid

If power is lost before the commit marker is programmed, the bootloader ignores the incomplete record and uses the previous valid configuration.

The exact commit procedure must follow the NOR device’s programming granularity and ordering requirements.

5.6 Safe Block Migration

#

When the active block runs out of available records, the system must transfer configuration to another block.

A robust migration procedure is:

1. Identify the latest valid committed configuration.
2. Prepare the destination block without erasing the only valid configuration.
3. Write the configuration into the destination block.
4. Verify the destination record.
5. Commit the destination record.
6. Make the destination the new active block.
7. Erase the old block only after confirming successful migration.

This ordering protects against power loss during block rotation.

If continuous 1+1 redundancy is required, the design must also preserve or recreate a second valid copy instead of leaving the backup block empty for the entire active-record accumulation period.

The exact recovery protocol should consider failures at every intermediate step.

💻 6. VxWorks BSP Interface Implementation

#

6.1 Flash Address Definitions

#

The following definitions describe the corrected logical memory layout.

    #include <vxWorks.h>
    #include <stdint.h>
    #include <stddef.h>

    #define NOR_FLASH_BASE      0xE0000000UL
    #define NOR_FLASH_END       0xEFFFFFFFUL

    #define NOR_ERASE_SIZE      0x00040000UL

    #define BOOT_PRIMARY_BASE   0xEFF80000UL
    #define BOOT_BACKUP_BASE    0xEFFC0000UL

    #define BOOT_HEADER_SIZE    0x00000100UL
    #define BOOT_SLOT_SIZE      256U

    #define BOOT_PRIMARY_DATA   \
        (BOOT_PRIMARY_BASE + BOOT_HEADER_SIZE)

    #define BOOT_BACKUP_DATA    \
        (BOOT_BACKUP_BASE + BOOT_HEADER_SIZE)

    #define BOOT_LINE_BYTES     256U

    #define BOOT_SLOT_MARK_FREE 0xFFU
    #define BOOT_SLOT_MARK_USED 0x00U

These constants are specific to the example memory map.

The BSP must verify that the reserved addresses do not overlap:

• Bootloader code.
• VxWorks image storage.
• Flash filesystem partitions.
• Environment data.
• Manufacturing information.
• Other persistent configuration.

The physical Flash driver must also support the device’s actual erase and programming geometry.

6.2 sysNvRamGet() Design

#

The read interface retrieves the latest valid configuration.

For a redundant record-based implementation, the logic is:

1. Validate arguments.
2. Scan the primary storage area.
3. Scan the backup storage area.
4. Validate candidate records.
5. Select the newest valid committed record.
6. Verify the requested offset and length.
7. Copy data to the caller’s buffer.
8. Return the appropriate status.

A simplified interface skeleton is:

    STATUS sysNvRamGet
        (
        char *string,
        int strLen,
        int offset
        )
    {
        /*
         * Implementation outline:
         *
         * 1. Validate input parameters.
         * 2. Locate the newest valid Flash record.
         * 3. Verify record integrity.
         * 4. Validate the requested range.
         * 5. Copy the requested data.
         */

        if (string == NULL)
            return ERROR;

        if (strLen <= 0 || offset < 0)
            return ERROR;

        if ((size_t)offset > BOOT_LINE_BYTES)
            return ERROR;

        if ((size_t)strLen >
            BOOT_LINE_BYTES - (size_t)offset)
            return ERROR;

        /*
         * BSP-specific record scanning,
         * CRC validation, and buffer copying
         * must be implemented here.
         */

        return ERROR;
    }

This code shows argument validation and the interface contract. It intentionally returns ERROR until the BSP-specific record lookup and copy operations are implemented.

It is not a complete Flash driver.

For boot-line use, the caller must also ensure the returned string is null-terminated before parsing.

6.3 sysNvRamSet() Design

#

The write interface persists a new boot configuration.

Its conceptual workflow is:

1. Validate the input buffer.
2. Check logical NVRAM bounds.
3. Locate the latest valid record.
4. Prepare a complete updated configuration image.
5. Select an available erased record.
6. Program the new payload.
7. Program and verify metadata.
8. Commit the record.
9. Rotate to the other block when necessary.
10. Return the operation status.

A basic interface skeleton is:

    STATUS sysNvRamSet
        (
        char *string,
        int strLen,
        int offset
        )
    {
        /*
         * Implementation outline:
         *
         * 1. Validate input arguments.
         * 2. Merge the requested range into
         *    the current logical configuration.
         * 3. Locate a free Flash record.
         * 4. Program and verify the new data.
         * 5. Commit the record.
         */

        if (string == NULL)
            return ERROR;

        if (strLen <= 0 || offset < 0)
            return ERROR;

        if ((size_t)offset > BOOT_LINE_BYTES)
            return ERROR;

        if ((size_t)strLen >
            BOOT_LINE_BYTES - (size_t)offset)
            return ERROR;

        /*
         * BSP-specific Flash programming,
         * verification, commit, and block
         * rotation logic must be added here.
         */

        return ERROR;
    }

The implementation should not erase a block or report success until all required validation and recovery conditions have been satisfied.

6.4 Flash Driver Abstraction

#

Instead of embedding raw Flash commands in the NVRAM interface, the design should isolate device-specific operations.

A conceptual abstraction is:

    flashRead(address, buffer, length)

    flashProgram(address, buffer, length)

    flashEraseBlock(blockAddress)

    flashVerify(address, buffer, length)

These are design-level interface names, not standard VxWorks APIs.

The concrete implementations must use the supported BSP Flash driver and the appropriate NOR command set.

The abstraction simplifies testing and allows the storage algorithm to remain largely independent of the physical Flash device.

6.5 NOR Flash Write Constraints

#

A correct Flash driver must account for:

• Erase-block boundaries.
• Program granularity.
• Device command sequences.
• Write-buffer programming limits.
• Operation completion polling.
• Timeouts.
• Hardware write protection.
• Flash bus width.
• Read-back verification.

Programming into a non-erased location should not be assumed safe.

An implementation must verify that a proposed programming operation changes only bits that the device permits to transition.

6.6 Integrating the Driver into the BSP

#

The replacement interfaces should be compiled into the relevant VxWorks bootloader or BSP image.

A typical integration procedure includes:

1. Add the custom Flash-backed NVRAM source file to the BSP build.
2. Verify the NOR Flash driver is initialized before NVRAM access.
3. Ensure sysNvRamGet() and sysNvRamSet() are linked exactly once.
4. Remove or disable conflicting legacy implementations.
5. Review the relevant VxWorks configuration components.
6. Build the bootloader using Workbench.
7. Program and verify the resulting image.
8. Test both initial and repeated startup.

The original implementation requires INCLUDE_NV_RAM to remain undefined in its particular build configuration to avoid conflicts with the supplied NVRAM implementation.

That condition is BSP- and project-specific.

It should not be treated as a universal VxWorks configuration rule, because some builds require NVRAM-related components while allowing BSP-level customization of the underlying storage routines.

The key requirement is to ensure that the intended custom implementation is selected and that no duplicate symbols or incompatible initialization paths remain.

⚡ 7. Fast Boot Optimization and Performance Considerations

#

7.1 Eliminating Repeated Manual Configuration

#

The primary startup benefit is automatic reuse of stored parameters.

On the first boot, the system may require interactive configuration.

After a successful save, subsequent boots can restore the configuration without operator intervention.

The expected behavior is:

Automatic parameter restoration is particularly valuable for unattended switches and communication equipment.

7.2 Boot-Time Read Optimization

#

NOR Flash reads are generally much faster than erase operations.

For a memory-mapped Flash device, configuration records may be scanned directly after the hardware and memory mappings are initialized.

However, scanning an entire large Flash area is unnecessary.

The bootloader should limit its search to the reserved configuration sectors.

Further optimizations may include:

• Fixed-size records.
• Aligned metadata.
• Early rejection of invalid signatures.
• Bounded record scanning.
• Sequence-based record selection.
• Minimal copying.
• Avoiding dynamic memory allocation during early boot.

These techniques reduce bootloader complexity and make startup behavior more predictable.

7.3 Keep Erase Operations Out of the Normal Boot Path

#

The bootloader should not erase Flash during ordinary startup unless a recovery operation explicitly requires it.

Normal startup should consist primarily of:

1. Reading configuration metadata.
2. Validating the latest record.
3. Copying the boot line.
4. Continuing the boot sequence.

Flash erasure belongs primarily in configuration updates, block migration, or maintenance operations.

This separation helps prevent unpredictable erase latency from affecting normal boot time.

7.4 Understanding the Reported 2–5 Second Overhead

#

The original engineering report describes approximately 2–5 seconds of additional time associated with certain Flash searching or erase operations.

This value should not be interpreted as a universal NOR Flash read latency.

It may reflect implementation overhead, device-specific erase timing, or a particular test procedure.

Ordinary boot-line retrieval should not require erasing a Flash block.

A production implementation should separately measure:

• Flash initialization time.
• Configuration record scanning time.
• CRC validation time.
• Boot-line loading time.
• Flash programming time.
• Block erase time.
• Total power-on-to-application-ready time.

These measurements are necessary to determine whether the design satisfies its actual startup deadline.

🛡️ 8. Flash Reliability, Endurance, and Power-Loss Protection

#

8.1 NOR Flash Program/Erase Endurance

#

NOR Flash has a finite number of erase cycles per physical block.

The guaranteed endurance depends on the exact device and operating conditions.

A fixed-offset configuration update may require erasing a block for every change.

Sequential storage allows multiple configuration versions to be programmed before an erase becomes necessary.

If a block contains \(N\) usable records, then approximately \(N\) record updates can be accommodated per erase cycle under a simple append-only policy.

The resulting reduction in erase frequency can be substantial.

8.2 Example Endurance Model

#

Assume:

• 511 usable logical records per block.
• 100,000 supported erase cycles per block, purely as an illustrative endurance value.
• One configuration update per hour.

A simplified theoretical capacity is:

Therefore:

This is a theoretical record-programming count under the stated assumptions, not a predicted service life.

Actual lifetime depends on the device’s specified endurance, retention requirements, temperature, write distribution, block migration policy, and other failure mechanisms.

A two-block redundancy design may also introduce additional writes when maintaining a backup copy.

8.3 Detecting Invalid Flash Records

#

A robust record validation mechanism should check:

• Record signature.
• Format version.
• Payload length.
• Sequence number.
• CRC32 checksum.
• Commit marker.
• Boot-line syntax.

The validation flow is:

Read Candidate Record
        |
        v
Check Signature and Version
        |
        v
Validate Length
        |
        v
Check Commit Marker
        |
        v
Calculate CRC32
        |
        v
Compare Stored CRC
        |
        v
Validate Boot-Line Syntax
        |
        v
Accept or Reject Record

CRC32 helps detect accidental corruption but is not a cryptographic authentication mechanism.

If unauthorized Flash modification is part of the threat model, stronger integrity protection is required.

8.4 Handling Power Failure During Programming

#

Unexpected power loss may occur while:

• Writing the payload.
• Writing metadata.
• Programming the commit marker.
• Erasing a block.
• Migrating configuration to another block.

The storage design must ensure that at least one valid committed configuration remains available whenever possible.

An append-only record structure helps because the previous record does not need to be overwritten before the new record is committed.

Dual-sector migration further protects the configuration when implemented with correct operation ordering.

8.5 Handling Physical Flash Failures

#

NOR Flash devices can develop programming, erase, or retention failures.

The original design reports successful recovery when the primary block was forced into an invalid state.

For production use, fault handling should distinguish:

• A corrupted individual record.
• A failed programming operation.
• A failed block erase.
• A permanently unreadable region.
• A transient read error.
• An invalid but physically readable configuration.

Not every failure can be repaired by switching sectors.

If both reserved sectors are inaccessible, the system must use an appropriate recovery strategy.

For network-booted systems, this might involve falling back to a compiled default configuration and entering a maintenance mode.

🧪 9. Implementation Verification and Experimental Results

#

9.1 First-Boot Test

#

The first test begins with the reserved Flash configuration regions in an erased state.

Expected behavior:

1. Bootloader starts.
2. No committed configuration record is found.
3. Default parameters are loaded or manual configuration is requested.
4. The operator configures the boot line.
5. The new configuration is written to Flash.
6. The system continues startup.

The original implementation successfully supported initial manual configuration.

9.2 Persistent Configuration Test

#

After saving the boot parameters, the board is reset.

Expected behavior:

1. Bootloader initializes.
2. Flash-backed NVRAM interface is called.
3. The latest valid configuration is located.
4. Boot parameters are restored.
5. VxWorks proceeds without manual re-entry.

The reported tests confirmed successful parameter restoration after resets.

9.3 Sequential Write Test

#

Repeatedly update the boot parameters.

Verify that:

• New records are allocated sequentially.
• Previously committed records remain intact.
• The latest valid configuration is selected.
• Writes do not erase the block unnecessarily.
• Record alignment remains correct.

This test is essential for confirming the intended reduction in erase frequency.

9.4 Redundant Block Recovery Test

#

Simulate an invalid or unavailable primary configuration block.

Expected behavior:

1. Primary configuration validation fails.
2. Backup configuration is examined.
3. A valid backup record is selected.
4. Boot parameters are restored.
5. The system continues startup.

The original study reports successful switching to the backup region when the primary region was deliberately made invalid.

9.5 Power-Loss Fault-Injection Test

#

A production implementation should test power interruption during each critical Flash operation.

Recommended scenarios include:

• Power loss before programming begins.
• Power loss during payload programming.
• Power loss during metadata programming.
• Power loss before commit.
• Power loss during block migration.
• Power loss during old-block erasure.

The test should confirm that startup either recovers a previously committed configuration or enters a controlled recovery state.

These tests are recommended enhancements; the supplied source does not provide quantitative results for all power-interruption scenarios.

9.6 Test Summary

#

The original implementation reports functional success and reduced erase frequency on the prototype switch-board platform.

However, it does not provide precise boot-time distributions, erase counts, endurance-test duration, or detailed power-loss fault-injection statistics.

These values should be measured before making quantitative service-life or recovery-time guarantees.

🔍 10. Common Problems and Troubleshooting

#

10.1 Boot Parameters Are Lost After Reset

#

Possible causes:

• Incorrect Flash address.
• Programming failure.
• Invalid record selection.
• Configuration not committed.
• Unexpected erase operation.
• Wrong BSP NVRAM interface.

Recommended checks:

Verify the programmed Flash contents and confirm that the bootloader calls the intended sysNvRamGet() implementation.

10.2 Backup Configuration Is Also Erased

#

Possible cause:

Primary and backup addresses belong to the same physical erase unit.

Recommended solution:

Verify the actual Flash erase geometry and ensure the backup begins at an independently erasable block boundary.

For the reported 256 KB logical geometry, the corrected backup base is:

0xEFFC0000

not:

0xEFFB0000

10.3 sysNvRamSet() Returns ERROR

#

Possible causes:

• Invalid input length.
• Unsupported offset.
• Flash write protection.
• Programming timeout.
• Non-erased destination.
• Incorrect Flash driver commands.
• Verification failure.

Recommended solution:

Inspect the low-level NOR driver status and verify the device’s command sequence and programming constraints.

10.4 Flash Data Appears Corrupted

#

Possible causes:

• Interrupted programming.
• Incomplete record writes.
• Invalid metadata.
• Incorrect bus width.
• Memory mapping errors.
• Cache or synchronization problems.
• Overlapping Flash partitions.

Recommended solution:

Validate the record structure, device mapping, programming operations, and checksum calculations.

10.5 Duplicate Symbol Errors During Linking

#

Possible cause:

Both the original BSP NVRAM implementation and custom Flash-based implementation define:

    sysNvRamGet()
    sysNvRamSet()

Recommended solution:

Ensure that exactly one implementation of each interface is linked into the bootloader image.

Review component selection, source inclusion, and BSP build configuration.

10.6 Flash Erase Causes Excessive Startup Delay

#

Possible cause:

Flash erasure is being performed during normal boot initialization.

Recommended solution:

Move routine erase and block-rotation operations into configuration-update paths.

Ordinary startup should primarily read and validate existing records.

🚀 11. Applying the Design to Modern VxWorks Platforms

#

11.1 Differences Between Legacy and Modern VxWorks

#

The implementation described here targets a classic VxWorks 6.x environment using Workbench 3.1.

Modern VxWorks releases may have different:

• BSP organization.
• Bootloader implementations.
• Flash driver frameworks.
• Nonvolatile storage interfaces.
• Device-tree integration.
• VxBus components.
• Security mechanisms.

Therefore, the original source files and build configuration should not be copied unchanged into a modern VxWorks 7 project.

The persistent-storage algorithm can remain useful, but integration must follow the supported interfaces for the selected release.

11.2 Separating the Storage Algorithm from the BSP

#

A maintainable implementation should separate three layers.

Boot Configuration Layer

Responsible for boot-line parsing and default parameter selection.

Persistent Record Layer

Responsible for record validation, sequence tracking, redundancy, and recovery.

Flash Driver Layer

Responsible for physical read, program, erase, and hardware status operations.

The architecture is:

+-----------------------------------+
|       VxWorks Bootloader          |
|                                   |
| sysNvRamGet / sysNvRamSet         |
+-----------------+-----------------+
                  |
                  v
+-----------------------------------+
|       Persistent Record Layer     |
|                                   |
| Record Validation                 |
| Sequence Management               |
| Redundancy                        |
| Power-Loss Recovery               |
+-----------------+-----------------+
                  |
                  v
+-----------------------------------+
|          Flash Driver             |
|                                   |
| Read / Program / Erase            |
| Hardware Status                   |
+-----------------+-----------------+
                  |
                  v
+-----------------------------------+
|        Physical NOR Flash         |
+-----------------------------------+

This approach allows the same logical configuration scheme to be adapted to different storage devices.

11.3 Alternative Nonvolatile Storage Technologies

#

The same high-level approach can be adapted to:

• SPI NOR Flash.
• Parallel NOR Flash.
• NAND Flash with appropriate bad-block and ECC management.
• EEPROM.
• FRAM.
• eMMC or other managed Flash storage.

However, each technology has different write and erase semantics.

For example, EEPROM and FRAM generally support smaller write units, while NAND Flash requires additional bad-block management and error correction.

A robust design should use the storage device’s native programming model rather than assuming that all nonvolatile memories behave like NOR Flash.

11.4 Security and Configuration Integrity

#

Boot parameters can influence network connectivity, image loading, and startup behavior.

Consequently, persistent configuration should be treated as security-sensitive data.

Recommended controls include:

• Restricting unauthorized Flash writes.
• Validating configuration syntax and field lengths.
• Avoiding plaintext secrets where possible.
• Protecting boot-image paths and startup settings.
• Using cryptographic integrity checks when required.
• Maintaining a controlled recovery configuration.

CRC32 provides protection against accidental data corruption but does not prevent deliberate tampering.

Systems that require authenticated startup configuration should use a suitable message authentication code or digital signature mechanism supported by their security architecture.

✅ 12. Conclusion

#

Replacing dedicated NVRAM with a carefully managed NOR Flash region is a practical approach for VxWorks embedded systems that need persistent boot configuration but do not include separate nonvolatile RAM hardware.

The original implementation demonstrates that the standard VxWorks sysNvRamGet() and sysNvRamSet() interfaces can be implemented using reserved Flash storage without requiring major changes to the surrounding bootloader logic.

The proposed architecture combines two key techniques:

1. Sequential Record Storage: Boot parameters are written into successive Flash records, reducing repeated erase operations and improving endurance.

2. Dual-Sector Redundancy: Independently erasable primary and backup regions provide alternative configuration storage when one region becomes invalid.

The approach provides several practical benefits:

• Automatic restoration of boot parameters.
• Reduced dependence on manual boot configuration.
• Lower Flash erase frequency.
• Improved resilience to configuration corruption.
• Compatibility with classic VxWorks BSP interfaces.
• Reduced hardware complexity when NOR Flash is already available.

The source implementation was validated on a PowerPC-based embedded switch-board platform, demonstrating correct configuration read/write behavior and recovery from an invalid primary storage region.

For production deployments, additional safeguards are important.

These include correct erase-block alignment, CRC-based record validation, sequence tracking, power-loss-safe commit operations, verified block migration, and thorough fault-injection testing.

The central engineering principle is to treat NOR Flash configuration storage as a transactional, append-oriented persistent data system rather than as ordinary rewritable RAM.

By applying this principle, VxWorks developers can build reliable unattended startup mechanisms while reducing Flash wear and improving configuration availability.

The same architectural concepts remain useful for modern embedded systems that require persistent configuration, controlled recovery, and dependable startup behavior across power cycles.