GNU toolchain
NEW
New toolchain release program announced. New contributors and maintainers for tools needed.
Introduction
This project aims to maintain a set of easy to use development tools for the OpenRISC processor platform.
The included tools are currently:
- GNU binutils 2.18.50 (with binutils 2.20.1 available experimentally).
- GNU GCC 4.2.2
- GNU GDB 6.8 (with GDB 7.1 available experimentally)
- uClibc 0.9.29
- newlib 1.18.0
- Linux 2.6.24
- BusyBox 1.7.5
- or1ksim 0.4.0 (or1skim 0.3.0 for precompiled tool chains)
Experimental versions of tools are only available from SVN.
Installation
Script download
The normal method of installation for the GNU toolchain uses a script which will download and install the latest versions of all tools. The script can be downloaded here.
The latest version of the toolchain, version 5a, has finally been released. It is a significant upgrade the previous version, including a new version of GCC, the Linux kernel, GDB and or1ksim. Also note the prefix of the resulting executables is now or32-elf rather than or32-uclinux as it was under the previous toolchain version.
Toolchain installation for Linux
System setup
Compiling the OpenRISC toolchain from sources requires that some standard
development tools are already installed. Most of these tools are
pre-installed in modern Linux distributions. However, some may still require
installation before the OpenRISC toolchain can be built.
The specifics
of installing these required tools differs from distro to distro. The
example given here uses the apt-get package management tool common
among Debian and Ubuntu distros (among others,) however it should be easy
enough to perform this installation using the package management tool your
system uses.
Under Ubuntu, the following set of commands should ensure all packages required to build the OpenRISC toolchain are installed:
$ sudo apt-get update
$ sudo apt-get -y install build-essential make gcc g++ flex bison patch texinfo libncurses-dev
Once these tools are installed on the system, the toolchain script can be downloaded and run.
Perform the installation
Save the script in a new directory. Open a console, change path to where the script is located and run:
$ sh MOF_ORSOC_TCHN_v5c_or32-elf.sh
Follow the prompts given by the script. It will automatically attempt to install the toolchain under the current directory, but it can be targeted to install anywhere on the current system. For instance, setting the install path as /opt will result in the toolchain being installed under /opt/or32-elf however in most cases installation to any path outside of the user's home directory will require root access, or the script being with sudo.
Please ensure that at least 2 gigabytes of storage is available on the local harddisk before attempting to build the toolchain. Compile time can be anywhere from 30 minutes to 2 hours, depending on the host machine.
Precompiled Toolchains
Here we provide precompiled toolchains for those who wish to use them in environments where they cannot perform the installation. These have not been tested on any other platform than the ones they were compiled on. To test which version you should get, run uname -m.
Installation of precompiled toolchain
Change to the directory where you wish the toolchain to be installed, and extract the package with the following command:
$ tar xjf or32-elf-linux-x86.tar.bz2
This will create a new directory, or32-elf/, containing the toolchain. Add the executable path to your shell's PATH variable by adding the following line to your ~/.bashrc file:
export PATH=$PATH:⟨place where package was extracted⟩/or32-elf/bin
Toolchain installation for Cygwin Windows
System setup
The Cygwin Unix-like shell environment for Windows is required to build and use the toolchain. See the Cygwin website for instructions on how to install the basic Cygwin package.
There are some applications and libraries which must be installed in addition to the basic Cygwin packages. These are installed by running Cygwin's setup.exe, and continuing to the package "chooser" window, which, by default, presents all available packages sorted by category. Follow the list below, expand the appropriate category and mark the listed programs for install.
Category: Devel
- autoconf
- automake
- binutils
- bison
- gcc (gcc:C compiler upgrade helper)
- gettext-devel
- libiconv
- libncurses-devel
- make
Category: Utils
- bzip2
- patch
Category: Web
- wget
Once these applications and libraries are marked for installation continue with setup.exe until it is finished. The Cygwin system should now be capable of compilation of the OpenRISC toolchain.
Perform the installation
Save the script in a new directory. Open a console, change path to where the script is located and run:
$ sh MOF_ORSOC_TCHN_v5c_or32-elf.sh
Follow the prompts given by the script. It will automatically attempt to install the toolchain under the current directory, but it can be targeted to install anywhere on the current system. For instance, setting the install path as /opt will result in the toolchain being installed under /opt/or32-elf. Please note that the BusyBox applications built in the script cannot be installed into the ramdisk due to ext2 filesystem support issues under Cygwin.
Precompiled Toolchains
Here we provide precompiled toolchains for those who wish to use them in environments where they cannot perform the installation.
Installation of precompiled toolchain
Change to the directory where you wish the toolchain to be installed, and extract the package with the following command:
$ tar xjf or32-elf-cygwin-1.7.tar.bz2
This will create a new directory, or32-elf/, containing the toolchain. Add the executable path to your shell's PATH variable by adding the following line to your ~/.bashrc file:
export PATH=$PATH:⟨place where package was extracted⟩/or32-elf/bin
Toolchain installation for Mac OS X
At present the script does not compile the toolchain completely under Mac OS X. The core components such as binutils, GCC with uClibc and GDB, can be compiled seperately. See the section on doing this by hand, below.
Precompiled Toolchains
Here we provide precompiled toolchains. Note that this first one, for Mac OS X 10.6 (Snow Leopard), will probably only work on Snow Leopard (and potentially Leopard) and not on OS X 10.4 (Tiger).
Installation of precompiled toolchain
Change to the directory where you wish the toolchain to be installed, and extract the package with the following command:
$ tar xjf or32-elf-linux-x86_64-OSX-10.6.tar.bz2
This will create a new directory, or32-elf/, containing the toolchain. Add the executable path to your shell's PATH variable by adding the following line to your ~/.bashrc file:
export PATH=$PATH:⟨place where package was extracted⟩/or32-elf/bin
Robert Guenzel has provided an application note on building the tool chain (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.
Toolchain installation by hand
Embecosm Application Note 2 outlines manually compiling and installing the individual components of the OpenRISC toolchain. This is useful for those who wish to customise the components included in the toolchain, or those who experience trouble with the provided install script.
Script download
The normal method of installation for the GNU toolchain uses a script which will download and install the latest versions of all tools. The script can be downloaded here.
The latest version of the toolchain includes a new version of GCC, the Linux kernel, GDB and or1ksim. The prefix of the resulting executables is now or32-elf rather than or32-uclinux as it was with previous scripts.
Unified toolchain build from repository source (NEW)
To build the very latest development source of the GNU toolchain port, first obtain a copy the source from the OpenRISC project repsitory. This includes new releases of binutils (2.20.1) and GDB (7.1), as well as the latest fixes to the other tools in the chain.
$ svn co http://opencores.org/ocsvn/openrisc/openrisc/trunk/gnu-src
Note that this will take some time to complete. There are known problems with the OpenCores HTTP interface, one of which is to do with the svn checkout command ending before actually downloading everything. Run this command twice to ensure everything has been checked out from the server.
Included in the gnu-src path is a build script, bld.sh, which performs a unified build of all the GNU tools.
Note that GDB requires or1ksim, the OpenRISC 1000 architectural simulator, is already installed. At present, release 0.4.0 of or1ksim does not provide the required library that GDB needs, so the latest version from the repository must be built. Future releases of or1ksim will have the required features. For now, see the commands relating to downloading or1ksim from the repository to obtain the latest source. Ensure this latest version of or1ksim is buit and installed before starting the unified build.
Perform the unified build, specifying the install (prefix) path and or1ksim path. In the example below, the toolchain will be installed in the path /opt/or32-elf, and or1ksim has already been installed in /opt/or1ksim.
$ cd gnu-src
gnu-src$ ./bld.sh --prefix /opt/or32-elf --or1ksim /opt/or1ksim
GNU tool chain testing
The GNU tool chain is currently tested against Or1ksim, using the newlib library where appropriate. The current results of testing can be found on the GNU tool chain test page
Manual install of µClibc (NEW)
The OpenRISC port of µClibc has received some udpates recently, but this version has not been integrated into the main installation script, yet.
To install the latest port of µClibc, first obtain and extract the source from the µClibc site, then the OpenRISC support patch and then apply it.
$ wget http://www.uclibc.org/downloads/uClibc-0.9.31.tar.bz2
$ tar xjf uClibc-0.9.31.tar.bz2
$ svn export http://opencores.org/ocsvn/openrisc/openrisc/trunk/uClibc/patches/uClibc-0.9.31-or32.patch.bz2
$ cd uClibc-0.9.31
uClibc-0.9.31$ bzcat -dc ../uClibc-0.9.31-or32.patch.bz2 | patch -p1
For Linux userspace support, µClibc requires the kernel header files are accessible. The next step involves installing the Linux kernel headers in the OR1k toolchain's sysroot path.
See the guide on obtaining and patching the Linux kernel source for OpenRISC platform support. Follow the steps in the "download source" section, ensuring the source is at least patched, and ready to build before continuing with the next steps from within the Linux source directory. The example here relies upon the or1k toolchain having been installed under /opt/or32-elf.
linux-2.6.34$ make defconfig
linux-2.6.34$ make INSTALL_HDR_PATH=/opt/or32-elf/or32-elf headers_install
The headers should now be installed, and the µClibc library can now be configured and built.
The first stage of configuring the µClibc port involves performing the defconfig.
uClibc-0.9.31$ make ARCH=or32 defconfig
That will set up almost everything ready to build the library, however two options must be set in the configuration before building. One is the location of the Linux kernel headers, the other is the place to install the library. Using the menuconfig tool, these options can be configured.
uClibc-0.9.31$ make menuconfig
In the menuconfig tool, in
Target Architecture Features and Options → Linux kernel header location
Ensure the location is the include path under the toolchain's sysroot path. In the example above, this would be /opt/or32-elf/or32-elf/include
Library Installation Options → uClibc development environment directory
Here enter just the toolchain's sysroot path. From the example above, this would be /opt/or32-elf/or32-elf
Exit menuconfig and save the changes.
µClibc will now be ready to compile and install. This can be done with
uClibc-0.9.31$ make
uClibc-0.9.31$ make install
Feedback, Bugs and Assistance
To participate in development, or discuss and report success/failure
building the toolchain, go to the OpenRISC forum.
Or keep
up to date with the goings on of the toolchain by subscribing to the
OpenRISC mailing list. Enable the subscription by going to your OpenCores account page (click My
Account in the top left of the page) and check the openrisc box
under Subscriptions.
This set of tools, or tool chain, is based around the GNU binutils and GNU Compiler Collection (GCC) packages, which provide the basic compilation related functions of the toolchain. Also included are libraries and specialised software for the OpenRISC platform. Included are OpenRISC targeted versions of the uClibc library, the Linux 2.6 kernel and BusyBox. In addition there are some tools aimed at assisting development on the OpenRISC platform. The GNU Debugger (GDB) is included and can be used to debug code running on the OpenRISC architectural simulator, or the or1ksim tool, which is also included in this project. To ensure an easy installation process, and automated install script is provided.
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
A number of changes are in progress for GCC and can be found in the development version of GCC in SVN. There are no immediate plans to migrate to GCC 4.5, but this will happen in the longer term. All the development work is based on the current stable GCC 4.2.2 for OpenRISC.
-
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.
-
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.
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.
Experimental Version, GDB 7.1
GDB 7.1 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.1.
It is anticipated that this will soon be replaced by GDB 7.2, which is due for release mid-2010.
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.
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 Tool Chain 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.
For more information about uClibc see the project's homepage.
Linux kernel
An operating system kernel. It is ported to the OpenRISC architecture and
features preemptive multitasking, virtual memory and threading to name just
a few things.
For more information about the Linux kernel sources see
the project's homepage.
BusyBox
BusyBox combines tiny versions of many common UNIX utilities into a single
small executable. It provides replacements for most of the utilities you
usually find in GNU fileutils, shellutils, etc.
Although version 1.7.5
is included here, versions up 1.16.0 are known to work in the RAMdisk in the
OpenRISC port of the Linux kernel.
For more information about BusyBox
see the project's homepage.
OpenRISC architectural simulator
A simulator of the generic OpenRISC 1000 architecture simulator capable of emulating OpenRISC based computer systems. It provides high level, fast architectural simulation that allows early code analysis and system performance evaluation.
For more information see the project's homepage here at OpenCores.
GNU tool chain with 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 tool chain.
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.
Installation
At present newlib can only be built from the latest SVN sources, and also requires the latest version of the rest of the GNU tool chain built from SVN sources. These should be checked out from http://www.opencores.org/ocsvn/openrisc/openrisc/trunk/gnu-src. Warning. This is a large checkout and will take some time.
The build also requires the latest version of Or1ksim from SVN (Or1ksim 0.4.0 will not suffice). This can be checked out from http://www.opencores.org/ocsvn/openrisc/openrisc/trunk/or1ksim.
If the tool chain and library are to be tested, DejaGnu should also be installed.
O1rksim should be built and installed first. The script bld.sh can then be used to build and install the entire tool chain. Use ./bld.sh --help to see all the options which can be used to control the build.
Future installation script
At some point in the future an alternative toolchain script, installing newlib alongside uClibc and Linux, will be made available. For now the above procedure should be followed.
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 tool chain, libraries and architectural simulator every six months, containing the most stable ports of the latest tools and libraries available.
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, GCC (to relieve Rich D'Addio), and uClibc.
Current responsibilities
- Release Manager: Julius Baxter of ORSoC AB
- GNU binutils: vacant
- GCC: Rich D'Addio, but his day job limits his capacity at present
- GDB: Jeremy Bennett of Embecosm
- Newlib: Jeremy Bennett of Embecosm
- uClibc: vacant
- 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.
Schedule for Next Release
Dates
| Date | Status |
| 01 Sep 2010 | Release Candidate 1 of all tools etc tagged in SVN packaged versions available for public test |
| 08 Sep 2010 | RC 1 of installation script tagged in SVN available for public test |
| 21 Sep 2010 | Final RC of all tools etc tagged in SVN packaged versions available for public test |
| 24 Sep 2010 | Final RC of installation script tagged in SVN available for public test |
| 27 Sep 2010 | Release versions of all tools tagged in SVN |
| 30 Sep 2010 | Public release of all tools and installation script |
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 |
| GNU binutils | 2.20.1 |
| GCC | 4.2.2 |
| GDB | 7.2 |
| Newlib | 1.18.0 |
| uClibc | 0.9.32 |
| Or1ksim | 0.5.0 |
| Installation script | 6.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 here, or email the Release Manager, Julius Baxter (julius@opencores.org) or come and talk to us on IRC at irc.freenode.net, channel #opencores.
Wishlist
The following is a list of future work for the GNU toolchain port.
If
you want to help, send an email to openrisc_team@opencores.org
-
A nice tutorial, showing off the installation and use of the new toolchain.
-
Port of the toolchain enabling the 64-bit features of the OpenRISC spec.
-
Write optimized versions of routines in uClibc instead of using generic ones.
-
Testing the script and resulting toolchain on other platforms.
Feel free to post any suggestions to the OpenRISC forum or an email to openrisc_team@opencores.org
Developers
The team working on the GNU Toolchain port:
- Jeremy Bennett, jeremybennett@opencores.org (GDB, Newlib, Or1ksim)
- Rich D'Addio, rich_daddio@opencores.org (GCC, Linux)
- Marcus Erlandsson, marcus.erlandsson@opencores.org
- Julius Baxter, julius@orsoc.se (install script)