The bigger issue in all of this is NOT the PCI server itself, but
the presence or absence of a physical PCI BIOS in the box.
Under QNX4, none of the device drivers were written to use
a PCI server, they just basically looked for the devices at a
set of hard coded physical addresses that were initialized to
those locations prior to the start of the QNX kernel (by the
BIOS or a hard coded startup routine). This also meant that
multiple device drivers could attempt to beat on a single
device simultaneously and cause all sorts of problems.
However, it was generally speaking, easier to live with in
a “hard wired” embedded environment where you knew
exactly what was running, what hardware was present, and
never allowed any “user” apps to run. In essence, the
environment that, historically, QNX has primarily been used
for.
Under QNX6, as more emphasis has been placed on being
a true “plug & play” environment and a development
“platform”, everything has migrated to the new PCI
server style of management. Which, quite frankly, is
much nicer and much safer. However, as a result, all the
new RTP device drivers now require the PCI server to be
running before they can work. This is where a MAJOR
problem arises:
A sizeable percentage of embedded PC’s do not incorporate
a real BIOS of any kind (including a PCI BIOS) – which
means that the PCI server will not start, which in turn means
the drivers won’t run, which means you can’t use RTP.
This is a BIG problem for embedded boxes, as many
specifically do not want or need a full BIOS implementation
for any number of reasons – i.e. cost (licensing) and the
fact that no user configurability can be allowed.
For other platforms, RTP already has PCI servers that
directly access the PCI hardware without need of a PCI
BIOS in the system (e.g. pci-raven). The same is needed
for x86 based embedded platforms. In essence, what is
needed is basically a “pci-x86_direct”. Unfortunately,
this could easily evolve into “pci-geode”, “pci-intel”,
“pci-via”, “pci-ali”, etc. due to differences in system
chipsets (although I personally feel a single driver could
be written without too much effort – the PCI spec is
pretty well standardized at this point).
The full “RTP” suite may be intended as a desktop
development system, which one can reasonably
assume will include a true BIOS in the system.
However, the target embedded platforms that RTP is
being used to develop for – i.e. what will actually be
sold and QNX will be getting paid licensing
fees for – will NOT include a BIOS as often as not.
If QNX6 can’t run on a true embedded platform,
this is really going to be cutting straight into the
“bread & butter” of their target market – i.e. this
one problem is big enough to totally eliminate QNX6
from consideration for a lot of embedded projects
(many of which were QNX4 based and would have
been logical candidates for upgrading otherwise).
Personally, I feel this is a pretty serious issue.
(as, apparently from his comments, so does Igor)
Michael D. Burkey
