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

Sun Feb 1 23:53:52 UTC 2015

On February 1, 2015 4:40:45 PM MST, Ben Gras <beng at shrike-systems.com> wrote:
>Dear all,
>
>I took a quick look at why the beagle bsp fails to link. It seems
>there is a multilib interaction I don't really understand that is
>causing the symbol to be missing. (The symbol appears in some library
>arch variants and not in others.) I'm not too familiar with how that
>works so I can't find a clean solution right now.

Building multilib is rather useless to most people. It builds the cpukit for every arm CPU variant GCC knows. In this case, the error is in a variant we don't have a BSP for. You only need one of the variants. More below.

Build rtems for a single BSP and drop the multilib option. For some BSPs, you might see an issue linking a dynamic loading test. I saw  it on the Pi last week but the other test ran.

>If possible in your scenario, rebuilding the beagle bsp without the
>multilib option should work as a workaround for now. You can run the
>code on a linaro qemu fork that implements the bbxm if you don't have
>the hw.
>
>Info on how to do that is at my blog post on the subject,
>
>http://www.shrike-systems.com/beagleboard-xm-beaglebone-black-and-everything-else-rtems-on-the-beagles.html

>Let me know if I can help there.
>
>
>On Sun, Feb 1, 2015 at 10:56 PM, Jonathan Brandmeyer
><jonathan.brandmeyer at gmail.com> wrote:
>> 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 rtems.org.
>>
>> 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

The rtems $prefix/bin should be at the head of your PATH. Especially when you bootstrap RTEMS.

>> 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.

There is a much faster replacement build system being worked on. We are trying to wrap up outstanding tickets and branch before switching.

>> 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.

Multilib issue I am sure. I build all bsps fairly regularly and the beagle builds without that option.

>> 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
>>
>'/home/jonathan/src/build_rtems_arm/arm-rtems4.11/c/stm32f4/testsuites/libtests/dl01'
>> 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
>> USER     TTY        LOGIN@   IDLE   JCPU   PCPU WHAT
>> ../../../../../../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.

You don't appear to have tar installed. Pax is the FOSS tar implementation. If you loom in the logs, there is probably a message about what it looked for.

>>
>> 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
>> armcortexa9"
>> $ 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
>> ./arm-rtems4.11/c/armcortexa9/testsuites/samples/ticker/ticker.exe
>> GNU gdb (GDB) 7.8.1
>> Copyright (C) 2014 Free Software Foundation, Inc.
>> License GPLv3+: GNU GPL version 3 or later
><http://gnu.org/licenses/gpl.html>
>> 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:
>> <http://www.gnu.org/software/gdb/bugs/>.
>> Find the GDB manual and other documentation resources online at:
>> <http://www.gnu.org/software/gdb/documentation/>.
>> For help, type "help".
>> Type "apropos word" to search for commands related to "word"...
>> Reading symbols from
>>
>./arm-rtems4.11/c/armcortexa9/testsuites/samples/ticker/ticker.exe...done.
>> (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:
>>
>/home/jonathan/src/build_rtems_arm/arm-rtems4.11/c/armcortexa9/testsuites/samples/ticker/ticker.exe
>> [Inferior 1 (process 42000) exited with code 0110]
>> (gdb) quit

The simulator in gdb does not support all the instructions for all the arm models. Not sure if this is the issue but with cortex seems likely from memory.

>> 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
>>
>./arm-rtems4.11/c/xilinx_zynq_a9_qemu/testsuites/samples/ticker/ticker.exe
>> 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.

Qemu is an interesting project which doesn't seem to merge patches in a timely manner. Very likely unless you use the RSB to build a qemu, you want get the needed patches. As Ben mentioned Linaro's qemu works for the Beagle. I think the rsb works for realview and zynq. Not sure for beagle.

>> 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.
>>
>> Sincerely,
>> Jonathan Brandmeyer
>> _______________________________________________
>> users mailing list
>> users at rtems.org
>> http://lists.rtems.org/mailman/listinfo/users
>_______________________________________________
>users mailing list
>users at rtems.org
>http://lists.rtems.org/mailman/listinfo/users

--joel