Building leJOS firmware using arm-elf-gcc on Mac OS Lion

[mcrosbie]

Hi everyone,

First off, apologies if this is covered in a FAQ but I've searched the forums and can't quite seem to figure this one out. This question is on how to build the gcc-arm-elf toolchain on Mac OS Lion so I can build the current leJOS firmware image.

I'm working on a leJOS driver class for the Dexter wifi sensor. It uses the RS485 port on the NXT to speak an AT modem protocol at varying baud rates from 9600 up to 921600 baud. I have the guts of a working webserver written in NXC for this sensor, and now it's time to work on the leJOS equivalent.

I know that the leJOS firmware hard-codes the baud rate to 921600 in hs.c for the RS485 port. I'd like to re-build the firmware to change that to (say) 115200, or better yet allow variable baud rates. Reading hs.c it seems that this would be possible as BAUD_RATE is used in only one place in the file. I know how to make the necessary Java class changes, and also how to adjust the JNI code. So far so good...

I'm struggling to re-build the current 0.9.0 trunk of leJOS. My first challenge is to get a working arm-elf-gcc toolchain working on Mac OS Lion (10.7.1). I've installed Macports arm-elf-gcc but it assumes a hardware FP unit, so none of the libraries link against the code built for leJOS (obviously the NXT does not have a FPU!) After two evenings beating my head on the wall with this I moved on.

Next I turned my attention to running the build_arm_toolchain.sh script in the nxtvm/platform/nxt directory. The first problem I encountered was that nothing would build without adding ---disable-werror to the configure calls on lines 87, 113 and 126 of the script. This is because the format string literals used in dozens of source files caused the compiler to crap out.

The second challenge is getting gcc 4.3.2 to build for the arm-elf target. It was looking for GMP (GNU Multi precision library) and MPFR (multi-precision float library). I got around that problem by adding --with-gmp=/opt/local --with-mpfr=/opt/local to the configure call for gcc-core. I installed GMP and MPFR from macports.org. The compile seemed to go well until died looking for iconv - unmatched symbols is the challenge. Yet iconv exists in /opt/local in my build machine. I have built newlib-1.16.0 and binutils-2.18.50 and have them in the install/ directory.

Has anyone succeeded in building the latest version of leJOS firmware on Mac OS?
Is there a clean known-to-work combination of binutils, gcc and newlib ?
Is there any easier way to adjust the baud rate of the RS485 interface in leJOS than rebuilding hardware?

Many thanks for any pointers!
Mark

[gloomyandy]

Hi,
If you can use 9600 baud rather then 115,000 then I have a pre-built version that I put together for another user... If not then I can probably build you a firmware that uses this speed (I will probably add a way to set the speed as this seems to be a popular change, but I don't have the time to do this right now)... Note however that to use this build you must use the development version of leJOS, rather than the release...

Andy

[mcrosbie]

Hi Andy,

Super stuff - thanks! I'll definitely take the 9600 baud firmware from you and give it a shot. When you say "use the development version of leJOS" do you mean build my own classes.jar from the latest development trunk? I think I can do that.

As for adding the setting for the baud rate - I've no problem making that change and contributing back into the source tree if someone can help me out in building the firmware and toolchain.

Regards,
Mark

[gloomyandy]

Hi,
The 9600 baud version is available here:
http://www.gloomy-place.com/lejos/lejos ... m.bin.9600
You can either build your own classes, or use the developer snapshot files (search the forum for details on how to do this). Don't worry about the baud rate setting code. If I add the firmware function to change the speed I will need to write code to test it, so I'll add the methods to the leJOS classes, it is not a big job...

Andy

PS I know that this code works at 9600baud, but if it turns out you must have 115,000 let me know and I will build you a version of the firmware that runs at that speed. Can't help with your toolchain problems as I don't have a Mac. But I would not advise using other versions of compiler/libs/tools unless you really know what you are doing as later versions of gcc result in bigger/slower code and do not always seem to work well with leJOS...

[mcrosbie]

Thanks Andy - I'll give that 9600 baud ROM a go tonight.

As for the toolchain - what are the "approved" or "known to work" versions of binutils/gcc/newlib? The build_arm_toolchain.sh script pulls the latest from the GNU site, which is perhaps not what was intended?

Regards,
Mark

[gloomyandy]

As far as I know the shell script in svn:
http://lejos.svn.sourceforge.net/viewvc ... h?view=log
downloads and build particular versions of the toolchain, see below:

Code: Select all

GCC_URL=ftp://ftp.mirrorservice.org/sites/sourceware.org/pub/gcc//releases/gcc-4.3.2/gcc-4.3.2.tar.bz2
GCC_VERSION=4.3.2
GCC_DIR=gcc-$GCC_VERSION

BINUTILS_URL=ftp://sourceware.org/pub/binutils/snapshots/binutils-2.18.50.tar.bz2
BINUTILS_VERSION=2.18.50
BINUTILS_DIR=binutils-$BINUTILS_VERSION

NEWLIB_URL=ftp://sources.redhat.com/pub/newlib/newlib-1.16.0.tar.gz
NEWLIB_VERSION=1.16.0
NEWLIB_DIR=newlib-$NEWLIB_VERSION

So version 4.3.2 of gcc, 2.18.50 of binutils and 1.16.0 of newlib. Is there some sort of problem with this script that means you end up with the most recent version rather than the versions specified?

Andy

[mcrosbie]

No problem in the script - and those are the exact versions that got downloaded and that the script failed to build

Mark

[gloomyandy]

I'm sorry but I don't understand your comments. You said earlier that the script downloaded the latest versions of the tools not specific ones. Perhaps you could explain? The versions of the tools downloaded by the script are the ones used to build leJOS release firmware...

The problems you have seen when attempting to build the tools are a combination of having a very recent version of gcc on your Mac (recent versions of gcc added the code to detect non static format strings and warn about the use), and using MacOS rather than Linux (Linux is the recommended leJOS firmware build environment). As you have found you may have to install extra packages, but this is not normally a problem, it's just something you have to deal with when building from gcc source...

Andy

[nate]

First off, apologies if this is covered in a FAQ but I've searched the forums and can't quite seem to figure this one out. This question is on how to build the gcc-arm-elf toolchain on Mac OS Lion so I can build the current leJOS firmware image.

Next I turned my attention to running the build_arm_toolchain.sh script in the nxtvm/platform/nxt directory. The first problem I encountered was that nothing would build without adding ---disable-werror to the configure calls on lines 87, 113 and 126 of the script. This is because the format string literals used in dozens of source files caused the compiler to crap out.

The second challenge is getting gcc 4.3.2 to build for the arm-elf target. It was looking for GMP (GNU Multi precision library) and MPFR (multi-precision float library). I got around that problem by adding --with-gmp=/opt/local --with-mpfr=/opt/local to the configure call for gcc-core. I installed GMP and MPFR from macports.org. The compile seemed to go well until died looking for iconv - unmatched symbols is the challenge. Yet iconv exists in /opt/local in my build machine. I have built newlib-1.16.0 and binutils-2.18.50 and have them in the install/ directory.

Has anyone succeeded in building the latest version of leJOS firmware on Mac OS?

Using the above instructions got me most of the way there. With a couple more additions to the build script, I was able to build things completely, although I haven't tested anything. Note, I'm also building things on Snow Leopard at this point, although I'm not sure it matters.

Code: Select all

Build complete! Add /Users/nate/src/lejos/trunk/nxtvm/platform/nxt/install/bin to your PATH to make arm-elf-gcc and friends accessible directly.


Like you, I installed GMP and MPFR via Mac ports, and iconv was installed at some point in the past via one of my previously installed ports. Aside from XCode, I'm not aware of any other dependencies, although there may be others I just don't know about.

Here are the relevant diffs from the latest build script build_arm_toolchain.sh as of SVN revision 5802:

Code: Select all

Index: build_arm_toolchain.sh
===================================================================
--- build_arm_toolchain.sh      (revision 5799)
+++ build_arm_toolchain.sh      (working copy)
@@ -83,8 +83,12 @@
 mkdir -p $BUILDDIR/$BINUTILS_DIR
 cd $BUILDDIR/$BINUTILS_DIR

+export CPPFLAGS=-I/opt/local/include
+export LDFLAGS=-L/opt/local/lib
 $SRCDIR/$BINUTILS_DIR/configure --target=arm-elf --prefix=$PREFIX \
-    --enable-interwork --enable-multilib --with-float=soft \
+    --enable-interwork --enable-multilib --with-float=soft --disable-werror \
+    --with-gmp=/opt/local --with-mpfr=/opt/local \
+    --with-libiconv-prefix=/opt/local \
     && make all install
 ) || exit 1

@@ -110,8 +114,9 @@

 $SRCDIR/$GCC_DIR/configure --target=arm-elf --prefix=$PREFIX \
     --enable-interwork --enable-multilib --with-float=soft \
-    --enable-languages="c" --with-newlib \
+    --enable-languages="c" --with-newlib --disable-werror \
     --with-headers=$SRCDIR/$NEWLIB_DIR/newlib/libc/include \
+    --with-gmp=/opt/local --with-mpfr=/opt/local --with-libiconv-prefix=/opt/local \
     && make all-gcc install-gcc
 ) || exit 1

@@ -123,7 +128,8 @@
 cd $BUILDDIR/$NEWLIB_DIR

 $SRCDIR/$NEWLIB_DIR/configure --target=arm-elf --prefix=$PREFIX \
-    --enable-interwork --enable-multilib --with-float=soft \
+    --enable-interwork --enable-multilib --with-float=soft --disable-werror \
+    --with-gmp=/opt/local --with-mpfr=/opt/local --with-libiconv-prefix=/opt/local \
     && make all install
 ) || exit 1


At some point I'll try these out to make sure I can build an image, but not today...


Nate