Running newlib programs using libgloss on or32 platforms

If you have an OpenRISC platform and want to run programs which require a libc on it without the overhead/complexity of a full operating system then this page is for you. Provided here should be enough to get a reasonably confident Linux/Cygwin user going with my port of libgloss (low-level I/O part of newlib) to the or32 platform. This basically provides enough infrastructure to start executing a C program on an or32 platform and perform simple text I/O via the Opencores UART commonly used with OpenRISC designs. The advantage of using newlib is that many standard C functions including printf (to the UART), malloc/free, string functions and math functions should all be available.

For more details on newlib, please visit http://sources.redhat.com/newlib/.

Please also note that everything on this page is provided as-is without any kind of warranty. I hope what's here useful, however use it at your own risk!

Approximate instructions

• Download newlib version 1.13.0.

wget ftp://sources.redhat.com/pub/newlib/newlib-1.13.0.tar.gz
tar xzvf newlib-1.13.0.tar.gz


• Patch newlib with or32 patch.

cd newlib-1.13.0
wget http://www.doc.ic.ac.uk/~jab00/or32-newlib/newlib-patch
patch -p0 < newlib-patch
chmod +x libgloss/or32/configure
cd ..


• Customise libgloss to your specific or32 platform.

Particularly you might need to:

• Set IN_CLK to the speed in Hz of your design in newlib-1.13.0/libgloss/or32/board.h. This is needed for the UART to work.
• Modify the newlib-1.13.0/libgloss/or32/or32.ld linker script to suit your RAM configuration. You will probably need to adjust the 'ram' MEMORY section, and alter the stack symbols to point to the top of memory.
• Add any platform specific hardware initialisation code that must be executed before main() in your program to newlib-1.13.0/libgloss/or32/crt0.S (see the Todo list below).
• Checkout or1k toolchain from CVS.

cvs -d :pserver:anonymous@cvs.opencores.org:/cvsroot/anonymous login
cvs -d :pserver:anonymous@cvs.opencores.org:/cvsroot/anonymous co or1k/gcc-3.2.3
cvs -d :pserver:anonymous@cvs.opencores.org:/cvsroot/anonymous co or1k/binutils
cvs -d :pserver:anonymous@cvs.opencores.org:/cvsroot/anonymous co or1k/gdb-5.0


• Patch or1k version of gcc-3.2.3.

cd or1k/gcc-3.2.3
wget http://www.doc.ic.ac.uk/~jab00/or32-newlib/gcc-patch
patch -p0 < gcc-patch

Note that while the newer version of gcc in the CVS may work, I would recommend sticking with gcc-3.2.3.

• Symlink newlib and libgloss into the gcc source tree.

ln -s ../../newlib-1.13.0/libgloss
ln -s ../../newlib-1.13.0/newlib


• Build and install binutils and gcc.

I have provided an example script for automating this, but I provide no guarantees as to its functionality. You almost certainly want to read this script before you use it!. Among other things it will delete /opt/or32-elf and assumes you can 'sudo' to root.

cd ..
mkdir toolchain_build
cd toolchain_build
wget http://www.doc.ic.ac.uk/~jab00/or32-newlib/run.sh
sh run.sh


• Copy libgloss/or32 specs file into the gcc installation.

cd ../../newlib-1.13.0/libgloss/or32
(as root) cp specs /opt/or32-elf/lib/gcc-lib/or32-elf/3.2.3/


• Add /opt/or32-elf/bin to your path.

Sh-like shells:
export PATH=/opt/or32-elf/bin:$PATH
Csh-like shells:
setenv PATH "/opt/or32-elf/bin:${PATH}"

Now, if you're lucky, you should now be able to compile and run programs with relative ease on your OpenRISC platforms. For example a simple hello-world program might be compiled as follows:

I personally use gdb to upload and run programs generated in this way to my or32 platform.

If and you have a problem which specifically relates to newlib and libgloss I might be able to help you: jacob.bower at ic dot ac dot uk. If however your problem is to do with a lack of understanding of a Unix like environment or problems with other or1k tools then I'm afraid you're asking the wrong person. You might try the openrisc mailing list or your local Unix/Linux guru instead.

Todo

• Enable caches at start-up.
• Configure memory controllers.
• Support booting from flash.
• Confirm setjmp, longjmp work.
• Figure out why -Ox options to gcc cause linking failure.
• Find out why heap management functions leak (probably a newlib problem).