Re: [acpi-os2] BASEDEV etc.
On Tue, 10 Dec 2002 13:21:08 +0100 (CET), Daniela Engert wrote: >On Tue, 10 Dec 2002 13:05:19 +0100 (CET), kiewitz wrote: > >>>Are there any non-German-speakers around ? >>Roderick complained on IRC ;-)) > >Dutch counts as a strange German accent ;-) > Swedish ? OTOH I'll probably be lurking most of the time. Sincerely JMA Development and Consulting John Martin , [EMAIL PROTECTED] == Website: http://www.jma.se/ email: [EMAIL PROTECTED] Phone: 46-(0)70-6278410 == --- To unsubscribe yourself from this list, send the following message to [EMAIL PROTECTED] unsubscribe acpi-os2 end
Re: [acpi-os2] BASEDEV etc.
On Tue, 10 Dec 2002 13:21:08 +0100 (CET), Daniela Engert wrote: >>?? It's possible to modify Dev-Helper functions using PSDs? That's a nice feature. >Where can I get >>documentation about them? >You can do a lot of interesting things in PSDs; you'll find this >documented in the SMP programming addendum. If people need it I can >push it to the list. please push. I downloaded nearly the whole DDK and much more, but I never found anything about SMP. 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. >Better do before building too much into your GCONFIG driver. well, GCONFIG is work from about 6 months ago. I'm not currently working on it. >>>As I said before, no fiddling with OS2LDR, please. It wouldn't work >>>with IOAPICs at all. >>device-driver OEMHLP$. If there is a non-patching solution (e.g. PSDs), I will >change my code of course. >Have a look at that. I don't mind the non-IRQ stuff, but IRQ handling >is to be done in PSDs. No problem. Are PSDs somewhat like BASEDEVs or are they completely different? We will need to replace ISAPNP.SNP nearly 100% for sure, because the original driver could and would mess on systems, that got both PnP and e.g. ACPI support, so perhaps we will need to split the work. One brandnew PSD-driver and one replacement. Also ISAPNP.SYS will get used to find out when snoopers are done loading (used by GCONFIG), because configuration of e.g. PnP devices may first get done after all snooper drivers got loaded (giving legacy hardware, I know outdated, anyway we need to maintain some compatibility and the original one wouldn't work anymore). cu, Kiewitz --- To unsubscribe yourself from this list, send the following message to [EMAIL PROTECTED] unsubscribe acpi-os2 end
Re: [acpi-os2] BASEDEV etc.
On Tue, 10 Dec 2002 13:05:19 +0100 (CET), kiewitz wrote: >>Are there any non-German-speakers around ? >Roderick complained on IRC ;-)) Dutch counts as a strange German accent ;-) >?? It's possible to modify Dev-Helper functions using PSDs? That's a nice feature. >Where can I get >documentation about them? You can do a lot of interesting things in PSDs; you'll find this documented in the SMP programming addendum. If people need it I can push it to the list. >>>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. Better do before building too much into your GCONFIG driver. >>As I said before, no fiddling with OS2LDR, please. It wouldn't work >>with IOAPICs at all. >device-driver OEMHLP$. If there is a non-patching solution (e.g. PSDs), I will change >my code of course. Have a look at that. I don't mind the non-IRQ stuff, but IRQ handling is to be done in PSDs. 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
Re: [acpi-os2] BASEDEV etc.
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
Re: [acpi-os2] BASEDEV etc.
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
Re: [acpi-os2] BASEDEV etc.
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? 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. 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. 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). Is there anything more than that? I mean PCI is already done. Only detection needs to get done by using ACPI functions. 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). That 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. So PIC code is left. Is there anything besides that? (not speaking about extra ACPI features like e.g. power-managment). Also could it be that some implementations of ACPI are buggy in terms of 16-bit PM? 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. cu, Kiewitz --- To unsubscribe yourself from this list, send the following message to [EMAIL PROTECTED] unsubscribe acpi-os2 end
Re: [acpi-os2] BASEDEV etc.
Hi! On Tue, 10 Dec 2002 10:47:56 +0100 (CET), 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. 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
