This page describes my experiences bringing up the Leaf Bering-uClibc-2.0rc2 on a Soekris net4501 board using a "cross-configuration" process that I haven't seen described in the Bering user guides yet.
What do I mean "cross-configuration?" By analogy with "cross-compiling" I mean that most configuration and setup is done on a desktop host computer, to create a bootable compact-flash card that starts and runs exactly the way you want with minimal intervention on the target computer's console.
This is in contrast to LEAF's usual installation and configuration process, where the packages and configuration are modified on the running target system and then saved back to the boot media.
The net4501 has no floppy interface, so all of the Bering install documents that start out saying "boot from the floppy" are useless there.
While the examples here are oriented towards the Soekris net4501 target, others may find them useful to. Running Leaf/Bering on any system with a serial console and removable IDE boot media will need very similar steps. Beyond that, the general cross-configuration process usiing a desktop host may be applicable to any Leaf or Bering installation, even one that uses a floppy or PXE boot process.
Bering-uClibc-2.0rc2 is distributed as a floppy-image that can be dd'ed directly to a 1.68MB floppy disk.
Instead of making a real floppy, mount the image file as a filesystem, and copy its contents to a normal directory on the host system. This is analagous to unpacking a tar file.
mount Bering-uClibc_2.0-rc2_img_bering-uclibc-1680.bin /mnt/floppy -tmsdos -oloop mkdir fdimage-2.0rc2 cp -p /mnt/floppy/* fdimage-2.0rc2 umount /mnt/floppy
Keep the fdimage-2.0rc2 directory as-is to have a clean orignal copy
to refer to, and make a copy that you will modify as you configure your
system. I called this directory cfimage for "compact flash image".
Make these edits to the working compact-flash image in cfimage:
syslinux.dpy: remove all of the pc graphic-character glop to leave
a plain-ascii startup message.
lrcfg.cfg: adjust the list of leaf packages that you need.
syslinux.cfg: serial-console and boot media parameters.
My syslinux.cfg looks like this:
display syslinux.dpy timeout 0 default linux console=ttyS0,19200n8 initrd=initrd.lrp init=/linuxrc rw root=/dev/ram0 boot=/dev/hda1:msdos PKGPATH=/dev/hda1 tmp_size=16M syst_size=10M
The parameter "console=ttyS0,19200n8" sets up a serial console at that
rate. Match it to whatever you have the Soekris' comBios serial port
rate set to. The compact flash card will always be /dev/hda on the
net4501, so we change all instances of the original /dev/fd0u1680 to
/dev/hda1.
I've also increased the root ramdisk filesystem to 10M and limited
/tmp to 16MBH with the syst_size and tmp_size parameters.
After the modifications described above, I was eager to see the net4501 boot linux. You may be too. So even though the setup isn't done yet, here is how to make a bootable CF card.
You need a way to mount the CF card on your host. I'm using a no-name
USB-attached CF reader that cost me $15 and works fine under RedHat 9.
With no other SCSI or USB drives in the system, CF cards show up as
/dev/sda, with their single dos-formatted partition being /dev/sda1.
I use this script, called installcf, to copy my working cfimage
directory to the cf card and make it bootable with the syslinux loader:
#!/bin/sh rm -f cfimage/*~ mkdir -p /mnt/cf mount /dev/sda1 /mnt/cf cp -p cfimage/* /mnt/cf # ls -ltr /mnt/cf # optional - list contents umount /dev/sda1 syslinux -s /dev/sda1
This procedure is the only part of the whole process that probably has to be done as root on the desktop host.
Insert the CF card in the host's reader, run installcf, move the card to the net4501, and power up the net4501. To try again, power off the net4501 and move the card back to the host.
As distributed, Bering won't get very far because the kernel driver modules necessary to access IDE disks (like the compact-flash card) aren't included on the boot floppy image.
Download the package of additional kernel modules from http://prdownloads.sourceforge.net/leaf/Bering_uClibc_2.0_modules_2.4.20.tar.gz?download and unpack it to create a directory "2.4.20".
The initial ramdisk is a gzipped minix filesystem image contained in the file initrd.lrp on the CF card and cfimage working directory.
To modify the initial ramdisk, do somthing like this:
zcat cfimage/initrd.lrp > initrd.bin mkdir -p /mnt/initrd mount initrd.bin /mnt/initrd -tminix -oloop # do what you need to modify the contents of /mnt/initrd umount /mnt/initrd gzip < initrd.bin > cfimage/initrd.lrp
Finish up by running installcf (deescribed above) to copy everything to the CF card again.
The modifications I made to the initial ramdisk are essentialy those described in http://leaf.sourceforge.net/doc/guide/bubooting.html but done on the desktop host instead of on the target. We have to copy three modules into the right place, and edit the boot/etc/modules file containing the list of modules to load.
Commands I used were basicly:
cp -p 2.4.20/kernel/drivers/ide/ide-mod.o /mnt/initrd/boot/lib/modules cp -p 2.4.20/kernel/drivers/ide/ide-disk.o /mnt/initrd/boot/lib/modules cp -p 2.4.20/kernel/drivers/ide/ide-probe-mod.o /mnt/initrd/boot/lib/modules emacs /mnt/initrd/boot/etc/modules
My boot/etc/modules looks like:
ide-mod ide-disk ide-probe-mod
With the initial ramdisk fixed, linux will boot on the net4501 all the way up to multi-user mode, and then be unable to spawn a getty on the virtual video consoles - because there is no video hardware.
To fix this, we need to modify /etc/inittab, which resides in the required package etc.lrp.
This same basic procedure will work for modifying any other .lrp
package except for initrd.lrp, which was described above. Ordinary
.lrp packages are simply .tar.gz files, which we can unpack, modify,
and repack.
Just for completeness, the general procedure goes somthing like this:
mkdir etc-lrp cd etc-lrp tar xzvf ../cfimage/etc.lrp emacs etc/inittab tar czvf ../cfimage/etc.lrp *
If you don't untar the .lrp packages as root on your desktop host, all of the file owners and group ID's will get changed to your uid and gid. I forgot about this and found out by accident, but things actually seem to work OK. Still, it probably would be best to preserve the original permissions, even though you normally wouldn't need to do this as root on the host.
In inittab, comment out the getty on the video consoles, and uncomment the one on ttyS0. My exact diff is:
51,52c51,52 < 1:2345:respawn:/sbin/getty 38400 tty1 < 2:23:respawn:/sbin/getty 38400 tty2 --- > #1:2345:respawn:/sbin/getty 19200 tty0 > #2:23:respawn:/sbin/getty 38400 tty2 60c60 < #T1:23:respawn:/sbin/getty -L ttyS0 19200 vt100 --- > T1:2345:respawn:/sbin/getty -L ttyS0 19200 vt100
The Bering package includes a driver for the DP83815 ethernet chips on the net4501, but it isn't loaded by default.
To get it loaded, modify the file etc/modules in package modules.lrp,
using the .lrp unpack/edit/repack procedure described above.
For the net4501, and probably for any other Soekris board, uncomment the line "natsemi". That's it.
After you get everything set up the way you want, you can remove unnecessary module .o files from modules.lrp to save a little space.
The procedure described above for modifying a .lrp package requires that you untar each .lrp into a seperate directory.
I'm working on a way to allow keeping all of the .lrp files in a single directory tree that looks much like the filesystem of the running Bering system.
It packs the modified host directory tree back into a set of .lrps by using a modified version of the scripts used to back up packages in a running Bering system.