Chapter 14. LEAF for the pcengines WRAP

Revision History
Revision 0.12004-08-01eTitl
Initial document

Table of Contents

The challenge
Analysis
The solution
<authorblurb>

I would like to dedicate this to the enthusiasts who made this product possible. Special thanks to Eric Spakman who was gentle enough to be convinced by my reasoning and to K.-P. Kirchdörfer who helped me to get my act together and write this little introduction. Erich Titl

</authorblurb>

The challenge

I got my hands on a nifty little SBC which had all the markings of being a perfect platform for LEAF. Installing und running a LEAF standard distribution went without much trouble but there were a few little quirks which annoyed me.

PCengines WRAP Hardware

Pcengines WRAP is a small single board computer optimized for wireless access and network routing applications. It is built on the low power National Geode SC1100 processor and has 2 or 3 LAN sockets.

Features

  • · National SC1100 CPU, 266 MHz 5x86 CPU, 16KB cache

  • 2 or 3 Ethernet channels (National DP83816)

  • 2 or 1 miniPCI sockets for 802.11 wireless cards and other expansion (better performance than CardBus, adapters should be lower cost soon)

  • 64 MB SDRAM, 64 bit wide for higher memory bandwidth compared to AMD ElanSC520 based boards.

  • 128 KB flash for tinyBIOS system BIOS and optional PXE boot.

  • CompactFlash header for user’s operating system and application

  • 12V DC supply through DC jack or passive power over LAN 1 connector

  • 1 serial port (DB9 male)

  • Watchdog timer built into SC1100 CPU

  • LM77 thermal monitor

  • Header for I2C bus (can be used for front panel interface)

  • Header for LPC bus (can be used for I/O expansion)

Please refer to the above link for more details on the PCengines wrap platform.

The problem area

  • At boot up the serial port spewed hundreds of messages about a jammed keyboard controller.

  • The system would hang after the shutdown command.

Analysis

I quickly found that the messages and the system hang had a common reason. The board I was playing with was missing a keyboard controller. But why would the absence of a keyboard controller hang a system? Simply put, the kernel uses the keyboard controller to issue a reset to the processor. So we had 2 problems to solve

Get rid of those irritating messages at system boot, more of a cosmetic issue as the system runs fine once the keyboard init timed out.

Provide a method to overcome the katatonic state at shutdown, e.g. reboot the system.

Keyboard controller jammed messages

These messages are generated at an early kernel initialisation state when the kernel tries check and initiate the keyboard controller. They do not interfere with the normal system operation but are a nuisance. The Linux kernels up to 2.4 expect the presence of a keyboard controller and react kind of annoyed if it is missing. There is a patch by Randy Dunlap available to fix this but it would interfere with the standard hardware used on Bering boxes. Therefore this patch is not included in the standard distribution. Roll your own kernel if you feel the need to get rid of those messages. A copy of the patch can be found here.

Enable reboot without use of the the keyboard controller

To enable the reboot of the system several options are available, either write a driver which would perform the necessary system related operation, or use the internal watchdog of the SC1100 processor to reset the system if the watchdog does not receive a reset signal within a predefined interval . The platform I had in mind was geared towards 24/24 service so I opted for the watchdog, especially as I could find a driver which handles the hardware watchdog.

The wd1100 driver

This driver enables the internal hardware watchdog timer of the sc1100 processor.

The Bering kernel has the softdog driver compiled statically into the kernel. It must be made a module in order to use the wd1100 driver.

The wd1100 driver implements the devfs interface, so it is very easy to control its behaviour through the files it presents in /proc/sys/dev/wd. The following is needed to set the wd1100 up for automatic reboot.

- insert the wd1100 module. The driver allows the specification of the base address of the configuration block as a parameter. Normally this is only needed If the BIOS does not set the address of the configuration block to the scratch pad register. Use the gcb parameter to tell the driver where the configuration block is located.

insmod wd1100 [gcb=0x9000]

- set the wd1100 watchdog to reset when /usr/sbin/watchdog dies

echo 0 > /proc/sys/dev/wd/graceful

- set the timeout to 2 times the value of the watchdog timer interval. /usr/sbin/watchdog writes every 10 seconds a single byte to /dev/watchdog.

echo 20 > /proc/sys/dev/wd/timeout

syslinux.conf

Syslinux.conf must be set up for a serial console to monitor the system start . Modify your syslinux.conf file according to this documentation.

The solution

Bering uClibc

Bering uClibc starting at 2.0rc2 provides a kernel which modularizes softdog and includes a wd1100.o module in the distribution. Along with this comes a /etc/modules file which loads softdog by default, but here wd1100 can be defined as an alternative. This fits the existing model of module initialisation and makes other changes in the initialisation unnecessary. The real beauty of this is that userland does not need to be touched. If the watchdog driver is initialised as documented above then killing the watchdog program will reset the system.

The standard distribution does not include the keyboard patch. This slows down startup a little bit while the error messages are sent. A replacement kernel can be found in the cvs repository of Leaf Bering-uClibc.

Bering

Bering does not yet provide a modified kernel, you will have to roll your own using the instructions by Jacques Nilo which can be found here.