Any support for Intel audio device 0x24c5 (Intel 82801DBM)?

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

Any hope of supporting the device below under QNX 6.2.1
on IA-32? This is, I think, an “Intel 82801DBM I/O Controller
Hub 4 Mobile (ICH4-M)” If I can just pump audio out to the
thing I’ll be happy. Thanks.

John Nagle
Team Overbot

Class = Multimedia (Audio)
Vendor ID = 8086h, Intel Corporation
Device ID = 24c5h, Unknown Unknown
PCI index = 0h
Class Codes = 040100h
Revision ID = 1h
Bus number = 0
Device number = 31
Function num = 5
Status Reg = 290h
Command Reg = 7h
Header type = 0h Single-function
BIST = 0h Build-in-self-test not supported
Latency Timer = 0h
Cache Line Size= 0h
PCI IO Address = e800h length 256 enabled
PCI IO Address = e400h length 64 enabled
PCI Mem Address = dff7ba00h 32bit length 512 enabled
PCI Mem Address = dff7b900h 32bit length 256 enabled
Subsystem Vendor ID = 4005h
Subsystem ID = 4710h
Max Lat = 0ns
Min Gnt = 0ns
PCI Int Pin = INT B
Interrupt line = 5
Capabilities Pointer = 50h
Capability ID = 1h
Capabilities = c9c2h - 0h

2

John Nagle wrote:
Look at http://www.qnxzone.com/~phearbear/i8500.html

some hacking and it works pretty decent.


Any hope of supporting the device below under QNX 6.2.1
on IA-32? This is, I think, an “Intel 82801DBM I/O Controller
Hub 4 Mobile (ICH4-M)” If I can just pump audio out to the
thing I’ll be happy. Thanks.

John Nagle
Team Overbot

Class = Multimedia (Audio)
Vendor ID = 8086h, Intel Corporation
Device ID = 24c5h, Unknown Unknown
PCI index = 0h
Class Codes = 040100h
Revision ID = 1h
Bus number = 0
Device number = 31
Function num = 5
Status Reg = 290h
Command Reg = 7h
Header type = 0h Single-function
BIST = 0h Build-in-self-test not supported
Latency Timer = 0h
Cache Line Size= 0h
PCI IO Address = e800h length 256 enabled
PCI IO Address = e400h length 64 enabled
PCI Mem Address = dff7ba00h 32bit length 512 enabled
PCI Mem Address = dff7b900h 32bit length 256 enabled
Subsystem Vendor ID = 4005h
Subsystem ID = 4710h
Max Lat = 0ns
Min Gnt = 0ns
PCI Int Pin = INT B
Interrupt line = 5
Capabilities Pointer = 50h
Capability ID = 1h
Capabilities = c9c2h - 0h

/Johan Björk

3

Is it possible to do this without patching the executable?
Are there command line arguments that will do it, as with
the serial driver?

John Nagle
Team Overbot

Johan Bjoerk wrote:

John Nagle wrote:
Look at > http://www.qnxzone.com/~phearbear/i8500.html

some hacking and it works pretty decent.


Any hope of supporting the device below under QNX 6.2.1
on IA-32? This is, I think, an “Intel 82801DBM I/O Controller
Hub 4 Mobile (ICH4-M)” If I can just pump audio out to the
thing I’ll be happy. Thanks.

John Nagle
Team Overbot

Class = Multimedia (Audio)
Vendor ID = 8086h, Intel Corporation
Device ID = 24c5h, Unknown Unknown
PCI index = 0h
Class Codes = 040100h
Revision ID = 1h
Bus number = 0
Device number = 31
Function num = 5
Status Reg = 290h
Command Reg = 7h
Header type = 0h Single-function
BIST = 0h Build-in-self-test not supported
Latency Timer = 0h
Cache Line Size= 0h
PCI IO Address = e800h length 256 enabled
PCI IO Address = e400h length 64 enabled
PCI Mem Address = dff7ba00h 32bit length 512 enabled
PCI Mem Address = dff7b900h 32bit length 256 enabled
Subsystem Vendor ID = 4005h
Subsystem ID = 4710h
Max Lat = 0ns
Min Gnt = 0ns
PCI Int Pin = INT B
Interrupt line = 5
Capabilities Pointer = 50h
Capability ID = 1h
Capabilities = c9c2h - 0h



/Johan Björk

4

John Nagle wrote:

Is it possible to do this without patching the executable?
Are there command line arguments that will do it, as with
the serial driver?

John Nagle
Team Overbot

Johan Bjoerk wrote:

John Nagle wrote:
Look at > http://www.qnxzone.com/~phearbear/i8500.html

some hacking and it works pretty decent.


Any hope of supporting the device below under QNX 6.2.1
on IA-32? This is, I think, an “Intel 82801DBM I/O Controller
Hub 4 Mobile (ICH4-M)” If I can just pump audio out to the
thing I’ll be happy. Thanks.

John Nagle
Team Overbot

Class = Multimedia (Audio)
Vendor ID = 8086h, Intel Corporation
Device ID = 24c5h, Unknown Unknown
PCI index = 0h
Class Codes = 040100h
Revision ID = 1h
Bus number = 0
Device number = 31
Function num = 5
Status Reg = 290h
Command Reg = 7h
Header type = 0h Single-function
BIST = 0h Build-in-self-test not supported
Latency Timer = 0h
Cache Line Size= 0h
PCI IO Address = e800h length 256 enabled
PCI IO Address = e400h length 64 enabled
PCI Mem Address = dff7ba00h 32bit length 512 enabled
PCI Mem Address = dff7b900h 32bit length 256 enabled
Subsystem Vendor ID = 4005h
Subsystem ID = 4710h
Max Lat = 0ns
Min Gnt = 0ns
PCI Int Pin = INT B
Interrupt line = 5
Capabilities Pointer = 50h
Capability ID = 1h
Capabilities = c9c2h - 0h



/Johan Björk



Havn’t found any, not anything that’s documented atleast.

I really hope qssl will support this card out of the box in 6.3, as
there should be very minor modifications in the i8x0 driver to make it
work ‘perfect’.

Anyone from qssl to comment?

/Johan

5

The way drivers are deployed for QNX is fundamentally broken.
The whole point of QNX is that drivers are just ordinary
programs. Yet you have to wait for the “next release” to
get a new driver. This routinely puts QNX a year or two behind on
hardware support.

A big problem is the traplist. The traplist is one big
file, or at least one file for each type of device. This
creates a packaging issue that breaks the independence of
drivers, because installing a new driver means modifying
the centralized traplist files.

If each driver had its own traplist, and they were combined
into one big traplist at boot time, deployment of new drivers
could be far more timely. New drivers could be issued as repositories
on a web site, and you could download what you needed.

Right now, QNX driver release works worse than the way Windows does it.
Unnecessarily.

John Nagle
Team Overbot

Johan Bjoerk wrote:

Havn’t found any, not anything that’s documented atleast.
I really hope qssl will support this card out of the box in 6.3, as
there should be very minor modifications in the i8x0 driver to make it
work ‘perfect’.

Anyone from qssl to comment?

/Johan

6

In article <3FE2035A.9090009@downside.com>, nagle@downside.com says…

The way drivers are deployed for QNX is fundamentally broken.
The whole point of QNX is that drivers are just ordinary
programs. Yet you have to wait for the “next release” to
get a new driver. This routinely puts QNX a year or two behind on
hardware support.

A big problem is the traplist. The traplist is one big
file, or at least one file for each type of device. This
creates a packaging issue that breaks the independence of
drivers, because installing a new driver means modifying
the centralized traplist files.

If each driver had its own traplist, and they were combined
into one big traplist at boot time, deployment of new drivers
could be far more timely. New drivers could be issued as repositories
on a web site, and you could download what you needed.

Each driver may have its own configuration file for enumerator, and all these files are combined
into one big traplist at boot time. You probably meant not QNX but other OS where traplist is whole
mess with a huge file called registry hive :slight_smile: As Kabe mentioned above the problem is a lack of
documentation for the subject. But it doesn’t take too long to learn how things work by reading
documentation on enum-devices and examples in /etc/system/enum. But I didn’t say it’s a good way,
did I? A good documentation is much better.

Right now, QNX driver release works worse than the way Windows does it.

I suppose it will be for a long time. Windows and QNX are too different, fortunatelly. BTW, to add
new driver in QNX system isn’t hard at all, you even don’t have to bother with enumerator - you can
launch it just as a regular program. And it is a good point, IMHO. As about lack of drivers for QNX,
please count number of people developing drivers for these two platforms. There will be windows
drivers in abundance while windows is popular, in demand, and a lot of business work for it.

Cheers,
Eduard

Unnecessarily.

John Nagle
Team Overbot

Johan Bjoerk wrote:

Havn’t found any, not anything that’s documented atleast.
I really hope qssl will support this card out of the box in 6.3, as
there should be very minor modifications in the i8x0 driver to make it
work ‘perfect’.

Anyone from qssl to comment?

/Johan

7

nagle@downside.com sed in <3FE2035A.9090009@downside.com>:

A big problem is the traplist. The traplist is one big
file, or at least one file for each type of device. This
creates a packaging issue that breaks the independence of
drivers, because installing a new driver means modifying
the centralized traplist files.

You don’t have to. See

<URL:news:b1s1u4$6qm$1@nntp.qnx.com>
URL:nntp://inn.qnx.com/comp.os.qnx/13149
<URL:news:b9b77j$394$1@inn.qnx.com>
URL:nntp://inn.qnx.com/qdn.public.sysadmin/94
<URL:news:b9b7qd$394$2@inn.qnx.com>
URL:nntp://inn.qnx.com/qdn.public.sysadmin/95

I already add otherwise undetected devices using /etc/system/enum/oem/*
without touching /etc/system/enum/devices/*, which you don’t
want to modify as they are under fs-pkg.

You can easily package the driver with enumurator.
Also survives upgrades.

Yes, the trouble is the mechanism is undocumented.
(Does PE DDK has the docs?)


Back to the original topic,
the trouble is that vid=0xHHHH did=0xHHHH [chipset=nnnn] option
does not always work for all drivers; which when you have to revert to
binary patches. (I’ve done it for FE2000 OEM card)

kabe

8

kabe@sra-tohoku.co.jp wrote:

Yes, the trouble is the mechanism is undocumented.

So many undocumented features, so little time…

John Nagle
Team Overbot

9

In article <brtm5v$cke$1@inn.qnx.com>, kabe@sra-tohoku.co.jp says…

Yes, the trouble is the mechanism is undocumented.

Topic “Configuration file contents” in
http://www.qnx.com/developer/docs/momentics621_docs/neutrino/utilities/e/enum-devices.html

I believe it’s all for now.

(Does PE DDK has the docs?)

Good question :slight_smile: I also want to know.
Eduard.

10

That patch doesn’t work.

Patched per instructions.
Ran
/sbin/io-audio -d i8x0 &


Dec 30 20:13:51 1 7 0 i8x0: create - codec NOT ready 10700000
TRYING

Dec 30 20:13:53 1 7 0 i8x0: create - never read codec ready
from AC’97 10700000

Dec 30 20:13:53 1 7 0 init_card: unable to init dll
deva-ctrl-i8x0.so

Dec 30 20:13:53 1 7 0 mount_card(): failed to initialize card
i8x0

Also tried “/sbin/io-audio -d i8x0 pci=0h”. Same result.

Is there any way to make this work? That patching business is iffy;
the patch suggested just patches the first occurence of that two-byte
pattern.

John Nagle


Johan Bjoerk wrote:

John Nagle wrote:
Look at > http://www.qnxzone.com/~phearbear/i8500.html

some hacking and it works pretty decent.


Any hope of supporting the device below under QNX 6.2.1
on IA-32? This is, I think, an “Intel 82801DBM I/O Controller
Hub 4 Mobile (ICH4-M)” If I can just pump audio out to the
thing I’ll be happy. Thanks.

John Nagle
Team Overbot

Class = Multimedia (Audio)
Vendor ID = 8086h, Intel Corporation
Device ID = 24c5h, Unknown Unknown
PCI index = 0h
Class Codes = 040100h
Revision ID = 1h
Bus number = 0
Device number = 31
Function num = 5
Status Reg = 290h
Command Reg = 7h
Header type = 0h Single-function
BIST = 0h Build-in-self-test not supported
Latency Timer = 0h
Cache Line Size= 0h
PCI IO Address = e800h length 256 enabled
PCI IO Address = e400h length 64 enabled
PCI Mem Address = dff7ba00h 32bit length 512 enabled
PCI Mem Address = dff7b900h 32bit length 256 enabled
Subsystem Vendor ID = 4005h
Subsystem ID = 4710h
Max Lat = 0ns
Min Gnt = 0ns
PCI Int Pin = INT B
Interrupt line = 5
Capabilities Pointer = 50h
Capability ID = 1h
Capabilities = c9c2h - 0h



/Johan Björk