I’m trying to convert a filter driver to control the watchdog timer functionality of the Intel chipsets. The existing driver handles ICH2. The changes are being made to handle ICH8. The actual TCO part of the functionality is very similar between ICH2 and ICH8. There are are few differences in register sizes, but the registers are still in IO space (offset from the ACPI pase address). i’m having problems accessing two register banks (memory mapped IO) in the chipset configuration registers. These are GCS at RBCA+3000H and TCTL at RBCA+3410H. I pick up the Rott Complex Base address (RBCA) at offset F0-F3 in the PCI configuration space for the LPC device (D31:F0). In IRP_MN_QUERY_RESOURCE_REQUIREMENTS, I reserve space for the TCO ports, the GCS port and the TCTL port (the latter two being memory mapped). I get an assertion from the kernel before IRP_MN_START_DEVICE is called.
*** Assertion failed: IopInitHalResources == NULL
*** Source File: d:\xpsprtm\base\ntos\io\pnpmgr\pnpinit.c, line 1455
If I remove the 3rd resource (TCTL) then the assertion goes away. If I reduce the resources to just one (TCTL) then I get the assertion, so it’s something to do with this part of the chipset configuration registers. Anyone got any clues about this behaviour?
The HAL will claim what it’s using. If you try to overlap with that, your
claim will fail. (And if you stop making the claim, you’ll just end up
corrupting a device that the HAL is using.)
It sounds like you’re trying to claim the HPET, which is in use in Vista and
later versions of NT.
–
Jake Oshins
Hyper-V I/O Architect
Windows Kernel Team
This post implies no warranties and confers no rights.
wrote in message news:xxxxx@ntdev…
> I’m trying to convert a filter driver to control the watchdog timer
> functionality of the Intel chipsets. The existing driver handles ICH2.
> The changes are being made to handle ICH8. The actual TCO part of the
> functionality is very similar between ICH2 and ICH8. There are are few
> differences in register sizes, but the registers are still in IO space
> (offset from the ACPI pase address). i’m having problems accessing two
> register banks (memory mapped IO) in the chipset configuration registers.
> These are GCS at RBCA+3000H and TCTL at RBCA+3410H. I pick up the Rott
> Complex Base address (RBCA) at offset F0-F3 in the PCI configuration space
> for the LPC device (D31:F0). In IRP_MN_QUERY_RESOURCE_REQUIREMENTS, I
> reserve space for the TCO ports, the GCS port and the TCTL port (the
> latter two being memory mapped). I get an assertion from the kernel
> before IRP_MN_START_DEVICE is called.
> Assertion failed: IopInitHalResources == NULL
> Source File: d:\xpsprtm\base\ntos\io\pnpmgr\pnpinit.c, line 1455
> If I remove the 3rd resource (TCTL) then the assertion goes away. If I
> reduce the resources to just one (TCTL) then I get the assertion, so it’s
> something to do with this part of the chipset configuration registers.
> Anyone got any clues about this behaviour?
>
Hi Jake,
Thanks for your response. I’m not trying to access HPET. I’m working with the Systems Management TMO timer (the hardware watchdog). In ICH8, the switch is in bit 5 (No Reboot (NR)) of the General Control and status (GCS) register. The GCS register is a DWORD at offset 3410H from the Root Complex Base Address. I’m reading the RCBA from offset F0 of the PCI configuration for the LPC device (D31:F0), then trying to report the DWORD resource physical address as a memory mapped port
As well as the NR bit, the GCS register uses 11 other bits but I can’t see within the DWORD, but I see no mention of HPET.
I need to be able to set NR to 0 meaning “System will reboot upon the second timeout of the TCO timer”. Any ideas?
Best Wishes
Colin
Without looking at the debugger myself, I don’t know the answer. I suggest
you continue to look for places where you’re in conflict with the HAL.
In general, you’ve got a frustrating path in front of you. Trying to take
control of chipset hardware can have results that are hard to predict.
–
Jake Oshins
Hyper-V I/O Architect
Windows Kernel Team
This post implies no warranties and confers no rights.
wrote in message news:xxxxx@ntdev…
> Hi Jake,
> Thanks for your response. I’m not trying to access HPET. I’m working
> with the Systems Management TMO timer (the hardware watchdog). In ICH8,
> the switch is in bit 5 (No Reboot (NR)) of the General Control and status
> (GCS) register. The GCS register is a DWORD at offset 3410H from the Root
> Complex Base Address. I’m reading the RCBA from offset F0 of the PCI
> configuration for the LPC device (D31:F0), then trying to report the DWORD
> resource physical address as a memory mapped port
> As well as the NR bit, the GCS register uses 11 other bits but I can’t see
> within the DWORD, but I see no mention of HPET.
> I need to be able to set NR to 0 meaning “System will reboot upon the
> second timeout of the TCO timer”. Any ideas?
> Best Wishes
> Colin
>
Just an update. I’ve managed to solve my problem. I was reporting the memory offset from RBCA with Type=CmResourceTypePort and Flags=CM_RESOURCE_PORT_MEMORY. I changed this to Type=CmResourceTypeMemory and Flags=CM_RESOURCE_MEMORY_READ_WRITE. I still have a 3rd resource that is a true IO port. I then use READ/WRITE_REGISTER_ULONG to read and write the memory mapped IO resources. So the driver now runs happily on XP :- essentially I’ve converted an ICH2 watchdog driver to work with ICH8, albeit on XP only. I think Vista has a true watchdog driver.
Can anyone explain to me what Type=CmResourceTypePort and Flags=CM_RESOURCE_PORT_MEMORY is used for? I’ve searched the web but haven’t found a definitive answer.
Together, these indicate a port resource (a hardware resource that is located in I/O space on the PCI bus, for example) that is mapped into memory space (because the current platform doesn’t support direct access to port space the way the x86 does, for example, using IN and OUT instructions).
Peter
OSR
xxxxx@osr.com wrote:
Together, these indicate a port resource (a hardware resource that is located in I/O space on the PCI bus, for example) that is mapped into memory space (because the current platform doesn’t support direct access to port space the way the x86 does, for example, using IN and OUT instructions).
Yes. As an example, when NT ran on PowerPC and Alpha machines, devices
that required I/O port access (like VGAs) had to use this resource
type. Drivers had to use magic parts of the physical memory space to
access the I/O ports.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Peter and Tim, Thanks for your explanations.
Colin