IRQ assignments on x86

I’m starting a new thread on this because I have learned a lot more about
it and have a different question to pose to the RTP implementers. For background,
please see the recent thread “Setting IRQ’s and ACPI”.

The summary of the problem is that it is getting more and more difficult to assign IRQ’s in the BIOS
setup screens. Big vendors (Dell, HP, IBM, Gateway) no longer have the PCI IRQ
assignment setup screen in most of their latest machines. Even the boxed Intel motherboards
allow one to only specify a slot’s IRQ, but not reserve it from being shared with other devices
(that are not hardwire shared). The solution, as Igor Kovalenko
suggests in the above mentioned thread, is for RTP to provide a mechanism to assign IRQ’s itself.
I have done much searching on the web, as well as discussed the issue with an engineer at Phoenix,
and can find no alternative.

For my own long-term planning here in the non-embedded realtime world,
I’d like to know if QNX has looked into this issue and
agrees that this is the solution and it is needed. If so, is it on a roadmap to be added at
some point in the future?

Thanks,

Art Hays
National Institutes of Health
avhays@nih.gov

Art Hays wrote:

I’m starting a new thread on this because I have learned a lot more about
it and have a different question to pose to the RTP implementers. For background,
please see the recent thread “Setting IRQ’s and ACPI”.

The summary of the problem is that it is getting more and more difficult to assign IRQ’s in the BIOS
setup screens. Big vendors (Dell, HP, IBM, Gateway) no longer have the PCI IRQ
assignment setup screen in most of their latest machines. Even the boxed Intel motherboards
allow one to only specify a slot’s IRQ, but not reserve it from being shared with other devices
(that are not hardwire shared). The solution, as Igor Kovalenko
suggests in the above mentioned thread, is for RTP to provide a mechanism to assign IRQ’s itself.
I have done much searching on the web, as well as discussed the issue with an engineer at Phoenix,
and can find no alternative.

For my own long-term planning here in the non-embedded realtime world,
I’d like to know if QNX has looked into this issue and
agrees that this is the solution and it is needed. If so, is it on a roadmap to be added at
some point in the future?

We have a rather low tech, but effective solution to the problem. We purchase
revision controlled motherboards from a company called Itox.

We have been extremely happy with them. When they change anything on the mobo
they send us an email to notify us, and give us extensive technical details of
the change.

Of course, this means your not getting the latest and greatest, but it is
stable, reliable, and well documented.

Rennie

“Art Hays” <avhays@nih.gov> wrote in message
news:bb5rb3$euo$1@inn.qnx.com

I’m starting a new thread on this because I have learned a lot more about
it and have a different question to pose to the RTP implementers. For
background,
please see the recent thread “Setting IRQ’s and ACPI”.

The summary of the problem is that it is getting more and more difficult
to assign IRQ’s in the BIOS
setup screens. Big vendors (Dell, HP, IBM, Gateway) no longer have the
PCI IRQ
assignment setup screen in most of their latest machines. Even the boxed
Intel motherboards
allow one to only specify a slot’s IRQ, but not reserve it from being
shared with other devices
(that are not hardwire shared). The solution, as Igor Kovalenko
suggests in the above mentioned thread, is for RTP to provide a mechanism
to assign IRQ’s itself.
I have done much searching on the web, as well as discussed the issue with
an engineer at Phoenix,
and can find no alternative.

Microsoft is steering the industry toward dropping the BIOS at some point
altogether, at least in its current form. The the ACPI is one driving
factor. It supercedes Plug-n-Play, APM and even MPS specs. The motive is
that since an OS that cares about power management needs to be able to
handle resource management that BIOS does, it might as well do it instead of
the BIOS and do better at that. The BIOS of course still boots the OS, but
here the EFI (Extensible Firmware Interface) comes into the play as another
driving factor. The eventual goal is to provide enough generic functionality
at the firmware level that a computer would be able to do some ‘basic’
operations (such as check email and blink LED to show that you have some)
before the OS even boots. Which of course answers the question how to boot
an OS. Some hardware manufacturers already have some kind of EFI support in
place.

The BIOS then will be reduced to a collection of ACPI tables that
motherboard manufacturer compiles and flashes so that an OS can access them
to obtain basic hardware information.

There’s one little trouble though. The ACPI is not realtime-friendly,
because compliance to ACPI seems to require that CPU and motherboard
implement the dreaded SMM (system management mode). Apparently it can be
used by manufacturers (even though it is not recommended) to emulate certain
APCI ‘fixed hardware’. Perhaps if the OS never hits that ‘hardware’ then it
is okay, but I haven’t figured yet if an ACPI-compliant OS can avoid
touching that.

The simple truth is, x86 world is not concerned about realtime/embedded
applications at all. Not until Microsoft decides otherwise :wink:

For my own long-term planning here in the non-embedded realtime world,
I’d like to know if QNX has looked into this issue and
agrees that this is the solution and it is needed. If so, is it on a
roadmap to be added at
some point in the future?

I’ve seen some references to ACPI in some roadmap, but it had a question
mark on it :wink:
I’d like to know the answer myself. It is rather large work to fully support
ACPI. It would involve serious kernel surgery and changes in the startup,
PCI layer and drivers.

Note that Intel has OS-independent ACPI interpreter. The source is available
under either GPL or BSD license as Intel tries to promote universal
acceptance of ACPI. Linux is trying to use that as a basis of ACPI support
in 2.4+ kernels. QNX could too, if they wanted to.

– igor

I’m posting a summary of all that I have learned about this issue.
Thanks to Igor Kovalenko, David Hinds, and engineers at Phoenix for
providing many answers.

PROBLEM: For hard realtime one may need to specify the IRQ for
a PCI card (such as an a/d converter, etc) such that it is high priority
and unshared. ‘High priority’ because the default IRQ priority under RTP
is 0,1,8,9,10,11,12,13,14,15,3,4,5,6,7. If the IRQ is, e.g., 5 it will be
behind the EIDE drive. ‘Unshared’ because PCI interrupts can be shared and
this may impact realtime response. Note that on most motherboards some
slots are ‘hardwire’ shared with motherboard devices. You may be able to
find a slot with an unshared interrupt line or may not be able to (on many
Dell motherboards all slots are hardwire shared with motherboard
devices. The ‘pci_irq_routing_options()’ call will provide info about
which slots are hardwire shared. This info is also usually in the motherboard doc.)

PRIOR SOLUTION: As part of the bootup process the BIOS assigns resources
to motherboard and slot devices. Most BIOS setup screens have, until recently, included
menus for ‘PCI Configuration’. This would allow one to do some or all of these
things- specify the IRQ of a PCI slot, reserve an IRQ from being assigned by the
BIOS, or specify the IRQs of motherboard devices. Note that when RTP boots,
it accepts whatever resource assignments the BIOS has assigned.

WHY THE PRIOR SOLUTION IS BECOMING PROBLEMATIC: Things change in the
PC world- new standards (ACPI, EFI), new functionality (I/O APIC mode used
by W2K and XP), etc. The ‘PCI Configuration’ screens
in many BIOS implementations are being removed by large vendors such as
Dell, Gateway, HP, IBM. There are many reasons for this,
but the bottom line is that control over IRQ assignments
it is being moved to the OS from the BIOS.

WHAT ARE THE OPTIONS?:

1.) Some BIOS’s have a non-volatile area called ESCD (Extended System Configuration Data,
from a specification written in 1994). This was when machines had PCI and ISA/EISA
busses all together with some cards that weren’t plug and play. This area would specify
how to configure resources and it was persistent across reboots. However, it was
optional and not required to be implemented. A DOS utility called ‘NVRAM.EXE’ can be found
on the net which will read/write this area. IF your BIOS has (or still has) this area AND uses
it you could specify resource assignments here. However, it’s very difficult. ‘NVRAM.EXE’
requires a binary image to write the area. (Note: the latest Dell Canterwood motherboards have
this area, but it is filled with all 1’s, which may mean it’s vestigial).

2.) After RTP boots, you can call the ‘pci_’ calls such as ‘pci_map_irq()’ to set the IRQ
of the realtime card. However even if your card is in a slot with an interrupt that is not
hardwire shared with anything else, the BIOS may have assigned other motherboard devices
to the same IRQ. If you change the IRQ of the other devices after RTP has booted its
drivers wont know. Note it may be possible to change the BIOS IRQ
assignments of motherboard devices to avoid having
a shared interrupt. Both the Linux command ‘setpnp’ and the DOS utility ‘PNPBTST.EXE’
call functions documented in the Plug and Play BIOS Specification (1994) to set the
resources of motherboard (not slot) devices. There is an option to make these changes
persistent (or ‘static’). However, it is not required that this option be implemented.

3.) You could modify the PCI Management layer in RTP as Igor Kovalenko notes to
control the resource assignments before RTP fully boots. The source is provided
in PE.

SHORT TERM ANSWER: None of the above options seem very approachable. For
myself, I am going to continue to try to find motherboards that provide some control in the
BIOS for IRQ assignments. If the BIOS will let one reserve an IRQ it can later be assigned
to the realtime card via ‘pci_map_irq()’. Note that it must be placed in a slot with an unshared
interrupt line, or else the assignment will change the other motherboard devices that are hardwire
shared
as well. Even the new Intel 865/875 motherboards from Asus and MSI still provide this
feature in the BIOS setup screens. Note that many boxed Intel motherboards will only allow one to
specify the IRQ for a slot, not reserve an IRQ or change the IRQs of motherboard devices.
Therefore there is no way to guarantee an unshared IRQ.

LONG TERM ANSWER: New functionality needs to be added to RTP to address this issue.
Hopefully this would also provide a way to specify which IRQ has the highest priority
(i.e. change the priority chain) as well.

“Art Hays” <avhays@nih.gov> wrote in message
news:bboqvh$8j6$1@inn.qnx.com

I’m posting a summary of all that I have learned about this issue.
Thanks to Igor Kovalenko, David Hinds, and engineers at Phoenix for
providing many answers.

LONG TERM ANSWER: New functionality needs to be added to RTP to address
this issue.
Hopefully this would also provide a way to specify which IRQ has the
highest priority
(i.e. change the priority chain) as well.

That was very helpful information - thanks.

Anyone know if RTP will be “upgraded”.
Has this issue been addressed in 6.2.1? Will it be?

Cheers,
Steve

Steve Cobb <steve_cobb0@yahoo.com> wrote:

“Art Hays” <> avhays@nih.gov> > wrote in message
news:bboqvh$8j6$> 1@inn.qnx.com> …
I’m posting a summary of all that I have learned about this issue.
Thanks to Igor Kovalenko, David Hinds, and engineers at Phoenix for
providing many answers.

LONG TERM ANSWER: New functionality needs to be added to RTP to address
this issue.
Hopefully this would also provide a way to specify which IRQ has the
highest priority
(i.e. change the priority chain) as well.


That was very helpful information - thanks.

Anyone know if RTP will be “upgraded”.
Has this issue been addressed in 6.2.1? Will it be?

My understanding is that the IRQ priorities are setup in startup-bios and
can be modified by anyone with a development seat.

chris


Chris McKillop <cdm@qnx.com> “The faster I go, the behinder I get.”
Software Engineer, QSSL – Lewis Carroll –
http://qnx.wox.org/