How to boot with -ptcpip [was: netstat and route]

bridged with qdn.public.qnxrtp.os
Post Reply
Thomas Fletcher

Re: ln from pkg-fs file Re: graphics-ddk svga build

Post by Thomas Fletcher » Fri Dec 08, 2000 10:11 pm

Michael J. Ferrador <n2kra@orn.com> wrote:
When I first tried this, to save devg-svga.so (In case I built a better
one), I tried linking it to devg-svga.orig.so and got a not supported.

Is that the expected behavior from pkg-fs, or a bug?
Long story made short ... links don't work well on files with the
package filesystem. The behaviour is better in the next version which
should percolate out with the next patch.

Thomas

Thomas Fletcher

Re: pkg-fs - ln (link) Re: Pathname resolution... with a lit

Post by Thomas Fletcher » Mon Dec 11, 2000 3:02 pm

Michael J. Ferrador <n2kra@orn.com> wrote:
so pkg-fs overlays a storage (ovlfs term) filesystem?
http://home.att.net/~artnaseef/ovlfs/ovlfs.html - seems down
in the same directory needing a soft, not hard link?
That is partially correct. The package filesystem lets the
request "fall through" to the underlying filesystem which
will allow the link to be created. At the same time it marks
the file as being spilled so that it is no longer resolved by
the package filesystem.
Or implementing Plan 9 :-) http://plan9.bell-labs.com/plan9dist/
speaking of which, can you support multi-API's aka
Personalities (Mach), Subsystems (NT)
It is entirely possible that you would be able to provide
a "per-user" customizable filesystem space on the same
machine. It isn't at all as straighforward as it would
be compared to Plan9 who actually implemented seperate
namespaces right from the start for users. I think of
it more as the ability to filter what the users sees
from the filesytem.
I was wondering how you did that, what looked like
links /x86/lib/dll & /lib/dll with out a link count
This layer rides above the actual device based filesystem.
That is to say that you can use the package filesystem with
files living on any other filesystem (dos,cd,qnx4,ext2 etc)
living on any medium (devb,flash,nfs etc). That is why
in the /bin directory you see that there are files there
which actually originate "elsewhere" where "elsewhere" is
more than one place.

Thomas

Paul N. Leonard

Re: Documentaton on serial devctl (dcmd_chr.h)

Post by Paul N. Leonard » Thu Jan 18, 2001 1:34 am

I am just going through newsgroup postings and the QNX site trying to find information about how to enable a 485 port and am only finding comments
such as these. I expected to find another driver or an option to Dev.ser that allows for 485 operation. It is very hard to believe, and annoying, that
this capability isn't already available. Oh well.

Is the source to Dev.ser available? It would be a small matter to modify an existing working driver to include RS485 than to have to start from
scratch. Otherwise I guess we will have to do what many of you out there have already done, and write our own driver. I'd like to avoid it since we
really don't have the time. We assumed this capability was going to be in the QNX driver.

As far as turn around time, many UARTs do let you know when the last character clears the transmit buffer. I've seen hat on the older Zilog UARTs from
the 80's. I don't know enough about the 82C50 or 16C550 parts, but I suspect they also allow for that.

Any suggestions?

-Paul N. Leonard

David Hawley wrote:
One would think that with all the RS-485 communication stuff used in QNX's targeted applications, that there would be a good 485 driver one of these years.
On the other-hand, there are problems with many UART chips as far as handling the 485 turn-around goes. The big one is that the transmitt buffer empty interrupt happens when the buffer is ready to handle another character - but before the bits of the last transmitted character are shifted out. This is a problem for the driver writer. One can set up a timer to wake you up a bit later (this may be the problem you are seeing), or send an extra final character which will possibly be trashed when you turn the transmitter off. Another solution is to moniter transmitted data via the receiver and turn off the transmitter when the message has been locally received. A side beni is that you have some indication that no other traffic interferred with your message.

Some of the newer UARTS can be programmed to handle turn-around after the last transmit bit is sent making life much easier - these are the deep fifo parts 165[67]0? or something like that.

--
David L. Hawley D.L. Hawley and Associates

rectech

Re: Documentaton on serial devctl (dcmd_chr.h)

Post by rectech » Thu Jan 18, 2001 3:45 pm

I use Connect Tech Inc. adapters to handle my 485 interface. The cards work fine and the have QNX and Neutrino (QRTP) drivers that work well. Once I set the adapter up I forgot it was there...

I don't work for them either - I just like their products.

See:
Connect Tech Inc
42 Arrow Road
Guelph, Ontario
N1K 1S6
www.connecttech.com
sales@connecttech.com
1-800-426-8979


"Paul N. Leonard" wrote:
I am just going through newsgroup postings and the QNX site trying to find information about how to enable a 485 port and am only finding comments
such as these. I expected to find another driver or an option to Dev.ser that allows for 485 operation. It is very hard to believe, and annoying, that
this capability isn't already available. Oh well.

Is the source to Dev.ser available? It would be a small matter to modify an existing working driver to include RS485 than to have to start from
scratch. Otherwise I guess we will have to do what many of you out there have already done, and write our own driver. I'd like to avoid it since we
really don't have the time. We assumed this capability was going to be in the QNX driver.

As far as turn around time, many UARTs do let you know when the last character clears the transmit buffer. I've seen hat on the older Zilog UARTs from
the 80's. I don't know enough about the 82C50 or 16C550 parts, but I suspect they also allow for that.

Any suggestions?

-Paul N. Leonard

David Hawley wrote:
One would think that with all the RS-485 communication stuff used in QNX's targeted applications, that there would be a good 485 driver one of these years.
On the other-hand, there are problems with many UART chips as far as handling the 485 turn-around goes. The big one is that the transmitt buffer empty interrupt happens when the buffer is ready to handle another character - but before the bits of the last transmitted character are shifted out. This is a problem for the driver writer. One can set up a timer to wake you up a bit later (this may be the problem you are seeing), or send an extra final character which will possibly be trashed when you turn the transmitter off. Another solution is to moniter transmitted data via the receiver and turn off the transmitter when the message has been locally received. A side beni is that you have some indication that no other traffic interferred with your message.

Some of the newer UARTS can be programmed to handle turn-around after the last transmit bit is sent making life much easier - these are the deep fifo parts 165[67]0? or something like that.

--
David L. Hawley D.L. Hawley and Associates

rectech

Re: Documentaton on serial devctl (dcmd_chr.h)

Post by rectech » Thu Jan 18, 2001 7:15 pm

Do some searching of deja and the knowledge base. This has been discussed before and I think code was posted.

"Paul N. Leonard" wrote:
All our serial ports reside on the CPU board. Of the four ports, one can be used as RS485
with RTS controlling the Tx/Rx direction. I think I may have found the drivers on the QNX
web site, but I'm not sure they are the current ones. I'll probably modify them to include
an RS485 option. <sigh

Thanks for the input.

rectech wrote:

I use Connect Tech Inc. adapters to handle my 485 interface. The cards work fine and the have QNX and Neutrino (QRTP) drivers that work well. Once I set the adapter up I forgot it was there...

I don't work for them either - I just like their products.

See:
Connect Tech Inc
42 Arrow Road
Guelph, Ontario
N1K 1S6
www.connecttech.com
sales@connecttech.com
1-800-426-8979

Paul N. Leonard

Re: Documentaton on serial devctl (dcmd_chr.h)

Post by Paul N. Leonard » Thu Jan 18, 2001 7:48 pm

All our serial ports reside on the CPU board. Of the four ports, one can be used as RS485
with RTS controlling the Tx/Rx direction. I think I may have found the drivers on the QNX
web site, but I'm not sure they are the current ones. I'll probably modify them to include
an RS485 option. <sigh>

Thanks for the input.

rectech wrote:
I use Connect Tech Inc. adapters to handle my 485 interface. The cards work fine and the have QNX and Neutrino (QRTP) drivers that work well. Once I set the adapter up I forgot it was there...

I don't work for them either - I just like their products.

See:
Connect Tech Inc
42 Arrow Road
Guelph, Ontario
N1K 1S6
www.connecttech.com
sales@connecttech.com
1-800-426-8979

Michael J. Ferrador

Re: Patch A Improves, BUT... init files

Post by Michael J. Ferrador » Tue Jan 30, 2001 8:45 pm

----- Original Message -----
From: <keith@qnx.com> in message news:94pk8n$6k7$1@nntp.qnx.com...
Newsgroups: qdn.public.qnxrtp.os
Subject: Re: Patch Improves, BUT... mostly net
Just for reference...

We don't actually recommend editing the system initialization files
directly. When you do an update they won't be updated since they're
spilled.
OK, I Cut and Pasted the all the commented stuff
from /etc/rc.d/rc.sysinit
to /etc/rc.d/rc.local
...example...

BTW, we didn't start inetd automatically since it tends to be a security
hole. That code in the /etc/rc.d/rc.sysinit was never actually meant to
and uncommented the stuff I wanted, even if it was not meant to be used
in /etc/rc.d/rc.sysint, if you copy / run it elsewhere, it would be nice to
have correct code that is capable of running. Not everyone who needs it,
is going to know enough shell to find the error.
be used . . .

Michael J. Ferrador <n2kra@orn.com> wrote:
uhhh... DUH!

why was there negation (!) in the test -d ???

should be:
if test -d /dev/socket

Now it works... Patch B material

Michael J. Ferrador <n2kra@orn.com> wrote in message
news:94kq89$im0$1@inn.qnx.com...

...
I still need to start inetd manually, despite...

# Start some daemons...
if test ! -d /dev/socket; then
echo "Starting inetd"
inetd

# echo "Starting pdebug at port 8000"
# pdebug 8000 &
fi

Michael J. Ferrador

Re: Patch A Improves, BUT... PPP+Qnet

Post by Michael J. Ferrador » Tue Jan 30, 2001 9:04 pm

since adding -pqnet in /etc/system/enum/include/net fails

I mount -T io-net npm-qnet.so in /etc/rc.d/rc.local


BUT when I connect with ppp, io-net dies (leaves a core)

maybe it doesn't like going from no default gateway, to my ISP's
My ethernet card uses the el900 driver


may be a mute point since my other machines
are non-PCI 486's and a SparcStation 2
although I'm going to set one of them up as a NAT/proxy/firewall

does anyone have good shell level examples of the
usefullness of Qnet?

Do you need it to run one machine as: a photon font server, voyager server,
remote ph

Michael J. Ferrador

Diff swapfile w/o editing init files Re: Patch A Improves, B

Post by Michael J. Ferrador » Sun Mar 11, 2001 5:03 pm

After booting w/o swap, or edit /etc/rc.d/rc.sysinit to a different swap
file
(linux swap /dev/hd[1-4]t130) and deleting /.swapfile

I made a symbolic link
ln -s /dev/hd1t130 /.swapfile

then recovered
pkgctl -r /etc/rc.d/rc.sysinit

Michael J. Ferrador <n2kra@orn.com> wrote in message
news:9578o3$321$1@inn.qnx.com...
----- Original Message -----
From: <keith@qnx.com> in message news:94pk8n$6k7$1@nntp.qnx.com...
Newsgroups: qdn.public.qnxrtp.os
Subject: Re: Patch Improves, BUT... mostly net

Just for reference...

We don't actually recommend editing the system initialization files
directly. When you do an update they won't be updated since they're
spilled.

OK, I Cut and Pasted the all the commented stuff
from /etc/rc.d/rc.sysinit
to /etc/rc.d/rc.local

Wayne Fisher

Re: Maximum addressing range: PCI

Post by Wayne Fisher » Mon Apr 16, 2001 3:21 pm

It doesn't look like this made it out last time... Here it is again.

Wayne

"Wayne Fisher" <wayne.fisher@focusautomation.com> wrote in message news:...
Hi,

We're in the design stages for some custom image processing boards and our
hardware guys asked me what was the maximum amount of memory-mapped I/O
that
they can configure the boards with and still be usable with Neutrino/RTP.
I
didn't know and didn't see anything in the docs or knowledge base on this.

For our system, we expect to have 4 to 8 similar PCI devices per single
board computer (PowerPC based). Each device has some large memories on
board
for which it would be convenient if it could be mapped directly into a
process's address space.

What is the maximum amount of memory-mapped I/O that Neutrino can handle?
Can we use a gigabyte or more, several hundred megabytes, or what? Any
limits on a per-device basis?

Thanks for any info or pointers to docs on this that you can provide.

Wayne Fisher
Team Leader/Architect - Core Software
Focus Automation Systems Inc.

Rennie Allen

Maximum addressing range: PCI

Post by Rennie Allen » Mon Apr 16, 2001 7:08 pm

Non-authoritative answer:

I would think that a 1GB per card would be OK in theory, I might get
concerned around 2GB (don't know why exactly :-). Remember that each
process get's it's own 4GB address space currently (at least on x86) so
the total memory mapped by your processes (including stack, heap, shared
memory, and the memory mapped board) definately *can not* exceed 4GB.
This is an interesting question, I hope someone from QSSL answers in a
more authoritative fashion. In theory you should be able to map (4GB -
memory used by process) but there may be some implementation
thingamajigs that prevent this.

-----Original Message-----
From: Wayne Fisher [mailto:wayne.fisher@focusautomation.com]
Posted At: Monday, April 16, 2001 8:21 AM
Posted To: os
Conversation: Maximum addressing range: PCI
Subject: Re: Maximum addressing range: PCI


It doesn't look like this made it out last time... Here it is again.

Wayne

"Wayne Fisher" <wayne.fisher@focusautomation.com> wrote in message
news:...
Hi,

We're in the design stages for some custom image processing boards and
our
hardware guys asked me what was the maximum amount of memory-mapped
I/O
that
they can configure the boards with and still be usable with
Neutrino/RTP.
I
didn't know and didn't see anything in the docs or knowledge base on
this.

For our system, we expect to have 4 to 8 similar PCI devices per
single
board computer (PowerPC based). Each device has some large memories on
board
for which it would be convenient if it could be mapped directly into a
process's address space.

What is the maximum amount of memory-mapped I/O that Neutrino can
handle?
Can we use a gigabyte or more, several hundred megabytes, or what? Any
limits on a per-device basis?

Thanks for any info or pointers to docs on this that you can provide.

Wayne Fisher
Team Leader/Architect - Core Software
Focus Automation Systems Inc.

Mario Charest

Re: Maximum addressing range: PCI

Post by Mario Charest » Tue Apr 17, 2001 12:18 am

"Rennie Allen" <RAllen@csical.com> wrote in message
news:D4907B331846D31198090050046F80C903D2C2@exchangecal.hq.csical.com...
Non-authoritative answer:

I would think that a 1GB per card would be OK in theory, I might get
concerned around 2GB (don't know why exactly :-). Remember that each
process get's it's own 4GB address space currently (at least on x86) so
the total memory mapped by your processes (including stack, heap, shared
memory, and the memory mapped board) definately *can not* exceed 4GB.
This is an interesting question, I hope someone from QSSL answers in a
more authoritative fashion. In theory you should be able to map (4GB -
memory used by process) but there may be some implementation
thingamajigs that prevent this.
I think NTO is limited to 4GB of virtual memory.
-----Original Message-----
From: Wayne Fisher [mailto:wayne.fisher@focusautomation.com]
Posted At: Monday, April 16, 2001 8:21 AM
Posted To: os
Conversation: Maximum addressing range: PCI
Subject: Re: Maximum addressing range: PCI


It doesn't look like this made it out last time... Here it is again.

Wayne

"Wayne Fisher" <wayne.fisher@focusautomation.com> wrote in message
news:...
Hi,

We're in the design stages for some custom image processing boards and
our
hardware guys asked me what was the maximum amount of memory-mapped
I/O
that
they can configure the boards with and still be usable with
Neutrino/RTP.
I
didn't know and didn't see anything in the docs or knowledge base on
this.

For our system, we expect to have 4 to 8 similar PCI devices per
single
board computer (PowerPC based). Each device has some large memories on
board
for which it would be convenient if it could be mapped directly into a
process's address space.

What is the maximum amount of memory-mapped I/O that Neutrino can
handle?
Can we use a gigabyte or more, several hundred megabytes, or what? Any
limits on a per-device basis?

Thanks for any info or pointers to docs on this that you can provide.

Wayne Fisher
Team Leader/Architect - Core Software
Focus Automation Systems Inc.



Igor Kovalenko

Re: Maximum addressing range: PCI

Post by Igor Kovalenko » Tue Apr 17, 2001 2:40 am

"Mario Charest" <mcharest@deletezinformatic.com> wrote in message
news:9bg27d$dn1$1@inn.qnx.com...
"Rennie Allen" <RAllen@csical.com> wrote in message
news:D4907B331846D31198090050046F80C903D2C2@exchangecal.hq.csical.com...

Non-authoritative answer:

I would think that a 1GB per card would be OK in theory, I might get
concerned around 2GB (don't know why exactly :-). Remember that each
process get's it's own 4GB address space currently (at least on x86) so
the total memory mapped by your processes (including stack, heap, shared
memory, and the memory mapped board) definately *can not* exceed 4GB.
This is an interesting question, I hope someone from QSSL answers in a
more authoritative fashion. In theory you should be able to map (4GB -
memory used by process) but there may be some implementation
thingamajigs that prevent this.


I think NTO is limited to 4GB of virtual memory.
I suspect that mapping more than 3.5Gb might be problematic due to
'thingamajigs'.
There might be architecture-specific pacularities as well.

- igor

Steve Munnings, Corman Te

Re: Maximum addressing range: PCI

Post by Steve Munnings, Corman Te » Tue Apr 17, 2001 2:02 pm

Hi Wayne,

This is also a non-authoritative non-QSSL answer.

Since PCI cards are mapped into REAL memory before being re-mapped into
virtual memory, and the address bus is 32 bits wide...
I think that all of the limitations under QNX6 are hardware limitations.
i.e. If running on an x86 machine with 32-bit PCI (as far as I know, the
only type supported by QNX6 at the moment)
1. Max of 4gb of REAL address space
2. With all PCI cards installed, they must allow for all other real memory
ranges required by other memory/peripherals
Other than that, the only limits should be the ones imposed by physical
restraints and the PCI standards

I too, am waiting for the official QSSL response, however!


Wayne Fisher <wayne.fisher@focusautomation.com> wrote in message
news:9bf2iv$okp$1@inn.qnx.com...
It doesn't look like this made it out last time... Here it is again.

Wayne

"Wayne Fisher" <wayne.fisher@focusautomation.com> wrote in message
news:...
Hi,

We're in the design stages for some custom image processing boards and
our
hardware guys asked me what was the maximum amount of memory-mapped I/O
that
they can configure the boards with and still be usable with
Neutrino/RTP.
I
didn't know and didn't see anything in the docs or knowledge base on
this.

For our system, we expect to have 4 to 8 similar PCI devices per single
board computer (PowerPC based). Each device has some large memories on
board
for which it would be convenient if it could be mapped directly into a
process's address space.

What is the maximum amount of memory-mapped I/O that Neutrino can
handle?
Can we use a gigabyte or more, several hundred megabytes, or what? Any
limits on a per-device basis?

Thanks for any info or pointers to docs on this that you can provide.

Wayne Fisher
Team Leader/Architect - Core Software
Focus Automation Systems Inc.



Wayne Fisher

Re: Maximum addressing range: PCI

Post by Wayne Fisher » Tue Apr 17, 2001 8:43 pm

If we assume that QNX6 uses 32bits for all of its addressing then the PCI
addressing range will be limited to something smaller than the max. of 4GB.
Gotta leave room for main memory, etc.

But, if QNX6 uses 64bits behind the MMU than it's theoretically possible
that a full 32 bits of addressing could be allocated to PCI devices
(assuming, of course, that the CPU itself can address more than 4GB).
However, with processes limitted to 4GB of address, no one process could
address all 32bits worth of the PCI bus.

I expect that the answer may also be different depending on the CPU
selected. I'm interested in the x86 and PowerPC architectures.

QSSL, can we get an authoritative answer?

Wayne


"Steve Munnings, Corman Technologies" <steve@cormantech.com> wrote in
message news:9bhicl$bc0$1@inn.qnx.com...
Hi Wayne,

This is also a non-authoritative non-QSSL answer.

Since PCI cards are mapped into REAL memory before being re-mapped into
virtual memory, and the address bus is 32 bits wide...
I think that all of the limitations under QNX6 are hardware limitations.
i.e. If running on an x86 machine with 32-bit PCI (as far as I know, the
only type supported by QNX6 at the moment)
1. Max of 4gb of REAL address space
2. With all PCI cards installed, they must allow for all other real memory
ranges required by other memory/peripherals
Other than that, the only limits should be the ones imposed by physical
restraints and the PCI standards

I too, am waiting for the official QSSL response, however!
--
Wayne Fisher
Team Leader/Architect - Core Software
Focus Automation Systems Inc.

Post Reply

Return to “qdn.public.qnxrtp.os”