Qnet between Intel (little endian) and MPC 8260 (big endian)

QNX Newsgroups (Archives) qdn.public.qnxrtp.os
1

Dear sirs,

We worked on PPC BSP, we booted Neutrino on a card (Interphase 4532)
based on MPC 8260 processor (Power Quick II) and we adapted successfully
serial port and Ethernet networking. We used the latest version of RTP
available on the Web. We have connected via LAN the PPC card and the
host PC (Pentium III) that we are using as development platform.

From the documentation it looks that it is possible to have processes
exchanging messages between the PPC and the Pentium, using low level IPC
and Qnet support, with the proper endian conversions performed within
the communicating processes.

To start the IPC the client has to find the pid of the server so we
expected that the namespace of any system is always available on the
Qnet network, also in case of different endianism.

We noted that the PPC namespace is correctly working from a shell
activated on the serial line of that processor, but when we attempt to
perform ‘ls’ of the /net mount point of both processors (Intel and PPC)
we got the “Unsupported endian” message referring to the other peer.

Is there anybody that could clarify the operation and the restrictions
of Neutrino in such cases ?

Thanks

–

| Enrico Bendinelli | Prisma Engineering srl |
| enricob@prisma-eng.it | Via Petrocchi 4 20127 MILANO ITALY |
| http://www.prisma-eng.it | Tel. +39 02 26113507 Fax. 26113597 |

This mail was sent using 100% recycled electrons
2

Enrico Bendinelli <enricob@prisma-eng.it> wrote:

Dear sirs,

We worked on PPC BSP, we booted Neutrino on a card (Interphase 4532)
based on MPC 8260 processor (Power Quick II) and we adapted successfully
serial port and Ethernet networking. We used the latest version of RTP
available on the Web. We have connected via LAN the PPC card and the
host PC (Pentium III) that we are using as development platform.

From the documentation it looks that it is possible to have processes
exchanging messages between the PPC and the Pentium, using low level IPC
and Qnet support, with the proper endian conversions performed within
the communicating processes.

To start the IPC the client has to find the pid of the server so we
expected that the namespace of any system is always available on the
Qnet network, also in case of different endianism.

We noted that the PPC namespace is correctly working from a shell
activated on the serial line of that processor, but when we attempt to
perform ‘ls’ of the /net mount point of both processors (Intel and PPC)
we got the “Unsupported endian” message referring to the other peer.

Is there anybody that could clarify the operation and the restrictions
of Neutrino in such cases ?

Cross endian transmission of standard messages is not
yet supported at the resource manager layer. Your
reques of ls will result in an OPEN->STAT->CLOSE at
the very least so the resmgr framework will EENDIAN
that request. I don’t know if qnet will also block
the request, but I suspect not since it obviously
knows about the request.

Thomas

Thomas (toe-mah) Fletcher QNX Software Systems
thomasf@qnx.com Neutrino Development Group
(613)-591-0931 http://www.qnx.com/~thomasf

3

thomasf@qnx.com wrote:

Enrico Bendinelli <> enricob@prisma-eng.it> > wrote:
Dear sirs,

We worked on PPC BSP, we booted Neutrino on a card (Interphase 4532)
based on MPC 8260 processor (Power Quick II) and we adapted successfully
serial port and Ethernet networking. We used the latest version of RTP
available on the Web. We have connected via LAN the PPC card and the
host PC (Pentium III) that we are using as development platform.

From the documentation it looks that it is possible to have processes
exchanging messages between the PPC and the Pentium, using low level IPC
and Qnet support, with the proper endian conversions performed within
the communicating processes.

To start the IPC the client has to find the pid of the server so we
expected that the namespace of any system is always available on the
Qnet network, also in case of different endianism.

We noted that the PPC namespace is correctly working from a shell
activated on the serial line of that processor, but when we attempt to
perform ‘ls’ of the /net mount point of both processors (Intel and PPC)
we got the “Unsupported endian” message referring to the other peer.

Is there anybody that could clarify the operation and the restrictions
of Neutrino in such cases ?

Cross endian transmission of standard messages is not
yet supported at the resource manager layer. Your
reques of ls will result in an OPEN->STAT->CLOSE at
the very least so the resmgr framework will EENDIAN
that request. I don’t know if qnet will also block
the request, but I suspect not since it obviously
knows about the request.

This fact means that at the moment the only solution for doing IPC
between Pentium and PPC is rpc, is not it ?
When this restriction will be solved ?

Thomas

Thomas (toe-mah) Fletcher QNX Software Systems
thomasf@qnx.com > Neutrino Development Group
(613)-591-0931 > http://www.qnx.com/~thomasf

–

| Enrico Bendinelli | Prisma Engineering srl |
| enricob@prisma-eng.it | Via Petrocchi 4 20127 MILANO ITALY |
| http://www.prisma-eng.it | Tel. +39 02 26113507 Fax. 26113597 |

This mail was sent using 100% recycled electrons
4

Enrico Bendinelli <enricob@prisma-eng.it> wrote:

thomasf@qnx.com > wrote:

Enrico Bendinelli <> enricob@prisma-eng.it> > wrote:
Dear sirs,

We worked on PPC BSP, we booted Neutrino on a card (Interphase 4532)
based on MPC 8260 processor (Power Quick II) and we adapted successfully
serial port and Ethernet networking. We used the latest version of RTP
available on the Web. We have connected via LAN the PPC card and the
host PC (Pentium III) that we are using as development platform.

From the documentation it looks that it is possible to have processes
exchanging messages between the PPC and the Pentium, using low level IPC
and Qnet support, with the proper endian conversions performed within
the communicating processes.

To start the IPC the client has to find the pid of the server so we
expected that the namespace of any system is always available on the
Qnet network, also in case of different endianism.

We noted that the PPC namespace is correctly working from a shell
activated on the serial line of that processor, but when we attempt to
perform ‘ls’ of the /net mount point of both processors (Intel and PPC)
we got the “Unsupported endian” message referring to the other peer.

Is there anybody that could clarify the operation and the restrictions
of Neutrino in such cases ?

Cross endian transmission of standard messages is not
yet supported at the resource manager layer. Your
reques of ls will result in an OPEN->STAT->CLOSE at
the very least so the resmgr framework will EENDIAN
that request. I don’t know if qnet will also block
the request, but I suspect not since it obviously
knows about the request.


This fact means that at the moment the only solution for doing IPC
between Pentium and PPC is rpc, is not it ?

Well, sort of.

If the IPC is done by raw MsgSend/MsgReceive/MsgReply(),
you don’t use anything like resmgr, you don’t talk to any
exist system services, it will be ok.

Bacially, YOUR cross endian process could still MsgSend/
MsgRecieve/MsgReply to each other, provide your process
detect and correct the endian of the message.

When this restriction will be solved ?

Sorry, I don’t have timeframe about this one.

-xtang

5

Xiaodan Tang wrote:

Enrico Bendinelli <> enricob@prisma-eng.it> > wrote:

thomasf@qnx.com > wrote:

Enrico Bendinelli <> enricob@prisma-eng.it> > wrote:
Dear sirs,

We worked on PPC BSP, we booted Neutrino on a card (Interphase 4532)
based on MPC 8260 processor (Power Quick II) and we adapted successfully
serial port and Ethernet networking. We used the latest version of RTP
available on the Web. We have connected via LAN the PPC card and the
host PC (Pentium III) that we are using as development platform.

From the documentation it looks that it is possible to have processes
exchanging messages between the PPC and the Pentium, using low level IPC
and Qnet support, with the proper endian conversions performed within
the communicating processes.

To start the IPC the client has to find the pid of the server so we
expected that the namespace of any system is always available on the
Qnet network, also in case of different endianism.

We noted that the PPC namespace is correctly working from a shell
activated on the serial line of that processor, but when we attempt to
perform ‘ls’ of the /net mount point of both processors (Intel and PPC)
we got the “Unsupported endian” message referring to the other peer.

Is there anybody that could clarify the operation and the restrictions
of Neutrino in such cases ?

Cross endian transmission of standard messages is not
yet supported at the resource manager layer. Your
reques of ls will result in an OPEN->STAT->CLOSE at
the very least so the resmgr framework will EENDIAN
that request. I don’t know if qnet will also block
the request, but I suspect not since it obviously
knows about the request.


This fact means that at the moment the only solution for doing IPC
between Pentium and PPC is rpc, is not it ?

Well, sort of.

If the IPC is done by raw MsgSend/MsgReceive/MsgReply(),
you don’t use anything like resmgr, you don’t talk to any
exist system services, it will be ok.

Sorry Xtang, I think that a channel is needed even if we are using low
level IPC.

How can a process find the Pid of any process on the other Cpu if it
cannot use the namespace nor remote activation ?

Are you thinking to pass the Pid from the command line, after you have
issued pidin on both consoles ?

Bacially, YOUR cross endian process could still MsgSend/
MsgRecieve/MsgReply to each other, provide your process
detect and correct the endian of the message.

When this restriction will be solved ?

Sorry, I don’t have timeframe about this one.

-xtang

–

| Enrico Bendinelli | Prisma Engineering srl |
| enricob@prisma-eng.it | Via Petrocchi 4 20127 MILANO ITALY |
| http://www.prisma-eng.it | Tel. +39 02 26113507 Fax. 26113597 |

This mail was sent using 100% recycled electrons