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