These patches to the mainline GNU projects binutils and gcc are necessary to compile firmware for the Alteon Tigon2 NIC. The original patches were developed by Jamie Lokier at CERN and are available here. The versions below have been modified somewhat and applied to more recent binutils and gcc source versions.
Also take a look at http://alteon.shareable.org/ where it appears that Jamie has made available the original Alteon firmware and documentation too, as well as the CERN patches mentioned above. Note that this original firmware might very well have some bugs which are exposed only by more recent versions of gcc. If you are not getting the results you expect, do try gcc-2.95 which is known to compile it.
I modified it just a bit to port to more recent versions, and removed the soft-mult and -div features. They are nice, but for writing firmware I explicitly do not want to have the compiler emulate any instructions. Instead, I get an error from the assembler which points me to change the firmware code not to be so inefficient (and generate the bitshifts manually if necessary).
If you'd rather just download a directory of a comfortably working gcc3-based toolset for alteon2 hosted on x86, compiled using gcc-3.2 on redhat 8.0, this tarball will expand into a directory "tools" containing bin, lib, etc. directories. See below for patches to gcc source.
Here are my current patches, against a stock binutils distribution, and against a certain gcc snapshot. Just the core part of the gcc distribution is necessary, unless you want to run Java in the firmware. :) Pick the one at the top of each list for the most recent toolset. Note that some of these are against snapshot distributions, not against any production version of gcc or binutils, if you see a date as opposed to some dots in the name of gcc or binutils. You will most likely want to stick with the releases proper.
Binutils
GCC
I do roughly the following to build. Don't type this directly, but you'll see what I mean.
# get GNU stock distributions wget ftp://ftp.gnu.org/pub/gnu/gcc/gcc-3.2.1/gcc-core-3.2.1.tar.gz wget ftp://ftp.gnu.org/pub/gnu/binutils/binutils-2.13.2.1.tar.bz2 # untar and apply patches bzcat binutils-2.13.2.1.tar.bz2 | tar xf - gzip -dc tigon-binutils-2.13.2.1.diff.gz | patch -d binutils-2.13.2.1 -p1 -sNE gzip -dc gcc-core-3.2.1.tar.gz | tar xf - gzip -dc tigon-gcc-core-3.2.1.diff.gz | patch -d gcc-3.2.1 -p1 -sNE # build and install binutils mkdir build ; cd build ../binutils-2.13.2.1/configure --target=mips-alteon-elf \ --prefix=/home/pw/gige/tools make make install cd .. ; rm -rf build # build and install gcc mkdir build ; cd build ../gcc-3.2.1/configure --target=mips-alteon-elf --prefix=/home/pw/gige/tools make make install cd .. ; rm -rf build # rename binaries since I know better than to have this in my path cd /home/pw/gige/tools/bin for i in * ; do mv $i $(echo $i | sed s/mips-alteon-elf-//); done # done
The most effective way I have found to debug the firmware is using a trace log which can be read out by the host on demand. This is equivalent to good old printf-style debugging, but is really the best way if you understand the code. You can see one implementation of a trace mechanism in the EMP project.
However, people do seem to like to use the GNU debugger, GDB, and it can be made to work against the firmware although a few things don't work completely. First, compile your firmware with `-g' or maybe `-g -O2'. You may find that turning off optimization completely breaks the code, perhaps due to improper abuse of inline assembly. Load this firmware and start it running.
Go compile a GDB which has as its target the Alteon card modified MIPS architecture, pointing it to your previous binutils build. Note that it is not necessary to patch GDB at all.
mkdir build cd build ../gdb-5.1/configure --target=mips-alteon-elf --prefix=/home/pw/gige/tools \ --program-prefix= --enable-sim=no make make install cd .. rm -rf build
Next, compile the GDB Alteon target backend. There are two target flavors included in the distribution, which vary on how they access card registers. The first, be_alteon, relies on a modified kernel driver to poke card registers. The second, be_emp, depends on having a user-space mapping of the card PCI memory space. You can find old patches against the linux kernel acenic driver here and I'd be happy to offer an updated version of this patch if anybody got around to modernizing it. Again, see EMP if you want to go the userspace mapping route. Thanks to Austin Donnelly for contributing this gdbstub code and the be_alteon target, which was developed as part of the Arsenic project.
The backend process must run on the machine which hosts the NIC card:
cd gdbstub ./gdbstub &
The gdb process itself can run anywhere, you just have to point across the network to the machine which has the NIC. Be sure to run the special gdb, not the one in /usr/bin, on your firmware executable:
$ ../tools/bin/gdb my_firmware (gdb) target remote frag:5000
Use `localhost' or the actual remote machine name instead of `frag' above. Debug as normal, using `break', `continue', `step', etc.
If you try to compile the "stock" firmware from Alteon and notice that it does not seem to work, you probably want to apply this patch to fwmain.c. Notice the addition of the ampersands.
/* main dispatcher loop */ __asm__ volatile (" .set noreorder .globl _disp_loop _disp_loop: lw %0,0x60($28) # load event register pri %1,%0,%2 # determine next event joff %1,%3 # jump to next event move $31,%4 .set reorder nop halt /* & means don't clobber inputs --pw */ " : "=&r" (events), "=&r" (high_event) : "r" (event_mask), "r" (ev_handlerp), "r" (dispp) );
Back to index
Last update 18 Mar 2005.