This article contains my notes for setting up a m68k cross-compiler using Cygwin. It’s all free software and gives me a way to create binary images for a 68000 CPU from C code on Windows. Here’s the step-by-step to set it up:

Step 1. Install Cygwin

Go to http://www.cygwin.com/ and download setup.exe. Run it.

During the setup, you will have the opportunity to select what packages to install. Choose the following:

• binutils
• gcc-core
• bzip2
• flex
• make

Step 2. Download the compiler source code

You want binutils and gcc-core from GNU. Go to the GNU download page, choose a mirror and download the following files. Place them in your Cygwin home directory.

• binutils-2.15.tar.bz2
• gcc-core-3.4.2.tar.bz2

Yes there are more up-to-date versions but at the time of writing, the latest gcc versions do not support the 68000 platform. Feel free to try different versions but I know the versions just mentioned will work.

Step 3. Compile and install binutils

Launch Cygwin and type the following commands. Typing this kind of stuff is automatic for me these days. Its a pretty standard GNU setup procedure.

mkdir /usr/local/m68k

tar jxvf binutils-2.15.tar.bz2

cd binutils-2.15/

./configure --prefix=/usr/local/m68k --target=m68k-coff

make install

Step 4. Compile and install gcc

Same again for the C compiler.

cd ~

export PATH=$PATH:/usr/local/m68k/bin

tar jxvf gcc-core-3.4.2.tar.bz2

cd gcc-core-3.4.2/

./configure --prefix=/usr/local/m68k --target=m68k-coff --enable-languages=c

make install

Step 5. Set up your path

The 68000 compiler will be located in /usr/local/m68k/bin. To make life easier, you might like to add the following to your ~/.bashrc file:

export PATH=$PATH:/usr/local/m68k/bin

Step 6. Enjoy

Here’s the command to compile some C code:

m68k-coff-gcc -o test.out test.c

And the command to create a binary image from the compiled code:

m68k-coff-objcopy -O binary test.out test.bin

I have here a server (Debian Linux of course) which is storing its data on a 1TB hard drive. I want to upgrade the storage to a RAID5 using 4x 1TB drives. I’d like the existing drive to be a part of the RAID array so I only need to buy 3 new drives, but I don’t want to lose the 600G or so of data on it.

The solution ? Set up a degraded array, copy the data and then add the original disk to the array.

Put simply, a degraded array is a RAID array with one or more drives missing. RAID5 can operate with any one drive down. This is very useful if a drive fails, you can replace the faulty drive without losing any data. So we are going to pretend the drive with the data on it is ‘faulty’ so it won’t be part of the RAID until later when we miraculously ‘fix’ it.

On my machine, the new drives are /dev/sde, /dev/sdf and /dev/sdg. The drive with the data is /dev/sdh1. First we partition the new drives. You’ll need to type these two commands for each new drive:

echo ",,L" | sfdisk /dev/sde

sfdisk --change-id /dev/sd1 1 fd

You don’t have to use sfdisk, as long as you set up the partitions somehow and set them to type 0xFD (Linux RAID).

Now to create the degraded array. This is the magic bit.

mdadm --create /dev/md3 --level=5 --raid-devices=4 --spare-devices=0 /dev/sde1 /dev/sdf1 /dev/sdg1 missing

The magic word missing stands in for the drive with the data on it.

Next format the RAID array, mount the data drive and copy the data

mkfs.xfs /dev/md3

mount /dev/md3 /home/adam

mount /dev/sdh1 /mnt

cp -prv /mnt/* /home/adam/

This will take a while so you might want to do it in a screen session.

Finally, after the data is copied, we can add the data drive to the array. This is the bit where we can lose everything if it goes wrong so check your data is all on the RAID before proceeding.

umount /dev/sdh1

sfdisk --change-id /dev/sdh 1 fd

mdadm --manage /dev/md3 --add /dev/sdh1

I’m really pleased at this neat trick. I’ve now got a shiny RAID array with a total storage of 3TB. It all worked so well, I just had to blog about it!

Its nice to know that while I was obsessing over my circuit board, the kids were busy making stuff too. A wonderful Mudistrone Soup!

They are so proud of it.

I have a machine with about 8 SATA hard drives in it some of which are connected to a PCI controller card and some are on the motherboard. I have an issue with Debian that it keeps swapping the device nodes around on reboot. Sometimes the first drive will be /dev/sda, other times it will be /dev/sde. Somehow the system manages to boot up OK but when it comes time to mount the drives, all hell breaks loose!

My solution is to mount the drives by their UUID rather than by their device node. It took me quite a bit of Googling to find an example of how to do this so I thought I’d write it here so I will know for next time.

Normally, I’d put an entry in /etc/fstab like this to mount a drive:

/dev/sdb1  /var/www  ext3  defaults  0  2

But now I change it like so:

UUID=bd412298-d540-4e4e-8f31-33ff45644bc4  /var/www  ext3  defaults  0  2

You’ll notice it is exactly the same except I have used the UUID instead of /dev/sdb1.

But wait! I hear you ask, how do you find out what your drive’s UUID is ?

Well, I have the answer for that too:

ls -l /dev/disk/by-uuid/

I’ve got a Debian machine here which is set up for TV recording. It is fully stacked with 2 x cx88 DTV cards and 3 x PVR150 cards using the IVTV driver. I’m running Debian Etch which comes with version 0.8.2 of the ivtv driver at the time of writing.

The problem is that the PVR150 cards sometimes register themselves as /dev/video0, 1 and 2 but other times, after a reboot they register themselves as /dev/video2, 3 and 4. I needed some way to make them stay on the same device nodes.

Enter this little UDEV rules file I wrote. It creates new device nodes called /dev/ivtvenc0, /dev/ivtvenc1 etc. up to however many cards you have. These will symlink to the correct device nodes every time. Here’s the script. Call it 010_ivtv.rules and put it in /etc/udev/rules.d/

# Rule to sort out those pesky IVTV cards which never
# seem to load in the correct order when DTV cards are
# also installed.
# by Adam Pierce 01-Feb-2008

ATTR{name}=="ivtv0 encoder MPEG",SYMLINK+="ivtvenc0"
ATTR{name}=="ivtv1 encoder MPEG",SYMLINK+="ivtvenc1"
ATTR{name}=="ivtv2 encoder MPEG",SYMLINK+="ivtvenc2"
ATTR{name}=="ivtv3 encoder MPEG",SYMLINK+="ivtvenc3"
ATTR{name}=="ivtv4 encoder MPEG",SYMLINK+="ivtvenc4"
ATTR{name}=="ivtv5 encoder MPEG",SYMLINK+="ivtvenc5"
ATTR{name}=="ivtv6 encoder MPEG",SYMLINK+="ivtvenc6"
ATTR{name}=="ivtv7 encoder MPEG",SYMLINK+="ivtvenc7"

Watch it in action. Here it is after one reboot:

# ls -l /dev/ivtv*
lrwxrwxrwx 1 root root 6 2008-02-01 13:54 /dev/ivtvenc0 -> video0
lrwxrwxrwx 1 root root 6 2008-02-01 13:54 /dev/ivtvenc1 -> video1
lrwxrwxrwx 1 root root 6 2008-02-01 13:54 /dev/ivtvenc2 -> video2

And again after the next reboot

# ls -l /dev/ivtv*
lrwxrwxrwx 1 root root 6 2008-02-01 13:54 /dev/ivtvenc0 -> video2
lrwxrwxrwx 1 root root 6 2008-02-01 13:54 /dev/ivtvenc1 -> video3
lrwxrwxrwx 1 root root 6 2008-02-01 13:54 /dev/ivtvenc2 -> video4

Now I can always rely on the ivtvenc device nodes to point at the right cards.