2.10 kernel and Cobalts.

I had begun trying to port over the Cobalt driver patch to the 2.10 kernel 
for awhile and the kernel has just changed so much since 3.4 that I am not 
100% certain it can be done and if ever so, is it worth the effort? About 
four years ago when I had to modify for things like spinlock changes and 
moving some things from traps.c to elsewhere, I did catch up with Jeff 
Walter who was the person who ported all the drivers to 2.6 in the first 
place but could not put more time into it after the 2.6.32 kernel. During 
this conversation he stated then that it was almost to the point where new 
drivers should be written from scratch. After the 3.4 kernel it IS to that 
point. Do we really need unique Cobalt drivers in the first place?

Every chip on a Cobalt x86 board has a kernel driver already. The serial 
number is derived from a Dallas 1 wire DS2401 chip, in the 550 they get it 
from the eeprom. I believe the serial number scheme is bogus anyway as it 
changes after every rom reset. The Raq3/4 Qube3 and Raq XTR use an LM77 for 
things like cpu temp and in the XTR, fan speeds as well as system temp. The 
550 uses an adm1029 for monitor functions. For i2c the Raq3/4 and Qube3 use 
the Ali chipset for i2c of which the kernel driver exists. The Raq XTR and 
550 use a Serverworks chipset which uses piix4 as it's i2c.

I have a Raq4 running with the 2.10 kernel and I included the above drivers. 
I only had to patch the e100 driver to ignore the checksum which has always 
been the case with the e100 driver and the weird 82551er implementation on 
the Raq3/4. Prior to that, everyone used Donald Becker's eepro100 driver 
which did not care about the checksum being strange. 

Looking at the source code for Cobalt sensors, it does give the 
multiplication factors to get meaningful values from the sensors. 

Another important thing is that the Cobalt rom tries to pass a command line 
to the system kernel. The serial terminal one quit working many kernels ago 
and Jeff had come up with a hack that allowed the rom serial terminal 
commandline to talk to the new one. This was before the kernel had the 
option of embedding command line parameters. To get this kernel to show the 
cli over serial terminal, I had to embed console=ttyS0,115200n8 into it. 
It's also the only one that shows when running:
root@raqcop:~ # cat /proc/cmdline
console=ttyS0,115200n8

Prior Cobalt patched kernels with Jeff's command line fix show this:
root@cellcop:~ # cat /proc/cmdline
console=ttyS0,115200 debug ip=off

I've added debug and ip=off to my kernel config. The ip=off I believe is 
there because the rom has some nfs booting capabilities.

So there it is, to try to fix the patch if possible or use all in kernel 
drivers for the chips. Thoughts? 



-- 
Dave Studeman
http://www.raqcop.com 



------------------------------------------------------------------------------
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/