ARM Getting Started Assistance: Beagleboard, Zedboard, or STM32F4Discovery?

Jonathan Brandmeyer jonathan.brandmeyer at
Sun Feb 1 21:56:57 UTC 2015

I've been doing embedded programming on "proprietary" small RTOS like
FreeRTOS, ChibiOS, and DSP/BIOS for about a decade, as well as POSIX
programming on Linux systems.  I'm interested in using RTEMS as a
full-featured POSIX RTOS, to see if it is a portable alternative to
the other proprietary RTOS out there.  Unfortunately, all of my
attempts to get started using the standard documentation have failed
miserably.  If anyone has successfully gotten any of these BSP's to
actually work, it would be very helpful.

My host OS is Debian Testing, on x86_64.  Source code was checked out
of git from the mainline sources on

I've successfully built a toolchain using the rtems-source-builder,
according to its instructions, with no obvious errors:

$ ./source-builder/sb-check
$ cd rtems && ../source-builder/sb-set-builder 4.11/rtems-arm.bset
--prefix=$HOME/Programs/rtems_4_11 --log=rtems-user-log.txt

Recent builds of GCC, the autotools and other standard programs all
get successfully installed to my designated --prefix.

Next I attempt to build RTEMS for the arm target, and things start to fail.

$ export PATH=$HOME/Programs/rtems_4_11:$PATH
$ cd rtems-git && ./bootstrap && cd ../
$ mkdir build_rtems_arm && cd build_rtems_arm
$ ../rtems-git/configure --target=arm-rtems4.11
--prefix=$HOME/Programs/rtems_4_11 --enable-posix --enable-networking
--enable-cxx --enable-tests --enable-multilib
--enable-rtemsbsp="stm32f4 beagleboneblack xilinx_zynq_a9_qemu
xilinx_zynq_zedboard armcortexa9"
$ make -j8 all

I've picked the stm32f4 and xilinx BSP's because I actually own those.
Well, I own a microzed, but I'm hoping that I can port the zedboard
BSP to the microzed without too much difficulty.  Failing that, the
armcortexa9 target should support some level of generic qemu.  I hope.

In the "wishlist" category, it would be nice if the recursive
Makefiles were written to use the make jobserver for parallel process
control.  As it stands, the build is almost entirely serial.  A little
inconvenient, but not fatal.

The first thing that goes seriously wrong, is that the beagleboneblack
bsp doesn't link.  All of its example programs fail to link due to the
missing symbol _CPU_Thread_Idle_body.

The next thing to go wrong is that some of the test programs (other
than examples themselves) on the stm32f4 and xilinx targets fail to
build.  Each of these Makefiles have a set of steps like this:

$(PAX) = # empty assignment
sometarget: someprereqs
    $(PAX) -w -f $@ $<

I don't know what program $(PAX) is supposed to be referencing, but
since it is an empty variable, the program w(1) gets executed instead.
Instead of creating a tar file from a .o file, it describes the
current machine load to the console, producing an error sequence like:
make[6]: Entering directory
w -f dl.tar dl-o1.o
 21:59:30 up 31 days, 11:10,  3 users,  load average: 1.83, 2.49, 2.08
../../../../../../tools/build/rtems-bin2c -C dl.tar dl-tar.c
../../../../../../tools/build/rtems-bin2c -H dl.tar dl-tar.h
cannot open dl.tar for reading
Makefile:645: recipe for target 'dl-tar.c' failed
make[6]: *** [dl-tar.c] Error 1
make[6]: *** Waiting for unfinished jobs....
# trimmed: Make continues to unwind its recursive invocations.

OK, so I cut out the beaglebone bsp, and reduce the testsuite down to
demonstration samples (starting from a fresh build directory):
$ ../rtems-git/configure --target=arm-rtems4.11
--prefix=$HOME/Programs/rtems_4_11 --enable-posix --enable-networking
--enable-cxx --enable-tests=samples --enable-multilib
--enable-rtemsbsp="stm32f4 xilinx_zynq_a9_qemu xilinx_zynq_zedboard
$ make -j8 all
$ make install

This build at least completes.  However, the sample test programs
don't run.  Using the armcortexa9 bsp:

jonathan at pheonix:~/src/build_rtems_arm$ arm-rtems4.11-gdb
GNU gdb (GDB) 7.8.1
Copyright (C) 2014 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "--host=x86_64-linux-gnu --target=arm-rtems4.11".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
Find the GDB manual and other documentation resources online at:
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from
(gdb) target sim
Connected to the simulator.
(gdb) load
Loading section .start, size 0x1e4 vma 0x0
Loading section .text, size 0x14eb0 vma 0x1e4
Loading section .init, size 0x18 vma 0x15094
Loading section .fini, size 0x18 vma 0x150ac
Loading section .rodata, size 0x1150 vma 0x150c4
Loading section .ARM.exidx, size 0x8 vma 0x16214
Loading section .eh_frame, size 0x48 vma 0x1621c
Loading section .init_array, size 0x4 vma 0x16264
Loading section .fini_array, size 0x4 vma 0x16268
Loading section .jcr, size 0x4 vma 0x1626c
Loading section .data, size 0x5c0 vma 0x166b0
Start address 0x40
Transfer rate: 737664 bits in <1 sec.
(gdb) run
Starting program:
[Inferior 1 (process 42000) exited with code 0110]
(gdb) quit

Similar (same?) problem with qemu on the xilinx_zynq_a9_qemu bsp:

jonathan at pheonix:~/src/build_rtems_arm$ qemu-system-arm -S -s
-no-reboot -serial mon:stdio -serial /dev/null -net none -nographic -M
xilinx-zynq-a9 -m 256M  -kernel
Warning: nic cadence_gem.0 has no peer
Warning: nic cadence_gem.1 has no peer

The nic warnings should be harmless since I've specified explicitly
disabling the network interface.  Nevertheless, QEMU just halts here
with no output whatsoever.  It must be killed externally.  In this
case, qemu-system-arm is v2.1+dfsg-11 as packaged by the Debian
project.  A fresh build of qemu directly from their Git repository has
the same result.

So yeah.  I would appreciate any help in getting these targets to
build.  I understand that I'm working with the development repository,
and some measure of breakage and instability is to be expected.  It
also seems that my most preferred target (the Zynq) has the steepest
hill to climb according to the mailing list archives.  But since the
BSP's that I want to use are only present in the 4.11 development
series, here I am.

Jonathan Brandmeyer

More information about the users mailing list