On Tue, 10 Dec 2002 12:47:30 +0100 (CET), Daniela Engert wrote:
>>>BTW, es wäre besser, das auf acpi-os2 zu diskutieren. Ich CC das mal.
>>That's why I quickly e-mailed you ;-) I think some people in here don't understand
>German or do they?
>Are there any non-German-speakers around ?
Roderick complained on IRC ;-))
>>I don't know where to hook the PIC functions,
>>I bet they are in OS2LDR as well, so we can patch ourselves into it as well. I will
>look for that code, when
I'm
>>done with MINSTALL.
>No, this is what PSDs are for! No modifications to existing code!
?? It's possible to modify Dev-Helper functions using PSDs? That's a nice feature.
Where can I get
documentation about them?
>>ISAPNP.SNP is one of the first drivers that get loaded. I think only 2 other
>hardcoded drivers get loaded
>>before (one of them is TIMER0, I don't know about the other one anymore).
>TIMER0.SYS is listed in CONFIG.SYS
Then it was CLOCK01.SYS :-)
>>Is there anything more than that? I mean PCI is already done. Only detection needs
>to get done by using
>>ACPI functions.
>Don't forget device configuration (i.e. _HID ACPI methods, IRQ routing
>and possibly some more).
well, that one could get done using the detection area concept. It already supports
IRQ routing (not
configuring yet, but detecting). It's daemon based, which means the driver just finds
out what hardware there
is and the daemon (Ring-3) loaded using RUN command is used to ask the user how to
configure the device.
Then it will write to a configuration area (file in \OS2\BOOT) and GCONFIG will then
use that configuration to
configure the hardware. That way it's also possible to implement WPS-based
configuration later.
> GCONFIG uses OEMHLP$ call for detection (sadly) because I'm not able
>to call BIOS safely
>>during 16-bit PM. (I discovered an old MCA-BIOS that has INT opcode (!) in its BIOS
>interrupt handler).
>I don't do OEMHELP$ calls at all to enumerate the PCI bus in my
>drivers. Just some port IO and you're done.
I noticed, but it's used for PCI detection and that call is intercepted as well. So
it's possible to "emulate" a
"PCI-I'm here" to all drivers even PCI BIOS is missing. Config-Space Read/Write calls
are also done using
hardware instead of BIOS (original OS2LDR forwards to BIOS) and some drivers use it.
actually it's even
better to use those calls (R/W), because if the config-space mechanismn changes, all
drivers wouldn't work
anymore.
>>Also could it be that some implementations of ACPI are buggy in terms of 16-bit PM?
>ACPI is something completely different. The BIOS is hardly involved
>(except for providing the AML code which will be interpreted by the
>ACPI AML interpreter).
That's good.
Like I said, I had no time to read ACPI documentation.
>>I will do the PIC code hook-in (if the code is in OEMHLP$ aka OS2LDR) asap. I won't
>be able to code the
>>actual replacements, because I don't have any ACPI system here, so I wouldn't have a
>way to test my
code.
>As I said before, no fiddling with OS2LDR, please. It wouldn't work
>with IOAPICs at all.
Well, afaik patching into OS2LDR is required to replace PCI functions with our own.
They are hardcoded as
device-driver OEMHLP$. If there is a non-patching solution (e.g. PSDs), I will change
my code of course.
Anyway it's just a FAR-CALL patch and it's working even on old Warp3 systems. It's
also safe code. I didnt
find any tester, where the code didn't work (and that's including some real special
machines e.g. MCA)
cu, Kiewitz
-----------
To unsubscribe yourself from this list, send the following message
to [EMAIL PROTECTED]
unsubscribe acpi-os2
end
