On Tue, 10 Dec 2002 11:24:09 +0100 (CET), wrote:
>On Tue, 10 Dec 2002 10:57:06 +0100 (CET), Daniela Engert wrote:
>
>>>Hab gerade dein Posting in der os2-dev mailingliste gelesen.
>>>GCONFIG soll sp�ter mal ISAPNP.SNP ersetzen und der wird vor allen anderen BASEDEVs
>geladen und
>>>muss nicht gelistet werden (in config.sys).
>>Deswegen ist dies die beste Stelle, um dort das Thema
>>Enumerieren/Konfigurieren und evtl. sp�ter mal ACPI Event-Controller zu
>>behandeln. Am besten w�re da vermutlich ein Multi-Device: einmal das
>>was Du schon hast, dann ACPI-Interface f�r Usermode-Module, und was
>>sonst noch gebraucht wird.
>>
>>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 ?
>My GCONFIG is already able to replace functionality of ISAPNP.SNP and PCIBUS.SNP,
>whereas
>ISAPNP.SNP is loaded at anytime (not limited to Snooper on/off) because it also
>activates PnP cards. That's
>why I think that place would be the best to "insert" the ACPI support in there. And
>because I already have
>PNP support, replacing it shouldn't be a hassle. I need to implement RM code, so that
>detected PnP devices
>will appear in Detected-resources, anyway that's not much code. OEMHLP$ insert is
>also implemented, so
>one would "just" need to append the ACPI code onto that one.
Exactly - well, at least one of sveral options ;-)
>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!
>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
>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).
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.
>nukes the machine of course. ACPI would need to go first and automatically fill
>PCI-Detected flag, so that this
>code won't get executed.
Ok.
>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).
>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.
Ciao,
Dani
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Daniela Engert, systems engineer at MEDAV GmbH
Gr�fenberger Str. 32-34, 91080 Uttenreuth, Germany
Phone ++49-9131-583-348, Fax ++49-9131-583-11
-----------
To unsubscribe yourself from this list, send the following message
to [EMAIL PROTECTED]
unsubscribe acpi-os2
end
