Next: 7 System Configuration Up: Debian on the ProGear Previous: 5 Advanced Configuration
The stock Progear uses kernel version 2.4.1ac19 with modified device drivers for audio, pcmcia, the i2c bus and power management. All the hardware supported by these custom drivers are now supported by the standard 2.4 kernel from at least 2.4.19, with standard extensions, like alsa, acpi, pcmcia-cs, i2c, which the exception of the LCD dimmer, the complications relating to battery status as described previously, and the lack of kernel support for the S3 (suspend to ram) ACPI mode. As of 2.6 all of these extensions have now been included in the standard kernel and no third party modules or patches are needed.
A kernel is easily replaced, but the Progear tools depend on some of the FrontPath modification to the standard kernel, so it would not be completely functional when booted from a standard kernel. Likewise, your new installation has its own preferred method of managing startup scripts and device module loading. You would like to be able to run the Progear startup scripts when booting from the old kernel, and the new distributions scripts when booting from a new kernel. Fortunately lilo allows this with no thought after initial configuration by specifying the device to use for the root filesystem on a per kernel image basis.
To make a kernel available to boot from you need lilo. lilo is also not included in the factory system. Get it and install it. You may also need a boot.b. You will need to create an initial lilo.conf. Be sure that 'root=...' is appropriate for your system.
Instructions for modifying this are discussed below. Run lilo, make sure it runs without errors. Reboot if you want to be sure it worked, but be warned that if it didn't you may just have permanently made you system un-bootable. See the appendix for notes about removing the hard drive to fix things.
You can use a standard, distribution suppled, precompiled kernel, or configure and compile your own. Most driver options are probably enabled in whatever distribution kernel you get, but for 2.4 series kernel check the ACPI status in particular, and you may have the option of using the standalone pcmcia-cs drivers, which are preferable. See the section below on configuring PCMCIA.
For stock distribution kernels, use one compiled for 386, as I am assuming you won't find one compiled specifically for a Crusoe, which tries no harder to work like anything better. The machine will not even start to boot a kernel compiled for anything higher.
If using a precompiled kernel skip to Installation ![[*]](crossref.png)
.
Get your the source for your favorite kernel. For 2.4 you may also want the latest ACPI patches, they weren't included as of 2.4.21. Note that the debian 2.4.(19-21) kernel sources includes some kind of ACPI support but it doesn't appear to do anything useful. I forget exactly how they failed, probably they wouldn't support sleep states or processor info or something. In any case, as a result, the ACPI patches fail on the debian supplied source, so you will need to get the vanilla source too apply the ACPI patches.
For 2.6, up to date ACPI support is standard.
For no work, use these .config's for 2.4.21 or 2.6.5. There may some extraneous options but both are close to minimal. For different minor versions adapt one of these. I will discuss some of the highlights and a few of the choices.
The Progear really uses a Transmeta CPU. So you can set CONFIG_MCRUSOE at (Processor type and Features)/(Processor family)/(Crusoe). The help in 2.6 mentions that this results in gcc compiling for a 586 with some particular optimization flags. I suppose it did the same for 2.4, though I know that compiling for a 586, (or 486 or 686 or Pentium,...) doesn't work. (Maybe it was just Pentuim, or 686) I don't know quantitatively what effect this has on performance. I never noticed anything dramatic. You can shut off any generic x86 support or emulation features.
In 2.6 turn on whatever you find in (Power management options)/(ACPI support), or in 2.4 with the ACPI patches, (General Setup)/(ACPI Support). The core support yields processor inputs, sleep states and apparently throttling control, though I have never successfully manipulated the latter. The only module I found functional was Button, for power button pressing events. There is no Fan. I keep AC Adaptor and Battery turned on in hopes that one day it will magically start to supply power status information. So far /proc/acpi/battery and /proc/acpi/ac_adapter are empty. I even fixed the dsdt and patched the kernel to load the corrected version at boot as instructed in the Linux ACPI Howto and HOWTO: Fix Common ACPI Problems .
Notice that in 2.6 you can enable CONFIG_X86_LONGRUN in (Power Management Options)/(CPU Frequency scaling)/(Transmeta LongRun). Don't be tempted. After some failed mucking around with this I finally did enough research to learn that the Progear uses the TM3200, but the first Transmeta processor to implement LongRun was the TM3400. This CPU simply doesn't do it. However, it may respond to frequency control via ACPI throttling states. Still studying the possibility. Meanwhile shutoff support for non-existent processors, including the Crusoe. You can try keeping cpuid and msr support in (Processor type and features).
Turn off any APM options. As far as I know, the Progear BIOS includes no APM functionality.
Make sure CONFIG_HOTPLUG is enabled in (General Setup)/(Support for hot-pluggable devices) as it is used for both PCMCIA and USB devices. You won't be needing CONFIG_HOTPLUG_PCI though.
I don't know about CONFIG_PNP, (Device Driver)/(Plug and Play Support) in 2.6, or (Plug and Play Configuration)/(Plug and Play Support) in 2.4. I don't understand the interaction between the BIOS settings and these kernel options, and I don't know what the BIOS capabilities or settings are and I can't change them. It is possible that this ignorance has something to do with my problems with PCMCIA/Pen/Audio conflicts. Once upon a time I meant to find out, but lately these problems went away so I probably will never care anymore.
Enable OSS or ALSA as you prefer in (Device Drivers)/(Sound) in 2.6, or (Sound) in 2.4. lspci reveals the sound card to be an ALI5451 device. This is listed with Trident for OSS. CONFIG_SOUND_TRIDENT from .../(OSS)/(Trident ...) in 2.6 and .../(Trident...) in 2.4 enables the OSS device.
For ALSA use CONFIG_SND_ALI5451 at .../(ALSA)/(PCI devices)/(ALi PCI Audio M5451) in 2.6. For 2.4 you need support from the external modules. To use these shut off any kernel sound support, download the alsa drivers, unpack them and do the usual config's and make's needed to install them after building and installing the kernel and the standard modules.
I highly recommend the ALSA drivers. They perform better, are more capable, and OSS is deprecated anyway. Also the OSS driver has the extremely annoying feature that mixer channels are not muted when the driver is loaded. The consequences of this and partial solutions are discussed below.
Also note that with 2.4, both the OSS and ALSA drivers screwed up the pen input. This is also further discussed below. For 2.6 there is still intermittent trouble, but in this case now mostly predictable and correctable, see Advanced Configuration below. If you use 2.4 you may need to consider dropping sound support.
The USB hardware is an OCHI interface so turn on CONFIG_USB_OCHI_HCD in (Device Drivers)/(USB Support) 2.6 or CONFIG_USB_OHCI in (USB Support) for 2.4. This works for both the single port on the machine itself and any ports on a docking station you might have. Include support for whatever USB devices you want. In particular enable CONFIG_USB_HID at (USB HID Support) and CONFIG_USB_HIDINPUT at (HID input layer support) so that you can use a USB keyboard and mouse.
For 2.4 this requires also enabling CONFIG_INPUT (Input Core Support) , CONFIG_INPUT_KEYBDEV ../(Keyboard support) and CONFIG_INPUT_MOUSE ../(Mouse support). I am not completely sure what is necessary for 2.6 as things have been rearranged and it is not easy to tell what is superfluous, though I broke both keyboard and mouse support several times trying to figure it out. The .config above results in a functional keyboard and mouse whatever unnecessary bits it happens to also include.
In both cases also be sure that CONFIG_USB_KBD and CONFIG_USB_MOUSE are disabled in ../(USB Support)/(USB HIDBP drivers) or (USB Support) for 2.6 and 2.4 respectively.
Consider compiling the USB keyboard support, and basic USB and HID input support, directly into the kernel rather than as a module. Otherwise the keyboard will not be available at startup until the root filesystem is mounted and the modules can be loaded. In this case if fsck should happen to fail on the root filesystem before it is mounted, because you have been goofing around to much with the system, you will be locked out. With keyboard support compiled in to the kernel you may be able to plug in a keyboard and repair things in single user mode.
I had regular with trouble with the mouse locking up in X when using 2.4. Unplugging and reinserting it always restored it. This happened independently of whether the driver was compiled as a module or directly into the kernel. I never figured out why this happened. For a while this problem was gone in 2.6, but lately I am starting to have the same trouble.
One other consideration is that the USB CueCat driver objects to HID support. In this case you may prefer to use the HIDBP drivers. I tried them for just this purpose and they work fine. The keyboard's extended keys and even the mouse wheel all work. I can't tell the difference in features so I don't understand why you are warned away from using these drivers in the kernel configuration help.
PCMCIA support is included in both 2.4 and 2.6 kernels in (General Setup)/(PCMCIA/CardBus support) or (Bus Options)/(PCMCIA/CardBus support) respectively. The system is a CardBus controller, again as shown by lspci, so enable CONFIG_YENTA in 2.6 or CONFIG_CARDBUS in 2.4. Then enable driver for any networking, (Device Driver)/(Networking Support)/(PCMCIA network device support) for 2.6 or (Network Device Support)/(PCMCIA network device support) or other cards you want to use, (SCSI, Audio, Wireless LAN) whose options are scattered all over the place but generally now grouped with the equivalents for other busses. Of course, turn on the other required related support, networking options....
With 2.4 you also have the option of instead using the standalone pcmcia drivers. In this case completely disable kernel PCMCIA support and follow the usual procedure for downloading, building and installing the pcmcia-cs source. For projects like linux-wlan, which provide support for, in particular Linksys WPC11 wireless cards, use of the standalone drivers is mandatory. In this case use 3.2.2 or later. I was unable to get any 3.1.? version to work properly.
All of these possibilities provide basic functionality but for the kernel drivers I have been unable to get the system to recognize to recognize card insertion and removal events without manually informing it via cardcrl insert/eject. The standalone i82365 driver that also runs cardbus devices allows for a poll_interval parameter that accommodated this, but such an option is not available in the kernel yenta_socket PCMCIA driver. More about this below.
The tools mentioned earlier for getting battery status through the i2c bus will work for a custom kernel if i2c support is enabled. Enable basic support with CONFIG_I2C at (Device Driver)/(Character Devices) in 2.6 and (Character Devices)/(I2C Support) in 2.4. Also enable the device interface CONFIG_I2C_CHARDEV at (I2C Device Interface). The /proc interface is also convenient, CONFIG_I2C_PROC at (I2C /proc interface), but it appear to be available only in 2.4. The proc device is necessary for using lm-sensor in 2.4. In 2.6 the /proc interface is not needed for hardware sensors.
For 2.6, in .../(I2C Hardware Bus Support) enable support for ALI 1535, CONFIG_I2C_ALI1535. For 2.4 you will need to download, build and install the external i2c drivers from lm-sensors.org.
Somehow support for this i2c bus in either kernel is not quite as good as with the stock Progear. Accessing the bus with the kernel drivers yields a lot of 'i2c-0: Error: command never completed' sorts of messages in syslog. The stock Progear support is from a modified lm-sensors.org project i2c driver. Perhaps it included a work around for some hardware implementation problem. Once again I haven't studied the differences or tried to fix the kernel implementation.
Here you can actually go beyond the capabilities of the stock Progear, if a bit frivolously. The system hardware includes an ADM1021 compatible hardware sensor chip. In 2.6 enable CONFIG_SENSORS_ADM1021 in ../(I2C Hardware Bus Support)/(Hardware Sensors Chip Support). Then after loading the adm1021, sensors will give you CPU and system temperature.
For 2.4 fetch and install the lm-sensors package. Follow the instructions.
Almost forgot. This thing has an IR port. Turn it on if you want, somewhere in (Device Drivers)/(Character Drivers). Never got to playing with it myself. Sounds fun, though it is probably something that sounds a lot more useful than it ever really turns out to be.
Build the kernel and modules in the usual way and install the results in the new filesystem. It is (probably) possible to install the kernel image in the Progear partition, but there might be something about needing the image in /boot on the root filesystem when booting. Anyway, the modules have to go in the new root, and you might as well keep everything self contained.
To set up lilo to use this kernel and the new file system add a section to /etc/lilo.conf in the Progear filesystem. The path to the image will be as seen in the current filesystem, that is /mnt/debian/boot/vmlinuz.... In this new section add a root=/dev/hda? to change the default root filesysystem when booting from this image. Note the following example:
<...>
image=/boot/bzImage-241ac19
root=/dev/hda2
label=Progear
read-only
image=/mnt/debian/boot/vmlinuz-2.6.5
root=/dev/hda6
label=Linux
read-only
<...>
image=/mnt/progear/boot/bzImage-241ac19
root=/dev/hda2
label=Linux
read-only
image=/boot/vmlinuz-2.6.5
root=/dev/hda6
label=Linux-2.6
read-only
For the moment keep the Progear kernel as the default in case the new kernel doesn't boot the machine far enough to interact with it to fix things or reset lilo, in which case you are also stuck with a dead machine because you can't go back and choose the Progear kernel with a keyboard at boot time. Of course, you still want to be able to try the new kernel and as you can't choose it at boot time for the same reason, you can instead arrange to have it selected after the next reboot, and only the next, using lilo's -R flag. Run something like 'lilo -R Linux-new'. This sets the command line for the next boot. It inserts what you would have been able to type at the lilo prompt if you had a keyboard, so it can also include other boot options. After booting this default command is cleared, so that if you don't explicitly reset it, the next boot will again use the default kernel.
This makes it perfectly safe to play around with your kernel. When you are confidant of the stability of the new kernel you can set it to be the default. Alternately you can use 'lilo -R' in you startup or shutdown scripts to effect a sort of rescue disk. See the appendix.
Before actually booting the kernel you may need do at least one bit of additional configuration to make sure that the system is accessible when you boot. In particular the keyboard must be operational. If you compiled USB and keyboard support into the kernel then everything should be loaded with no more work, though you might like to install the hotplug scripts so that a keyboard can be used even if it is not plugged in during the boot, but instead after the system has already started.
For loadable module USB keyboard support, hotplug is also the simplest and sufficient solution. Otherwise make sure the appropriate modules are listed in /etc/modules. These include usb-ohci, hid, and keybdev. You might be able to configure modutils to have the modules automatically loaded as well, but I can think what device the keyboard modules should be associated with offhand.
Alternately you could just have X start at the end of the init sequence and trust that it will start up fine. Which it actually should if it works in the chroot.