On Mon, 27 Oct 2003, Andrea Montefusco wrote:

> Steve,
> 
> I am experiencing timeout problems connecting to
> 
>     http://www.telltronics.org/
> 
> can you send me the whole thing ?

Here's the text.  Render to html if desired with emacs-wiki.el 
(http://damien.kangaweb.com/moving/emacs/wiki/)



#title Cross-configuring Bering-uClibc

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.

* Links

- http://leaf.sourceforge.net/ - Linux Embedded Appliance Firewall
- http://leaf.sourceforge.net/mod.php?mod=userpage&menu=904&page_id=21 The Leaf/Bering 
distribution
- http://www.soekris.com/net4501.htm - the Soekris 486-class single-board computer

* Unpacking the floppy image

Bering-uClibc-2.0rc2 is distributed as a 
[[http://prdownloads.sourceforge.net/leaf/Bering-uClibc_2.0-rc2_img_bering-uclibc-1680.bin?download][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.

<example>
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
</example>

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".

* Essential setup for Bering on Soekris

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:
<example>
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
</example>

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 16MB with the =syst_size= and =tmp_size= parameters.  Adjust
these to taste.

* Transferring the image to the CF card

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:

<example>
#!/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
</example>

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.

* Modifying the initial Ramdisk

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:

<example>
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
</example>

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:
<example>
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 
</example>

My boot/etc/modules looks like:
<example>
ide-mod
ide-disk
ide-probe-mod
</example>

* Modifying Other .lrp packages

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:

<example>
mkdir etc-lrp
cd etc-lrp
tar xzvf ../cfimage/etc.lrp 
emacs etc/inittab
tar czvf ../cfimage/etc.lrp *
</example>

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:

<example>
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
</example>


* Driver for the net4501's ethernet ports

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.

* Future Work

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.


* Additional Comments

The following is some feedback I got on the leaf-user mailing list.

** CF Cards

  "Since it's so hard to get the small ones lately, all I have used 
  lately are 64MB cards. The Soekris box tends to "see" these cards 
  differently than my normal computers (regarding their CHS mappings), so 
  this has to be set in fdisk, before partitioning (by going to the "extra 
  functionality" and setting the heads/sectors/cylinders manually). The 
  correct mapping can be seen in the in the BIOS messages when the Soekris 
  box boots up.

  "I don't know if that's not needed if one doesn't repartition the CF (I 
  always do, since I like to have a spare partition with a "failsafe" 
  setup to boot)

  "All of the cards I've seen so far need a master boot record to be 
  installed, before they boot properly. Unfortunately (at least on my 
  version of RedHat (9.0.95 aka Severn/Fedora Test 1)) the simple MBR 
  provided by syslinux is not included in the rpm - so, I built syslinux 
  from source, and then do
  <example>
  dd if=mbr.bin of=/dev/sda bs=512 count=1
  </example>
  to install the MBR
  This may not be needed if one just keeps the partitions as they were"

I've used both a 16MB and a 128MB card without this problem, but then
I've never repartitioned either of them from the original single msdos
partition that they came with.

** On Red Hat

  "It seems that Redhat has dropped minix support from their kernels 
  (verified on Severn/Fedora and also on RHEL 3.0). This obviously causes 
  a problem when trying to mount the initrd file. The module is built, but 
  is not included in the kernel rpms. On RHEL, one needs to install the 
  "whatever-unsupported.rpm" or (for either version) roll your own kernel 
  (or, mess with the SPEC file for the srpm and rebuild with that)."

On the released Red Hat 9, I didn't have any of this trouble.








-------------------------------------------------------
This SF.net email is sponsored by: The SF.net Donation Program.
Do you like what SourceForge.net is doing for the Open
Source Community?  Make a contribution, and help us add new
features and functionality. Click here: http://sourceforge.net/donate/
------------------------------------------------------------------------
leaf-user mailing list: [EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-user
SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html

Reply via email to