Dec 23, 2014

Zedboard for data center SW/HW development

In my previous blog entries (this and this), I started to explore using Zedboard as a instrument controller platform.  Zedboard is also a fine option for early stage prototype for an ARM server running special applications with custom FPGA logic within a data center.  To be sure, data centers are currently overwhelmingly filled with x64, and I explored how to integrate custom data processing HW into an x64 server with a PCIe slot in a blog entry a few years ago.  Zedboard does NOT have a PCIe slot (Avnet MiniITX does have a PCIe Gen2 x4) but NOT having to deal with PCIe when debugging the FPGA logic is actually productivity booster!  Once the logic is proven, I can use Xillybus to cross the PCIe barrier.  So in this article, I explore using Buildroot to run a minimal Linux distribution and a few data-center-ish applications on Zedboard (rev c).

Modify Buildroot config

  • Toolchain
    • C library: glibc 2.19, because data center applications will expect glibc for the most part, and Ubuntu 14.04 LTS (which most data center applications WILL support) is on glibc 2.19 (run "ldd --version" to check).
    • binutils 2.24 (Ubuntu 14.04 LTS is on 2.24, according to this)
    • gcc 4.8.x
    • Build cross gdb for the host: gdb 7.7.x (check "gdb -v" on the host)
    • Register toolchain without Eclipse Buildroot plugin, because I want the Buildroot Eclipse CDT integration.
  • System configuration
    • /dev management: Dynamic using eudev (servers run udev, and this is the closest thing Buildroot offers)
    • Unchecked "Install timezone info"
  • Target packages
    • Debugging, profiling, and benchmarking
      • gdb: just the gdbserver
      • oprofile
      • trace-cmd
      • NO valgrind: valgrind is slow even on the host; on a slow target like on Zynq, it will probably be too slow
    • Graphic libraries and applications: turn off everything
    • Libraries
      • Graphics: turn off everything
      • Hardware handling: turn off everything
      • JSON/XML: turn off everything
    • Networking
      • Uncheck dropbear (does not support FTP) and check openssh

Build the Buildroot and change rootfs as necessary to work around buildroot bugs

See my previous blog entry.  Also, setup Buildroot eclipse integration by first installing eclipse CDT

sudo apt-get install eclipse eclipes-cdt

Do NOT run above command, because Ubuntu eclipes package is severely down-revved for this reason, which is a problem because Buildroot integration does not seem to install on Juno (Eclipse 3.8).  So instead, install maven first, and then download the latest Eclipse for C/C++ from here, and then unzip to your home directory, so that you can ~/eclipse/eclipse

Now for the Buildroot integration: according to this this recipe, Buildroot Eclipse 3.x integration should point http://buildroot.org/downloads/eclipse/luna.  I thought I should try to keep the different Buildroot folders (for ARM vs. x86 for example) separate by putting the Eclipse workspace/ folder within the ~/work/zed folder, but as you can see below, the Buildroot Eclipse plugin discovers all Buildroot roots anyway (how??):

Boot the target

See this and this.

Write userspace applications running on Buildroot

See this blog entry.

Debug userspace application from Eclipse CDT

Eclipse CDT can debug userspace application project over ssh connection.  It can also do that through other dstore and supposedly that is easier, but Buildroot out of the box does not support dstore, so it's just easier to do it through ssh.  A new connection can be created in "Remote System Explorer" perspective.  Here, I chose the ssh connection kind, which works through sftp (to upload files) and the ssh shell, as you can see here:
I am using the root user for ease of development.  Every time I create a new rootfs, I will have to keep deleting ~/.ssh/known_hosts, but it's not THAT annoying.  Once I establish that I can upload files to /root folder, I can define a new debug configuration.

Setup a remote connection

The Buildroot CDT integration already added a configuration template that uses the correct cross-debugger.  The important thing is to specify the correct connection, and where to put the executable, as you can see below.

When I start the debug session, Buildroot will upload the debug executable to the designated location through sftp, and then start gdbserver (gdbserver :2345 /root/ocm) on the target through the ssh shell, and then make a TCP connection through ssh to gdbserver.
Posted by at