devc-ser8250 modification

bridged with qnx.ddk
Post Reply
bfaber

devc-ser8250 modification

Post by bfaber » Fri Feb 01, 2008 9:55 pm

Hello

We have just purchased a pc104+ board based off the XR17D158 Chipset.
It is a quad serial uart chip. I am trying to get this to run with
QNX and am not sure how to go about this. I have read a few
threads about changing the mmap_device_io call to
mmap_device_memory() call. I have never done any driver programming
so if anyone could/would give me any insight on the code modification
it would take to the devc-ser8250 ddk (init.c) code , I'd appreciate
it.

Here is my PCI Info
Class = Communication (Serial Controller)
Vendor ID = 13a8h, Exar Corp.
Device ID = 158h, XR17C158 Octal UART
PCI index = 0h
Class Codes = 070002h
Revision ID = 9h
Bus number = 1
Device number = 2
Function num = 0
Status Reg = 80h
Command Reg = 102h
I/O space access disabled
Memory space access enabled
Bus Master disabled
Special Cycle operations ignored
Memory Write and Invalidate disabled
Palette Snooping disabled
Parity Error Response disabled
Data/Address stepping disabled
SERR# driver enabled
Fast back-to-back transactions to different agents disabled
Header type = 0h Single-function
BIST = 0h Build-in-self-test not supported
Latency Timer = 0h
Cache Line Size= 0h
PCI Mem Address = ff7ff000h 32bit length 4096 enabled
Subsystem Vendor ID = 1435h
Subsystem ID = 7320h
Max Lat = 0ns
Min Gnt = 0ns
PCI Int Pin = INT A
Interrupt line = 6
CPU Interrupt = 6h
Device Dependent Registers:
0x40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0xA0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0xB0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0xC0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0xD0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0xE0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0xF0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

Thanks,

Ben

maschoen

RE: devc-ser8250 modification

Post by maschoen » Sat Feb 02, 2008 5:55 pm

Ben,

Take a quick look at:
http://www.ortodoxism.ro/datasheets/exa ... 58v110.pdf

and then at

http://www.ortodoxism.ro/datasheets/nat ... 008652.PDF

Notice anything similar? That's right, there's almost nothing
similar. These
chips process signals that have the same specifications, so many of
the concepts
will be the same, eg. Stop bits, RS/DS, but otherwise they are
completely different
hardware.

Assuming there is no existing driver available for your chip I highly
recommend
that you not attempt to write a driver yourself unless one of the
following conditions is true.

1) You are a hobbiest with lots of time on your hands and you think it
would be fun to learn how.
2) You are a professional programmer who would like to break into the
wonderful world of hardware drivers, and think this would be a good
starter project.
3) Your life depends on accomplishing this.

Otherwise I suggest you seek professional help.

Assuming you meet one of these criteria, here are some basic things
you should know about drivers in general, and QNX specifically.

A driver can logically be divided into to two types of code, that
required to interface to the OS, and that required to talk to the
hardware. In a well written driver, these are separated. I
suspect this is so in the available QNX 8250 source, which means that
you can at the very least learn how to interface to the OS from this
code, and at best you will merely have to drop in some hardware
code.

You might be able to find some hardware code for this chip on-line
such as if there is Linux source available. This sometimes can be
useful, but often not. It is very unlikely you would find source
for the hardware that could just be dropped into the QNX 8250
driver, but in an ideal programming world, this would be possible.

Even if you find good resources at described above, you will have to
become familiar with both of these areas in order to debug your
driver. Interfacing with the QNX OS involves understanding the
structure of a resource manager along with the details of getting
permission to access I/O ports, connecting an Interrupt Service
Routine to an interrupt, querying the PCI configuration information,
along with a general knowledge of how message passing under QNX
works. There are special rules regarding what you can put in an
ISR.
Familiarity with the Posix thread and process structure may also be
required, especially since your chip supports multiple serial ports.

On the hardware side, you will need to understand the I/O port
assignments of your card, and how they function, or similarly the
memory mapped version. You might also note from the specs above
that since this card has DMA capability, you might need a short
course in what a DMA channel does, and how to program it. And of
course you will need to understand how to turn on interrupts, and how
to service them.

In addition to all of this, I might note that debugging a driver
requires a bit more than a standard program. You will not always be
able to step through instructions. Your driver may occaisionally
crash your system. It is always good if you know how to reproduce
this. If not, the debugging experience will be much more, uh,
exciting. An understanding of what a race condition is, and what
kinds of coding errors cause one can be useful here. Finally, once
you have a driver that is functioning, other issues like efficiency
can sometimes be a problem.

While assembler is rarely needed in a driver anymore, an understanding
of it can be. For example, while you don't need to code a "rep
inb" instruction, you might need to know what it is, why it
might be important, and what subroutine will provide it for you.

Expect a wide development cycle. Usually the first version of a
driver works in the lab, but when put in the field, unexpected
problems crop up. If you are dealing with hardware from a specific
manufactorer, (unlike an 8250) a good relationship with the techies
at that company can be useful, helpful, and even required. Not all
hardware works as described in its spec sheets all the time. In
rare instances, an oscilliscope can be helpful.

That said, getting a driver working is a very satisfying experience.

Jacek Rudnicki

Re: devc-ser8250 modification

Post by Jacek Rudnicki » Mon Feb 04, 2008 10:03 am

Hello,

We have written driver for the XR17D158 chipset.
For more details about availability etc. please contact with us.

Regards,
Jacek



Uzytkownik "bfaber" <ben.faber@lmco-dot-com.no-spam.invalid> napisal w
wiadomosci news:fo04hc$a78$1@inn.qnx.com...
Hello

We have just purchased a pc104+ board based off the XR17D158 Chipset.
It is a quad serial uart chip. I am trying to get this to run with
QNX and am not sure how to go about this. I have read a few
threads about changing the mmap_device_io call to
mmap_device_memory() call. I have never done any driver programming
so if anyone could/would give me any insight on the code modification
it would take to the devc-ser8250 ddk (init.c) code , I'd appreciate
it.

Here is my PCI Info
Class = Communication (Serial Controller)
Vendor ID = 13a8h, Exar Corp.
Device ID = 158h, XR17C158 Octal UART
PCI index = 0h
Class Codes = 070002h
Revision ID = 9h
Bus number = 1
Device number = 2
Function num = 0
Status Reg = 80h
Command Reg = 102h
I/O space access disabled
Memory space access enabled
Bus Master disabled
Special Cycle operations ignored
Memory Write and Invalidate disabled
Palette Snooping disabled
Parity Error Response disabled
Data/Address stepping disabled
SERR# driver enabled
Fast back-to-back transactions to different agents disabled
Header type = 0h Single-function
BIST = 0h Build-in-self-test not supported
Latency Timer = 0h
Cache Line Size= 0h
PCI Mem Address = ff7ff000h 32bit length 4096 enabled
Subsystem Vendor ID = 1435h
Subsystem ID = 7320h
Max Lat = 0ns
Min Gnt = 0ns
PCI Int Pin = INT A
Interrupt line = 6
CPU Interrupt = 6h
Device Dependent Registers:
0x40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0xA0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0xB0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0xC0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0xD0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0xE0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0xF0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

Thanks,

Ben

Post Reply

Return to “qnx.ddk”