 Overview › Requirements › Proof of Principal › Issues … › First Step – Wrap Altera NIOS2 GNU Tools › Next Step – Build RTEMS/NIOS GNU Tools › Future Plans

 Requirements for EPICS IOCs, LANSCE RF system upgrade › Must be deterministically synchronized with the timing system  Binding of captured waveforms with beam flavor attributes obtained from the timing system  Modal behavior changes of low level RF controls depending on the flavor of beam › Must move captured waveforms from FPGA, into the IOC, and out to Ethernet

 Traditional VME/cPCI backplanes › Now they are becoming a bottleneck  There are Altera IP cores for › System processor › Ethernet interface  Can we distribute the solution? › One IOC on each cPCI RF board › Stream data directly, FPGA to Ethernet  A proof of principal is needed

 Third party FPGA intellectual property libraries for ARM, MIPS, etc › Are well supported by the GNU tools › However, use of these IP modules involves licensing expense  Which our RF group prefers to avoid

 Hardware › Altera NIOS Embedded Evaluation Kit  NIOS II Reference Platform on FPGA  Software › GNU Cross Development Tools › RTEMS OS › EPICS IOC

 Altera does › Provide source code for their nios2 enhancements to binutils / gcc/newlib › Modern version now available  FSF binutils 2.20 for nios2  FSF gcc 4.1 for nios2  FSF newlib 1.16 for nios2  Altera doesn't feed back their nios2 enhancements into the asynchronous FSF releases of binutils / gcc/newlib

 RTEMS does feed their enhancements back into the asynchronous FSF releases of binutils / gcc/newlib  RTEMS does depend on these enhancements › RTEMS 4.10 appears to require a recent release of gnu gcc and newlib

 RTEMS doesn’t supply it’s nios2 support files in any production release, but › These files can be obtained by fetching the main development trunk out of CVS  In summary, bringing all of the players together can be somewhat complicated …

 Various components independently maintained but working closely together › Binutils  Loader, assembler, and others … › Newlib  C runtime library for embedded systems › GCC  We use …  C and C++ compilers  Proper runtime support for C++ is essential  Various support libraries

 I tried the instructions available at › Create wrapper script for altera-built gnu cross compiler binaries › Build newlib, and then rtems  Very helpful tutorials at this site › See details about creating rtems bsp using output from Altera’s nios2-bsp tool  Unfortunately, some insurmountable issues with this specific approach › The Altera built gnu cross compiler…  Configured with –disable-threads  Compiler’s c++ runtime isn't using rtems primitives for synchronization

 Altera enhanced sources for binutils / gcc/newlib are available  Perhaps we can configure and build them specifically for RTEMS › Configuring RTEMS thread model › Configuring RTEMS BSP startup libraries to be implicitly linked in

 RTEMS main trunk is currently incompatible with newlib 1.16  Two options 1. Back annotate rtems nios2 support files from main trunk into earlier RTEMS release compatible with Altera’s newlib Forward annotate newlib nios2 support files from Altera modified FSF newlib 1.16 to FSF newlib 1.18  Currently I am concentrating on 2, but expect to eventually use a combination of 1 and 2 in production systems

 Typical steps when installing a GNU package from source › Obtain source › Patch source › Run autoconf in the source › Configure the source › Build the package › Install the package

 “cat../gcc rtems diff | patch -p1”  “find. -name "*.rej" –print”  Sometimes we have to fix by hand what is found in *.rej

 Need autoconf and automake › Always run first autoreconf in source tree if patches apply to *.am, *.ac, *.in, … › Maybe running autoconf isn't enough › Different packages need different versions of these tools › Sometimes the exact same version is needed › Sometimes the same or newer version is needed? › Different components have different requirements

 Need gnu libgmp, libppl, libelf…   But in practice, the uninitiated may iterate a few times as follows…  Run gnu “configure”  Look in config.log for “error”  If there are errors install missing packages  Run configure again …

 Altera Nios enhanced FSF source code › ftp://ftp.altera.com/outgoing/download/sup port/ip/processors/nios2/gnu/ › I used nios2_gnu_gcc4_11.0.tgz  Apply RTEMS patches › ftp://ftp.rtems.com/pub/rtems/SOURCES/4.10/ › ftp://ftp.rtems.com/pub/rtems/SOURCES/4.7

 Added gcc/config/nios2/rtems.h  Added gcc/config/nios2/t-rtems  Added new case in gcc/config.gcc  Added symbolic link to gcc/newlib

 › Altera’s newlib 1.16  Incompatible with RTEMS  Transplanting NIOS2 specific code from Altera’s Newlib 1.16 wasn't too daunting › Applied RTEMS 4.10 patches  Patch file “newlib rtems ” › Some RTEMS modifications for nios2

 Modified › newlib/include/machine/setjmp.h › newlib/libc/sys/rtems/machine/_types.h › newlib/libc/sys/rtems/crt0.c

 Run autoconf in gcc source tree  “mkdir b-gcc”  “cd b-gcc”  Run configure../gcc/altera-gcc-4.1-patched/configure --target=nios2-rtems --enable-threads --with-gnu-as --with-gnu-ld --with-newlib --verbose --disable-libstdcxx-pch --enable-multilib --enable-languages="c,c++" --prefix=$(INSTALL_RTEMS)  “make all” followed by “make install”

 I used RTEMS › But, nios2 support isn't included in any public rtems release › I obtained from anonymous CVS  In the cvs trunk, nios2 support is bundled

 “mkdir b-rtems”  “cd b-rtems” ../rtems-4.11-/rtems/configure --target=nios2-rtems --enable-posix --enable-networking --enable-rtbg --enable-cxx --disable-tests --enable-rtemsbsp=neek --prefix=$(INSTALL_RTEMS)

 The g++ appears to expect c++ header are in a different location than where they are actually installed.  Still working in this issue  Have booted RTEMS on NIOS, but not with C++ code.

 Altera Triple-Speed-Ethernet driver › Port Linux Ethernet driver to RTEMS  Regression Tests  Performance tests

   /xgcc.html