The LocSoft ImpacII board was designed in response to what is becoming a familiar request in the embedded hardware market. Our customer had employed a commercial off-the-shelf (COTS), ISA-based multiport serial board at the heart of their industrial machine. This machine sells for tens of thousands of dollars, but its viability was threatened by the board vendor's end of life (EOL) announcement. This EOL was due to the demise of the ISA bus as an industry standard, which in turn reflects the trend nature of the PC and illustrates the dangers of basing long-life industrial equipment around a PC product.

The customer came to LocSoft in response to our web-based description of a multiport ISA bus serial board with software support for iRMX, the real-time operating system around which their system was based. (Intel's protected mode real-time OS is still available from TenAsys Corporation--http://www.tenasys.com/.) LocSoft's Impac8 board was considered and indeed used as a replacement, but this involved significant redesign by the customer to accommodate the new form factor of the serial port interface. LocSoft therefore proposed a redesign of the Impac8 to allow it to be used as a form, fit and function replacement for the current COTS board.

The hardware design considerations for the replacement board were as follows:

Several different architectures were considered, and eventually an x86 architecture was selected as offering the best performance and shortest time to completed product. The need to keep down cost, restrict the PCB real estate requirement and support readily available code, without the need for excessive processing power and thermal dissipation, pointed toward a 486-based solution. At the time, the main contenders were the ST family of microprocessors and the then unannounced Elan SC520 processor. LocSoft's close relationship with AMD allowed us access to advance information on the Elan, and it quickly became apparent that this device offered the optimal solution. The single-chip footprint allowed the functionality to be easily designed into the AT form factor outline, while the PC-compatible architecture and readily available sample schematics provided a fast and proven route to prototypes. The only ``clean sheet design'' areas were the ISA bus slave interface (implemented easily into a CPLD) and the octal UART. This was provided in a single device through the Cirrus Logic CL-CD1865 that offered a small footprint, high functionality, low cost and readily available driver code. We decided to keep the basic PC architecture intact. This allowed the board to be debugged quickly using a standard BIOS and allowed for future variants of the board to be developed.

In order to minimize the effect of firmware bugs and support a variety of potential applications, the ImpacII was designed to house basic bootstrap ROM-based software. The board would download the operating system and application at boot time across the ISA bus, through a FIFO-based interface, providing a flexible and relatively fast data exchange mechanism. The control for this FIFO interface was implemented in a CPLD, which provided read/write control ports for either side of the interface. These ports provided FIFO status, direct data exchange and board reset capabilities.

In order to insulate the product from the future disappearance of the ISA bus, a 10/100 Ethernet port was added. This could allow the board to be controlled via a network or simply provide additional connectivity, thus enhancing the potential appeal of the product to the customer.

In addition, a 16MB paged StrataFlash ROM was added to allow the board to operate in a totally standalone mode. Finally, in order to aid debugging, field diagnosis and production testing, two extra features were added. The first made use of the extra serial ports located within the Elan to allow a ``programmers serial port'' to be implemented. The second allowed two hexadecimal LED displays to be connected to the board and be used to display code checkpoint information.

In order to reduce cost, all these additional features were configured as optional extras that could be omitted from the bill of materials and the board cost, as desired.

The long lifetime issue is a trickier problem to address. There are several design techniques that can be employed to minimize the exposure to EOL issues, for example, multifootprint CAD, device selection using suppliers' long-life road maps and selection of multivendor devices. In addition, careful monitoring of device availability and customer demand allows for last-time buys to be carried out when the worst finally happens. Ultimately, however, there will be devices that are single-sourced, and devices do go EOL. The approach adopted by LocSoft was to isolate the customer from this by defining a set of protocols to handle board control and data transfer across the ISA bus. This totally isolates the customer from the hardware. While it is envisioned that the board will be manufacturable for at least five years, by reducing the customer interface to the ISA bus interface and the protocols placed on top of this, LocSoft effectively maintained the ability to redesign (partially or even totally) the board to resolve supply issues now and in the future. Of course, this approach works only when the customer allows the supplier the freedom to take this approach, and when the system design is not constrained by regulation (e.g., medical equipment).

At the end of the system design phase, we proposed the following board specification. The ImpacII, an Elan SC520-based, ISA bus-compatible computer designed to provide eight asynchronous serial ports in an IBM PC compatible environment. The ImpacII will comprise a PC compatible form factor board (Host Board) and a remote custom form factor board (Remote Board). The inter-board interface will be TTL level RS-232 signals.

The feature set of the ImpacII Host Board (see Figure 1) includes an AMD Elan SC520 CPU running at 133MHz, DIMM-based SDRAM memory site, 16KB cache memory, 1MB Flash EPROM, 16MB StrataFlash memory expansion site, eight RS-232 TTL level serial ports, FIFO-based ISA (AT Bus) compatible interface and PCI-based Ethernet 10/100 Base-T interface with RJ45 connector AT Compatible form factor.

Figure 1. ImpacII Host Board

The feature set of the ImpacII Remote Board (see Figure 2) contains TTL to RS-232 level shifters for eight ports, eight RJ45 RS-232 connectors, opto-isolation on four ports, RTS reset on four ports, fiber Tx/Rx on two ports, full modem support on one port and a custom form factor to be defined by the customer.

Figure 2. ImpacII Remote Board

Figure 3. ImpacII Block Diagram

It was clear from the outset that in order to meet the timeline for development, and to properly support the ImpacII hardware, we would require a fully featured operating system kernel. The choice of kernel had to be made first, as this would dictate the way the bootstrap firmware and application software were implemented.

Linux was an obvious choice from the start for several reasons, those being the obvious advantages of being free and open source and easy configurability to run headless (no display or keyboard needed). Once running, Linux doesn't require a BIOS, and drivers exist for the ImpacII OCTART and Ethernet chip. Finally, AMD has supported Linux on the Elan processor from the outset, so we had seen the kernel running on an Elan evaluation platform even before our own hardware was developed.

Having decided on Linux, the main challenges we faced in the software design were how to provide a mechanism for bootstrapping the board and loading a Linux kernel via the ISA bus interface, how to configure a kernel that could be loaded in this way and how to build a compact ramdisk image containing initialization scripts, utilities, libraries and our application software.

One option we had was to put a standard PC BIOS on the board. We decided against this option because of the cost of a custom BIOS development kit, the per board cost of the BIOS license and the fact that Linux doesn't need or use the PC BIOS once the kernel is running.

This decided, we wrote a minimal bootstrap program in assembler, which was enough to initialize the Elan control registers, the DRAM controller, PIC and PCI bridge.

Then we wrote a simple loader, which used a simple handshaking protocol to load a real-mode executable binary image from the host PC via the ISA bus interface.

The next stage was to modify the Linux kernel setup code. The source files belong in the i386 platform-specific part of the kernel source tree (/usr/src/linux/arch/i386/boot/).

On a PC platform, Linux uses two slightly different methods to load a compressed kernel image, depending on the size of the image. A zImage kernel can be loaded entirely into low memory, accessible in real mode. Larger bzImage kernels need to be placed in high memory, but our kernel image was very small so we did not need to worry about supporting bzImages.

The process of booting a Linux zImage on a PC starts with the BIOS, which loads the boot sector of the boot device into memory at a fixed address. The boot sector code (see bootsect.S) uses BIOS int 13h to load a few more sectors (see setup.S) and begins a process of relocating itself and loading the kernel image. Next, the kernel image is moved to physical address 0x1000, the setup code switches to protected mode and jumps to an entry point in the zImage. The kernel zImage contains a small prologue of uncompressed code (see /usr/src/linux/arch/i386/boot/compressed/misc.c) that implements enough of gzip to decompress the kernel into RAM.

The modifications we made to bootsect.S and setup.S were simple and allowed us to include our handshaking protocol to load a compressed kernel image across the ISA bus.

The kernel decompression code is executed in protected mode (using a ``big flat'' GDT) and therefore has access to extended memory. For our own convenience, we added a routine here to load the ramdisk image into memory. There are kernel parameters that specify the size and location of the initial ramdisk. The kernel parameters are declared in setup.S and are located at a fixed physical address at runtime, so we were able to update the parameters after loading the ramdisk image.

Configuring the kernel itself was straightforward. We only needed to support a single serial console, no peripherals, minimal network and filesystem support. We linked the drivers for the OCTART, network chip and our own driver for the ImpacII-Host PC ISA bus interface into the kernel.

The techniques for building small ramdisk images are well documented (for example see http://www.linuxdoc.org/HOWTO/Bootdisk-HOWTO/index.html). In an embedded system like ours, you don't need a lot of command-line utilities, so we didn't have too much difficulty squeezing the binaries and libraries that we did need into a single 4MB initial ramdisk. We included a small suite of test programs that we would use for production testing and benchmarking, and almost as an afterthought we added a small web server (thttpd) and some simple CGI programs in order to demonstrate the potential of the Ethernet interface as a means of controlling the ImpacII.

It is worth putting a good word in here for BusyBox (http://busybox.lineo.com/), which should be familiar to ELJ readers by now. Suffice it to say that we have found it to be an excellent tool.

A useful trick when debugging the early stages of kernel initialization is to add statements to the implementation of printk( ) (in /usr/src/linux/kernel/printk.c) that copy the output buffer directly to a piece of hardware--in our case, the standard PC serial UART. Later on, you will want to remove these statements or the kernel messages will be doubled up.

The ImpacII application software was developed in several phases, allowing the customer to migrate the host software of three separate die sorting systems over to the ImpacII and to push some of the complexity of those host systems onto the ImpacII itself.

The first system would use ImpacII as a dumb 8-port ISA card in a PC host running iRMX. We defined a communications protocol between the host and the ImpacII and implemented this protocol on the ImpacII as a multithreaded process and on the host as a TTY driver for iRMX. The ImpacII-Host protocol was defined so as to support a number of different formats for the RS-232 message communication between the ImpacII and the devices it controls. These formats include Raw 8-bit ASCII data in and out; Sink, which acts as a null device, discarding all rx and tx data; SECS-1, a ``block'' messaging standard used in the semiconductor manufacturing industry; and Debug, a time-stamped SECS-1 messages in ASCII hex format.

The second system also required the ImpacII to sit on the ISA bus, but in this case the host OS was DOS, and the card itself was to implement a message protocol ubiquitous in the semiconductor manufacturing industry called ``SECS'' (see Sidebar). The implementation of SECS-I message passing under Linux was straightforward. We extended the ImpacII--host protocol to include SECS-I as the message communication standard (over RS-232) between the ImpacII and the outside world, in addition to Raw.

The third and latest system to use ImpacII was more interesting. This system also required ImpacII support for SECS-I, but in this case the host was a Windows NT 4 workstation. It was necessary to remove the dependence on the ISA bus, although an ISA slot would initially be used as a convenient site for locating the board and supplying its power. The Ethernet interface was to provide communication between the ImpacII and the host system, and a communications protocol based on UDP (user datagram protocol) was specified and implemented.

For the problem of loading the ImpacII Linux kernel and ramdisk image in this system, two solutions were proposed. The first was to fit the StrataFlash part, which would be programmed with the kernel and ramdisk images. The ImpacII accesses the StrataFlash through a 64KB window, so we proposed an implementation of the loader as a BIOS ``ROM Extension'' in the first page of the device. The ROM Extension initialization code would be called by the bootstrap program via a standard mechanism and would hook itself into the chain of BIOS int 19h handlers, again in a standard way. Therefore, the system would have a chance to load the OS from StrataFlash or fall back to the ISA interface.

The second solution proposed was to use Etherboot (http://etherboot.sourceforge.net/), a free software package for booting x86 PCs over a network. This would also take the form of a BIOS ROM extension, this time incorporated into the bootstrap EPROM.

The customer chose the Etherboot option because it was cheaper and would make the upgrade of the ImpacII application or OS kernel straightforward.

The implementation of the Etherboot solution was achieved without modification of any of the Etherboot sources. A little effort was required to implement some interrupt handlers (e.g., int 19h and some int 15h functions) that Etherboot expects to be provided by the boot ROM.

Etherboot uses DHCP or BOOTP protocols to establish itself on the LAN and T[rivial]FTP to download its operating system, so it was necessary to purchase DHCP and TFTP server applications for Windows NT workstation, the host computer.

Given the same project over again, or a completely new project based on similar hardware, would we do anything differently? I'm not sure that we would. For a project with a larger budget, I think using a standard BIOS (for example, General Software's customizable Embedded BIOS) would certainly cut the development time.

If there were hard real-time requirements on the system, then I would seriously consider using RTLinux (http://www.rtlinux.org/). RTLinux is open source and has excellent support for the Elan SC520. RTLinux works by running a standard kernel, as the lowest priority task of a true RTOS. Admittedly this is a compromise, but it's still a valid and potentially effective approach.

What is SECS?