Setup — Preparing for eCos Development


In a typical development environment, the VM boots into the RedBoot ROM monitor. eCos applications are configured for RAM startup and then downloaded and run on the board via the debugger arm-eabi-gdb. Preparing the VM therefore usually involves arranging for a suitable RedBoot image to be executed on startup.

QEMU Installation

This section describes how to run eCos under QEMU. The reader should be familiar with QEMU, how to install it onto their host and how to invoke it. The examples in this section describe running QEMU under Linux. This has been tested using QEMU version 4.2.0.

eCos applications can be run under QEMU either directly or by first loading RedBoot and then using that to load and execute the application. In both cases it is necessary to configure QEMU to emulate a virtual machine that matches the target for which eCos has been compiled. A typical QEMU invocation is shown below.

qemu-system-arm -M virt -m 32 -nographic -s -smp cpus=8 -kernel app \
          -netdev user,id=mynet,net=,hostfwd=tcp::9000-:9000 \
          -device virtio-net-device,netdev=mynet -device virtio-serial-device \
          -chardev socket,id=vio,host=,port=4322,server,telnet,nowait \
          -device virtserialport,chardev=vio

This will run an eCos application in an Aarch32 virtual machine with the main serial port routed to standard IO. Breaking that command line down into its components:

-M virt -m 32 -nographic -s -smp cpus=8

The -M option selects a generic ARMv7 virtual machine emulation. The -m option sets the main RAM size to 32MiB. The -nographic suppresses use of a graphical interface, confining QEMU to a command line interface. The -s option enables the GDB server. The -smp cpus=8 option instantiates eight CPUs. Initially only CPU0 is running and will run non-SMP builds. If eCos is built to use more CPUs, then it will enable the additional CPUs when the scheduler starts. By default eCos is configured to use four CPUs.

-kernel app

This specifies the application to load. The application may be either an ELF executable or a binary file. Only applications built using the ROM startup type should be used here. This application executable should be RedBoot if it is intended to run RAM startup application via GDB.

-netdev user,id=mynet,net=,hostfwd=tcp::9000-:9000
-device virtio-net-device,netdev=mynet

These options set up the networking interface. In this case we are using QEMU's user networking support, which avoids the need to set up additional interfaces on the host and does not need privileged access. This option runs the virtual machine in a private subnet, in this case, which should be chosen so as not to clash with the existing network. The hostfwd option maps the host's TCP port 9000 to the virtual machine's port 9000; which is RedBoot's telnet/GDB port. Additional port mappings may be added if necessary.

-device virtio-serial-device
-chardev socket,id=vio,host=,port=4322,server,telnet,nowait
-device virtserialport,chardev=vio

These options map the virtual machine's second serial port on to a telnet server on local port 4322.

The above command line uses standard IO for the main console. An alternative would be to attach the console to a Telnet socket. The following additional options will do this:

-serial tcp:,server,telnet,nowait

Use of telnet here provides support for the RedBoot command line interface. However, if the intention is to use GDB to load and run applications via the console, then the telnet option should be omitted since the telnet protocol does not interact well with the GDB protocol. The same consideration applies to the arguments for the second serial line given earlier.

For simplicity, a shell script, ecos_qemu, is available in the etc directory of the RedBoot install directory which runs an eCos application using the options above. It is recommended that this script and the executable to be run are copied out to a working directory. This script may be edited to adjust the arguments if a different configuration is needed. Running RedBoot using the script under Linux, will look something like this:

$ ./ecos_qemu redboot.elf
APP       redboot.elf
QEMU      qemu-system-arm
CMD       -M virt -m 32 -nographic -s -kernel redboot.elf -netdev user,id=mynet,net=,
hostfwd=tcp::9000-:9000 -device virtio-net-device,netdev=mynet -device virtio-serial-device
-chardev socket,id=vio,host=,port=4322,server,telnet,nowait -device virtserialport,

Ctrl-A X to exit
Ctrl-A C for qemu monitor

+Ethernet eth0: MAC address 52:54:00:12:34:56
IP:, Gateway:
Default server:
DNS server IP:, DNS domain name: <null%gt;

RedBoot(tm) bootstrap and debug environment [ROM]
Non-certified release, version UNKNOWN - built 14:28:56, May 26 2020

Copyright (C) 2000-2009 Free Software Foundation, Inc.
Copyright (C) 2003-2019 eCosCentric Limited
The RedBoot bootloader is a component of the eCos real-time operating system.
Want to know more? Visit for everything eCos & RedBoot related.
This is free software, covered by the eCosPro Non-Commercial Public License
and eCos Public License. You are welcome to change it and/or distribute copies
of it under certain conditions. Under the license terms, RedBoot's source code
and full license terms must have been made available to you.
Redboot comes with ABSOLUTELY NO WARRANTY.

Platform: Virtual ARM (CORTEX-A)
RAM: 0x40000000-0x42000000 [0x40458000-0x42000000 available]

Rebuilding RedBoot

Typical users should never need to rebuild RedBoot. If you do intend to modify RedBoot then please note that rebuilding it is currently only supported from the Linux command line.

The steps needed to rebuild the ROM version of RedBoot are:

$ mkdir redboot_qemu_rom
$ cd redboot_qemu_rom
$ ecosconfig new virtual_qemu redboot
$ ecosconfig import $ECOS_REPOSITORY/hal/arm/cortexa/virrual/VERSION/misc/redboot_ROM.ecm
$ ecosconfig resolve
$ ecosconfig tree
$ make

At the end of the build the install/bin subdirectory should contain the files redboot.elf and redboot.bin. Either of these files can now be used to start RedBoot.