PCI device driver for PLX9030
Michael Köhler
does anybody knows a PCI device driver for a pci card equipped with a
PLX9030 (or similar device like
PLX 9052, PLX9080) PCI Bridge chip. We want to to use this chip to equip our
hardware with a simple
PCI Interface. The Host PC will run LINUX (kernel 2.2.14/16) and so I have
to write a device driver for the
chip and our application. If anybody knows a board with this chip I could
use the appropiated driver as an
example to access the chip.
Thank you for any help,
Mchael Köhler
Mikkel Elmholdt
You definitely want to go to hppt://www.jungo.com and have a look at
their WinDriver product. It's also suported under Linux these days, and
they have special support for several PLX chips (the 9030 I don't know
about specifically). WinDriver provides you with a library of
specialized functions, which makes writing your own driver much easier
than starting from scratch.
We are currently using WinDriver for WinNT/2000 PCI driver development,
and so far we are pretty happy with it. We are using the PLX 9054 in our
design.
--
Mikkel Elmholdt
Data Respons A/S, Denmark
mikkel....@datarespons.dk
http://www.datarespons.com
Matt Porter
If you are using the PLX9030 in a hardware design you should just
use a EEPROM to preload the local configuration registers so your
vendor id, device id, BAR sizes, and CS/bus region control are
presented when the PCI master autoconfigures the bus. By putting
a 1USD part on the board you can save a lot of software headaches.
Check the datasheet, that is the way they assume you will use it.
I did a kernel port to a custom board that had a PLX9030 to provide
access to a RTC and some PLD logic. Without a serial EEPROM to
preload the registers, I had to temporarily place the local
configuration registers in PCI mem space, configure each bus
region, and then re-autoconfigure the PCI bus so that the newly
enabled BARs on the PLX9030 would be placed into PCI mem space.
If they had preloaded those values with an EEPROM, I could
have relied on the firmware to autoconfigure the device.
That would have just left me the easy chore of using standard
PCI calls to locate the device/BARs and then ioremap the
region for use.
--
Matt Porter
MontaVista Software, Inc.
mpo...@mvista.com
Robert Schwebel
> You definitely want to go to hppt://www.jungo.com and have a look at
> their WinDriver product.
Don't even think about it. Windriver installs a proprietary driver
(windriver.o) which opens up an API that can be used to access whatever
hardware port you want from user space. This is completely agains the
Unix security policies. Read the "Secure programming on Linux and Unix
HOWTO" (can be found on the Linux Documentation Project server).
Robert
Mikkel Elmholdt
Well, the general idea from Jungo is to ease the burden of writing and
debugging device drivers. Debugging kernel code is pretty hard compared
to user mode programming. Thus the generic (why call it "proprietary"?)
kernel driver. Apart from this, in the case of PLX 9030 Jungo will
supply you with an API tailormade for this chip. If you use this, you
will not accidentally thrash any other hardware.
I don't quite get your point about Unix secutiry policies. Any kernel
mode driver can access (and mess with) whatever hardware thingie it
bloddy well wants. So why should that be more safe than a well-debugged
driver in user mode, accessing a specific piece of hardware through a
well-defined and narrow interface?
I had a brief look-through of your mentioned HOWTO. It looks like a good
collection of well-known software programming guidelines, some also
valid for other than *nix systems. I fail however to see how the
Jungo/Windriver concept violates anything in this respect.
Robert Schwebel
> Well, the general idea from Jungo is to ease the burden of writing and
> debugging device drivers.
Yes. But if you don't exactly know what you do you'll open up a huge
security hole.
> Debugging kernel code is pretty hard compared to user mode programming.
Ok, compared to user land programming it's a little bit harder. But I
would not say it's "pretty hard". Writing Windows drivers is much harder
:-)
> Thus the generic (why call it "proprietary"?) kernel driver.
It is closed source. You run a piece of software insite your kernel
where only trusted code should run and you don't even have the source
for it.
> Apart from this, in the case of PLX 9030 Jungo will
> supply you with an API tailormade for this chip. If you use this, you
> will not accidentally thrash any other hardware.
Not if you use it correctly. But if windriver.o is installed you (or
some of the other 100 users on your system) can write a pseudo driver
which accesses wrong ports and crash your system.
> So why should that be more safe than a well-debugged driver in user mode,
> accessing a specific piece of hardware through a well-defined and
> narrow interface?
You're right, but it looks to me as if windriver.o opens up a way of
accessing ports to user mode. This is not what I call a narrow
interface.
Robert
Claus Giebert
I would not even think about using PLX without the config-prom. The only
secure way to do this is integrating the initialisation in the BIOS. We
sometimes do this, but for volume less then 10K i don't think it is woth
since you might need the BIOS-Source.
But where do you buy EEPROMs? 1USD? We pay somethink like 0.5 USD.
Best Regards
Claus Giebert
Sam Jansen
forget the Jungo junk, you don't need it. I'm working at the moment on
Card with a PLX9052 and a USART behind it. You only have to program the
registers of PLX serial EEPROM in a right way for your chip behind the
brigde ( if you wanna do I/O or mmap, the chip selects and so on ) and
the Brigde will be transparent to you.
bye Sam
Klaus Hitschler
Hi all,
this grows into a interresting discussion about "Why writing a driver?".
There are some reasons which are neglected when you use so called
"generic drivers":
1. A driver must hide the special secrets of your device from the user
view. The user (the programmer of a application) don't want to bother
with device registers. She/he want to open a port or a device or a file.
2. A driver must allow different applications to share or a common port
or device. E.g. a network driver, or a driver for a
analoge-to-digital-converter share its conversion data to many
applications.
3. A driver must provide a unified view to a group of devices to ease
changeing the device to another one.
4. A driver must interact with the operating system and provide
informations to the OS or sometimes control the OS. Think of drivers
running in a multiprocessor environment or drivers which reserve ports
or memory resources for a path.
5. A driver in a modern OS has to fullfil some security conditions.
There are several vendors which provide so called "generic drivers"
which need only a recompilation to run on all flavors of MS-Windows, on
LINUX and so on. All these drivers are simple port mappers which do not
even compare to real drivers. These port mappers are only useful for
simple prototyping tests. Driver writing for LINUX is not so hard.
Allesandro Rubinis book about driver writing is a good starting point.
Try it, regards from Klaus