driver development for StarTech/Rayon serial expansion cards


New Member

Messages: 7

[ed: My apologies if I've chosen the wrong forum. I've been with FreeBSD for a long time, but I've only participated online sporadically.]

Here's my situation. I have in my possession three quad RS422/RS485 expansion cards from (which seem to also have some association with Rayon). When last I tried to use these, they worked under Linux but not under FreeBSD. The manual claims they are 16C550A compatible. There are presently cards listed in pucdata.c mentioned as being based around this chip, such as the quad-port SIIG Cyber 4S PCI.

Back in the Debian Lenny timeframe (ancient history), an outfit named the Roller Network hacked on some related cards.

StarTech (Rayon) RS422/485 Serial Driver

From there you can drill down to their source at:


Two chips mentioned in passing in that file are the PLX9050 PCI bridge and the MCS9845 dual 16C450/16C550.

My own P485U cards are presently in storage and I don't have them at hand, but that at least suggests the kinds of chipsets that might be involved.

From this limited scouting expedition of mine, I imagine that hacking on pucdata.c to get my cards working might not actually be that big of a job. Maybe even as small as adding some vendor codes. I'm willing to dive in if it's a somewhat modest project. I don't have a ton of driver experience, but do I have a fair amount of embedded experience and the associated debugging processes.

Anyone else have an assessment about what this initiative might finally involve?

I've wanted to hack on a driver in a modest way for a long time, and I thought this might be a good place to dip my toe into the pond.


New Member

Messages: 7

Well, I got ambitious and fetched one out of storage. The chips are indeed PLX PCI9030 and TL16C554AFN.

I found a daunting manual for the 9030 here, of a mere 184 pages: PCI 9030 Data Book

My P485U board also contains two 44-pin TQFPs labelled "Lattice" and some text too dim to read in normal light. These are connected to the dip switches and are probably some kind of small CPLDs implementing custom glue logic. I don't know how much that might show through at the driver level, though.

In any case, I would rate this as a 90% known beast of a mostly familiar configuration.