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

Sun Feb 1 23:40:45 UTC 2015

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.

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