So it can now be installed by running:

yum install msp430-binutils

Or, if you’re of PackageKit persuasion:

pkcon install msp430-binutils

msp430-binutils contains a number of tools for working with msp430 binaries. The ones that people will use the most are likely to be the assembler and linker. These are a requirement for the compiler, which I have packaged, but have yet to submit to Fedora. Hopefully I will get gcc in there over the next week — closely followed by the rest of the mspgcc toolchain.

Those who manually installed my packages will get the update through the normal Fedora update sources.

Above image derived from the Tango Desktop Project — CC-SA licence.

Update (5/2/2009): I forgot to mention that this is part of the toolchain required to build the software for the Formica robots!

su -c "cp /lib/firmware/ti_3410.fw /lib/firmware/ti_usb-3410.bin"

I’ll look into whether there are any open bugs on this soon.

I decided that my time would be better invested if I finished packaging msp430-gdb rather than performing another source install on someone else’s machine. Whilst I was at it, I also packaged msp430-gdbproxy and the udev rule required to get the UIF to work.

Now all the mspgcc packages are available for Fedora 9:

• msp430-binutils 2.18
• msp430-gcc 3.2.3
• msp430-libc (from CVS on 2008-08-28)
• msp430-gdb 6.8
• msp430-gdbproxy 0.7 (includes udev rule).

You’ll find the specfiles and source RPMs in the same directory.

You can install them all by running:

su -c "rpm -Uvh http://users.ecs.soton.ac.uk/rds/rpm/mspgcc/msp430-binutils-2.18-1.fc9.i386.rpm \
http://users.ecs.soton.ac.uk/rds/rpm/mspgcc/msp430-gcc-3.2.3-1.20080827cvs.fc9.i386.rpm \
http://users.ecs.soton.ac.uk/rds/rpm/mspgcc/msp430-libc-0-1.20080828cvs.fc9.noarch.rpm \
http://users.ecs.soton.ac.uk/rds/rpm/mspgcc/msp430-gdb-6.8-1.fc9.i386.rpm \
http://users.ecs.soton.ac.uk/rds/rpm/mspgcc/msp430-gdbproxy-0.7.1-1.fc9.i386.rpm"

I’m still waiting for someone to review my request to get binutils for msp430 into Fedora. :-/

I haven’t done GDB yet, but hope to over the next few days.

Update (13/12/2008): I’ve since built these RPMs for Fedora 10. Find them here.

About 10 builds and 20 reboots later, I found the commit in which the problem was happening, and then read some stuff about USB etc (the LWN device drivers book proved invaluable yet again) and subsequently generated a patch. I’ve sent it to (what I think are) the right places.

If you can’t wait for the next kernel release (if it passes review…), then you can rebuild the ti_usb_3410_5052 module by downloading this tarball, untarring it and then running “make” in the resulting directory, and then “make install” as root. You will need enough of your kernel’s sources hanging around to do this. In Fedora, these are provided in the kernel-devel package.

Update (5th April ’08): The patch has made its way into Linus’s tree, so I think it’ll be in 2.6.25.

I clicked “Yes” (I’d click “always”, but this was on a Live CD so it wouldn’t really have meaning), and then it popped up with:

Pretty cool. It didn’t ask me for any of my details, which I think is cool. Going to kerneloops.org reveals that it exists to track which crash signatures occur the most.

It located a couple of adjacent ext3 partitions (Phil’s Fedora and Ubuntu roots) and generated some overlapping numbers for them. I had to manually edit the partition table using sfdisk to get it right. I particularly enjoyed the rollback-like features that sfdisk has (using -O and -I). I had to tell sfdisk to use sector units because it defaults to cylinders.

Then Phil gave me food. Excellent. Technical support for food.

Got a couple of management textbooks out from the library earlier. They’re really boring. Seem to be stating the obvious. Joy.

• I started the week with little understanding of the Linux ARM boot process, Steve’s NSLU2 and the need to get a working Linux install on it. Tom and I spent a considerable amount of time working on getting it to work. Almost all of the problem was because for some (yet to be fully determined) reason, the kernel is passed an incorrect machine code by redboot. Whether this is because someone’s flashed the slug in the past, I don’t know. I ended the week with an understanding of the ARM MMU, linux ARM boot process and a working booting slug with functioning network adapter :-)
• I created my first RPM. :-D I spent christmas eve reading various documentation on the subject, and so have packaged my yum plugin. I’ve stuck the spec file, srpm and rpm up for public access.