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.
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
cd "2nd Step - configuring client/01 - linux kernel/linux-2.2.16" make menuconfigand choose the right drivers. If you want to use my startup scripts for the mini-linux distribution, make all the drivers modularized (network, filesystem, sound card).
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 mini-distribution setup). To compile and install in temporary directory do:
export INSTALL_MOD_PATH=/tmp make modules;make modules_installThe modules for the kernel will be located in /tmp/lib/modules/2.2.16. Remember that path.
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.
To understand why we need to create a INITial Ram Disk filesystem, its necessary to understand how Linux boots up.
For more info, man initrd.
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).
This creates a initrd file 4MB big. The last command should say: Linux/i386 ext2 filesystem. This is the file that we eventually use to boot the Linux OS on the MP3-box.
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
To use the initrd for something its necessary to make a mount-point a mount the initrd file:
Now you freely copy files back and forth onto the 4MB initrd file, which is mounted under /data.
mkdir /data mount /root/initrd /data -o loop
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 - )
Do you remember the modules that we compiled in the previous section?
df -h serves only to show you how much space you have left on the filesystem.
cp -Rf /tmp/lib/modules/2.2.16/* ./data/lib/modules/2.2.16 sync df -h
Using the initrd file generally means we have to unmount the file, gzip it and copy it into the tftpboot directory.
This will unmount the initrd, and compress it into linux.2 file (which is what the NBP will look for and download).
umount /data sync gzip -c9 /root/initrd > /tftpboot/X86PC/UNDI/linux-install/linux.2
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.
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.
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.
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.
The scripts were made as simple as possible. The files you ought to look into and alter are:
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.
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:
/dev/ttyS1 is the serial port for my infrared receiver, yours might be different. od -t x2 converts the output to hexadecimal.
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.
Just run make and copy the arcamp file into /data/bin directory - assuming you still have the initrd filesystem mounted under /data.
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.
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.