Hi,
I’m working on a system with a custom LPC device. The device exists at a fixed address in LPC address space.
The motherboard I’m prototyping on has an ICH7 ISA bridge. This bridge has 4 general-purpose LPC I/O decode registers in PCI config space. I need to program one of these registers to pass-through I/O cycles to my device on the LPC bus.
Do I need to write some sort of driver to update this register? If so, what type of driver do I need to write? ISAPNP filter? Bus/Device filter? And which stack does it need to be in?
Alternatively, does isapnp.sys have some mechanism to set the register without a driver? Registry entry? WMI/ACPI interface? Something else?
FWIW I have manually written the config register via WinDbg and I can subsequently access my LPC device via the portio.sys DDK example driver/app. Obviously I need to do this “the right way” programmatically at boot time.
TIA
Regards,
Mark
Ideally, you don’t add an LPC device to your machine when you don’t control
the BIOS. It doesn’t really work any other way.
For people who can modify the BIOS of the motherboard that they’re
modifying, you have the BIOS set those register windows. Windows doesn’t
know anything about the windows. (Capitalization turns out be important in
this discussion.)
Then the BIOS enumerates the LPC device by putting an entry for it in the
ACPI namespace. The _CRS object under the device reports the resources used
by the device and Windows will hand those to your driver.
–
Jake Oshins
(former ACPI guy)
Windows Kernel Team
This post implies no warranties and confers no rights.
wrote in message news:xxxxx@ntdev…
> Hi,
>
> I’m working on a system with a custom LPC device. The device exists at a
> fixed address in LPC address space.
>
> The motherboard I’m prototyping on has an ICH7 ISA bridge. This bridge has
> 4 general-purpose LPC I/O decode registers in PCI config space. I need to
> program one of these registers to pass-through I/O cycles to my device on
> the LPC bus.
>
> Do I need to write some sort of driver to update this register? If so,
> what type of driver do I need to write? ISAPNP filter? Bus/Device filter?
> And which stack does it need to be in?
>
> Alternatively, does isapnp.sys have some mechanism to set the register
> without a driver? Registry entry? WMI/ACPI interface? Something else?
>
> FWIW I have manually written the config register via WinDbg and I can
> subsequently access my LPC device via the portio.sys DDK example
> driver/app. Obviously I need to do this “the right way” programmatically
> at boot time.
>
> TIA
> Regards,
> Mark
>
>
Jake Oshins wrote:
Ideally, you don’t add an LPC device to your machine when you don’t
control the BIOS. It doesn’t really work any other way.
For people who can modify the BIOS of the motherboard that they’re
modifying, you have the BIOS set those register windows. Windows
doesn’t know anything about the windows. (Capitalization turns out be
important in this discussion.)
Then the BIOS enumerates the LPC device by putting an entry for it in
the ACPI namespace. The _CRS object under the device reports the
resources used by the device and Windows will hand those to your
driver.
Hmmm…
The situation I have here is that I’m prototyping an LPC device on an ICH7
chipset. In this case, for prototyping, I may be able to get away with
manually patching the decode register via WinDbg on each boot.
Apparently the southbridge in the target module (which we don’t have
access to yet) is an SCH. IIUC, that chip will forward any unclaimed I/O
access onto the LPC bus. At least, I’m hoping that’s the case because it
would make my life a lot easier! 
Thanks for your feedback!
Regards,
Mark
If you do a lot of this sort of stuff, you might want to check out General Software’s EmbeddedBIOS
and perhaps Firmbase as well.
General Software - http://www.gensw.com/
EmbeddedBIOS - http://www.gensw.com/subpage.aspx?ID=132&L=3
Firmbase - http://www.gensw.com/subpage.aspx?ID=133&L=24
As Jake said, you really should have the BIOS initiate this process, and having the source for a
EmbeddedBIOS would allow you to do that. Firmbase - their framework for SMM development - runs on
top of EmbeddedBIOS and would provide you with an efficient way to simulate devices like this.
Neither of these is by a long shot cheap, however, and the later requires the former (practically
speaking, at least), and there are obviously other BIOS vendors to consider (though General Software
is now part of Phoenix); this is the only one that I know about. The big issue is that at the
moment (Phoenix may improve this), both EB & FB are relatively speaking quite limited in platform
support.
I’m not really sure if this will be help you or be of interest, but I thought I would mention it.
Good luck,
mm
Mark McDougall wrote:
Jake Oshins wrote:
> Ideally, you don’t add an LPC device to your machine when you don’t
> control the BIOS. It doesn’t really work any other way.
>
> For people who can modify the BIOS of the motherboard that they’re
> modifying, you have the BIOS set those register windows. Windows
> doesn’t know anything about the windows. (Capitalization turns out be
> important in this discussion.)
>
> Then the BIOS enumerates the LPC device by putting an entry for it in
> the ACPI namespace. The _CRS object under the device reports the
> resources used by the device and Windows will hand those to your
> driver.
Hmmm…
The situation I have here is that I’m prototyping an LPC device on an ICH7
chipset. In this case, for prototyping, I may be able to get away with
manually patching the decode register via WinDbg on each boot.
Apparently the southbridge in the target module (which we don’t have
access to yet) is an SCH. IIUC, that chip will forward any unclaimed I/O
access onto the LPC bus. At least, I’m hoping that’s the case because it
would make my life a lot easier!
Thanks for your feedback!
Regards,
Mark
Martin O’Brien wrote:
If you do a lot of this sort of stuff, you might want to check out
General Software’s EmbeddedBIOS and perhaps Firmbase as well.
Thanks for the info. Whilst I can’t use it in this instance, it’s
certainly something I’ll keep as a reference for future work. Our customer
has some unique BIOS requirements and will be working with the vendor to
produce a custom BIOS for this platform. Any changes we require for purely
technical reasons - as you & Jake suggest - should be able to be fulfilled
by the vendor.
I’m not really sure if this will be help you or be of interest, but I
thought I would mention it.
Definitely of interest!
Thanks again!
Regards,
Mark
Not a problem; glad to help.
Good luck,
mm
Mark McDougall wrote:
Martin O’Brien wrote:
> If you do a lot of this sort of stuff, you might want to check out
> General Software’s EmbeddedBIOS and perhaps Firmbase as well.
Thanks for the info. Whilst I can’t use it in this instance, it’s
certainly something I’ll keep as a reference for future work. Our customer
has some unique BIOS requirements and will be working with the vendor to
produce a custom BIOS for this platform. Any changes we require for purely
technical reasons - as you & Jake suggest - should be able to be fulfilled
by the vendor.
> I’m not really sure if this will be help you or be of interest, but I
> thought I would mention it.
Definitely of interest!
Thanks again!
Regards,
Mark