[cgl_discussion] Hot Plug support for PICMG2.16

John Grana jjg at pt.com
Thu Jan 9 13:37:23 PST 2003


I have been looking over the CompactPCI hot plug software in 2.5.5X and it
occurred to me that it did not support the newer enhancement to cPCI, namely
PICMG2.16 Packet Switched Backplanes. My feeling is that most new systems
are moving farther and farther away from parallel bus based systems and more
to packet/fabric. CompactPCI's 2.16 is the first in a long line of packet
based backplanes (AdvancedTCA, PCI Express and the).

I decided to look into the requirements and arch. specifications and found
that there is the "philosophy" in place, but really no actual framework for
supporting hot plug 2.16 systems. The architecture specification does well
in describing "Hot Device Identity" in a generic format. For the present,
CompactPCI systems leaverage the PCI bus config. cycle. In looking over what
we have today (at least what was in the 2.5.51 kernel tree), the real issue
is not the hot plug sensing, but the enumeration of the device where there
is no PCI signaling. This is going to take some thought...

It looks like the present hot plug code (at least in 2.5.51) will handle
PICMG 2.16 fine as far as the ejector, hot swap LED, etc. Where the problem
lies is in the fact that 2.16 based systems do NOT need to have a PCI bus at
all. So, enumeration in the present form of accesing the PCI configuration
space and getting the Vendor and Device ID's is not going to work. We still
need the enumeration or "Hot Device Identity" as the arch. spec. 1.1 puts
it, but we can't do it using the present infrastructure.

I feel this is important, but would like some feedback on how to move
forward with getting this added to the CGL framework. Again, my feeling is
we will be seeing lots more PICMG 2.16 backplane/systems (without a PCI bus)
being introduced this year so the sooner discussed the better.

Here are a few ideas on how to handle the enumeration/identity. These are in
no particular order and I am sure there are other. I would like to solicit
feedback and discussion on what people feel is the best way:

1) IPMI - aka PICMG 2.9.
 Benefits - fairly simple, already has definition for Vendor/Device ID
information in a format that is easy to map to the PCI config cycles. Is
required in AdvancedTCA and maybe even PCI Express.
Disadvantages - not mandatory in PICMG (is a "should" not a "shall").

2) SNMP (RFC 1156)
Benefits - since packet switched backplanes are network based, supporting
SNMP should be easy. Can use the SysDescr OID to describe what the device
is.
Disadvantages - requires TCP/IP running before SNMP can respond. SysDescr is
pretty generic - no real standard format as to what is there other then text
string.

3) Define new TCP Port service (PacketEnum or something)
Benefits - can be simple - all we need is something like the Vendor name and
device ID. would be a simple ask/respond protocol.
Disadvantages - requires TCP/IP up and running before response can be done.
Would need to request port number from IETF.

4) Define a new Ethernet packet type
Benefits - simplest in the network domain, a single packet with a different
packet type field that would contain a Vendor and device ID. Doesn't require
TCP/IP running, just the ethernet driver. In fact, doesn't require IP at
all. Would also solve another problem in packet based backplane systems -
when is the newly inserted device ready? Device could broadcast a single
packet when ready or when requested.
Disadvantages - need to get IEEE to allocate new packet #

Some of the issues with #2 and #3 are that you need to have the newly
inserted board bring it's network up - IP addresses, netmask etc might
require DHCP before it could even respond to the Identity process.

Not sure which is ideal, any ideas on the above or others? I have just read
that Monte Vista and Nokia are working on Hot Device Identity. Should I be
taking this up with them???

Cheers
John Grana
jjg at pt.com

Performance Technologies, Inc.
205 Indigo Creek Drive
Rochester, NY  14626




More information about the cgl_discussion mailing list