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 http://www.nios2rtems.com/› 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 options1. Back annotate rtems nios2 support files from
main trunk into earlier RTEMS release compatible with Altera’s newlib 1.16
2. 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-4.3.2-rtems4.10-20080917.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… http://gcc.gnu.org/install/
prerequisites.html 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/
support/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
http://sourceware.org/newlib/› Altera’s newlib 1.16
Incompatible with RTEMS 4.11- Transplanting NIOS2 specific code from
Altera’s Newlib 1.16 wasn't too daunting
› Applied RTEMS 4.10 patches Patch file “newlib-1.18.0-rtems4.10-
20110518”
› 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 4.11-› But, nios2 support isn't included in any
public rtems release› I obtained 4.11- 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
http://www.nios2rtems.com http://www.alterawiki.com/wiki/CrossGcc http://www.ifp.illinois.edu/~nakazato/
tips/xgcc.html