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.
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=10.4.0.0/24,hostfwd=tcp::9000-:9000 \ -device virtio-net-device,netdev=mynet -device virtio-serial-device \ -chardev socket,id=vio,host=0.0.0.0,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
-M option selects a generic ARMv7
virtual machine emulation. The
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.
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=10.4.0.0/24,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
10.4.0.0/24, 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
-device virtio-serial-device -chardev socket,id=vio,host=0.0.0.0,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:
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-ARGS QEMU qemu-system-arm CMD -M virt -m 32 -nographic -s -kernel redboot.elf -netdev user,id=mynet,net=10.4.0.0/24, hostfwd=tcp::9000-:9000 -device virtio-net-device,netdev=mynet -device virtio-serial-device -chardev socket,id=vio,host=0.0.0.0,port=4322,server,telnet,nowait -device virtserialport, chardev=vio Ctrl-A X to exit Ctrl-A C for qemu monitor +Ethernet eth0: MAC address 52:54:00:12:34:56 IP: 10.4.0.15/255.255.255.0, Gateway: 10.4.0.2 Default server: 10.4.0.2 DNS server IP: 10.4.0.3, 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 www.ecoscentric.com 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] 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.bin. Either of these files can
now be used to start RedBoot.
|2023-08-15||eCosPro Non-Commercial Public License|