tih@barsoom.nhh.no (Tom Ivar Helbekkmo) (06/13/90)
I'm using SCO Unix V/386 3.2.0 here, and would like to be able to use
a serial card that I've got, with 4 ports on it. However, the card is
not "intelligent": I can assign each of the ports individually to IRQ
2, 3, 4 or 5, and each has its own I/O base address. Actually, I can
even add another card of the same type, as each port can be configured
as COM1 through COM8. Since I can only use IRQs 3 and 4 for serial
I/O, I have to let 2 ports share each of these (4 ports if I add
another board of the same type).
Anyway, with SCO's serial driver ("sio"), this won't work. (Unless
I'm mistaken, in which case I'd like to hear about it!) Each serial
port that's not on an intelligent card has to have its own IRQ.
Because of this, I've been trying to write my own replacement for the
supplied sio driver. I've based it on the example code in the Device
Driver Writer's Guide, and followed the guidelines there. I call the
compiler as:
/bin/cc -c -O -K -Zp4 -M3 -DINKERNEL sio.c
Using /etc/conf/cf.d/link_unix (after replacing the files in
/etc/conf/pack.d/sio with my own code) actually produces a new unix,
giving no warnings or error messages in the process. I've kept the
configuration info from the original sio, as my driver currently only
supports COM1 and COM2 on IRQs 4 and 3, respectively.
Now for the problem: When I try to boot this new unix, it says
"Header read error: 0" immediately after I specify the unix file name.
This seems strange to me -- I'd expect my new kernel to crash when
accessing the serial ports, sure, but at least I thought I should be
able to boot it! :-)
If anyone can give me any hints and tips, I'd be very grateful!
-tih
--
Tom Ivar Helbekkmo, NHH, Bergen, Norway. Telephone: +47-5-959205
tih@barsoom.nhh.no, thelbekk@norunit.bitnet, edb_tom@debet.nhh.notih@barsoom.nhh.no (Tom Ivar Helbekkmo) (06/15/90)
david@csource.OZ.AU (david nugent) writes (on SCO Unix serial drivers): -> The sample sio driver in the documentation is abysmal; when compiled -> and linked in - even without modifications and after cleaning up the -> typo's - doesn't even work. It's also quite dated under the current -> kernel version and doesn't support everything required (hardware flow -> control and additional line disciplines, for example). Sure -- I know it won't work the way it is, and among other things I have to figure out what sioputchar() and siogetchar() are supposed to do. Still, I've taken on the challenge by now, and am pretty determined to write a replacement that can handle the multi-port serial boards that I happen to have... :-) I don't worry about hardware flow control and the like. All I want is to be able to hook up a two terminals, a serial printer and a slip link using the age-old "RS237" cable (*grin*) and make them work acceptably well at low baud rates. I also hope to learn something in the process, as I've never written an actual device driver before... -> You're probably asking the impossible of the hardware. I'm yet to find -> a serial card which doesn't advertise that it can share IRQ's (even though -> you might be able to switch them independantly) and yet can. What -> this amounts to is that you probably _CAN'T_ share IRQ's on the card -> you're using. It may not have the necessary hardware and logic to do -> it. This card *does* advertise that it can share IRQs. In fact, the default configuration of the board, as delivered from the factory, includes shared IRQs. So it all boils down to, right now, that I need to know why my kernel becomes unbootable with a "Header read error: 0" immediately after I press return at the boot prompt when I link my own sio module into it. Anyway, I figure I'm doing one of two things wrong here. Either I'm calling something that I shouldn't, or I'm missing a compiler flag that should be there. I guess I'll try to reverse engineer the supplied sio module a bit, to see if I can spot any interesting information that way. Meanwhile, if anyone who has successfully written a device driver for SCO Unix could give me any hints or pointers, I'd be grateful! -tih -- Tom Ivar Helbekkmo, NHH, Bergen, Norway. Telephone: +47-5-959205 tih@barsoom.nhh.no, thelbekk@norunit.bitnet, edb_tom@debet.nhh.no
david@csource.OZ.AU (david nugent) (06/15/90)
In <916@barsoom.nhh.no> tih@barsoom.nhh.no (Tom Ivar Helbekkmo) writes: > Anyway, with SCO's serial driver ("sio"), this won't work. (Unless > I'm mistaken, in which case I'd like to hear about it!) Each serial > port that's not on an intelligent card has to have its own IRQ. That's not quite true. SCO supports a few serial cards which aren't "intelligent" (ie. processor driven) which can share IRQ's. The Hostess and DigiBoard (not the COM?/i versions), for example. The sample sio driver in the documentation is abysmal; when compiled and linked in - even without modifications and after cleaning up the typo's - doesn't even work. It's also quite dated under the current kernel version and doesn't support everything required (hardware flow control and additional line disciplines, for example). > Because of this, I've been trying to write my own replacement for the > supplied sio driver. I've based it on the example code in the Device > Driver Writer's Guide, and followed the guidelines there. You're probably asking the impossible of the hardware. I'm yet to find a serial card which doesn't advertise that it can share IRQ's (even though you might be able to switch them independantly) and yet can. What this amounts to is that you probably _CAN'T_ share IRQ's on the card you're using. It may not have the necessary hardware and logic to do it. Sorry - I know it's bad news. I had to learn the hard way too. :-( david -- * Unique Computing Pty Ltd, Melbourne, Australia. * david@csource.oz.au 3:632/348@fidonet 28:4100/1@signet