I have an old embedded system that uses an SBC-MAX (pdf) board from Computer Dynamics. The unit was part of a vehicle monitoring system that used Windows 98 (one of many fundamental flaws in the design). It has a K6/2 333MHz CPU and 128MB of EDO DRAM. It features a whole bunch of integrated devices and a fairly broken BIOS. As an embedded system it has a PC/104 bus for which I have a few modules including a GPS. I'm would like to get that working but getting Ubuntu to even install on it has been a pain.
The source of the problem is an ITE IT8330G PCI-ISA bridge with IDE controller that is only supported by the ide-generic driver. This is rather obsolete and isn't loaded in most kernel images including bootable CDs. The latest Ubuntu CD that would boot is the 7.10 (Gutsy Gibbon) alternate CD.
Gutsy's install worked up to where it loaded packages where it would hang after a while. I suspected it was running out of memory so I tried again. After formatting the partitions I switched to a different terminal and activated swap before continuing. This solved the problem:
free
fdisk -l /dev/hda
swapon /dev/hda5
free
When the install completed, it hung at restarting so I power-cycled it. It does this at power-off (halt) as well which may be a board limitation as the system originally used a serial port to shut off power via an "intelligent" power supply made by Dynamic Engineering. The system booted and Grub loaded initrd (containing the kernel) and then the init scripts started but then it stalled for a while - ending up at an initramfs prompt. Rebooting and editing the boot line in Grub to remove the "quiet" and "splash" entries resulted in more detailed messages which showed it couldn't find the drive. Basically the only driver that supports the ID8330G is ide-generic and it's not in linux-generic which Gutsy and later releases use by default.
The solution to getting Linux to boot is to add the driver but it's in linux-386. To install it, I rebooted with the CD and entered "rescue" mode. After a series of prompts it gives you the option to open a root terminal on a chrooted partition. I selected the root partition and got a bterm session. On Gutsy, it's not a friendly environment as you don't get tab completion or history so you get a lot of finger exercise. First thing was to activate swap then use apt-get to install linux-386.
This is were the next problem was encountered. Gusty is obsolete so the repos have moved to the old releases server. Trying to fix the sources.list file with vi was impossible due to refresh and scrolling bugs with either it or bterm. I tried Midnight Commander (mc) and had to set the TERM environment variable (export TERM=linux or whatever) but it was also rather ugly. I eventually figured out a sed script to fix them faster:cp /etc/apt/sources.list /etc/apt/sources.list_orig
sed 's/us\.archive\|security/old-releases/' /etc/apt/sources.list_orig >/etc/apt/sources.list_oldr
This just looks for "us.archive" or "security" and replaces them with "old-releases". The next problem was that Gutsy's installer had disabled the repos since it couldn't find them during installation. Another sed script fixed this:
sed 's/^#[# ]*\(deb .*$\|deb-src .*$\)/\1/' /etc/apt/sources.list_oldr > /etc/apt/sources.list
This looks for lines starting with the comment character # followed by "deb" and attempts to skip other comment lines. Then I ran "apt-get update" and "apt-get install linux-386" and was good to go - almost.
After rebooting it ended up at the initramfs prompt again. I entered "modprobe ide-generic" and it found the drive. I entered a Ctrl-D and the boot completed. I filed bug 128833 about this a while back but I know now that the driver can have problems with more-specific IDE drivers so normally it isn't loaded. To fix it I wrote a basic init script named "idegeneric" and put it in "/usr/share/initramfs-tools/scripts/local-top":
#!/bin/sh
PREREQ=""
prereqs()
{
echo "$PREREQ"
}
case $1 in
# get pre-requisites
prereqs)
prereqs
exit 0
;
esac
modprobe ide-generic
I just basically copied one of the other scripts and modified it. I then created a new initrd image with the command "update-initramfs". It loaded on the next reboot without problems.
Next I updated Gutsy with "apt-get -y upgrade" which updated a whole lot of stuff and installed a new kernel (which included the idegeneric script automatically). On a system this old it's like watching grass grow so I worked on something else for a few hours but later found it had locked up (the Magic SysRq keys didn't work). After a power cycle I ran dpkg --configure -a" and it completed without problems but it found some bad inodes on the next reboot and had to fix them (should have done this first before finishing). Then it was time to upgrade to something a little more modern, Ubuntu 8.04 (Hardy Heron). The command to do this is "do-release-upgrade". The first thing it does after finding a new release is change the release targets in the sources.list file to "hardy". Next it loads in the new package lists. Of course this failed as it was looking for them on the old-releases server so I had to change the entries back to "us.archive" first. Then it was happy and began the upgrade. After a reboot Hardy loaded without problems.
An upgrade to Intrepid Ibex (8.10) was next but "do-release-upgrade" couldn't find a newer version. This is because Hardy is a "Long Term Support" version and the next LTS release will be 10.04 which isn't out yet. To fix it, you have to edit "/etc/update-manager/release-upgrades" and change "Prompt=lts" to "Prompt=normal". This upgrade continued without problems.
Jaunty Jackalope (9.04) is the latest but after the upgrade it failed to load the driver. A message was shown:
ide_generic: please use "probe_mask=0x3f" module parameter for probing all legacy ISA IDE ports
Looks like "probe_mask=0x3f" was needed at the end of the modprobe line in the script to make it happy. Luckily the older Intrepid kernel was still configured in Grub so I was able to boot it instead. I added the parameter to idegeneric, then ran "update-initramfs" with the "-k" parameter to specify the Jaunty kernel (referencing it in the form that "uname -r" returns). After a reboot it loaded without problems but then started segfaulting all over the place. Apparently ide-generic is broke in Jaunty or doesn't like the ID8330G so it's back to Gutsy and restart the process. I stopped at Hardy as I have better things to do. I did try Puppy Linux but both the regular and "retro" versions failed to find the drive even with the "all-generic-ide" boot option.
16 comments:
http://www.howtoforge.com/kernel_compilation_ubuntu Why not just roll your own kernel with ide_generic enabled, and use that from now on? you only need do it once.
Because it's already in the linux-386 kernel and just needs a script added to load it. This is a lot easier than compiling.
Yes, but this way you can have it compiled directly into the kernel rather than a module, and you can use whichever kernel revision works for your hardware and not worry about the ubuntu stock kernel not working correctly on newer versions of ubuntu.
Compiling a kernel isn't diffcult using that guide and you get a handy package you can use with whichever flavour of ubuntu you please.
Because if he wanted to roll his own kernel he would have used Gentoo in the first place! The time it took to get Ubuntu upgraded would have been about the same as an 'emerge -aDu world' on this old hardware.
Do you still have this board?
@Joe: Sold it on eBay years ago. Are you looking for a replacement in a piece of equipment?
@jhansonxi Thank you for the response. Yes, looking for a replacement for an existing system.
@Joe: Depending on the problem, the board may be fixable. Leaking caps are a common motherboard problem but they can be replaced. The most obvious potential problem with the SBC-MAX is the Dallas CMOS/RTC/battery module. If the battery fails then it won't retain BIOS settings or time. The module is no longer made (Dallas Semiconductor was bought by Maxim) but I remember reading articles about bypassing it with a new battery. It was popular on motherboards and embedded systems 10-15 years ago.
@Joe: You should ask about it at Electronics subreddit. Someone there may know more about it.
@jhansonxi Thank you for your advice. I'll look into alternative solutions.
@jhansonxi Just one more question. You indicated that it was part of a vehicle monitoring system. Do you remember what the make and/or model of this system was?
@Joe: It was an aftermarket system, predecessor to this system, that was installed in buses, trains, and other public transports. Was very unreliable but mostly due to the use of laptop hard drives at 100% duty cycle in temperatures way over their ratings.
@jhansonxi Just to make sure, when you say predecessor to the linked system, it was by the same manufacturer?
@Joe: Vultron in the USA. I'm not sure how it relates to the Hungary company and I don't know anything about their current products. The parent of Vultron, Trans-Industries, went bankrupt a decade ago. IIRC, the brand was bought by investors at auction, mostly to service existing customers, but it's a different company. I believe American Technical Fabricators is what was left of the manufacturing part of the new company. The Vehicle Components picture looks like part of the system that used the SBC-MAX but the linked page is blank. They may not be servicing the old customers anymore or sold off that part of the business. You could try contacting a customer of the system but the original version is so old (and unreliable) that they probably don't use it anymore.
@jhansonxi Thank you for the background information. This is helpful.
Post a Comment