I have a memory mapped CAN card (RTD ECAN527D) that I occasionally make
use of in my system.
Is it possible to tell QNX to reserve a region of memory (say D8000 to
D81FF) so no other apps in the system can make use of this region? I’ve
tried writing a program to open Physical memory and lock the region I’m
interested in with no luck. Any suggestions?
Thanks,
Brian
The memory space between ~A000: and FFFF is not use the operating system.
The is usually no physical memory there, it’s reserved for expension card.
What makes you beleive QNX uses that space?
“Brian G. Fleury” <bgf104@psu.edu> wrote in message
news:3A9CF5FA.7D551392@psu.edu…
I have a memory mapped CAN card (RTD ECAN527D) that I occasionally make
use of in my system.
Is it possible to tell QNX to reserve a region of memory (say D8000 to
D81FF) so no other apps in the system can make use of this region? I’ve
tried writing a program to open Physical memory and lock the region I’m
interested in with no luck. Any suggestions?Thanks,
Brian
“Mario Charest” <mcharest@void_zinformatic.com> wrote in message
news:97itms$ld9$1@nntp.qnx.com…
The memory space between ~A000: and FFFF is not use the operating system.
The is usually no physical memory there, it’s reserved for expension card.What makes you beleive QNX uses that space?
“Brian G. Fleury” <> bgf104@psu.edu> > wrote in message
news:> 3A9CF5FA.7D551392@psu.edu> …
I have a memory mapped CAN card (RTD ECAN527D) that I occasionally make
use of in my system.
Is it possible to tell QNX to reserve a region of memory (say D8000 to
D81FF) so no other apps in the system can make use of this region? I’ve
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
i think brian means locking hardware resources on os level by some
application
in order to be sure no one else for example some third party driver access
them
at the same time and interference with his own completly breaking the
picture.
that’s related not only to allocating physical memory regions but also i/o
ports,
shared irqs and so on.
tried writing a program to open Physical memory and lock the region I’m
interested in with no luck. Any suggestions?
afaik the answer is not. you cannot safety lock memory course qnx allows
tasks to map physical memory without usage control and anyway allows to
access GDT dirrectly. same related to IDT, io ports and so on.
and in general it dosn’t use many of benefits of ia32 protected mode
architecture.
there’s good side: you can easy access any needed hardware with minimal
overheads.
there’s bad side: luck of control of usage sytem resources.
// wbr
Thanks,
Brian
\
Ian Zagorskih
Novosoft CyBearNet Department
Custom software development and web design since 1992
E-mail: ianzag@novosoft.ru
Phone: +7 (3832) 39-72-60, 39-72-61
Fax: +7 (3832) 39-63-58
For more visit www.novosoft-us.com
afaik the answer is not. you cannot safety lock memory course qnx
allows
tasks to map physical memory without usage control and anyway allows to
access GDT dirrectly. same related to IDT, io ports and so on.
This is nonsense of course. Anyone who has done any driver
development whatsoever on QNX has found out pretty quickly
(either by reading the docs or having their program
terminate), that a program cannot access privity 1 level
features unless it has explicitly had a flag set in the
executable header. Further, you cannot execute a program
with the above mentioned privity flag set, unless you have
root priviledge (i.e. one must be a super user, and have an
appropriately linked executable in order to perform operations
on io ports for instance).
Rennie
I run into the following behavior:
with the CAN card in the system but no driver loaded for it (a PC104 stack
with a CPU card, VGA card and CAN card) I cannot ftp large files (say over
100K bytes), but small files ftp fine. If I were to remove the CAN card ftp
of any size file works fine. The network card is an Ethernet 2000 variant,
and is using I/O port 320 and a different interrupt from the CAN card so there
should be no conflicts there…
Mario Charest wrote:
The memory space between ~A000: and FFFF is not use the operating system.
The is usually no physical memory there, it’s reserved for expension card.What makes you beleive QNX uses that space?
“Brian G. Fleury” <> bgf104@psu.edu> > wrote in message
news:> 3A9CF5FA.7D551392@psu.edu> …
I have a memory mapped CAN card (RTD ECAN527D) that I occasionally make
use of in my system.
Is it possible to tell QNX to reserve a region of memory (say D8000 to
D81FF) so no other apps in the system can make use of this region? I’ve
tried writing a program to open Physical memory and lock the region I’m
interested in with no luck. Any suggestions?Thanks,
Brian
The test code I wrote was linked with the -T1 switch to set the appropriate
privity level and I did run it as root… Ian phrased my question better
than I did (thanks 
I haven’t found a way to get exlusive access to a
region of memory under QNX - do you have any specific suggestions?
Thanks,
Brian
Rennie Allen wrote:
afaik the answer is not. you cannot safety lock memory course qnx
allows
tasks to map physical memory without usage control and anyway allows to
access GDT dirrectly. same related to IDT, io ports and so on.This is nonsense of course. Anyone who has done any driver
development whatsoever on QNX has found out pretty quickly
(either by reading the docs or having their program
terminate), that a program cannot access privity 1 level
features unless it has explicitly had a flag set in the
executable header. Further, you cannot execute a program
with the above mentioned privity flag set, unless you have
root priviledge (i.e. one must be a super user, and have an
appropriately linked executable in order to perform operations
on io ports for instance).Rennie
“Brian G. Fleury” <bgf104@psu.edu> wrote in message
news:3A9D3EB7.8C7A200B@psu.edu…
The test code I wrote was linked with the -T1 switch to set the
appropriate
privity level and I did run it as root… Ian phrased my question better
than I did (thanks >
region of memory under QNX -
You cannot do this when program is linked with -T1.
do you have any specific suggestions?
Well the question again is why would you need to do that.
I can understand it can be usefull to detect if drivers are
trying to access same resources (IRQ, IOPORT, MEMORY)
in case of a user error. But that would not solve hardware conflict
Thanks,
Brian
Rennie Allen wrote:afaik the answer is not. you cannot safety lock memory course qnx
allows
tasks to map physical memory without usage control and anyway allows to
access GDT dirrectly. same related to IDT, io ports and so on.This is nonsense of course. Anyone who has done any driver
development whatsoever on QNX has found out pretty quickly
(either by reading the docs or having their program
terminate), that a program cannot access privity 1 level
features unless it has explicitly had a flag set in the
executable header. Further, you cannot execute a program
with the above mentioned privity flag set, unless you have
root priviledge (i.e. one must be a super user, and have an
appropriately linked executable in order to perform operations
on io ports for instance).Rennie
“Brian G. Fleury” <bgf104@psu.edu> wrote in message
news:3A9D3D79.B7231851@psu.edu…
I run into the following behavior:
with the CAN card in the system but no driver loaded for it (a PC104 stack
with a CPU card, VGA card and CAN card) I cannot ftp large files (say over
100K bytes), but small files ftp fine. If I were to remove the CAN card
ftp
of any size file works fine. The network card is an Ethernet 2000
variant,
and is using I/O port 320 and a different interrupt from the CAN card so
there
should be no conflicts there…
What if you don’t start the driver for the CAN card? If the driver
isn’t started and you still have problem, there is a hardware conflict
and there is nothing the OS can do about that.
The CAN card could be broken or the PC/104 ISA bus is out of spec
in your perticular setup. Try putting a terminaison on the BUS
Mario Charest wrote:
The memory space between ~A000: and FFFF is not use the operating
system.
The is usually no physical memory there, it’s reserved for expension
card.What makes you beleive QNX uses that space?
“Brian G. Fleury” <> bgf104@psu.edu> > wrote in message
news:> 3A9CF5FA.7D551392@psu.edu> …
I have a memory mapped CAN card (RTD ECAN527D) that I occasionally
make
use of in my system.
Is it possible to tell QNX to reserve a region of memory (say D8000 to
D81FF) so no other apps in the system can make use of this region?
I’ve
tried writing a program to open Physical memory and lock the region
I’m
interested in with no luck. Any suggestions?Thanks,
Brian
“Rennie Allen” <RAllen@csical.com> wrote in message
news:D4907B331846D31198090050046F80C902CA1F@exchangecal.hq.csical.com…
afaik the answer is not. you cannot safety lock memory course qnx
allows
tasks to map physical memory without usage control and anyway allows to
access GDT dirrectly. same related to IDT, io ports and so on.This is nonsense of course. Anyone who has done any driver
development whatsoever on QNX has found out pretty quickly
(either by reading the docs or having their program
terminate), that a program cannot access privity 1 level
features unless it has explicitly had a flag set in the
executable header. Further, you cannot execute a program
with the above mentioned privity flag set, unless you have
root priviledge (i.e. one must be a super user, and have an
appropriately linked executable in order to perform operations
on io ports for instance).
thank you, rennie, this is really new and important information for me 
and so, now we must to get working all this stuff together proper
way without any conflicts. again ideal case.
there’s a lot enough chances that some hardware/drivers use the
same io ports or mapped memory or interrupt requests or dma
channels or smth else [did i forget smth ?].
my a little but hard practice shows me that sometimes such
configuration process more looks like a shaman dance with
tambourine rather then a banal situation.
“how can you give the guarantee that written by you driver will
work in any situation as far as if serviced hardware is propertly
installed and configured ?”
note, that in real life your application can easily interfere with some
another without any notifications from os side or whatever else
about the conflicts in resources usage. even assuming that it is
written absolutelly correctly and has no one bug, you cannot be
sure for 100% that everything is going right way just due to the
luck of controlling information. for example from os side.
remember that we all together are building more reliable world (c)…
and imho too much of freedom for the builders and especially
luck of control from the residents of this world can cause
a lot of troubles.
// wbr
Rennie
Ian Zagorskih
Novosoft CyBearNet Department
Custom software development and web design since 1992
E-mail: ianzag@novosoft.ru
Phone: +7 (3832) 39-72-60, 39-72-61
Fax: +7 (3832) 39-63-58
For more visit www.novosoft-us.com
Ian M. Zagorskih <ianzag@novosoft.ru> wrote:
thank you, rennie, this is really new and important information for me >
- but actually i meant smth absolutely another. let assume for simplisity
that we have all needed priviledges, correctly linked executables and
so on. ideal case. and we have also some set of drivers that need to
access some installed hardware. note that all this drivers were done
by some different third party companies and anyway we have no
access to the source code and sometimes it’s even difficult to access
the authors to get some consiltations a’la “how damn it works ?!”.and so, now we must to get working all this stuff together proper
way without any conflicts. again ideal case.there’s a lot enough chances that some hardware/drivers use the
same io ports or mapped memory or interrupt requests or dma
channels or smth else [did i forget smth ?].
The problem, here, is that if the hardware uses conflicting
ioports, irqs, or memory address ranges then it doesn’t matter
whether or not the OS only allocates the “logical use” of that
resource to any one driver – the hardware configuration is
already broken and the OS can’t fix it. (Well, in the PCI
situation, it might be able to. QNX4 doesn’t do plug&play,
so the PCI-BIOS has to resolve these conflicts. And if you
are using ISA cards, these can’t generally be dynamically
reconfigured by the OS.)
So, you have to resolve hardware conflicts at the hardware
level – if using ISA cards, jumper them properly. If using
a mixture of ISA & PCI cards, you must properly inform your
PCI bios of the resources (irqs, memory ranges, io ports)
that you have assigned to ISA cards so that the PCI BIOS
doesn’t assign them to PCI cards. From the software point
of view, PCI irqs can actually be shared between more than
one driver and more than one io card – though the drivers
do have to be coded intelligently.
In none of these cases, though, would the OS “reserving” a
certain irq/io port/memory range help to resolve the fact
that two pieces of HARDWARE have been configured with
conflicting resources.
If you are working in a non-BIOS PCI configuration model,
then it does make some sense – but QNX4 does not have
code or servers that would help with this, you would have
to write the PCI configuration & allocation code yourself.
(And resolve conflicts, etc.) (QNX Neutrino does have such
code and servers for at least some PCI configurations. And,
those servers allow you to register for and reserve resources
for your card/driver.)
- how do you see the reasonable realization of one of mentioned
above drivers having no underlaying os support ? when inside your
programm as far as it was started with root priveledges you can
do actually anything ? and more that, quite often you still have
to do this “anything” accidentally named by some one “tips & tricks”.
when all controlling functions on your [driver author] actions is
your personal deal ? when you can input/output data from/in any
port regardless to if it’s actually used by another application,
read/write data to/from any physical memory region and so on ?
the primary question is:
Again – applications don’t own io ports – hardware does. If
you write to the io-port belonging to some other piece of hardware,
then your driver is broken.
“how can you give the guarantee that written by you driver will
work in any situation as far as if serviced hardware is propertly
installed and configured ?”
If the hardware is properly installed & configured, then there will
be no conflicts in hardware between the resources needed by one card
and by another. In this case, your (properly coded) driver will never
want to write to a resource (memory/io port) that is owned by another
driver/program. (Well, unless you are trying to have two drivers
handle the same piece of hardware. Doesn’t sound like a healthy
configuration to me.)
note, that in real life your application can easily interfere with some
another without any notifications from os side or whatever else
about the conflicts in resources usage.
If there is a conflict in resource usage, it MUST be resolved at the
hardware level. If the hardware doesn’t conflict, the drivers won’t.
even assuming that it is
written absolutelly correctly and has no one bug, you cannot be
sure for 100% that everything is going right way just due to the
luck of controlling information. for example from os side.
The “controlling information” must be from the hardware configuration
side.
QNX Training Services
dagibbs@qnx.com
“Rennie Allen” <RAllen@csical.com> wrote in message
news:D4907B331846D31198090050046F80C902CA1F@exchangecal.hq.csical.com…
This is nonsense of course. Anyone who has done any driver
development whatsoever on QNX has found out pretty quickly
(either by reading the docs or having their program
terminate), that a program cannot access privity 1 level
features unless it has explicitly had a flag set in the
executable header. Further, you cannot execute a program
with the above mentioned privity flag set, unless you have
root priviledge (i.e. one must be a super user, and have an
appropriately linked executable in order to perform operations
on io ports for instance).
thank you, rennie, this is really new and important information for me
- but actually i meant smth absolutely another. let assume for
simplisity
that we have all needed priviledges, correctly linked executables and
so on. ideal case. and we have also some set of drivers that need to
access some installed hardware. note that all this drivers were done
by some different third party companies and anyway we have no
access to the source code and sometimes it’s even difficult to access
the authors to get some consiltations a’la “how damn it works ?!”.
What I was responding to was your assertion, that QNX doesn’t use the
protection features available on the ia86 processor. It does. You
are now talking about a resource database; in this respect you are
correct in that QNX4 does not have a resource database. QNX6 does
though.
- how do you see the reasonable realization of one of mentioned
above drivers having no underlaying os support ? when inside your
programm as far as it was started with root priveledges you can
do actually anything ? and more that, quite often you still have
If you give root priviledge to a user, your saying that they are
responsible, and knowledgable, and you trust them with the system.
to do this “anything” accidentally named by some one “tips & tricks”.
when all controlling functions on your [driver author] actions is
your personal deal ? when you can input/output data from/in any
port regardless to if it’s actually used by another application,
read/write data to/from any physical memory region and so on ?
the primary question is:
And how would you propose that access control to say a particular
I/O address be enforced on ia86 architecture ? Remember QNX is a
RTOS. Even if you have a resource database (like QNX6 does), it is
only advisory, not mandatory. It is a simple matter to ignore what
the resource database tells you and hit some “reserved” hw anyway.
note, that in real life your application can easily interfere with
some
another without any notifications from os side or whatever else
about the conflicts in resources usage. even assuming that it is
This is why resource databases are a good idea, however, you originally
suggested that QNX doesn’t make use of the hardware supported protection
features. It does. A resource database does not enforce correct
resource utilization, it only enables it. This is perfectly sufficient
IMO.
remember that we all together are building more reliable world (c)…
and imho too much of freedom for the builders and especially
luck of control from the residents of this world can cause
a lot of troubles.
I remain unconcerned about renegade driver developers (those that choose
to ignore the advisory locks of the resource database). As for
virus/worm/trojan developers, they would need to get their virus root
access on your system before it can run with privity, if they get root
there are probably many (far worse) things they might choose to do
before
conflicting with your hardware
Rennie