GNU Toolchain
NEW
Newlib toolchain 1.0rc1 released! Download now. Contributors and maintainers for tools still needed.
New newlib toolchain page covering the recent changes to the library for 1.0rc1.
Introduction
This page contains information about the OpenRISC software toolchain.
The following is a list of tools and software libraries with ports providing support for the OpenRISC 1000 platform.
Installation
Newlib Toolchain 1.0rc1 Precompiled Binaries
The following are precompiled OpenRISC 1000 toolchains for a variety of platforms.
They contain version 1.0rc1 of the newlib (or32-elf) toolchain. The included components are GCC-4.5.1, binutils-2.20.1, newlib-0.18.0, GDB-7.2 and or1ksim-0.5.1.
Download
OpenRISC
newlib toolchain 1.0rc1 compiled under Ubuntu x86/i686 (32-bit)
OpenRISC
newlib toolchain 1.0rc1 compiled under CentOS-5.5 x86_64 (64-bit)
OpenRISC
newlib toolchain 1.0rc1 compiled under OS X 10.6 (Snow Leopard) (Note: no libstdc++-v3)
Extract and install
The following commands indicate how to install the toolchain from the download archive. The tools are installed to the /opt path and symbolic links are created to more general path names (which helps with switching to more updated versions of the toolchain later.) The shell's PATH environment variable must be updated.
cd /opt
tar xjf ⟨path to downloaded archive⟩/⟨archive name⟩
sudo ln -s or32-elf-1.0rc1 or32-elf
sudo ln -s or1ksim-0.5.1rc1 or1ksim
Finally, open your .bashrc file (typically just ~/.bashrc) and add the following at the end. Note: If the toolchain was installed elsewhere, please use the appropriate path.
export PATH=$PATH:/opt/or32-elf/bin:/opt/or1ksim/bin
See the newlib toolchain page for usage details.
Build From Source
This section will contain information about compiling the toolchain from the source contained in the repositories. Note that this is only recommended for those developing the toolchain itself, or wishing to obtain a version more recent than the previous release.
Download source
First obtain a checkout of the OpenRISC GNU tool source directory. Note that this may take a while as it contains many files, and is large in size, which may cause the checkout to stop part-way through. Run the following command until no more files are downloaded to be sure all of the files were successfully checked out.
svn co http://opencores.org/ocsvn/openrisc/openrisc/trunk/gnu-src
If intending to compile and use the OpenRISC Linux kernel port, ensure a copy of the uClibc and kernel ports is downloaded.
uClibc and Linux kernel source
At present the uClibc and Linux kernel port source are located in a repository run by South Pole. Obtaining a copy of them will require the git client.
It is best to save the source for these into the gnu-src path just created when checking out from the OpenCores SVN repository.
cd gnu-src
git clone git://git.openrisc.net/jonas/uClibc
git clone git://git.openrisc.net/jonas/linux
Prerequisites
Libraries
Various libraries are required to compile the GNU tools. The following is a command for Debian-based GNU/Linux systems to ensure the required libraries are installed.
sudo apt-get -y install build-essential make gcc g++ flex bison patch texinfo libncurses-dev libmpfr-dev libgmp3-dev libmpc-dev libzip-dev
Please post on the OpenRISC forum if any tools are missing, or to provide a one-liner to install the required prerequisites on another distribution.
or1ksim
Ensure or1ksim is built and installed somewhere on the system. See the guide on the or1ksim page for information on downloading, building and installing it.
It is assumed in the rest of this that install prefix used when building or1ksim was /opt/or1ksim - if this is different to the path used then please substitute the correct one appropriately in the following commands.
Install path
The install path of the compiled toolchain used in the following examples is /opt/openrisc - it is recommended this is used, but if an alternative is desired, then substitute /opt/openrisc appropriately.
Create the install path and ensure it has sufficient permissions to allow the user to write to it when performing the installation of the toolchain.
Building
The script used to build the toolchains is bld-all.sh and it is found in the gnu-src/ path. It will create a unified build environment when compiling the GNU tools (binutils, GCC, GDB.)
There are two toolchains that can be compiled with bld-all.sh, one with the newlib C library, and one with the uClibc C library.
The newlib toolchain, with toolchain executables prefixed by or32-elf- are primarily for compiling applications which will be run on the bare metal, or without an operating system.
The uClibc toolchain, with toolchain exeutables prefixed by or32-linux- are for compiling software intended to run on Linux, as userspace applications.
For a full list of options provided by the build script, run it with the --help option:
./bld-all.sh --help
All toolchains
To build and install both newlib (or32-elf-) and uClibc-based (or32-linux-) toolchains:
./bld-all.sh --force --prefix /opt/openrisc --or1ksim-dir /opt/or1ksim --uclibc-dir uClibc --linux-dir linux
Newlib toolchain only
To build and install only the newlib (or32-elf-) toolchain:
./bld-all.sh --force --prefix /opt/openrisc --or1ksim-dir /opt/or1ksim --no-uclibc --no-or32-linux
uClibc (Linux) toolchain only
To build and install only the uClibc (or32-linux-) toolchain:
./bld-all.sh --force --prefix /opt/openrisc --or1ksim-dir /opt/or1ksim --uclibc-dir uClibc --linux-dir linux --no-newlib --no-or32-elf
See the Linux page for information on building and running the OpenRISC kernel port.
PATH Variable
Be sure to add the install prefix's binaries directory to the PATH environment variable so the tools can be found.
Add the following line to the end of the .bashrc file:
export PATH=$PATH:/opt/openrisc/bin
GNU toolchain testing
The GNU toolchain is currently tested against Or1ksim, using the newlib library where appropriate. The current results of testing can be found on the GNU toolchain test page
Support for non-Linux platforms
Microsoft Windows with Cygwin
At present only the older pre-compiled OpenRISC toolchains exist for Cygwin. The OpenRISC project currently does not have a maintainer for the toolchain on the Cygwin platform. Without one it is not certain that each toolchain release will be built for Cygwin.
If you would like to contribute to the project by maintaining a build script and guide for Cygwin platforms, please contact the OpenRISC team .
Apple Mac OS X
Robert Guenzel has provided an application note on building the toolchain (excluding GDB) for Mac OS 10.4: chschroeder.gamiro.de/rg/or1ksim_macOS10.4.pdf. Users will find this provides valuable additional information beyond the instructions above.
Tool Information, Notices
GNU binutils
This is a collection of tools for the manipulation of object code in various object file formats. Among its many tools, it provides the assembler and linker.
The latest version of binutils, 2.20.1, has recently been ported to OpenRISC and can be downloaded from SVN at http://www.opencores.org/ocsvn/openrisc/openrisc/trunk/gnu-src/binutils-2.20.1.
More information about the GNU project's release of binutils can be found at its homepage.
GNU GCC
A version of GCC targeted at the OpenRISC platform is provided here. Known as a cross compiler, it is a version which will create code that is executable on an OpenRISC processor.
More information about the official GCC releases can be found at the project's homepage.
GCC Stable Version: Known issues:
-
Backwards compatibility issue: The old GCC 3.4.4 for OpenRISC defined three constants, OR1K, __or1k__ and __OR1K__, allowing users to bracket OpenRISC dependent code with #ifdef __OR1K__. These are not at present defined in the current GCC 4.2.2 by default, so users must explicitly set them by hand
-
Backwards compatibility issue: The old GCC 3.4.4. for OpenRISC assumed the availability of hardware multiplication, but not hardware division by default (i.e. -mhard-mul, -msoft-div), which was consistent with the default Verilog configuration. The current GCC 4.2.2 appears to assume neither hardware multiplication nor hardware division are present (i.e. -msoft-mul, -msoft-div). The old behavior can be restored by using -mhard-div on the GCC command line of in the CFLAGS within Makefiles.
GCC Development Version, GCC 4.5.1
GCC 4.5.1 has been ported to OpenRISC. It can be checked out from SVN at http://www.opencores.org/ocsvn/openrisc/openrisc/trunk/gnu-src/gcc-4.5.1.
A number of changes are in progress for GCC.
-
Fix the known issues listed above.
-
The stable version of OpenRISC GCC prefixes all global symbols (functions and variables) in the compiled code with an underscore ('_'). Historically this was done to avoid namespace clashes. However with ELF output files it really is no longer needed. GDB struggles with mapping the high level names in the compiled code to the values in the object file symbol table, particularly with STABS debug info.
Most modern compilers leave global names unchanged for ELF targets. We will move to this convention for OpenRISC. However it will mean that code compiled with the old compiler will not be linkable with code from the new compiler (since the naming convention for globals will be different). This should not cause any problem in practice, since there are not large bodies of pre-compiled library code out there.
This functionality is currently available in the SVN version of GCC.
-
The stable version of OpenRISC GCC generates STABS debugging info by default when -g is used. This is now quite an old, inconsistent and limited format. Most modern compilers generate DWARF2 debugging for -g. DWARF2 offers a richer debugging experience, and is the preferred format for GDB. It is what is generated if you use GCC with -ggdb.
We will change to make DWARF2 the default debugging format for OpenRISC GCC. This should not cause compatibility problems. This requires further work, since OpenRISC GCC does not always generate valid DWARF2 output at present.
This functionality is currently available in the SVN version of GCC.
-
The C++ compiler, g++, is now built. Support is highly experimental, and there are many regression failures, largely due to linking problems.
-
Function prologues are currently generated using the TARGET_ASM_FUNCTION_PROLOGUE, which is called at the start of a function to output the prologue. The preferred approach is to define the pattern prologue in the machine definition, since this allows greater flexibility when scheduling instructions.
This is currently available for OpenRISC using the -mlogue option to GCC. It requires testing and then should become the default.
-
GCC provides sibcall optimization, which is a subset of tail call optimization.
This is currently available for OpenRISC using the -msibcall option to GCC. It requires testing and then should become the default.
-
GCC for OpenRISC currently provides an option -maj, to align branches and jumps on a double word boundary, padding with l.nop 0x15 if required.
This appears to be an obsolete option and should removed.
-
There are still a significant number of regression failures in GCC, which need to be fixed.
At present compilation regression fails, due to incomplete support for trampolines. This needs fixing.
GNU GDB
The GNU Project Debugger (GDB) is a standard debugging tool. It is used for debugging code whilse it is executing on any OpenRISC target, be it simulated (architectural simulator or RTL) or physical (FPGA, or ASIC.) At early stages of development it is the easiest way of transferring and running code in an OpenRISC based system.
GDB 6.8 has now been ported to the OpenRISC 1000 architecture and is regarded as the stable implementation. The latest version (2.1) of the source code patch for the standard GDB 6.8 distribution is available in the OpenRISC 1000 Downloads section here.
This latest stable version supports the GDB Remote Serial Protocol (RSP), which will ensure ongoing compatibility with GDB in future releases. The legacy OpenRISC Remote JTAG Protocol is still supported for backwards compatibility, but is now deprecated. All new users and applications should adopt the RSP interface.
This version of GDB works directly with Or1ksim 0.4.0, the current stable release of The OpenRISC 1000 Architectural Simulator, Or1ksim as well as the previous version 0.3.0. It is not suitable for earlier versions of the simulator.
To date this release has been tested on the architectural simulator, Or1ksim, a cycle accurate Verilator model of ORPSoC and on the ORSoC FPGA board. Feedback from users on experience with other hardware (via the tracker) will be appreciated. Limited testing with the GDB regression test suite has been carried out, and shows a substantial number of test failures.
Details of the internal workings of the GDB 6.8 port for OpenRISC 1000 can be found in the application note Howto: Porting the GNU Debugger: Practical Experience with the OpenRISC 1000 Architecture published by Embecosm.
Details of the implementation of the RSP server functionality for Or1ksim can be found in the application note Howto: GDB Remote Serial Protocol: Writing a RSP Server published by Embecosm.
This version of GDB works with the graphical user interface DDD. It has also been tested with the Insight graphical debugger and appears to work.
GDB Development Version, GDB 7.2
GDB 7.2 has been ported to OpenRISC. It can be checked out from SVN at http://www.opencores.org/ocsvn/openrisc/openrisc/trunk/gnu-src/gdb-7.2.
Key new features are:
-
Or1ksim is now integrated as a GDB simulator, so target sim is now available as a command. Note. This requires the latest version of Or1ksim from SVN built and installed first. The Or1ksim install location must be specified using --with-or1ksim when configuring GDB.
-
As planned, support for the legacy OpenRISC Remote JTAG Protocol is dropped. All targets must connect using the GDB Remote Serial Protocol.
-
To match the changes to the development version of GCC, DWARF2 debugging is now tested by default.
A consequence of the integrated simulator is that full GDB regression testing can be carried out. At the time of writing, there were still a large number of failures, so there is more work to be carried out. However the results represent a significant improvement on GDB 6.8!
Full test results can be found on the GNU Toolchain Testing page.
Known issues in the stable version (6.8)
-
Message "Value being assigned to is no longer active" when trying to alter a register immediately after loading a new program image. This is a known bug in GDB. It is one feature of a complex problem with the way GDB represents stack frames.
One workaround is to set a breakpoint on the first instruction of the loaded image, run to that breakpoint (which will do nothing), and then GDB will allow registers to be set. However user nyawn has found a small patch from the Fedora project which fixes this particular problem. It can be found at:
cvs.fedoraproject.org/viewvc/devel/gdb/gdb-6.8-bz436037-reg-no-longer-active.patch?view=log
-
GDB will not work reliably with code that omits the frame pointer (compiled with GCC using -fomit-frame-pointer). This has been fixed in the version of GDB in SVN (checkout http://www.opencores.org/ocsvn/openrisc/openrisc/trunk/gnu-src/gdb-6.8).
-
Some limited testing using the GDB regression test suite has been carried out, and indicates a large number of failures, which need to be addressed.
uClibc
This is a C library aimed at embedded Linux systems. It removes a lot of the bulk that comes with a standard C library, such as the GNU C Library, making it more suitable for compiling embedded applications against.
At present the OpenRISC port of uClibc is hosted on a git repository provided by South Pole.
It can be browsed and downloaded from here: http://openrisc.southpole.se/cgit.cgi/jonas/uClibc/
For more information about uClibc see the project's homepage.
newlib
There is now a fully tested port of the GNU toolchan using the latester version of newlib, 1.18.0, with board support packages suitable for use with Or1ksim.
This is a smaller and simpler C library than uClibc, and is better suited to development of bare-metal applications. It is also used to test the entire GNU toolchain.
The implementation installs in a custom location, so can be used with uClibc installed. Adding the -mor32-newlib or -mor32-newlib-uart flags will cause the newlib library to be linked. The former will direct all output to the console and offers no input stream. The latter offers input and output via a UART memory mapped at 0x90000000. Both assume the availability of a block of contiguous RAM from 0x0 upwards, and will fully use such memory.
In principle the UART version of the library should also work with physical hardware, but this has not been tested.
Further information
Embecosm Application Note 9 Howto: Porting Newlib: A Simple Guide explains in full detail how the port for the OpenRISC 1000 architecture was done.
Newlib port acknowledgements
This original port was for newlib 1.13.0 by Jacob Bower, then of Imperial College, London. Details can be found here.
The port has been completely rewritten and tested for newlib 1.18.0 by Jeremy Bennett of Embecosm.
Future toolchain development and release plan
We plan to move towards a scheduled development and release plan for the OpenRISC toolchain. The goal is to provide stable releases of the entire toolchain, libraries and architectural simulator every six months, containing the most stable ports of the latest tools and libraries available.
We intend to release two toolchains, one based on the newlib C library and aimed at bare-metal use, and one based on the uClibc C library aimed at Linux userspace application use. The development and release schedule of these toolchains might not coincide.
Please note, as of the beginning of April 2011, this toolchain release plan has been changed to split the releases into newlib and uClibc toolchains.
Newlib toolchain
The newlib toolchain is intended to provide support for applications to run on the bare-metal, that is without any underlying operating system support software. This toolchain will be suitable for use with all software except for those specifically targeting Linux userspace.
uClibc toolchain
The uClibc toolchain will provide support for compiling applications intended to run in Linux userspace. Each released toolchain will be compatible with a specific OpenRISC Linux kernel port.
Assistance
The OpenRISC maintainers would like to invite those interested in assisting with development and maintenance of the OpenRISC tools to contact us and indicate they would like to help out.
Specifically, we are looking for those with an interest in maintaining the OpenRISC ports of GNU binutils, and GCC.
We are also open to including OpenRISC 1000 ports of such tools and libraries as QEMU, EGLIBC, and LLVM. Please contact us if you are interested in developing these, or similar, ports for OpenRISC.
Current responsibilities
- Release Manager: Julius Baxter of ORSoC AB
- GNU binutils: vacant
- GCC: vacant
- GDB: Jeremy Bennett of Embecosm
- newlib: Jeremy Bennett of Embecosm
- uClibc: Jonas Bonn of South Pole
- Or1ksim: Jeremy Bennett of Embecosm
- Installation script: Julius Baxter of ORSoC AB
Responsibilities
We would like volunteers who would take responsibility for the ongoing maintenance and development of these tools. That means deciding on what improvements to make, when to migrate to new versions, how changes will get done, reviewing and integrating code from others, keeping OpenRISC specific documentation up to date etc. Central to this will be fitting in with the timetable for release, so that code is stable and ready for integration testing around 4 weeks before release.
Newlib toolchain (or32-elf)
Schedule for Next Release
Dates
| Date | Status |
| 10 April 2011 | RC 1 versions tagged in SVN, precompiled binaries available |
| 24 April 2011 | Public release of precompiled binaries |
After RC 1 is tagged, only bug fixes will be allowed in SVN. Tool maintainers may make available as many RC versions as they wish, so long as the final version is tagged by the specified date. Once the release version is tagged in SVN, maintainers should provide a packaged version (tar.bz2) to the Release Manager. The goal is to meet these dates. However the Release Manager will adjust them if that is necessary to ensure critical bugs are eliminated from the release.
Candidate components:
| Tool | Version | RC for RC1 |
| GNU binutils | 2.20.1 | rc1 |
| GCC | 4.5.1 | rc4 |
| GDB | 7.2 | rc3 |
| Newlib | 1.18.0 | rc2 |
| Or1ksim | 0.5.1 | rc1 |
uClibc toolchain (or32-linux)
Schedule for Next Release
Dates
| Date | Status |
| TBA | TBA |
Candidate components:
| Tool | Version |
| GNU binutils | 2.20.1 |
| GCC | 4.5.1 |
| GDB | 7.2 |
| uClibc | 0.9.31 |
| Or1ksim | 0.5.0 |
Why and How to Volunteer
Taking responsibility for maintaining a package is a great way to gain experience of practical program management. If you are a student, or early in your career, it adds important credibility to your resume. And since it is all open source, your expertise can be publicly verified by any potential employer.
To take part, post a message on the forum, or email the Release Manager, Julius Baxter or come and talk to us on IRC at irc.freenode.net, channel #opencores.
Bugs
Please make use of the OpenRISC project's bug tracker if any actual bugs are found and the development team should look at them.
Support
Please contact the OpenRISC forum with any problems experienced with the toolchain.
TODO:
-
Dynamic linker/loader in binutils port
-
Correct toolchain prefix naming (or32 to openrisc or or1k)
-
Write optimized versions of routines in uClibc instead of using generic ones.
-
Additional boards supported in newlib's libgloss
Wishlist
The following is a list of future work for the GNU toolchain port.
-
A nice tutorial, showing off the installation and use of the new toolchain.
-
Maintainers for various platforms (Cygwin, Mac OS X)
-
Maintainers for packaging toolchain for Debian (apt) and Fedora (yum) package managers.
Feel free to post any suggestions or offers to assist the project to the OpenRISC forum or openrisc_team@opencores.org
Developers
The team working on the GNU Toolchain port:
- Jeremy Bennett, jeremybennett@opencores.org (GDB, GCC, Newlib, Or1ksim)
- Marcus Erlandsson, marcus.erlandsson@opencores.org
- Julius Baxter, julius@orsoc.se (install script)
- Jonas Bonn, jonas@southpole.se