You may see that I have a lot of other ARM based projects at github,
I do have a lot of low level ARM experience, as well as a fair amount
with other platforms but never got into MIPS.  Have wanted to but
needed a starting place.

So this year I bought a couple of boards from Sparkfun.  The UBW32

http://www.sparkfun.com/products/8971

I bought is now retired and replaced with a newer one.  I dont know if
that is good or bad as I found PIC32MX4 tools after buying this CUI32
board

http://www.sparkfun.com/products/9645

Specifically this tool:

http://members.dslextreme.com/users/paintyourdragon/uc/ubw32/ubw32.tar.bz2

Linked to from this page:

http://www.paintyourdragon.com/uc/ubw32/index.html

Not without problems of course.  libhid-dev is apparently not supported
by Ubuntu, or at least 10.10.  10.04 does have it and I was able to
get the sources from debian/ubuntu for 10.04 and build and install
it on 10.10.  Have not tried the newer Ubuntu versions....

Building the Microchip pic32 compiler from sources was a bust, more
work than I was interested in when the current llvm and stock gcc
are so easy to come by.  I am not interested in canned libraries, and
$900 is way out of the hobby budget for such tools.

I did find that the Microchip c32 compiler is available in pre-built
32 and 64 bit Linux versions.  You have to pay to get -O2 to work.

Codesourcery is now completely Mentor Graphics, so we will see what
happens with that .  Hopefully they wont make the typical mistakes that
cause the product line and purchase of the company to be a bust for
the existing user base.

So I still have a lot to learn about MIPS and the instruction set, I
was able to get enough assembler going to boot and run some sample
programs.

These are NOT StickOS nor UBW32 programs.  These are C and/or assembly
programs that replace StickOS or UBW32.  You can always put that
firmware back on the board, so long as you dont mess up the lower
area of flash.  The xD000000 - xD005000 range of flash at a minimum
is preserved for the bootloader, between xD005000 and xD006000 is
for exception vectors or something like that and the user programs
can/should start at 0xxD006000.  Mess up the flash below 0xxD005000
and maybe you brick the board, maybe not, you have been warned.

I assume it may be crt0.o from the Mirochip tools, who knows but
the UB32 firmware .hex file used the physical addresses in the
0x1D006000+ range, but the first few instructions switched to a
0x9D006000+ range (thus the 0xxD006000 nomenclature above), so I made
my linker script cause the same to occur, executes as if it was
0x9Dxxxxxx but build a .hex file for 0x1Dxxxxxx.  Using 0x80000000
for ram goes along with the 0x9Dxxx flash and it appears to work just
fine so far.

Microchip is using little endian so -EL is used on all the gnu command
lines.  This is critical if you leave that off and get big endian
.hex files, well it wont work...

The ubw32 flash loader program did not like a type 05 entries in the
.hex file, probably a simple change in that program, which is not mine,
so I wrote a quick program that takes the binutils created .hex file
and creates another .hex file with the offending line removed.  The
ihex tool takes something.hex in and creates something.hex.hex.  The
.hex.hex file is the one you want to feed the ubw32 loader.

Codesourcery which I think is completely switched over to Mentor
Graphics now, is currently THE place for ARM based gcc tools, so I went
there to get MIPS based tools.  And that is what was used for gcc and
binutils with these examples.

I normally build the current llvm release (2.9 at the moment) as well
as a copy of the cutting edge trunk from the svn repo.  They take a
while to build, if you have a multi core processor using make -j num
makes a huge difference.  Their make file system is not perfect
so unfortunately you have to make clean if there have been changes.

LLVM is great as a cross compiler, you get all the targets in one
tool, unlike others where you have to compile a new toolchain for each
target.  Other than 32 vs 64 bit ints you can do most of your work
target independent and then the last step go from bitcode to target
specific assembler.  I use binutils assembler and linker to merge it
with startup code and other hand written assembler and take it to a
final binary.  I had some relocation problems both with gcc and llvm
using -G0 on the gnu side and -relocation-model=static or
-relocation-model=dynamic-no-pic with LLVM (llc).  As of this writing
for the blinker02 example both static and dynamic-no-pic produced the
exact same output.

Examine the makefile for more on how to use llvm
for cross compiling, at least one way to do it.  I find it best to
build all the C code, then use llvm-link to link into a single
bitcode file.  Then optimize at that point where the optimizer has
the most amount of meat to crunch on.  Then turn it into a single .s
file to feed binutils.

As of this writing there are only a couple of examples, an assembly only
example using a counter based delay, blinker01.  Blinker02 is a baseline
C based example.  Future examples will use more peripherals and get
progressively more complicated.  No desire to clone the Microchip
libraries or anything like that, take the programmers reference,
schematics and figure things out.


In case you want to roll your own tools that you can compile these
examples with here are some notes.  Binutils is used by both gcc and
llvm in these examples, gives you an assembler and linker which
is all you need if assembly language is what you are after.  If you run
linux/Ubuntu you probably already have a number of the development tools
as you are probably already a programmer/developer.  Things like
build-essential, automake, etc. you will need bison and flex which
you may not already have, and for the more recent gcc versions
libgmp3-dev, libmpfr-dev and libmpc-dev (apt-get install all of these
items BTW).

So binutils, at the time of this writing the most current is:
wget http://ftp.gnu.org/gnu/binutils/binutils-2.21.1a.tar.bz2

Note 2.22 fails to build for mips

> tar xjvf binutils-2.21.1a.tar.bz2
> cd binutils-2.21.1
> mkdir build
> cd build
> ../configure --target=mips-none-elf --prefix=/opt/mips-none-elf
this takes a bit, not long
> make
this takes longer depending on your machine, if you have multiple
cores then put the number of cores:
> make -j 4
this still takes a while but much faster in parallel.  you may figure
out on the way that you need to install something else and have to try
a few times.  using a directory (like build, it doesnt have to
be a subdir of the binutils sources) to configure/build in you can
easily just delete that directory instead of the whole binutils tree
to start over fresh.  when you get a clean build then
> make install
that might need a sudo on it...

Add this to your path so gas and ld are available for the gcc build.
> PATH=/opt/mips-none-elf/bin:$PATH

Now for gcc if you are interested
>wget http://ftp.gnu.org/gnu/gcc/gcc-4.6.1/gcc-core-4.6.1.tar.gz
>tar xzvf gcc-core-4.6.1.tar.gz
> cd gcc-4.6.1
> mkdir build
> cd build
>../configure --target=mips-none-elf --prefix=/opt/mips-none-elf \
>--disable-nls --enable-languages=c --disable-libssp --disable-libmudflap \
>--disable-libquadmath --without-headers --with-newlib
takes a while, not long
>make
takes a really long time, multi core or fast computer makes a huge
difference, put the number of cores in there
>make -j 4
same deal, if you didnt get libmpfr or libmpc for example you will
have to keep trying.  not long ago a single apt-get install libmpfr-dev
would give you the things you needed for building gcc, then it was that
you had to do both libmpfr and libgmp3, now you have to manually do all
three libmpfr-dev, libgmp3-dev and libmpc-dev.  to get a gcc 4.6 built.
of course I am running an older Ubuntu 10.04 LTS. and 10.10 on some
machines.  when gcc finishes building successfully
>make install
I dont know if that needs a sudo or not, it might.

Now anytime you want to use it PATH=/opt/mips-none-elf/bin:$PATH
tools are mips-none-elf-gcc, mips-none-elf-as, etc.

When using with my Makefiles either:
> make MIPSGNU=mips-none-elf
Or change the line in the makefile to use the alternate prefix.  It is
possible the tools will build for you with the same prefix as
Codesourcery used.  mips-sde-elf.


Building the llvm 29 release

>svn co http://llvm.org/svn/llvm-project/llvm/branches/release_29/ llvm29
>cd llvm29
>cd tools
>svn co http://llvm.org/svn/llvm-project/cfe/branches/release_29/ clang
>cd ..
>./configure --enable-optimized --disable-doxygen --prefix=/llvm29
>make
takes forever, -j num helps greatly. can change it from go get lunch
amount of time to go get a coke from the coke machine amount of time.
>make install


Building the trunk is as simple:

>svn co http://llvm.org/svn/llvm-project/llvm/trunk llvm
>cd llvm
>cd tools
>svn co http://llvm.org/svn/llvm-project/cfe/trunk clang
>cd ..
>./configure --enable-optimized --disable-doxygen --prefix=/llvm
>make
>make install

For both from your toplevel llvm or llvm29 source directory

> make update

will pull in svn updates for both llvm trunk and clang trunk.  The
cutting edge development will have daily activity and there are definitely
times where some checkins do not work, sometimes you are doing a
update while pushes are going in, so I normally do two or three
make updates in a row to wait for no activity.  Definitely, unfortunately
do a make clean to clean out intermediate files, unfortunately the
make system doesnt catch everything, the make, make install again.
If it fails to build, try some more make updates or wait for a while
for whomever to find the build bug and fix it and check in a patch.

A/The reason for having the trunk is that when you find and want to file
a bug you may find that a number of them have been found and fixed and
by running the prior release, it is stable but does not have all
bugfixes backported, if any.

The above (gcc) does not necessarily give you a C library, or even gcc
library for that matter, I have no use for those in an embedded
environment so it doesnt bother me.  It might bother you, so more work
may be required. Likewise I dont use C++ so I use the core gcc tarball
not the full gcc tarball.  With gcc in general you are likely to have
floating point problems, with this chip not having an fpu (well I dont
see it mentioned in the docs) a soft fpu with gcc is that much more
painful.  Here again I have no use for floating point in embedded work
so these tools usually work great for me.

Apple has put a lot of resources into llvm development putting the results
back into the open source world.  The last couple bugs I filed were
handled by @apple.com email addresses during weekday work hours.  I think
llvm is used for iphone app development so the core compile and at least
arm backend is maturing nicely.