Kibler Electronics Embedded Linux Page

Headless or Serial Console and Embedded Linux

A long time ago at a Ham swap meet, I purchased several PC104 boards and a complete data collection system. The seller was under orders from his spouse to not return with the data collection system or find a new home. Since we live on 10 acres, finding a hiding place for a rather large metal case was no issue for me. What I really wanted was the controllers and stuff inside the box.

Overall my under $100 worth of purchases provided me with several systems to play and learn about. There were two PC104 WinSystems PCM-586-133 main boards (CPU/I/O/DISK Controllers), several serial and I/O expansion boards, power supplies, and one Advantech PCM-9570S, a 5" by 9" SBC with Ethernet and SCSI interfaces on board. Some manuals on disk were provided, but later I obtained from the internet, the latest manuals and software available for all the components. Not everything was avialable, as these are all discontinued products, but I think I have enough information to start playing.

What got me started on bringing life to these old systems, was a job interview. The interviewer had said how much trouble they were having using Linux From Scrath to install Linux on a few embedded systems. I think the systems are PowerPC based, but I commented how several years ago I gave up on both Linux From Scratch (LFS) and Gentoo in favor of Slackware. I read about LFS, got the book and CDROM, it is always nice to support free software with a pruchase or two, and spent many hours, a few crashed systems, as well as trashing a hard drive with Gentoo. I did learn how these system setups work, mainly using chroot and copying that isolated file structure to the new system image.

To say I wasn't impressed was only part of the problem. LFS is really a rather short list of tools when your done, and gentoo locks you into their packages when done. Gentoo was just too frustrating to keep up with, as for some reason I kept running into missing and incorrect directory paths. It would go out to do a compile and fail as the compiler was in the wrong location. I started editing and moving paths around and made it to another step, only to have a new set of problems.

What is the Objective

I am pretty pragmatic about things and over the years have picked up a few bits of advice. I did considerable forth programming in the past and managed to sit in on several fireside chats with Chuck Moore, the creator and still super programmer of forth. He trully can do things in amazingly small spaces with forth. At one of the fireside chats, he stated that "if you can't do it in one screen, you don't understand the problem." Forth has it's own editor, and a page of code is call a "screen", which is typically 1000 characters. To simply put his advice then, is to say that taking multiple pages to do a soltuion to a problem, means you really don't understand the problem at all.

Now over the years, that advice has stuck, and as I viewed other programmers work, I discovered how correct he was. I so often found that programmers who had pages and pages of code (I once found a case statement that went on for ten pages) clearly have no idea of the problem they are solving. If anything, these people are making things worse for everyone. Often as I went back and cleaned up other's code, I noticed how it shrunk from pages to often less than one. All that because I spent the time needed to trully understand the problem.

When I was playing with LFS and Gentoo, I was thinking the problem I wanted to solve, was getting away from a big distro and be able to grab anyone's code and stick it on my system. What I learned was doing so was no simple task, and it seemed like few had mastered it. What life is all about however, is selecting the right compromise and LFS and Gentoo to me didn't seem like any kind of good compromise. This is where Slackware enters the game and helped me separate the problems from the hype.


For those who don't know, Slackware is the oldest still in production distribution of Linux. It started in 1991, with I believe the first full releases of Linux in 1992. There were a few others about then, but all except Slackware have gone. The process and tools have little changed since they started. Back then, the release came on several 1.4MB floppies, and was sorted out based on grouping of components. The packaging of components is a combination of build script, production information, a tar file, and any patches. Often the included tar file is direct from the source without changes. It is pretty easy to see what your getting and how to handle changes if needed. The component package is a simple tgz file and so no special tools are needed to see what is in the package. It is all pretty simple and straight forward, just what I like.

After my job interview, I decided to embed a Linux in the PCM-586 as a refresher on embedding Linux and to use Slackware. After all I had spouted off about using it instead of LFS. Surely in a few nights I could get it done now that I knew what the real problem was - staying focused. Focused on what? The objective of this and I think the job interviewers project, is to get a Linux OS shoe horned into an embedded system with the least amount of trouble and time. We don't want to be spending all our time fixing someone's toolset, searching the net for packages, or having trouble getting packages to compile with each other. We want the only unknown to be related to our embedded system - our tools should work on a normal system of the same type.

I think Slackware fits this concept perfectly. The packages are already broken out into selections that are pretty easy to understand. "X base" is what it means, all the packages that provide the X-Windows base set of programs. Don't need X, don't load that package set. That selection not fine enough for you, then click on the "select each package" and as you install, you will be prompted for a "yes" or "no" before a package is loaded. Pretty simple to do, and all on two sets of CDROMs. Need the source to make changes later, all on two more sets of CDROMs. Remember too, that all the source files were used to build the packages provided, so we take care of two other problems, getting the source for all our packages, and knowing that the source we have will in fact compile. That is a big list of problem solvers in my book. It tells me I can start from a positive position as I start porting to my controller.

We start porting

The first step in starting any project is gathering your tools and references. For me I had to grab an old PC power supply for the PCM-586, some serial cables, no built in VGA anything here, just plain old 38400 Baud 8n1 with a null modem connection. I downloaded WinSystems wincom for DOS, as I later learned, it handles the PC based escape codes and presents a usable tool interface for talking to the controller. Next to get was my Linux CDROMs from Slackware web site, where I downloaded the four ISO's for the 10.2 release (2 install, 2 source). I downloaded the Slackware Book if you will, and inside it, it said that embedding projects might find version 7 and 4 more suited to their needs, than getting the latest release. Slackware 7 has no ISO's on download, while 4 does. The release 4 ISOs are one install, one internet collection, and one live CD.

I have a complete test lab and live web server in my office/lab. Right now the live servers are providing this web site and collecting the temperature data. I have two engineering servers, one a masive system, while another is older and ideal for setting up Slackware 10.2 as a reference system. On my lab bench is a 586 PC with 64MB of memory, a SCSI interface and plenty of cables for testing and connecting IDE devices to. This last system will be my Slackware 4.0 build box and stand in for the embedded system. I also have VMware installed on my personal workstation and loaded two virtual images with Slackware 4, one to do building and one for testing ISOs. A great feature of VMware is it's ability to use ISO images as drives - simply point the device setup file pointer at your ISO image and reboot, the virtual system will use the ISO as if it was loaded like any normal CDROM.

Loading Slackware was pretty un-eventful and takes less than 10 minutes for version 4. I only selected at the package level to load, leaving component selection for a later time. Total hard disk usage hovered around the 200MB range, yet I know you can get down into the 50MB range, as several distros are available on the internet in that size range. Try searching for SLAX, or ZENWALK. I am using an old 1 gig drive for testing and so for now the 200MB file system is just fine. This size will allow complete rebuilding of the kernel and has a full set of compiler tools as well as perl and tcl. The 10.2 load was everything including KDE and took over 2 gigs of space on a 40 gig drive.

Some early testing

So far all I have been able to do is start seeing what works from the standard set of disks from both 10.2 and 4. During the install process you will be prompted to create a boot disk on floppy for later emergency use. I used these floppies to see what might work and discovered a few problems and surprises. The problem seems to be LILO from release 4 refuses to load, no matter what. I think this might be some incompatible problem with the PCM's chipset, but will need more testing to be sure. I tried the syslinux disk from 10.2 and got pretty close to booting, which suggests to me, that I might need a newer version of LILO. The big surprise however was using DR DOS 6.0 boot disk - it worked even with the serial terminal. DIR worked fine, however the FDISK display was unusable. That proved that the system will boot using floppies, if I can just get the right set of tools or drivers.

Here again is why I want to use Slackware and not some from scratch set of files. I know that it does work on similar systems, after all I just installed it and can recompile the kernel without issue. I can create boot floppies and test them on both the host system and the test system. I know from the start where my problems are and are not. Plenty of people have been down these paths of testing and building and have succeded, so there too should I be able to do it.

A pause for another project

At this point I need to pause this project and move over to the LAMP projects, where I need to show off my skills to some future clients. I will be researching on the net for tips, as I recommend for you do as well.

Bill Kibler, PO Box 535, Lincoln, CA 95648-0535, USA.
Copyright © 2008, Bill Kibler/Kibler Electronics.