Hi!
Well, I found some tuple examples on the web and I think it's possible to translate it
into gconfig-format.
Anyway, I got one question about Cardbus and PCMCIA cards.
Some PCMCIA cards may request e.g. I/O region 0x330h. That's okay on PCMCIA controller
(the old ones,
16-bit). But what happens on Cardbus? I only have 2 memory and 2 I/O windows. How
should such resource
assignment work in that case? Or would I need to assign something from within the
window and ignore the
0x330h request at all?
I would really appreciate some details on those tuples. I'm able to find out much
about the (pretty simple)
format, but I need some real documentation especially for resource tuples and the
"link-tuples".
I propose that I will include an API for HWDevice generation, so one will have to
include support for
GCONFIG into AUTOCFG2.SYS driver(s). I don't see any other way, especially because of
the driver
configuration choosing.
Tuple #3, code = 0x20 (Manufacturer ID), length = 4
000: 49 01 ab c1
PCMCIA ID = 0x149, OEM ID = 0xc1ab
^^^^^^
This would get put into Vendor/DeviceID in BASE-Block.
Tuple #4, code = 0x15 (Version 1 info), length = 26
000: 04 01 45 74 68 65 72 6e 65 74 00 41 64 61 70 74
010: 65 72 00 32 2e 30 00 ff 00 ff
Version = 4.1, Manuf = [Ethernet], card vers = [Adapter]
Addit. info = [2.0]
^^^
All strings will get appended on each other and put into NAME-SubBlock (like for PnP).
Version will get put into Version/Revision bytes in BASE-Block.
Tuple #12, code = 0x21 (Functional ID), length = 2
000: 06 00
Network/LAN adapter
^^^^^
This would get put into Class and Sub-Class bytes in BASE-Block
Tuple #5, code = 0x1a (Configuration map), length = 5
000: 01 06 d0 0f 0b
Reg len = 2, config register addr = 0xfd0, last config = 0x6
Registers: XX-X----
^^^^
No idea what this is for
Tuple #6, code = 0x1b (Configuration entry), length = 7
000: c0 81 18 45 30 fc be
Config index = 0x0(default)
Interface byte = 0x81 (I/O) wait signal supported
Card decodes 5 address lines, limited 8/16 Bit I/O
IRQ modes: Level
IRQs: 2 3 4 5 6 7 9 10 11 12 13 15
^^^^^
I bet bit-encoded design. If no one in here has a full tuple documentation, I will go
into a library and look for
the info. I looked at the official specs and they are priced at 500$ (!!) crazy. I
couldn't find anything quite
useful (i mean fully documented, not some crazy l33t linux super-source w/o comments).
I understand Config Index. If it's 0, it has to get included in any configuration.
Otherwise it's selected by the
driver. e.g. all resource requests with index 0x1 get used when configuration 1 is
selected.
I propose to generate multiple PROPosal blocks. One per configuration. So if a device
has 2 configurations, it
will have 2 PROPosal blocks and the default requirements are listed in *both*.
Tuple #13, code = 0x14 (No link), length = 0
^^^^
Another strange thing. I don't really know what those "links" are for. I would really
appreciate some help.
Tuple #14, code = 0x0 (Null tuple), length = 9
000: 57 42 4c 41 4e 39 32 36 ff
^^^^
NULL Tuple???
Tuple #15, code = 0xff (Terminator), length = 0
^^^^^
Seems logical.
May I access those tuples in a stream or do I have to call an API per tuple?
I don't have anything to try it on here, so I will also need someone to test out.
cu, Kiewitz
-----------
To unsubscribe yourself from this list, send the following message
to [EMAIL PROTECTED]
unsubscribe acpi-os2
end
