OT: wanting to write PCI daemon

OT: wanting to write PCI daemon

[Stefan Jeglinski]

Now that I have your attention with the moronic subject line, ahem...
I feel more comfortable writing to this list than a gen-purpose linux
list; feel free to respond off-list.

As background, our current product is a PCI card that works in Wintel
and Mac boxes. We make a hardware driver for Win/OS9/OSX, and a
control and data acquisition application for Win/OS9/OSX that talks
to the driver, which in turn talks to DSPs on the PCI card.

Our company is faced with a redesign of our PCI card because of the
new PCI-X architecture coming up. We were already planning to drop
PCI altogether and move our card electronics to an external box that
runs a Linux kernel on a commercial motherboard, with internal
connections to our custom hardware, and communicating with external
computers via TCP/IP.

We have been moving along in this project slowly, and you could say
we're now caught with our pants down a bit, given that part of our
customer base will soon be buying G5s with PCI-X only (except the one
model).

As an interim solution until our next-gen hardware becomes real, we
want to use up our stock of existing PCI cards, and have mostly
settled on the idea that we can build a small box with a commercial
motherboard including 1 PCI slot. But to further our next-gen design,
we'd like to go ahead and run a linux kernel on it. That means it
will likely be Intel, so already I'm getting seriously close to
getting booted here, but this we know how to do. We then just need a)
to talk TCP/IP out the one end, and b) PCI on the other.

We had the naive idea that we could take an existing [open-source]
daemon that listens via TCP/IP on an ethernet interface, and modify
it for our purposes. We would then wed the kernel (and daemon) with
source code from PLX, the maker of our PCI controller chip (they
apparently provide Linux source as part of a $99 devel kit).

Now the questions: does this seem at all reasonable? Are there
obvious gotchas or better approaches? Is the idea of adapting an
existing daemon a stupid one? If not, which existing daemon might be
best adapted? Are there existing TCP/IP daemons that already are
adapted for use in a PCI environment? Is there already a free OOTB
solution for us? <grin>

Any other thoughts or suggestions? Is my terminology even in the
right place? Searching on sourceforge for "PCI" brings quite a few
hits, but our resources to investigate even the reasonable
possibilities are limited.

Regards, and thanks for your patience,

Stefan Jeglinski

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: OT: wanting to write PCI daemon

[Tim Seufert]

On Tuesday, July 8, 2003, at 03:46  PM, Stefan Jeglinski wrote:

> We have been moving along in this project slowly, and you could say
> we're now caught with our pants down a bit, given that part of our
> customer base will soon be buying G5s with PCI-X only (except the one
> model).
>
> As an interim solution until our next-gen hardware becomes real, we
> want to use up our stock of existing PCI cards, and have mostly
> settled on the idea that we can build a small box with a commercial
> motherboard including 1 PCI slot.

You may be aware of this already, but it seems like an obvious question
to ask, so: Are your cards 5V, or are they Universal (compatible with
both 5V and 3.3V)?  If they're Universal, they will work as-is.  The
conflict isn't about PCI protocol vs PCI-X protocol (PCI-X is backwards
compatible), it's about signal levels.  All PCI slots faster than 33
MHz must (according to the standard) use 3.3V signaling, PCI-X slots
included.  3.3V slots don't accept 5V cards, 5V slots don't accept 3.3V
cards, and Universal cards work in either kind of slot.  Up until now,
Apple has used 5V slots almost exclusively (the lone exceptions prior
to the G5 were the B&W G3, which had one 32-bit 66 MHz 3.3V slot, and
the XServe, where I believe all slots are 3.3V and 66 MHz).  Recent
cards are usually Universal, but there must be enough 5V only cards
still in common use that Apple felt it necessary to make at least one
model compatible with them.

>  But to further our next-gen design,
> we'd like to go ahead and run a linux kernel on it. That means it
> will likely be Intel, so already I'm getting seriously close to
> getting booted here, but this we know how to do.

Aw, c'mon, use one of those cute little TeronCX boards or something
like that.  :)

> We then just need a)
> to talk TCP/IP out the one end, and b) PCI on the other.
>
> We had the naive idea that we could take an existing [open-source]
> daemon that listens via TCP/IP on an ethernet interface, and modify
> it for our purposes. We would then wed the kernel (and daemon) with
> source code from PLX, the maker of our PCI controller chip (they
> apparently provide Linux source as part of a $99 devel kit).
>
> Now the questions: does this seem at all reasonable?

Yes.  Presumably what PLX provides is a driver skeleton that knows how
to do DMA, use the chip's mailbox registers and other features, and
communicate with userspace.  You would flesh this skeleton out with
whatever device specific stuff you need to do, extending the userland
interface as appropriate.  Then you would hack the daemon to serve data
retrieved through the userland knobs of the device driver.

(Though I'm not sure whether it would be a good idea to use an existing
daemon as anything beyond sample code to see how real live TCP/IP
communications work.  You might have a hard time finding one that is
ideal for direct adaptation, and it can be a big mistake to try to bend
existing programs too far.  Hopefully somebody else who knows better
about what kind of server code is out there can provide you with some
advice on this.)

>  Are there
> obvious gotchas or better approaches? Is the idea of adapting an
> existing daemon a stupid one? If not, which existing daemon might be
> best adapted? Are there existing TCP/IP daemons that already are
> adapted for use in a PCI environment? Is there already a free OOTB
> solution for us? <grin>
>
> Any other thoughts or suggestions? Is my terminology even in the
> right place? Searching on sourceforge for "PCI" brings quite a few
> hits, but our resources to investigate even the reasonable
> possibilities are limited.

My only comment here is that the phrase "PCI daemon" probably isn't the
way you should think of it.  The canonical layering would be for the
device driver to present an abstract bus independent interface to the
card's functionality; the daemon shouldn't have to know anything about
what kind of bus the device happens to be on.

(But don't take that as gospel.  Sometimes it is good to push chunks of
driver functionality out into userland, especially if performance isn't
critical.  It can make debugging a great deal easier, for example.  And
to provide the proper disclaimer, I am not a driver expert, I just play
one on TV.)


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: OT: wanting to write PCI daemon

[Giuliano Pochini]

On 09-Jul-2003 Tim Seufert wrote:
> Recent
> cards are usually Universal, but there must be enough 5V only cards
> still in common use that Apple felt it necessary to make at least one
> model compatible with them.

What model ?  AFAIK none of the G5 pmacs is compatible with
V5 PCI cards. See page 73 of the preliminary specs.


Bye.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: OT: wanting to write PCI daemon

[Stefan Jeglinski]

>  > Recent
>>  cards are usually Universal, but there must be enough 5V only cards
>>  still in common use that Apple felt it necessary to make at least one
>>  model compatible with them.
>
>What model ?  AFAIK none of the G5 pmacs is compatible with
>V5 PCI cards. See page 73 of the preliminary specs.


see <http://www.apple.com/Power Mac/specs.html>, the low end model.


Stefan Jeglinski


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: OT: wanting to write PCI daemon

[Giuliano Pochini]

On 09-Jul-2003 Stefan Jeglinski wrote:
>
>>  > Recent
>>>  cards are usually Universal, but there must be enough 5V only cards
>>>  still in common use that Apple felt it necessary to make at least one
>>>  model compatible with them.
>>
>>What model ?  AFAIK none of the G5 pmacs is compatible with
>>V5 PCI cards. See page 73 of the preliminary specs.
>
>
> see <http://www.apple.com/Power Mac/specs.html>, the low end model.

It's http://www.apple.com/powermac/specs.html

I can't see anything about 5V PCI compatibility in that
page. But in the preliminary specs
<http://developer.apple.com/documentation/Hardware/Developer_Notes/Macintosh_CPUs-G5/PowerMacG5/PowerMacG5.pdf>
at pages 27 and 73:

"The connectors to the PCI or PCI-X slots are 3.3V keyed [...]
5V keyed or signalling cards do not work in the Power Mac G5 computer".




Bye.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: OT: wanting to write PCI daemon

[Stefan Jeglinski]

>  > see <http://www.apple.com/Power Mac/specs.html>, the low end model.
>
>It's http://www.apple.com/powermac/specs.html

I have no idea how I screwed that link up.


>I can't see anything about 5V PCI compatibility in that
>page.

We had mistakenly interpreted "Three open full-length 33MHz, 64-bit
PCI slots" as 5V PCI slots, the same as their past PowerMac models.

>  But in the preliminary specs
><http://developer.apple.com/documentation/Hardware/Developer_Notes/Macintosh_CPUs-G5/PowerMacG5/PowerMacG5.pdf>
>at pages 27 and 73:
>
>"The connectors to the PCI or PCI-X slots are 3.3V keyed [...]
>5V keyed or signalling cards do not work in the Power Mac G5 computer".

Yup. Dawn's early light...


Stefan Jeglinski

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: OT: wanting to write PCI daemon

[Tim Seufert]

On Wednesday, July 9, 2003, at 12:52  AM, Giuliano Pochini wrote:

> On 09-Jul-2003 Tim Seufert wrote:
>> Recent
>> cards are usually Universal, but there must be enough 5V only cards
>> still in common use that Apple felt it necessary to make at least one
>> model compatible with them.
>
> What model ?  AFAIK none of the G5 pmacs is compatible with
> V5 PCI cards. See page 73 of the preliminary specs.

Ah.  I jumped to what seemed like the logical conclusion instead of
reading the specs.  :)


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: OT: wanting to write PCI daemon

[Stefan Jeglinski]

>You may be aware of this already, but it seems like an obvious question
>to ask, so: Are your cards 5V, or are they Universal (compatible with
>both 5V and 3.3V)?  If they're Universal, they will work as-is.  The
>conflict isn't about PCI protocol vs PCI-X protocol (PCI-X is backwards
>compatible), it's about signal levels.

Correct. Our cards are 5V only :-/

>>  But to further our next-gen design,
>>we'd like to go ahead and run a linux kernel on it. That means it
>>will likely be Intel, so already I'm getting seriously close to
>>getting booted here, but this we know how to do.
>
>Aw, c'mon, use one of those cute little TeronCX boards or something
>like that.  :)

Overkill on the PCI :-) We need one slot

Actually, we were looking at something like the following concept(s):

<http://www.mini-itx.com/hardware/intro.asp>
<http://www.hushtechnologies.net/hushmini.htm>
<http://www.michael-dieckmann.de/projekt_luefterlose_pc.htm>


>My only comment here is that the phrase "PCI daemon" probably isn't the
>way you should think of it.

ya, I figured that. Thanks for the other comments.


Stefan Jeglinski

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: OT: wanting to write PCI daemon

[linas]

On Tue, Jul 08, 2003 at 08:53:09PM -0700, Tim Seufert wrote:
>
> On Tuesday, July 8, 2003, at 03:46  PM, Stefan Jeglinski wrote:
> > We then just need a)
> > to talk TCP/IP out the one end, and b) PCI on the other.

??
tcpip has the concept of sockets and ports.  Maybe you mean 'udp'?
Do you need to forward *all* internet traffic, or just some of it?
Not everything on an ethernet cable is tcpip; there's a whole zoo
of protocols that one typically sees on a LAN.

> (Though I'm not sure whether it would be a good idea to use an existing
> daemon as anything beyond sample code to see how real live TCP/IP
> communications work.

Agreed.  The standard unix programming interfaces are not that hard.
You can write a simple daemon yourself with a few dozen lines of code.
(and less if you're clever).  After that, its all custom, app-specific
code.   I think you need a good book w/ examples in it.


--linas

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/