GetTickCount() is a real handy function in Windows but does not exist in Linux. This code will give a similar result:

#include <sys/time.h>

unsigned GetTickCount()
{
        struct timeval tv;
        if(gettimeofday(&tv, NULL) != 0)
                return 0;

        return (tv.tv_sec * 1000) + (tv.tv_usec / 1000);
}

After doing a dist-upgrade on a Debian Etch system, it would no longer boot! It loads the kernel and then stops displaying the following message:

Waiting for root filesystem

I’ve just spent a few torturous hours trying to get it back up again. It took me a while to figure out what was happening but it seems that the updated package for UDEV changes the GRUB configuration so it tries to mount hdb1 instead of hda1 as the root file system. Of course hdb1 does not exist on this single-drive machine so it just sits there like a moron.

Turns out it is not frozen. If you wait about 3 minutes, it will eventually come up with the following prompt:

(initfs)

I found that I can kind of get the system running by typing the following commands. These are for a single-partition system on an EXT3 file system on an IDE hard drive. If your system is different, you will need to modify them a bit:

mkdir /mnt

mount /dev/hda1 -t ext3 /mnt

chroot /mnt

login

Then log in. The next thing to do is to correct the GRUB configuration:

nano -w /boot/grub/menu.lst

Change the root=/dev/sdb1 entry to root=/dev/sda1. Once again, this is for a single IDE drive, you may need to change it if you are booting from SATA or some other kind of device.

Now regenerate the initramfs image:

dpkg-reconfigure initramfs-tools

At last we can reboot. The system came up fine for me after this.

reboot

Well folks, I just got saddled with this Adaptec/Marvel piece of poo and now I have to make it work on a Debian server. The server belongs to my employer and is running Debian “Etch”.

The Etch release of Debian does not have a driver for this card built-in and even though Adaptec claim to support Linux, their drivers simply do not work unless you are running some specific outdated versions of Red Hat or SUSE. That’s not what I call Linux support!

I’m not the only one discovering this, Brent Norris wrote a wonderful article titled “Adaptec 1420SA is JUNK!” on his blog which describes pretty much the exact situation I find myself in which Adaptec just doesn’t want to know about Linux.

When are these guys (by whom I mean most major hardware manufacturers) going to realize that Linux is here to stay and is getting real popular, especially in the server room.

Anyway, enough ranting. After a couple of hours Googling around, I see that there is an open source driver available for this card and it is built into Linux kernel version 2.6.22. Debian Etch uses 2.6.18 so all I need to do is upgrade the kernel.

The easiest way to install the upgraded kernel is to get a DEB package from Debian Backports. Go to this page:

http://packages.debian.org/etch-backports/admin/

and grab a kernel, there are usually a couple of different versions available there.

Install it and reboot. Works great so far.

PS. I notice that the driver for this card was released into the Linux kernel by Red Hat corporation. So it seems even they are fed up with Adaptec’s poor support for Linux!

I’m astonished how quickly CDs and DVDs are going the way of the Fondue Fork. Seems that everyone is downloading stuff these days and USB devices have exceeded DVDs in capacity already.

I can see it won’t be long before DVD drives will be an optional extra on new PCs (especially laptops) and will eventually disappear like floppy drives (remember them ?).

So it’s time to look at installing from USB on a machine which has no disc drive at all. I’ve found a few guides out there on the internet but none of them were easy to follow. I had to read several of them and then I still had to guess at stuff that wasn’t mentioned.

So here is my guide which is a little more comprehensive.

NOTE 2: I’m assuming you are logged in as a regular user. if you are logged in as root, just drop “sudo” off the beginning of all these commands.

Step 1 - Download the installation image

While there are several “small” installs for putting on a credit-card CD and so on, USB sticks are now large enough that you can use a normal install CD image. I am going to use the Debian Net Install which weighs in at around 160MB. This should easily fit on a 256MB device which quite frankly, people throw away these days because it is so uncool to have such a small device dangling from your keyring.

Go to http://www.debian.org/CD/netinst/ and download the netinst image for your platfom (if you don’t know, it’s probably i386).

Step 2 - Partition and Format the USB device

Most USB keys come pre-formatted with a FAT16 or FAT32 file system. If this is the case with your stick, just erase all the files on it and proceed to Step 3.

But of course, I had previously formatted mine with EXT3 so I’ll need to reformat it with a DOS format.

First set the partition type to DOS

sudo sfdisk -c /dev/sdb 1 c

Next, format the partition.

sudo mkdosfs /dev/sdb1

Step 3 - Obtain a kernel and RAMdisk image

Next you need an hd-install kernel and initrd image. You can download these from Debian also. For the current version of the kernel, they should be available from here:

http://ftp.debian.org/debian/dists/stable/main/installer-i386/current/images/hd-media/

Grab the two files vmlinuz and initrd.gz then mount your USB device and copy them onto it:

sudo mount /dev/sdb1 /mnt

sudo cp vmlinuz /mnt/

sudo cp initrd.gz /mnt/

Then you will need to make a file on the USB device called syslinux.cfg - just create a plain text file. Cut and paste the following two lines into it:

default vmlinuz
append initrd=initrd.gz

Step 4 - Copy the installation image

Next copy the ISO file you downloaded onto the USB device. From the commandline you can do it like this:

sudo cp debian-40r3-i386-netinst.iso /mnt/

Step 5 - Make the device bootable

You will need to have a couple of additional packages installed to do this:

sudo apt-get install syslinux mtools

Type these commands to make the stick bootable:

sudo syslinux /dev/sdb1

sudo install-mbr -r -p 1 /dev/sdb

Now you can unmount the USB device and you are good to go!

sudo umount /mnt/usb

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!

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.

Now that my pan is ready, it is time to do this. First I needed a board. I got one of my designs prototyped by Batch PCB who are cheap and did a good job but I had to wait about six weeks which is OK for hobbyists but I wouldn’t want to be in a hurry.

This solder paste stuff is pretty toxic. Perhaps I’m going overboard here but I thought some rubber gloves would be a good idea.


To apply the paste, I just squirted it on the board. It kinda went everywhere at first until I got the hang of it. Next time I’ll get a smaller tube and perhaps a smaller nozzle. I fixed it up as best I could using a toothpick and cotton tips. It took quite a lot longer and was much more messy than I anticipated.


Next comes the pick-and-place. I got most of my parts from Digi-key who send them out as “Cut tape” which is pretty convenient, you just peel the backing off the tape until you get the quantity of parts you need and the rest are left still attached to the tape so you don’t lose them in the carpet. I positioned the parts with tweezers since most of them are incredibly teeny.

My board includes both surface-mount and through-hole components. I just placed the SMT stuff at this stage because I need the back of the board to be flat for heat transfer.

Now for the fun bit. I put the loaded board onto the pan cold. Then I increased temperature to around 100°C. I left it at that heat for a minute to get everything nice and warm. Then I cranked up the heat to maximum (in my case, 175°) until the solder melted. It was magic to watch. Everything just blobbed into place. Even components which were not exactly positioned right pulled themselves into line.

After a slow cool-down over 5 minutes, I examined the board. Everything looks good to my eye except for some pretty major bridging between the pins of my ARM chip. I’ll leave dealing with these to part 3.

In the end though, I’m pretty pleased with the result. Not bad for my first try!

I’ve been dying to have a go at this ever since I read some hobbyist websites on how to do solder reflow at home. I never even thought this was possible to do on a hobbyist budget.

The idea is to use a frying pan or toaster oven to perform solder reflow for SMT circuit boards. I decided to use a skillet thinking that a toaster oven would melt components since it heats both top and bottom.

I managed to find the perfect thing. A pre-owned 9″ electric skillet from the Salvation Army shop for $3.

Believe it or not, this device is not a precision instrument. The temperature dial is simply numbered from 1 to 10. The first thing I need to do is get some idea of what actual temperature this thing gets to.


So I need to do a scientific experiment. Firstly I put some oil in the pan and stuck in a thermometer (the fork is to hold the probe in the oil). Then I turned up the heat slowly making a note of the temperature. Finally I graphed the result. Here are the results in degrees C. That cheap little temperature knob is surprisingly linear.

1. Element not energized
2. 30°
3. 46°
4. 65°
5. 90°
6. 105°
7. 125°
8. 140°
9. >150°
10. >150°

The last two entries I could not measure since the thermometer only went up to 150°C, but by extrapolation I get 155° and 175°. Yes I did this on paper, it is much quicker than using Excel!

I am now ready to use this thing for solder reflow.