5. Client side software

The name of this section is rather misleading - since we are booting the system remotly, all the software is not located on the client, but rather on the server. The software, which includes the Linux kernel and a small Linux distribution is under 2MB of space. It could probably be squished into 1.44MB (so that it would fit onto a floppy) but its more fun to remotly boot the MP3-box, and not use floppies. The Linux kernel used was 2.2.16. Any versions can be used. The mini-distribution used is LRP - it normally fits on a 1.44 floppy compressed. The only thing that was left from the original mini-distribution is the binaries - the rest was changed by me.

5.1 Linux kernel

Making a new kernel for the MP3-box is a necessity. Your sound card will inevitable different than mine, and you might have a different network card.

The Linux kernel tree that I used is supplied. Look in:

2nd Step - configuring client/01 - linux kernel/linux-2.2.16

and type:

cd "2nd Step - configuring client/01 - linux kernel/linux-2.2.16"
make menuconfig

After successfully choosing your drivers, make the kernel. Copy your new kernel 2nd Step - configuring client/01 - linux kernel/linux-2.2.16/arch/i386/boot/bzImage into your tftpboot directory as linux.1 (not as linux.0!)

cd "2nd Step - configuring client/01 - linux kernel/linux-2.2.16"
make bzImage
cp arch/i386/boot/bzImage /tftpboot/X86PC/UNDI/linux-install

Presumably, you configured your network, sound drivers as modules. It will be necessary to compile them and put them in temporary directory (until you get the the mini-distribution setup). To compile and install in temporary directory do:

export INSTALL_MOD_PATH=/tmp
make modules;make modules_install

5.2 Linux filesystem

We need to make a filesystem that the Network Boot Program can download from the server, and pass to the kernel. The maximum size of such filesystem is limited to the amount of memory in the machine, but generally it shouldn't be bigger than 4MB.

Since we want to boot the MP3-box from the network, and have no media storage device on the MP3-box, the filesystem cannot be on a harddrive, floppy drive, nor ZIP drive. Linux provides a facility for that called Initial RAM Disk (initrd) - its a file, which actually is a ext2 filesystem embedded in a file.

Creating initrd filesystem.

To understand why we need to create a INITial Ram Disk filesystem, its necessary to understand how Linux boots up.

• After the kernel is finished loading itself, it starts executing itself.
• The kernel converts initrd (which the boot loader loads into memory as linux.2) into a "normal" RAM disk.
• When its done, it mounts the device specified in root_dev (which is changed by the Network Boot Program). This usually points to /dev/ram0 or /dev/ram1.
• /linuxrc is executed.
• When linuxrc terminates, the "real" root file system is mounted (which can be the RAM disk)
• /sbin/init is invoked.

For more info, man initrd.

Creating initrd fs.

The initrd - is a initial ram disk embedded inside a file. Creation of such a file is quite straightforward (you have to be root to use losetup).

dd if=/dev/zero of=/root/initrd count=4096 bs=1024
losetup /dev/loop0 /root/initrd
mke2fs /dev/loop0
losetup -d /dev/loop0
file /root/initrd

Mounting initrd fs.

To use the initrd for something its necessary to make a mount-point a mount the initrd file:

mkdir /data
mount /root/initrd /data -o loop

Copying LRP filesystem to initrd fs.

Its time to put something meaningful on the 4MB initrd. We need to copy a small linux distribution onto the initrd, otherwise we can't use it boot the MP3-box.

cd "2nd Step - configuring client/02 - the filesystem"
tar -cf - * | (cd /data; tar -xvf - )

Copying custom modules,

Do you remember the modules that we compiled in the previous section?

cp -Rf /tmp/lib/modules/2.2.16/* ./data/lib/modules/2.2.16
sync
df -h

Preparing the initrd fs for NBP.

Using the initrd file generally means we have to unmount the file, gzip it and copy it into the tftpboot directory.

umount /data
sync
gzip -c9 /root/initrd  > /tftpboot/X86PC/UNDI/linux-install/linux.2

Conclusion

That's basicly the method of designing and using an initrd filesystem. One thing to keep in mind - the initrd should always be compressed when deployed.

5.3 Configuring NBP (Network Boot Program).

After you have copied your initrd file and tried to boot up the workstation, you found out that the kernel complains about not being able to mount the root partition. The problem lies in the NBP that is supplied with PXE - it was compiled for RedHat type initrd images, and therefore does some changes to the kernel.

• When the NBP is finished downloading the kernel, it sets the root_dev environment to whatever was compiled inside the NBP. By default, that is 0101, which is /dev/ram1 (look at its major, minor).
• NBP passes the environment to kernel (in and in turn overwriting whatever settings the user supplied to the kernel using rdev) and starts it.
• The kernel happily executes and tries to mount a filesystem from /dev/ram1>, while the initrd image sits in /dev/ram0.
• The kernel hangs.

1st Step - configuring server/02 - pxe/pxe/pxe-linux/nbp.linux/prepare.c. Line 212 lists the hexadecimal address. Change it to 0x0100 - that way the kernel will mount /dev/ram0 and actually find a initrd filesystem.

5.4 Configuring startup scripts.

When the kernel completes loading the initrd into memory and mounts it as a filesystem, then /sbin/init is executed, which handles the rest of starting the operating system.

• init reads in /etc/inittab - which lists which scripts must be executed depending on the computer's state.
• It starts executing the boot-time configuration script /etc/rc.d/rc.boot.
• rc.boot setups BusyBox and POSIX links, configures all the modules - sound, network, and filesystem. If you are using your own modules, you must edit this file and change the settings.
• Then init changes the runlevel to its default - 2, which result in running /etc/rc.d/rc.multi.
• rc.multi setups the network card (configures its IP), mounts the NFS server and starts the audio-subsystem (/etc/rc.d/rc.audio). It gets all the custom configuration (where is the NFS server. its IP, etc) from /etc/rc.conf.
• rc.audio configures the sound, creates playlists, and starts the ARCamp program (which listens to the remote and runs/kills mpg123).

The scripts were made as simple as possible. The files you ought to look into and alter are:

• /etc/rc.conf - has the NFS IP, the mountpoint, and the client's IP
• /etc/rc.d/rc.boot - loads the network module, and the filesystem module.
• /etc/rc.d/rc.audio - loads the sound card module.

5.5 Configuring the infrared receiver program.

The Logitech Remote I obtained was quite easy to get working with Linux. The software used in Linux was ARCaMP (AST Remote control MP3 Player). The software basicly listens at the serial port for some predefined characters, and based on them, launches mpg123.

Getting scan-codes.

The source code is included in 2nd Step - configuring client/99 - the sources/ARCaMP. It differs from the original code - the key mappings are different and the default playlist has been altered. If you find out that the program works with your remote, but the buttons -> action mappings are screwed up, then edit the defs.h to match your scan-codes with your remote. Getting the scan-codes is quite easy:

cat /dev/ttyS1 | od -t x2
0000000 2000 7f10 7f10 7f10 7f10 7f10 7f10 7f10
0000020 7f10 7f10 202a 7f10 7f10 7f10 7f10 7f10
0000040 7f10 7f10 7f10 7f10 7f10 7f10 202a 7f10
0000060 7f10 7f10 7f10 7f10 7f10 7f10 7f10 202a
0000100 0f0f 0f0f 0f0f 0f0f 0f0f 2a0f 0f20 0f0f
0000120 0f0f 0f0f 0f0f 2a0f 0f20 0f0f 0f0f 0f0f
0000140 0f0f 0f0f 202a 1212 1212 1212 1212 2a12
0000160 1220 1212 1212 1212 1212 2a12 1220 1212
0000200 1212 1212 1212 1212 1212 202a 1212 1212

The first eight bytes are just offset locations - ignore them. If you look closely at the strings it becomes clear that whenever you hit a the same button on the remote, you get similar looking strings of numbers. The first three rows are actually the fastforward button being hit three times. The repetition of ox20, ox2A, 0x7F, and 0x10 suggest that 0x20 and/or 9x2A are remote-id number, while 0x7F or 0x10 are codes for fastforward.

The next three rows are for the play button (the scancode is 0x0F). And as you can see, the repetition of 0x20, 0x2A suggest remote-id again.

The last three rows are for the stop button - 0x12.

Compiling ARCaMP.

Just run make and copy the arcamp file into /data/bin directory - assuming you still have the initrd filesystem mounted under /data.

Different remote.

If you have different remote, and the scancode-match procedure doesn't work, then you won't be able to use ARCaMP. Instead you will have to search for some software under Linux that will support your remote. Look at the Remote control programs section at the end of the document for some URLs.

Just keep in mind, that you will have to modify /etc/rc.d/rc.audio (on the initrd fs) so that it will spawn a different program then ARCaMP.

mpg123

The program is staticly compiled and put in /bin (on the initrd) directory. If you find it necessary to get a more recent version , recompile it with -static flag and put in /bin.