Fixing VxWorks ROM Image Size Exceeding 1MB on P2020

Fixing VxWorks ROM Image Size Exceeding 1MB on P2020

When building a VxWorks ROM image for a PowerPC platform such as the NXP P2020 RDB, the build can fail when the generated vxWorks_rom or vxWorks_romCompress image exceeds the BSP’s default 1 MB ROM allocation.

A typical failure looks like this:

D:/opt/WindRiver/windriver6.9.4.9_powerpc/vxworks-6.9/host/x86-win32/bin/romsize ppc -b 00100000 vxWorks_romCompress

vxWorks_romCompress: 15568(t) + 1061632(d) = 1077200 (28624 over)

Error: image is larger than 1048576 bytes!

make.exe[1]: *** [vxWorks_romCompress] Error 1

The important part is:

image is larger than 1048576 bytes!

The generated image is approximately 1.078 MB, while the build system has allocated only:

0x00100000 = 1,048,576 bytes = 1 MB

This is normally a ROM allocation/configuration issue rather than a compiler failure. The solution is to increase the ROM image size allocation so that it can accommodate the generated image.

🧭 Understanding VxWorks Image Types

#

Before changing the ROM allocation, it is important to distinguish the major VxWorks image formats involved in booting and development.

Loadable vxWorks Image

#

The standard vxWorks image is primarily intended for development environments.

A typical workflow is:

Host
  |
  | download
  v
Target RAM
  |
  v
VxWorks

The image is stored on a development host and downloaded into target RAM by the bootloader.

Symbol information is commonly maintained separately on the host through:

vxWorks.sym

This avoids unnecessarily increasing the target image size.

If the following option is enabled:

#define INCLUDE_STANDALONE_SYM_TBL

the symbol table can instead be embedded into the image, increasing its size.

vxWorks_rom and vxWorks_romCompress

#

A vxWorks_rom image is designed to be stored in ROM or flash and then copied into RAM during boot.

The basic execution flow is:

ROM / Flash
     |
     | copy image
     v
   RAM
     |
     | execute
     v
  VxWorks

Because the image is copied to RAM before execution, it can execute from relatively fast RAM rather than directly from slower nonvolatile storage.

The uncompressed form is:

vxWorks_rom

The compressed variant is:

vxWorks_romCompress

The compressed form reduces the amount of nonvolatile storage required, although the boot process must decompress the image before normal execution.

vxWorks_romResident

#

A ROM-resident image uses a different execution model.

Instead of copying the entire code image into RAM, the system keeps the code in ROM while copying the required writable data into RAM.

Conceptually:

ROM / Flash
+----------------------+
| VxWorks code         | ---> CPU executes from ROM
+----------------------+

RAM
+----------------------+
| Data / writable area |
+----------------------+

This can reduce RAM requirements and provide a fast boot path, but execution performance depends on the access characteristics of the ROM or flash device.

⚠️ Why the 1 MB Build Fails

#

The VxWorks build system checks the generated ROM image against the configured ROM allocation.

In the example:

ROM_SIZE = 0x00100000

which corresponds to:

1,048,576 bytes

However, the generated image requires:

1,077,200 bytes

The difference is:

1,077,200 - 1,048,576 = 28,624 bytes

The build system therefore reports:

28624 over

The failure is generated by the romsize utility:

romsize ppc -b 00100000 vxWorks_romCompress

The -b 00100000 argument represents the configured image-size boundary.

The build will succeed only when the generated image fits within that allocation.

🔧 Increase ROM_SIZE in the BSP

#

One solution is to modify the BSP configuration directly.

Locate the BSP’s:

config.h
Makefile

and search for the ROM size definition.

If the BSP currently uses:

0x00100000

increase it to an allocation that comfortably accommodates the image.

For example:

0x00200000

allocates:

2 MB

The important principle is not to increase the value merely by the exact number of bytes currently missing. Leave sufficient headroom for future configuration changes, additional drivers, networking components, debugging facilities, and symbol information.

For example:

Old:
ROM_SIZE = 0x00100000

New:
ROM_SIZE = 0x00200000

The exact syntax depends on how the BSP exposes ROM_SIZE.

Rebuild After Changing the BSP

#

After modifying the BSP configuration, perform a clean rebuild:

make clean
make

or rebuild the relevant VxWorks image project through Wind River Workbench.

The objective is to ensure that the new ROM allocation is propagated into the image-generation step.

🛠️ Change ROM_SIZE in Wind River Workbench

#

If the project is managed through Wind River Workbench, the ROM allocation can instead be changed through the image project’s build properties.

Open the VxWorks Image Project and navigate to:

Project
  -> Properties
      -> Build Properties

Locate the macro or build setting associated with:

ROM_SIZE

Increase the value to an appropriate size.

For example:

ROM_SIZE = 0x00200000

Then clean and rebuild the image.

This approach is preferable when the image project maintains build configuration independently from the original BSP source.

📐 Choosing an Appropriate ROM Size

#

The ROM allocation should be larger than the complete generated image, not merely larger than the text segment.

The build output provides the information required to estimate the required space:

vxWorks_romCompress: 15568(t) + 1061632(d) = 1077200

Here:

text segment = 15,568 bytes
data segment = 1,061,632 bytes
total        = 1,077,200 bytes

A 1 MB allocation is insufficient:

1,077,200 > 1,048,576

A 2 MB allocation provides considerably more room:

2,097,152 > 1,077,200

This also provides approximately 1 MB of additional capacity for future image growth.

However, ROM_SIZE must ultimately reflect the actual physical flash layout. Increasing a software macro does not create additional flash capacity.

Before selecting a larger value, verify:

• NOR or SPI flash capacity.
• Bootloader location.
• VxWorks image location.
• Flash sector boundaries.
• Environment/configuration storage.
• Firmware partitions.
• Reserved hardware regions.
• Board-specific memory mapping.

💡 ROM_SIZE Does Not Increase Physical Flash

#

A critical distinction is that:

ROM_SIZE

is a build-time allocation.

It does not physically enlarge the target’s flash device.

For example, changing:

ROM_SIZE = 0x00100000

to:

ROM_SIZE = 0x00200000

tells the build system that a 2 MB image region is available.

It does not guarantee that 2 MB of flash is actually available.

The physical memory layout must therefore support the new allocation.

A safe configuration should satisfy:

Image size
    <
Available flash region

and, preferably:

Image size + growth margin
    <
Available flash region

🧪 Verify the Generated Image

#

After rebuilding, check the romsize output again.

The previous failure:

vxWorks_romCompress: 15568(t) + 1061632(d) = 1077200 (28624 over)
Error: image is larger than 1048576 bytes!

should disappear when the configured allocation is sufficiently large.

For example, if the build uses:

-b 00200000

the maximum allocated image size becomes:

2,097,152 bytes

which is sufficient for the example 1,077,200-byte image.

Do not rely solely on the successful build. Also verify that the generated image fits within the target’s actual flash partition and bootloader layout.

📦 Flashing vxWorks_rom

#

Once the ROM image has been successfully generated, it can be programmed into the target’s nonvolatile storage.

For a P2020 RDB, a hardware debugging/programming interface such as CodeWarrior TAP can be used to program the image.

The general workflow is:

Build VxWorks ROM image
          |
          v
Verify image size
          |
          v
Verify flash address/layout
          |
          v
Program NOR/SPI Flash
          |
          v
Reset target
          |
          v
Boot ROM initializes
          |
          v
VxWorks ROM image starts

The exact programming procedure depends on the flash device, board configuration, debugger, and bootloader implementation.

📄 Flashing an ELF Image

#

When downloading an ELF-format image directly to flash, the ELF file already contains segment and address information.

Consequently, you generally do not need to manually invent an application offset merely to compensate for the ELF’s internal layout.

The programmer/debugger can use the ELF program headers and section mappings to determine where the relevant segments belong.

This is different from treating a raw binary image as an opaque byte stream, where the programmer typically requires an explicit destination address.

The exact behavior still depends on the programming tool and target configuration, so verify how the selected CodeWarrior or flash-programming workflow handles ELF images.

🔍 Troubleshooting Checklist

#

If vxWorks_romCompress continues to fail after changing ROM_SIZE, check the following.

Confirm the New ROM Size Is Actually Used

#

Inspect the build command and look for the romsize invocation:

romsize ppc -b 00200000 vxWorks_romCompress

If it still shows:

-b 00100000

the modified setting has not reached the image build.

Check both the BSP and image-project build properties for conflicting definitions.

Perform a Clean Build

#

Configuration changes can be hidden by stale generated files.

Use:

make clean
make

or perform the equivalent clean operation in Workbench before rebuilding the image.

Check for Multiple ROM_SIZE Definitions

#

Legacy VxWorks projects can obtain configuration values from multiple locations.

Search the BSP and project configuration for:

ROM_SIZE

and identify which definition ultimately controls the romsize command.

Verify the Flash Layout

#

If the image now builds successfully but fails to boot after programming, do not assume that the image itself is invalid.

Verify:

Bootloader address
ROM image address
ROM image size
Flash sector boundaries
Reserved flash regions
Reset vector
RAM load address

A software build can succeed while the physical flash layout remains incompatible.

Check Image Growth

#

If the image barely fits, consider why it became larger.

Common contributors include:

• Additional device drivers.
• Networking components.
• Filesystem support.
• Debugging facilities.
• Shell functionality.
• Symbol tables.
• Additional protocol stacks.
• Application modules.
• Logging infrastructure.

For example, embedding a standalone symbol table:

#define INCLUDE_STANDALONE_SYM_TBL

can significantly increase the image footprint compared with maintaining symbols externally.

📊 Image Type Comparison

#

The appropriate image type depends on the boot-time requirements, available flash, RAM capacity, execution performance, and development workflow.

🧠 Key Takeaways

#

The error:

Error: image is larger than 1048576 bytes!

means that the generated ROM image exceeds the build system’s configured 1 MB ROM allocation.

For a P2020 BSP, the typical resolution is:

1. Determine the actual generated image size.
2. Locate the ROM_SIZE configuration.
3. Increase it to a suitable value, such as:

   0x00200000
   

4. Ensure the physical flash layout can accommodate that allocation.
5. Clean and rebuild the VxWorks image.
6. Confirm that the romsize command uses the new boundary.
7. Program the resulting image using the appropriate hardware tool.
8. Verify the target’s bootloader and flash address configuration.

The most important distinction is between build-time allocation and physical memory capacity. Increasing ROM_SIZE solves the build-time size check, but the target hardware must still provide enough usable NOR/SPI flash space for the resulting image.

For legacy P2020/VxWorks systems, treating the BSP, image-project properties, bootloader, and physical flash map as one integrated configuration is essential. A successful compilation is only the first step; the generated image must also fit the actual nonvolatile memory layout and boot architecture.