Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

KERNEL PANIC when my Device Driver accesses hardware

19 views
Skip to first unread message

Bob Morrison

unread,
Dec 30, 2001, 1:50:52 AM12/30/01
to
Hi.

I have run into a brick wall while attempting to write a device driver
to access a hardware adaptor which uses a 1k block of dual port ram
located at address 0x0CA000.

I have created a simple version of the device driver and sucessfully
linked it with the kernel.

I have determined, using printf statements, that the driver is
receiving the correct hardware address.

However, a kernel PANIC occurs any time an attempt is made to read or
write to the hardware adaptor's addresses.

It seems clear that the Kernel is unhappy about the driver referencing
any addresses beyond the memory space provided for the driver.

I guess that there has to be some way of persuading the kernel that it
is OK, but what that is I know not.

The software environment is SCO 3.2v4.2 with development system.
The hardware is clone Pentium.

I have not been able to obtain access to a copy of SCO's device driver
writers manual which is clearly what I need. Nevertheless, I have got
this far with the following publications:

a). "Writing a UNIX Device Driver" , Janet I. Eagan & Thomas
J.Teixeira published by Wiley, &

b). "Writing UNIX Device Drivers", George Pajari, published by Addison
Wesley.

Both books have provided almost all that was needed up until now.
However, while Pajari's book deals specifically with SCO UNIX, he
makes only passing reference to the fact that some adaptor cards might
access dual port memory.

The first mentioned book appears to explain how to do it, but the
method does not seem to suit SCO UNIX.

The following files, Master, System, Node & space.c are used with the
command:
/etc/conf/bin/idinstall -a symax_

followed by:
/etc/conf/bin/idbuild

=====================================
Driver.o Compiled device driver

Master: symax_ Iocrw Hcio symax_ 0 0 1 1 -1

System: symax_ Y 1 3 0 0 0 0 ca000 ca3ff

Node: symax_ symax_ c 0

space.c

#include "config.h"
int symax_addr = SYMAX__0_SCMA;
=============================================
I am doing everything according to the books so far (except that I had
to figure out the bit about space.c for myself).

The KERNEK building operation is clearly being told that I want access
to hardware and the address of that hardware.

Within the driver I use the following code fragments in the
symax_init() routine:
.
.
struct mailbox *MB; /* hardware data structure defined earlier */
.
.
MB = (struct mailbox * ) symax_addr; /* Get the Hardware address */

MB->nim_parameters = restart; /* Reset the SyMax card */
.
.
==============================================
Clearly there is something important missing here.
Any assistance would be greatly appreciated.

Robert Lipe

unread,
Dec 30, 2001, 9:01:10 AM12/30/01
to
[ followup-to set to c.u.s.p.]

On Sun, 30 Dec 2001, Bob Morrison <rmorr...@bigpond.com.au> wrote:

>I have run into a brick wall while attempting to write a device driver
>to access a hardware adaptor which uses a 1k block of dual port ram
>located at address 0x0CA000.

It can be done.

>I have determined, using printf statements, that the driver is
>receiving the correct hardware address.
>
>However, a kernel PANIC occurs any time an attempt is made to read or
>write to the hardware adaptor's addresses.

Your code samples below show that you're reading the adapter's physical
address, not a virtual one. You need a virtual address for these accesses.


>The software environment is SCO 3.2v4.2 with development system.
>The hardware is clone Pentium.

Part of me wonders why you're developing on an OS that was obsolete
almost seven years ago, but I won't dwell on that now, since the answer
is the same for current OpenServer, too.

>I have not been able to obtain access to a copy of SCO's device driver
>writers manual which is clearly what I need. Nevertheless, I have got
>this far with the following publications:

Fortunately, most of what you need is available on line. The Hardware
Developer Kit (HDK) is available online at:
http://www.caldera.com/developers/hdk/
While it's less than intuitive, goto:
http://www.caldera.com/support/docs/
and folow OpenUNIX 8 (the HDK doc set between OpenServer, UnixWare,
and OpenUNIX is unified, but the OpenServer entry point on the web is
"broken") and follow hardware and driver development.

>a). "Writing a UNIX Device Driver" , Janet I. Eagan & Thomas
>J.Teixeira published by Wiley, &
>
>b). "Writing UNIX Device Drivers", George Pajari, published by Addison
>Wesley.
>
>Both books have provided almost all that was needed up until now.

The FAQ for c.u.s.p. lists a few others, too.

>However, while Pajari's book deals specifically with SCO UNIX, he
>makes only passing reference to the fact that some adaptor cards might
>access dual port memory.

I recall that outtage. I think I also recall a chapter or two that
was missing in my copy. ;-)

>The first mentioned book appears to explain how to do it, but the
>method does not seem to suit SCO UNIX.

Correct. This is one of the corners of device driver programming that's
different in all OSes. (Well, except in UDI where udi_pio_map is exactly
the same in all OSes....)

> int symax_addr = SYMAX__0_SCMA;


>.
>struct mailbox *MB; /* hardware data structure defined earlier */
>.
>.
>MB = (struct mailbox * ) symax_addr; /* Get the Hardware address */
>
>MB->nim_parameters = restart; /* Reset the SyMax card */
>.
>.
>==============================================
>Clearly there is something important missing here.
>Any assistance would be greatly appreciated.

You need to pass that physical address to sptalloc to get a mapped virtual
address. So that is approximately like:

MP=sptalloc(1, PG_P | PG_PCD, btoc(symax_addr), NOSLEEP);

You also probably need to tag this identifier as volatile to stop the
optimizer from getting clever on your hardware accesses. AFAIR, that
version of the optimizer is too stupid to get too ambitious in this
regard, but making accesses through MB volatile will save you grief.

RJL

0 new messages