2006-11-27 19:26:31 +00:00
|
|
|
/*
|
|
|
|
* PROJECT: ReactOS HAL
|
[HAL]: Bus support in the HAL actually creates a further wedge between the different x86 HALs: There are actually two dinstinct implementations. On the ACPI HAL, the system is assumed not to have things like special ISA, MCA, EISA buses, and a PCI driver is used in combination with the ACPI Interface for PCI Bus support. On non-ACPI systems, the legacy "Bus Handler" library is used, and the HAL provides a core set of CMOS, EISA, ISA, MCA and PCI bus handlers, each with their own routines and specific code. Additionally, PCI IRQ Routing and other PCI bus internals are handled directly by the HAL -- on the ACPI HAL, the PCI Bus support is implemented through a "Fake"/static bus handler, just to keep the functions shared. On ReactOS, both the ACPI and non-ACPI HAL were currently using a mix of both HAL bus handling types, mostly implemented the "ACPI way" (with a fake PCI bus handler and such).
As a result, none of the Hal*Bus HALDISPATCH routines were implemented, which bus drivers expect to find when they're not on ACPI systems (ReactOS today). eVb's new PCI driver was crashing, for example.
Furthermore, legacy systems suffer, because the ACPI HAL Bus routines (that we currently have) expect perfect ACPI-style-compliant systems, not the legacy crap from the early 90ies. This works fine in VMs and new hardware, but old hardware is left behind.
This patch basically corrects the first part of the problem, by making the bus handling support separate between ACPI and non-ACPI HALs. For now, the code remains 100% the same in functionality between both.
However, I have started adding the first few elements:
[HAL]: Implement HalRegisterBusHandler HALDISPATCH routine.
[HAL]: On legacy HALs, register the CMOS, ISA, SYSTEM handlers.
[HAL]: Add cmosbus.c. Stub all bus-specific bus handler routines in the xxxbus.c files.
No real functionality change occurs with this patch, yet.
svn path=/trunk/; revision=47649
2010-06-07 01:09:41 +00:00
|
|
|
* LICENSE: BSD - See COPYING.ARM in the top level directory
|
|
|
|
* FILE: hal/halx86/generic/legacy/bussupp.c
|
|
|
|
* PURPOSE: HAL Legacy Bus Support Code
|
|
|
|
* PROGRAMMERS: ReactOS Portable Systems Group
|
2001-08-21 20:18:27 +00:00
|
|
|
*/
|
|
|
|
|
[HAL]: Bus support in the HAL actually creates a further wedge between the different x86 HALs: There are actually two dinstinct implementations. On the ACPI HAL, the system is assumed not to have things like special ISA, MCA, EISA buses, and a PCI driver is used in combination with the ACPI Interface for PCI Bus support. On non-ACPI systems, the legacy "Bus Handler" library is used, and the HAL provides a core set of CMOS, EISA, ISA, MCA and PCI bus handlers, each with their own routines and specific code. Additionally, PCI IRQ Routing and other PCI bus internals are handled directly by the HAL -- on the ACPI HAL, the PCI Bus support is implemented through a "Fake"/static bus handler, just to keep the functions shared. On ReactOS, both the ACPI and non-ACPI HAL were currently using a mix of both HAL bus handling types, mostly implemented the "ACPI way" (with a fake PCI bus handler and such).
As a result, none of the Hal*Bus HALDISPATCH routines were implemented, which bus drivers expect to find when they're not on ACPI systems (ReactOS today). eVb's new PCI driver was crashing, for example.
Furthermore, legacy systems suffer, because the ACPI HAL Bus routines (that we currently have) expect perfect ACPI-style-compliant systems, not the legacy crap from the early 90ies. This works fine in VMs and new hardware, but old hardware is left behind.
This patch basically corrects the first part of the problem, by making the bus handling support separate between ACPI and non-ACPI HALs. For now, the code remains 100% the same in functionality between both.
However, I have started adding the first few elements:
[HAL]: Implement HalRegisterBusHandler HALDISPATCH routine.
[HAL]: On legacy HALs, register the CMOS, ISA, SYSTEM handlers.
[HAL]: Add cmosbus.c. Stub all bus-specific bus handler routines in the xxxbus.c files.
No real functionality change occurs with this patch, yet.
svn path=/trunk/; revision=47649
2010-06-07 01:09:41 +00:00
|
|
|
/* INCLUDES *******************************************************************/
|
2001-08-21 20:18:27 +00:00
|
|
|
|
2005-06-18 14:29:31 +00:00
|
|
|
#include <hal.h>
|
2005-06-19 22:53:49 +00:00
|
|
|
#define NDEBUG
|
|
|
|
#include <debug.h>
|
2001-08-21 20:18:27 +00:00
|
|
|
|
[HAL]: Bus support in the HAL actually creates a further wedge between the different x86 HALs: There are actually two dinstinct implementations. On the ACPI HAL, the system is assumed not to have things like special ISA, MCA, EISA buses, and a PCI driver is used in combination with the ACPI Interface for PCI Bus support. On non-ACPI systems, the legacy "Bus Handler" library is used, and the HAL provides a core set of CMOS, EISA, ISA, MCA and PCI bus handlers, each with their own routines and specific code. Additionally, PCI IRQ Routing and other PCI bus internals are handled directly by the HAL -- on the ACPI HAL, the PCI Bus support is implemented through a "Fake"/static bus handler, just to keep the functions shared. On ReactOS, both the ACPI and non-ACPI HAL were currently using a mix of both HAL bus handling types, mostly implemented the "ACPI way" (with a fake PCI bus handler and such).
As a result, none of the Hal*Bus HALDISPATCH routines were implemented, which bus drivers expect to find when they're not on ACPI systems (ReactOS today). eVb's new PCI driver was crashing, for example.
Furthermore, legacy systems suffer, because the ACPI HAL Bus routines (that we currently have) expect perfect ACPI-style-compliant systems, not the legacy crap from the early 90ies. This works fine in VMs and new hardware, but old hardware is left behind.
This patch basically corrects the first part of the problem, by making the bus handling support separate between ACPI and non-ACPI HALs. For now, the code remains 100% the same in functionality between both.
However, I have started adding the first few elements:
[HAL]: Implement HalRegisterBusHandler HALDISPATCH routine.
[HAL]: On legacy HALs, register the CMOS, ISA, SYSTEM handlers.
[HAL]: Add cmosbus.c. Stub all bus-specific bus handler routines in the xxxbus.c files.
No real functionality change occurs with this patch, yet.
svn path=/trunk/; revision=47649
2010-06-07 01:09:41 +00:00
|
|
|
/* GLOBALS ********************************************************************/
|
2001-08-21 20:18:27 +00:00
|
|
|
|
2010-06-07 03:23:48 +00:00
|
|
|
extern KSPIN_LOCK HalpPCIConfigLock;
|
|
|
|
ULONG HalpPciIrqMask;
|
|
|
|
|
[HAL]: Bus support in the HAL actually creates a further wedge between the different x86 HALs: There are actually two dinstinct implementations. On the ACPI HAL, the system is assumed not to have things like special ISA, MCA, EISA buses, and a PCI driver is used in combination with the ACPI Interface for PCI Bus support. On non-ACPI systems, the legacy "Bus Handler" library is used, and the HAL provides a core set of CMOS, EISA, ISA, MCA and PCI bus handlers, each with their own routines and specific code. Additionally, PCI IRQ Routing and other PCI bus internals are handled directly by the HAL -- on the ACPI HAL, the PCI Bus support is implemented through a "Fake"/static bus handler, just to keep the functions shared. On ReactOS, both the ACPI and non-ACPI HAL were currently using a mix of both HAL bus handling types, mostly implemented the "ACPI way" (with a fake PCI bus handler and such).
As a result, none of the Hal*Bus HALDISPATCH routines were implemented, which bus drivers expect to find when they're not on ACPI systems (ReactOS today). eVb's new PCI driver was crashing, for example.
Furthermore, legacy systems suffer, because the ACPI HAL Bus routines (that we currently have) expect perfect ACPI-style-compliant systems, not the legacy crap from the early 90ies. This works fine in VMs and new hardware, but old hardware is left behind.
This patch basically corrects the first part of the problem, by making the bus handling support separate between ACPI and non-ACPI HALs. For now, the code remains 100% the same in functionality between both.
However, I have started adding the first few elements:
[HAL]: Implement HalRegisterBusHandler HALDISPATCH routine.
[HAL]: On legacy HALs, register the CMOS, ISA, SYSTEM handlers.
[HAL]: Add cmosbus.c. Stub all bus-specific bus handler routines in the xxxbus.c files.
No real functionality change occurs with this patch, yet.
svn path=/trunk/; revision=47649
2010-06-07 01:09:41 +00:00
|
|
|
/* PRIVATE FUNCTIONS **********************************************************/
|
2001-08-21 20:18:27 +00:00
|
|
|
|
[HAL]: Bus support in the HAL actually creates a further wedge between the different x86 HALs: There are actually two dinstinct implementations. On the ACPI HAL, the system is assumed not to have things like special ISA, MCA, EISA buses, and a PCI driver is used in combination with the ACPI Interface for PCI Bus support. On non-ACPI systems, the legacy "Bus Handler" library is used, and the HAL provides a core set of CMOS, EISA, ISA, MCA and PCI bus handlers, each with their own routines and specific code. Additionally, PCI IRQ Routing and other PCI bus internals are handled directly by the HAL -- on the ACPI HAL, the PCI Bus support is implemented through a "Fake"/static bus handler, just to keep the functions shared. On ReactOS, both the ACPI and non-ACPI HAL were currently using a mix of both HAL bus handling types, mostly implemented the "ACPI way" (with a fake PCI bus handler and such).
As a result, none of the Hal*Bus HALDISPATCH routines were implemented, which bus drivers expect to find when they're not on ACPI systems (ReactOS today). eVb's new PCI driver was crashing, for example.
Furthermore, legacy systems suffer, because the ACPI HAL Bus routines (that we currently have) expect perfect ACPI-style-compliant systems, not the legacy crap from the early 90ies. This works fine in VMs and new hardware, but old hardware is left behind.
This patch basically corrects the first part of the problem, by making the bus handling support separate between ACPI and non-ACPI HALs. For now, the code remains 100% the same in functionality between both.
However, I have started adding the first few elements:
[HAL]: Implement HalRegisterBusHandler HALDISPATCH routine.
[HAL]: On legacy HALs, register the CMOS, ISA, SYSTEM handlers.
[HAL]: Add cmosbus.c. Stub all bus-specific bus handler routines in the xxxbus.c files.
No real functionality change occurs with this patch, yet.
svn path=/trunk/; revision=47649
2010-06-07 01:09:41 +00:00
|
|
|
PBUS_HANDLER
|
|
|
|
NTAPI
|
|
|
|
HalpAllocateBusHandler(IN INTERFACE_TYPE InterfaceType,
|
|
|
|
IN BUS_DATA_TYPE BusDataType,
|
|
|
|
IN ULONG BusNumber,
|
|
|
|
IN INTERFACE_TYPE ParentBusInterfaceType,
|
|
|
|
IN ULONG ParentBusNumber,
|
|
|
|
IN ULONG BusSpecificData)
|
|
|
|
{
|
|
|
|
PBUS_HANDLER Bus;
|
|
|
|
|
|
|
|
/* Register the bus handler */
|
|
|
|
HalRegisterBusHandler(InterfaceType,
|
|
|
|
BusDataType,
|
|
|
|
BusNumber,
|
|
|
|
ParentBusInterfaceType,
|
|
|
|
ParentBusNumber,
|
|
|
|
BusSpecificData,
|
|
|
|
NULL,
|
|
|
|
&Bus);
|
|
|
|
if (!Bus) return NULL;
|
|
|
|
|
|
|
|
/* Check for a valid interface */
|
|
|
|
if (InterfaceType != InterfaceTypeUndefined)
|
|
|
|
{
|
|
|
|
/* Allocate address ranges and zero them out */
|
|
|
|
Bus->BusAddresses = ExAllocatePoolWithTag(NonPagedPool,
|
|
|
|
sizeof(SUPPORTED_RANGES),
|
|
|
|
' laH');
|
|
|
|
RtlZeroMemory(Bus->BusAddresses, sizeof(SUPPORTED_RANGES));
|
|
|
|
|
|
|
|
/* Build the data structure */
|
|
|
|
Bus->BusAddresses->Version = HAL_SUPPORTED_RANGE_VERSION;
|
|
|
|
Bus->BusAddresses->Dma.Limit = 7;
|
|
|
|
Bus->BusAddresses->Memory.Limit = 0xFFFFFFFF;
|
|
|
|
Bus->BusAddresses->IO.Limit = 0xFFFF;
|
|
|
|
Bus->BusAddresses->IO.SystemAddressSpace = 1;
|
|
|
|
Bus->BusAddresses->PrefetchMemory.Base = 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Return the bus address */
|
|
|
|
return Bus;
|
|
|
|
}
|
|
|
|
|
|
|
|
VOID
|
|
|
|
NTAPI
|
|
|
|
HalpRegisterInternalBusHandlers(VOID)
|
|
|
|
{
|
|
|
|
PBUS_HANDLER Bus;
|
|
|
|
|
|
|
|
/* Only do processor 1 */
|
|
|
|
if (KeGetCurrentPrcb()->Number) return;
|
|
|
|
|
|
|
|
/* Register root support */
|
|
|
|
HalpInitBusHandler();
|
|
|
|
|
|
|
|
/* Allocate the system bus */
|
|
|
|
Bus = HalpAllocateBusHandler(Internal,
|
|
|
|
ConfigurationSpaceUndefined,
|
|
|
|
0,
|
|
|
|
InterfaceTypeUndefined,
|
|
|
|
0,
|
|
|
|
0);
|
|
|
|
DPRINT1("Registering Internal Bus: %p\n", Bus);
|
|
|
|
if (Bus)
|
|
|
|
{
|
|
|
|
/* Set it up */
|
|
|
|
Bus->GetInterruptVector = HalpGetSystemInterruptVector;
|
|
|
|
Bus->TranslateBusAddress = HalpTranslateSystemBusAddress;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Allocate the CMOS bus */
|
|
|
|
Bus = HalpAllocateBusHandler(InterfaceTypeUndefined,
|
|
|
|
Cmos,
|
|
|
|
0,
|
|
|
|
InterfaceTypeUndefined,
|
|
|
|
0,
|
|
|
|
0);
|
|
|
|
DPRINT1("Registering CMOS Bus: %p\n", Bus);
|
|
|
|
if (Bus)
|
|
|
|
{
|
|
|
|
/* Set it up */
|
|
|
|
Bus->GetBusData = HalpcGetCmosData;
|
|
|
|
Bus->SetBusData = HalpcSetCmosData;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Allocate the CMOS bus */
|
|
|
|
Bus = HalpAllocateBusHandler(InterfaceTypeUndefined,
|
|
|
|
Cmos,
|
|
|
|
1,
|
|
|
|
InterfaceTypeUndefined,
|
|
|
|
0,
|
|
|
|
0);
|
|
|
|
DPRINT1("Registering CMOS Bus: %p\n", Bus);
|
|
|
|
if (Bus)
|
|
|
|
{
|
|
|
|
/* Set it up */
|
|
|
|
Bus->GetBusData = HalpcGetCmosData;
|
|
|
|
Bus->SetBusData = HalpcSetCmosData;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Allocate ISA bus */
|
|
|
|
Bus = HalpAllocateBusHandler(Isa,
|
|
|
|
ConfigurationSpaceUndefined,
|
|
|
|
0,
|
|
|
|
Internal,
|
|
|
|
0,
|
|
|
|
0);
|
|
|
|
DPRINT1("Registering ISA Bus: %p\n", Bus);
|
|
|
|
if (Bus)
|
|
|
|
{
|
|
|
|
/* Set it up */
|
|
|
|
Bus->GetBusData = HalpNoBusData;
|
|
|
|
Bus->BusAddresses->Memory.Limit = 0xFFFFFF;
|
|
|
|
Bus->TranslateBusAddress = HalpTranslateIsaBusAddress;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* No support for EISA or MCA */
|
|
|
|
ASSERT(HalpBusType == MACHINE_TYPE_ISA);
|
|
|
|
}
|
|
|
|
|
2010-06-07 03:23:48 +00:00
|
|
|
#ifndef _MINIHAL_
|
|
|
|
NTSTATUS
|
|
|
|
NTAPI
|
|
|
|
HalpMarkChipsetDecode(BOOLEAN OverrideEnable)
|
|
|
|
{
|
|
|
|
NTSTATUS Status;
|
|
|
|
UNICODE_STRING KeyString;
|
|
|
|
ULONG Data = OverrideEnable;
|
|
|
|
HANDLE KeyHandle, Handle;
|
|
|
|
|
|
|
|
/* Open CCS key */
|
|
|
|
RtlInitUnicodeString(&KeyString,
|
|
|
|
L"\\REGISTRY\\MACHINE\\SYSTEM\\CURRENTCONTROLSET");
|
|
|
|
Status = HalpOpenRegistryKey(&Handle, 0, &KeyString, KEY_ALL_ACCESS, FALSE);
|
|
|
|
if (NT_SUCCESS(Status))
|
|
|
|
{
|
|
|
|
/* Open PNP Bios key */
|
|
|
|
RtlInitUnicodeString(&KeyString, L"Control\\Biosinfo\\PNPBios");
|
|
|
|
Status = HalpOpenRegistryKey(&KeyHandle,
|
|
|
|
Handle,
|
|
|
|
&KeyString,
|
|
|
|
KEY_ALL_ACCESS,
|
|
|
|
TRUE);
|
|
|
|
|
|
|
|
/* Close root key */
|
|
|
|
ZwClose(Handle);
|
|
|
|
|
|
|
|
/* Check if PNP BIOS key exists */
|
|
|
|
if (NT_SUCCESS(Status))
|
|
|
|
{
|
|
|
|
/* Set the override value */
|
|
|
|
RtlInitUnicodeString(&KeyString, L"FullDecodeChipsetOverride");
|
|
|
|
Status = ZwSetValueKey(KeyHandle,
|
|
|
|
&KeyString,
|
|
|
|
0,
|
|
|
|
REG_DWORD,
|
|
|
|
&Data,
|
|
|
|
sizeof(Data));
|
|
|
|
|
|
|
|
/* Close subkey */
|
|
|
|
ZwClose(KeyHandle);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Return status */
|
|
|
|
return Status;
|
|
|
|
}
|
|
|
|
|
|
|
|
PBUS_HANDLER
|
|
|
|
NTAPI
|
|
|
|
HalpAllocateAndInitPciBusHandler(IN ULONG PciType,
|
|
|
|
IN ULONG BusNo,
|
|
|
|
IN BOOLEAN TestAllocation)
|
|
|
|
{
|
|
|
|
PBUS_HANDLER Bus;
|
|
|
|
PPCIPBUSDATA BusData;
|
|
|
|
|
|
|
|
/* Allocate the bus handler */
|
|
|
|
Bus = HalpAllocateBusHandler(PCIBus,
|
|
|
|
PCIConfiguration,
|
|
|
|
BusNo,
|
|
|
|
Internal,
|
|
|
|
0,
|
|
|
|
sizeof(PCIPBUSDATA));
|
|
|
|
|
|
|
|
/* Set it up */
|
|
|
|
Bus->GetBusData = (PGETSETBUSDATA)HalpGetPCIData;
|
|
|
|
Bus->SetBusData = (PGETSETBUSDATA)HalpSetPCIData;
|
|
|
|
Bus->GetInterruptVector = (PGETINTERRUPTVECTOR)HalpGetPCIIntOnISABus;
|
|
|
|
Bus->AdjustResourceList = (PADJUSTRESOURCELIST)HalpAdjustPCIResourceList;
|
|
|
|
Bus->AssignSlotResources = (PASSIGNSLOTRESOURCES)HalpAssignPCISlotResources;
|
|
|
|
Bus->BusAddresses->Dma.Limit = 0;
|
|
|
|
|
|
|
|
/* Get our custom bus data */
|
|
|
|
BusData = (PPCIPBUSDATA)Bus->BusData;
|
|
|
|
|
|
|
|
/* Setup custom bus data */
|
|
|
|
BusData->CommonData.Tag = PCI_DATA_TAG;
|
|
|
|
BusData->CommonData.Version = PCI_DATA_VERSION;
|
|
|
|
BusData->CommonData.ReadConfig = (PciReadWriteConfig)HalpReadPCIConfig;
|
|
|
|
BusData->CommonData.WriteConfig = (PciReadWriteConfig)HalpWritePCIConfig;
|
|
|
|
BusData->CommonData.Pin2Line = (PciPin2Line)HalpPCIPin2ISALine;
|
|
|
|
BusData->CommonData.Line2Pin = (PciLine2Pin)HalpPCIISALine2Pin;
|
|
|
|
BusData->MaxDevice = PCI_MAX_DEVICES;
|
|
|
|
BusData->GetIrqRange = (PciIrqRange)HalpGetISAFixedPCIIrq;
|
|
|
|
|
|
|
|
/* Initialize the bitmap */
|
|
|
|
RtlInitializeBitMap(&BusData->DeviceConfigured, BusData->ConfiguredBits, 256);
|
|
|
|
|
|
|
|
/* Check the type of PCI bus */
|
|
|
|
switch (PciType)
|
|
|
|
{
|
|
|
|
/* Type 1 PCI Bus */
|
|
|
|
case 1:
|
|
|
|
|
|
|
|
/* Copy the Type 1 handler data */
|
|
|
|
RtlCopyMemory(&PCIConfigHandler,
|
|
|
|
&PCIConfigHandlerType1,
|
|
|
|
sizeof(PCIConfigHandler));
|
|
|
|
|
|
|
|
/* Set correct I/O Ports */
|
|
|
|
BusData->Config.Type1.Address = PCI_TYPE1_ADDRESS_PORT;
|
|
|
|
BusData->Config.Type1.Data = PCI_TYPE1_DATA_PORT;
|
|
|
|
break;
|
|
|
|
|
|
|
|
/* Type 2 PCI Bus */
|
|
|
|
case 2:
|
|
|
|
|
|
|
|
/* Copy the Type 1 handler data */
|
|
|
|
RtlCopyMemory(&PCIConfigHandler,
|
|
|
|
&PCIConfigHandlerType2,
|
|
|
|
sizeof (PCIConfigHandler));
|
|
|
|
|
|
|
|
/* Set correct I/O Ports */
|
|
|
|
BusData->Config.Type2.CSE = PCI_TYPE2_CSE_PORT;
|
|
|
|
BusData->Config.Type2.Forward = PCI_TYPE2_FORWARD_PORT;
|
|
|
|
BusData->Config.Type2.Base = PCI_TYPE2_ADDRESS_BASE;
|
|
|
|
|
|
|
|
/* Only 16 devices supported, not 32 */
|
|
|
|
BusData->MaxDevice = 16;
|
|
|
|
break;
|
|
|
|
|
|
|
|
default:
|
|
|
|
|
|
|
|
/* Invalid type */
|
|
|
|
DbgPrint("HAL: Unnkown PCI type\n");
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Return the bus handler */
|
|
|
|
return Bus;
|
|
|
|
}
|
|
|
|
|
|
|
|
BOOLEAN
|
|
|
|
NTAPI
|
|
|
|
HalpIsValidPCIDevice(IN PBUS_HANDLER BusHandler,
|
|
|
|
IN PCI_SLOT_NUMBER Slot)
|
|
|
|
{
|
|
|
|
UCHAR DataBuffer[PCI_COMMON_HDR_LENGTH];
|
|
|
|
PPCI_COMMON_CONFIG PciHeader = (PVOID)DataBuffer;
|
|
|
|
ULONG i;
|
|
|
|
ULONG_PTR Address;
|
|
|
|
|
|
|
|
/* Read the PCI header */
|
|
|
|
HalpReadPCIConfig(BusHandler, Slot, PciHeader, 0, PCI_COMMON_HDR_LENGTH);
|
|
|
|
|
|
|
|
/* Make sure it's a valid device */
|
|
|
|
if ((PciHeader->VendorID == PCI_INVALID_VENDORID) ||
|
|
|
|
(PCI_CONFIGURATION_TYPE(PciHeader) != PCI_DEVICE_TYPE))
|
|
|
|
{
|
|
|
|
/* Bail out */
|
|
|
|
return FALSE;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Make sure interrupt numbers make sense */
|
|
|
|
if (((PciHeader->u.type0.InterruptPin) &&
|
|
|
|
(PciHeader->u.type0.InterruptPin > 4)) ||
|
|
|
|
(PciHeader->u.type0.InterruptLine & 0x70))
|
|
|
|
{
|
|
|
|
/* Bail out */
|
|
|
|
return FALSE;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Now scan PCI BARs */
|
|
|
|
for (i = 0; i < PCI_TYPE0_ADDRESSES; i++)
|
|
|
|
{
|
|
|
|
/* Check what kind of address it is */
|
|
|
|
Address = PciHeader->u.type0.BaseAddresses[i];
|
|
|
|
if (Address & PCI_ADDRESS_IO_SPACE)
|
|
|
|
{
|
|
|
|
/* Highest I/O port is 65535 */
|
|
|
|
if (Address > 0xFFFF) return FALSE;
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
/* MMIO should be higher than 0x80000 */
|
|
|
|
if ((Address > 0xF) && (Address < 0x80000)) return FALSE;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Is this a 64-bit address? */
|
|
|
|
if (!(Address & PCI_ADDRESS_IO_SPACE) &&
|
|
|
|
((Address & PCI_ADDRESS_MEMORY_TYPE_MASK) == PCI_TYPE_64BIT))
|
|
|
|
{
|
|
|
|
/* Check the next-next entry, since this one 64-bits wide */
|
|
|
|
i++;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Header, interrupt and address data all make sense */
|
|
|
|
return TRUE;
|
|
|
|
}
|
|
|
|
|
|
|
|
static BOOLEAN WarningsGiven[5];
|
|
|
|
|
|
|
|
NTSTATUS
|
|
|
|
NTAPI
|
|
|
|
HalpGetChipHacks(IN USHORT VendorId,
|
|
|
|
IN USHORT DeviceId,
|
|
|
|
IN UCHAR RevisionId,
|
|
|
|
IN PULONG HackFlags)
|
|
|
|
{
|
|
|
|
/* Not yet implemented */
|
|
|
|
if (!WarningsGiven[0]++) DbgPrint("HAL: Not checking for PCI Chipset Hacks. Your hardware may malfunction!\n");
|
|
|
|
*HackFlags = 0;
|
|
|
|
return STATUS_UNSUCCESSFUL;
|
|
|
|
}
|
|
|
|
|
|
|
|
BOOLEAN
|
|
|
|
NTAPI
|
|
|
|
HalpIsRecognizedCard(IN PPCI_REGISTRY_INFO_INTERNAL PciRegistryInfo,
|
|
|
|
IN PPCI_COMMON_CONFIG PciData,
|
|
|
|
IN ULONG Flags)
|
|
|
|
{
|
2010-06-07 15:09:44 +00:00
|
|
|
ULONG ElementCount, i;
|
|
|
|
PPCI_CARD_DESCRIPTOR CardDescriptor;
|
|
|
|
|
|
|
|
/* How many PCI Cards that we know about? */
|
|
|
|
ElementCount = PciRegistryInfo->ElementCount;
|
|
|
|
if (!ElementCount) return FALSE;
|
|
|
|
|
|
|
|
/* Loop all descriptors */
|
|
|
|
CardDescriptor = &PciRegistryInfo->CardList[0];
|
|
|
|
for (i = 0; i < ElementCount; i++, CardDescriptor++)
|
|
|
|
{
|
|
|
|
/* Check for flag match */
|
|
|
|
if (CardDescriptor->Flags != Flags) continue;
|
|
|
|
|
|
|
|
/* Check for VID-PID match */
|
|
|
|
if ((CardDescriptor->VendorID != PciData->VendorID) ||
|
|
|
|
(CardDescriptor->DeviceID != PciData->DeviceID))
|
|
|
|
{
|
|
|
|
/* Skip */
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Check for revision match, if requested */
|
|
|
|
if ((CardDescriptor->Flags & HALP_CHECK_CARD_REVISION_ID) &&
|
|
|
|
(CardDescriptor->RevisionID != PciData->RevisionID))
|
|
|
|
{
|
|
|
|
/* Skip */
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Check what kind of device this is */
|
|
|
|
switch (PCI_CONFIGURATION_TYPE(PciData))
|
|
|
|
{
|
|
|
|
/* CardBUS Bridge */
|
|
|
|
case PCI_CARDBUS_BRIDGE_TYPE:
|
|
|
|
|
|
|
|
/* This means the real device header is in the device-specific data */
|
|
|
|
PciData = (PPCI_COMMON_CONFIG)PciData->DeviceSpecific;
|
|
|
|
|
|
|
|
/* Normal PCI device */
|
|
|
|
case PCI_DEVICE_TYPE:
|
|
|
|
|
|
|
|
/* Check for subvendor match, if requested */
|
|
|
|
if ((CardDescriptor->Flags & HALP_CHECK_CARD_SUBVENDOR_ID) &&
|
|
|
|
(CardDescriptor->SubsystemVendorID != PciData->u.type0.SubVendorID))
|
|
|
|
{
|
|
|
|
/* Skip */
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Check for subsystem match, if requested */
|
|
|
|
if ((CardDescriptor->Flags & HALP_CHECK_CARD_SUBSYSTEM_ID) &&
|
|
|
|
(CardDescriptor->SubsystemID != PciData->u.type0.SubSystemID))
|
|
|
|
{
|
|
|
|
/* Skip */
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* You made it! */
|
|
|
|
return TRUE;
|
|
|
|
|
|
|
|
/* PCI Bridge -- don't bother */
|
|
|
|
case PCI_BRIDGE_TYPE:
|
|
|
|
default:
|
|
|
|
|
|
|
|
/* Recognize it */
|
|
|
|
return TRUE;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/* This means the card isn't recognized */
|
2010-06-07 03:23:48 +00:00
|
|
|
return FALSE;
|
|
|
|
}
|
|
|
|
|
|
|
|
BOOLEAN
|
|
|
|
NTAPI
|
|
|
|
HalpIsIdeDevice(IN PPCI_COMMON_CONFIG PciData)
|
|
|
|
{
|
2010-06-07 15:02:49 +00:00
|
|
|
/* Simple test first */
|
|
|
|
if ((PciData->BaseClass == PCI_CLASS_MASS_STORAGE_CTLR) &&
|
|
|
|
(PciData->SubClass == PCI_SUBCLASS_MSC_IDE_CTLR))
|
|
|
|
{
|
|
|
|
/* The device is nice enough to admit it */
|
|
|
|
return TRUE;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Symphony 82C101 */
|
|
|
|
if (PciData->VendorID == 0x1C1C) return TRUE;
|
|
|
|
|
|
|
|
/* ALi MS4803 or M5219 */
|
|
|
|
if ((PciData->VendorID == 0x10B9) &&
|
|
|
|
((PciData->DeviceID == 0x5215) || (PciData->DeviceID == 0x5219)))
|
|
|
|
{
|
|
|
|
return TRUE;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Appian Technology */
|
|
|
|
if ((PciData->VendorID == 0x1097) && (PciData->DeviceID == 0x38)) return TRUE;
|
|
|
|
|
|
|
|
/* Compaq Triflex Dual EIDE Controller */
|
|
|
|
if ((PciData->VendorID == 0xE11) && (PciData->DeviceID == 0xAE33)) return TRUE;
|
|
|
|
|
|
|
|
/* Micron PC Tech RZ1000 */
|
|
|
|
if ((PciData->VendorID == 0x1042) && (PciData->DeviceID == 0x1000)) return TRUE;
|
|
|
|
|
|
|
|
/* SiS 85C601 or 5513 [IDE] */
|
|
|
|
if ((PciData->VendorID == 0x1039) &&
|
|
|
|
((PciData->DeviceID == 0x601) || (PciData->DeviceID == 0x5513)))
|
|
|
|
{
|
|
|
|
return TRUE;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Symphony Labs W83769F */
|
|
|
|
if ((PciData->VendorID == 0x10AD) &&
|
|
|
|
((PciData->DeviceID == 0x1) || (PciData->DeviceID == 0x150)))
|
|
|
|
{
|
|
|
|
return TRUE;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* UMC UM8673F */
|
|
|
|
if ((PciData->VendorID == 0x1060) && (PciData->DeviceID == 0x101)) return TRUE;
|
|
|
|
|
|
|
|
/* You've survived */
|
|
|
|
return FALSE;
|
2010-06-07 03:23:48 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
BOOLEAN
|
|
|
|
NTAPI
|
|
|
|
HalpGetPciBridgeConfig(IN ULONG PciType,
|
|
|
|
IN PUCHAR MaxPciBus)
|
|
|
|
{
|
|
|
|
/* Not yet implemented */
|
|
|
|
if (!WarningsGiven[3]++) DbgPrint("HAL: Not checking for PCI-to-PCI Bridges. Your hardware may malfunction!\n");
|
|
|
|
return FALSE;
|
|
|
|
}
|
|
|
|
|
|
|
|
VOID
|
|
|
|
NTAPI
|
|
|
|
HalpFixupPciSupportedRanges(IN ULONG MaxBuses)
|
|
|
|
{
|
|
|
|
/* Not yet implemented */
|
|
|
|
if (!WarningsGiven[4]++) DbgPrint("HAL: Not adjusting Bridge-to-Child PCI Address Ranges. Your hardware may malfunction!\n");
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
|
[HAL]: Bus support in the HAL actually creates a further wedge between the different x86 HALs: There are actually two dinstinct implementations. On the ACPI HAL, the system is assumed not to have things like special ISA, MCA, EISA buses, and a PCI driver is used in combination with the ACPI Interface for PCI Bus support. On non-ACPI systems, the legacy "Bus Handler" library is used, and the HAL provides a core set of CMOS, EISA, ISA, MCA and PCI bus handlers, each with their own routines and specific code. Additionally, PCI IRQ Routing and other PCI bus internals are handled directly by the HAL -- on the ACPI HAL, the PCI Bus support is implemented through a "Fake"/static bus handler, just to keep the functions shared. On ReactOS, both the ACPI and non-ACPI HAL were currently using a mix of both HAL bus handling types, mostly implemented the "ACPI way" (with a fake PCI bus handler and such).
As a result, none of the Hal*Bus HALDISPATCH routines were implemented, which bus drivers expect to find when they're not on ACPI systems (ReactOS today). eVb's new PCI driver was crashing, for example.
Furthermore, legacy systems suffer, because the ACPI HAL Bus routines (that we currently have) expect perfect ACPI-style-compliant systems, not the legacy crap from the early 90ies. This works fine in VMs and new hardware, but old hardware is left behind.
This patch basically corrects the first part of the problem, by making the bus handling support separate between ACPI and non-ACPI HALs. For now, the code remains 100% the same in functionality between both.
However, I have started adding the first few elements:
[HAL]: Implement HalRegisterBusHandler HALDISPATCH routine.
[HAL]: On legacy HALs, register the CMOS, ISA, SYSTEM handlers.
[HAL]: Add cmosbus.c. Stub all bus-specific bus handler routines in the xxxbus.c files.
No real functionality change occurs with this patch, yet.
svn path=/trunk/; revision=47649
2010-06-07 01:09:41 +00:00
|
|
|
VOID
|
|
|
|
NTAPI
|
|
|
|
HalpInitializePciBus(VOID)
|
|
|
|
{
|
2010-06-07 03:23:48 +00:00
|
|
|
#ifndef _MINIHAL_
|
|
|
|
PPCI_REGISTRY_INFO_INTERNAL PciRegistryInfo;
|
|
|
|
UCHAR PciType;
|
|
|
|
PCI_SLOT_NUMBER PciSlot;
|
|
|
|
ULONG i, j, k;
|
|
|
|
UCHAR DataBuffer[PCI_COMMON_HDR_LENGTH];
|
|
|
|
PPCI_COMMON_CONFIG PciData = (PPCI_COMMON_CONFIG)DataBuffer;
|
|
|
|
PBUS_HANDLER BusHandler;
|
|
|
|
ULONG HackFlags;
|
|
|
|
BOOLEAN ExtendedAddressDecoding = FALSE;
|
[HAL]: Bus support in the HAL actually creates a further wedge between the different x86 HALs: There are actually two dinstinct implementations. On the ACPI HAL, the system is assumed not to have things like special ISA, MCA, EISA buses, and a PCI driver is used in combination with the ACPI Interface for PCI Bus support. On non-ACPI systems, the legacy "Bus Handler" library is used, and the HAL provides a core set of CMOS, EISA, ISA, MCA and PCI bus handlers, each with their own routines and specific code. Additionally, PCI IRQ Routing and other PCI bus internals are handled directly by the HAL -- on the ACPI HAL, the PCI Bus support is implemented through a "Fake"/static bus handler, just to keep the functions shared. On ReactOS, both the ACPI and non-ACPI HAL were currently using a mix of both HAL bus handling types, mostly implemented the "ACPI way" (with a fake PCI bus handler and such).
As a result, none of the Hal*Bus HALDISPATCH routines were implemented, which bus drivers expect to find when they're not on ACPI systems (ReactOS today). eVb's new PCI driver was crashing, for example.
Furthermore, legacy systems suffer, because the ACPI HAL Bus routines (that we currently have) expect perfect ACPI-style-compliant systems, not the legacy crap from the early 90ies. This works fine in VMs and new hardware, but old hardware is left behind.
This patch basically corrects the first part of the problem, by making the bus handling support separate between ACPI and non-ACPI HALs. For now, the code remains 100% the same in functionality between both.
However, I have started adding the first few elements:
[HAL]: Implement HalRegisterBusHandler HALDISPATCH routine.
[HAL]: On legacy HALs, register the CMOS, ISA, SYSTEM handlers.
[HAL]: Add cmosbus.c. Stub all bus-specific bus handler routines in the xxxbus.c files.
No real functionality change occurs with this patch, yet.
svn path=/trunk/; revision=47649
2010-06-07 01:09:41 +00:00
|
|
|
|
2010-06-07 03:23:48 +00:00
|
|
|
/* Query registry information */
|
|
|
|
PciRegistryInfo = HalpQueryPciRegistryInfo();
|
|
|
|
if (!PciRegistryInfo) return;
|
[HAL]: Bus support in the HAL actually creates a further wedge between the different x86 HALs: There are actually two dinstinct implementations. On the ACPI HAL, the system is assumed not to have things like special ISA, MCA, EISA buses, and a PCI driver is used in combination with the ACPI Interface for PCI Bus support. On non-ACPI systems, the legacy "Bus Handler" library is used, and the HAL provides a core set of CMOS, EISA, ISA, MCA and PCI bus handlers, each with their own routines and specific code. Additionally, PCI IRQ Routing and other PCI bus internals are handled directly by the HAL -- on the ACPI HAL, the PCI Bus support is implemented through a "Fake"/static bus handler, just to keep the functions shared. On ReactOS, both the ACPI and non-ACPI HAL were currently using a mix of both HAL bus handling types, mostly implemented the "ACPI way" (with a fake PCI bus handler and such).
As a result, none of the Hal*Bus HALDISPATCH routines were implemented, which bus drivers expect to find when they're not on ACPI systems (ReactOS today). eVb's new PCI driver was crashing, for example.
Furthermore, legacy systems suffer, because the ACPI HAL Bus routines (that we currently have) expect perfect ACPI-style-compliant systems, not the legacy crap from the early 90ies. This works fine in VMs and new hardware, but old hardware is left behind.
This patch basically corrects the first part of the problem, by making the bus handling support separate between ACPI and non-ACPI HALs. For now, the code remains 100% the same in functionality between both.
However, I have started adding the first few elements:
[HAL]: Implement HalRegisterBusHandler HALDISPATCH routine.
[HAL]: On legacy HALs, register the CMOS, ISA, SYSTEM handlers.
[HAL]: Add cmosbus.c. Stub all bus-specific bus handler routines in the xxxbus.c files.
No real functionality change occurs with this patch, yet.
svn path=/trunk/; revision=47649
2010-06-07 01:09:41 +00:00
|
|
|
|
2010-06-07 03:23:48 +00:00
|
|
|
/* Initialize the PCI configuration lock */
|
|
|
|
KeInitializeSpinLock(&HalpPCIConfigLock);
|
[HAL]: Bus support in the HAL actually creates a further wedge between the different x86 HALs: There are actually two dinstinct implementations. On the ACPI HAL, the system is assumed not to have things like special ISA, MCA, EISA buses, and a PCI driver is used in combination with the ACPI Interface for PCI Bus support. On non-ACPI systems, the legacy "Bus Handler" library is used, and the HAL provides a core set of CMOS, EISA, ISA, MCA and PCI bus handlers, each with their own routines and specific code. Additionally, PCI IRQ Routing and other PCI bus internals are handled directly by the HAL -- on the ACPI HAL, the PCI Bus support is implemented through a "Fake"/static bus handler, just to keep the functions shared. On ReactOS, both the ACPI and non-ACPI HAL were currently using a mix of both HAL bus handling types, mostly implemented the "ACPI way" (with a fake PCI bus handler and such).
As a result, none of the Hal*Bus HALDISPATCH routines were implemented, which bus drivers expect to find when they're not on ACPI systems (ReactOS today). eVb's new PCI driver was crashing, for example.
Furthermore, legacy systems suffer, because the ACPI HAL Bus routines (that we currently have) expect perfect ACPI-style-compliant systems, not the legacy crap from the early 90ies. This works fine in VMs and new hardware, but old hardware is left behind.
This patch basically corrects the first part of the problem, by making the bus handling support separate between ACPI and non-ACPI HALs. For now, the code remains 100% the same in functionality between both.
However, I have started adding the first few elements:
[HAL]: Implement HalRegisterBusHandler HALDISPATCH routine.
[HAL]: On legacy HALs, register the CMOS, ISA, SYSTEM handlers.
[HAL]: Add cmosbus.c. Stub all bus-specific bus handler routines in the xxxbus.c files.
No real functionality change occurs with this patch, yet.
svn path=/trunk/; revision=47649
2010-06-07 01:09:41 +00:00
|
|
|
|
2010-06-07 03:23:48 +00:00
|
|
|
/* Get the type and free the info structure */
|
|
|
|
PciType = PciRegistryInfo->HardwareMechanism & 0xF;
|
|
|
|
|
|
|
|
/* Check if this is a type 2 PCI bus with at least one bus */
|
|
|
|
if ((PciRegistryInfo->NoBuses) && (PciType == 2))
|
|
|
|
{
|
|
|
|
/* Setup the PCI slot */
|
|
|
|
PciSlot.u.bits.Reserved = 0;
|
|
|
|
PciSlot.u.bits.FunctionNumber = 0;
|
|
|
|
|
|
|
|
/* Loop all slots */
|
|
|
|
for (i = 0; i < 32; i++)
|
|
|
|
{
|
|
|
|
/* Try to setup a Type 2 PCI slot */
|
|
|
|
PciType = 2;
|
|
|
|
BusHandler = HalpAllocateAndInitPciBusHandler(2, 0, TRUE);
|
|
|
|
if (!BusHandler) break;
|
|
|
|
|
|
|
|
/* Now check if it's valid */
|
|
|
|
if (HalpIsValidPCIDevice(BusHandler, PciSlot)) break;
|
|
|
|
|
|
|
|
/* Heh, the BIOS lied... try Type 1 */
|
|
|
|
PciType = 1;
|
|
|
|
BusHandler = HalpAllocateAndInitPciBusHandler(1, 0, TRUE);
|
|
|
|
if (!BusHandler) break;
|
|
|
|
|
|
|
|
/* Now check if it's valid */
|
|
|
|
if (HalpIsValidPCIDevice(BusHandler, PciSlot)) break;
|
|
|
|
|
|
|
|
/* Keep trying */
|
|
|
|
PciType = 2;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Now allocate the correct kind of handler */
|
|
|
|
HalpAllocateAndInitPciBusHandler(PciType, 0, FALSE);
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Okay, now loop all PCI bridges */
|
|
|
|
do
|
|
|
|
{
|
|
|
|
/* Loop all PCI buses */
|
|
|
|
for (i = 0; i < PciRegistryInfo->NoBuses; i++)
|
|
|
|
{
|
|
|
|
/* Check if we have a handler for it */
|
|
|
|
if (!HalHandlerForBus(PCIBus, i))
|
|
|
|
{
|
|
|
|
/* Allocate it */
|
|
|
|
HalpAllocateAndInitPciBusHandler(PciType, i, FALSE);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
/* Go to the next bridge */
|
|
|
|
} while (HalpGetPciBridgeConfig(PciType, &PciRegistryInfo->NoBuses));
|
|
|
|
|
|
|
|
/* Now build correct address range informaiton */
|
|
|
|
HalpFixupPciSupportedRanges(PciRegistryInfo->NoBuses);
|
|
|
|
|
|
|
|
/* Loop every bus */
|
|
|
|
PciSlot.u.bits.Reserved = 0;
|
|
|
|
for (i = 0; i < PciRegistryInfo->NoBuses; i++)
|
|
|
|
{
|
|
|
|
/* Get the bus handler */
|
|
|
|
BusHandler = HalHandlerForBus(PCIBus, i);
|
|
|
|
|
|
|
|
/* Loop every device */
|
|
|
|
for (j = 0; j < 32; j++)
|
|
|
|
{
|
|
|
|
/* Loop every function */
|
|
|
|
PciSlot.u.bits.DeviceNumber = j;
|
|
|
|
for (k = 0; k < 8; k++)
|
|
|
|
{
|
|
|
|
/* Build the final slot structure */
|
|
|
|
PciSlot.u.bits.FunctionNumber = k;
|
|
|
|
|
|
|
|
/* Read the configuration information */
|
|
|
|
HalpReadPCIConfig(BusHandler,
|
|
|
|
PciSlot,
|
|
|
|
PciData,
|
|
|
|
0,
|
|
|
|
PCI_COMMON_HDR_LENGTH);
|
|
|
|
|
|
|
|
/* Skip if this is an invalid function */
|
|
|
|
if (PciData->VendorID == PCI_INVALID_VENDORID) continue;
|
|
|
|
|
|
|
|
/* Check if this is a Cardbus bridge */
|
|
|
|
if (PCI_CONFIGURATION_TYPE(PciData) == PCI_CARDBUS_BRIDGE_TYPE)
|
|
|
|
{
|
|
|
|
/* Not supported */
|
|
|
|
DbgPrint("HAL: Your machine has a PCI Cardbus Bridge. This is not supported!\n");
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Check if this is a PCI device */
|
|
|
|
if (PCI_CONFIGURATION_TYPE(PciData) != PCI_BRIDGE_TYPE)
|
|
|
|
{
|
|
|
|
/* Check if it has an interrupt pin and line registered */
|
|
|
|
if ((PciData->u.type1.InterruptPin) &&
|
|
|
|
(PciData->u.type1.InterruptLine))
|
|
|
|
{
|
|
|
|
/* Check if this interrupt line is connected to the bus */
|
|
|
|
if (PciData->u.type1.InterruptLine < 16)
|
|
|
|
{
|
|
|
|
/* Is this an IDE device? */
|
|
|
|
DbgPrint("HAL: Found PCI device with IRQ line\n");
|
|
|
|
if (!HalpIsIdeDevice(PciData))
|
|
|
|
{
|
|
|
|
/* We'll mask out this interrupt then */
|
|
|
|
DbgPrint("HAL: Device is not an IDE Device. Should be masking IRQ %d! This is not supported!\n",
|
|
|
|
PciData->u.type1.InterruptLine);
|
|
|
|
HalpPciIrqMask |= (1 << PciData->u.type1.InterruptLine);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Check for broken Intel chips */
|
|
|
|
if (PciData->VendorID == 0x8086)
|
|
|
|
{
|
|
|
|
/* Check for broken 82830 PCI controller */
|
|
|
|
if ((PciData->DeviceID == 0x04A3) &&
|
|
|
|
(PciData->RevisionID < 0x11))
|
|
|
|
{
|
|
|
|
/* Skip */
|
|
|
|
DbgPrint("HAL: Your machine has a broken Intel 82430 PCI Controller. This is not supported!\n");
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Check for broken 82378 PCI-to-ISA Bridge */
|
|
|
|
if ((PciData->DeviceID == 0x0484) &&
|
|
|
|
(PciData->RevisionID <= 3))
|
|
|
|
{
|
|
|
|
/* Skip */
|
|
|
|
DbgPrint("HAL: Your machine has a broken Intel 82378 PCI-to-ISA Bridge. This is not supported!\n");
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Check for broken 82450 PCI Bridge */
|
|
|
|
if ((PciData->DeviceID == 0x84C4) &&
|
|
|
|
(PciData->RevisionID <= 4))
|
|
|
|
{
|
|
|
|
DbgPrint("HAL: Your machine has an Intel Orion 82450 PCI Bridge. This is not supported!\n");
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Do we know this card? */
|
|
|
|
if (!ExtendedAddressDecoding)
|
|
|
|
{
|
|
|
|
/* Check for it */
|
2010-06-07 15:09:44 +00:00
|
|
|
if (HalpIsRecognizedCard(PciRegistryInfo,
|
|
|
|
PciData,
|
|
|
|
HALP_CARD_FEATURE_FULL_DECODE))
|
2010-06-07 03:23:48 +00:00
|
|
|
{
|
|
|
|
/* We'll do chipset checks later */
|
|
|
|
DbgPrint("HAL: Recognized a PCI Card with Extended Address Decoding. This is not supported!\n");
|
|
|
|
ExtendedAddressDecoding = TRUE;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Check if this is a USB controller */
|
|
|
|
if ((PciData->BaseClass == PCI_CLASS_SERIAL_BUS_CTLR) &&
|
|
|
|
(PciData->SubClass == PCI_SUBCLASS_SB_USB))
|
|
|
|
{
|
|
|
|
/* Check if this is an OHCI controller */
|
|
|
|
if (PciData->ProgIf == 0x10)
|
|
|
|
{
|
|
|
|
DbgPrint("HAL: Your machine has an OHCI (USB) PCI Expansion Card. This is not supported!\n");
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Check for Intel UHCI controller */
|
|
|
|
if (PciData->VendorID == 0x8086)
|
|
|
|
{
|
|
|
|
DbgPrint("HAL: Your machine has an Intel UHCI (USB) Controller. This is not supported!\n");
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Check for VIA UHCI controller */
|
|
|
|
if (PciData->VendorID == 0x1106)
|
|
|
|
{
|
|
|
|
DbgPrint("HAL: Your machine has a VIA UHCI (USB) Controller. This is not supported!\n");
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Now check the registry for chipset hacks */
|
|
|
|
if (NT_SUCCESS(HalpGetChipHacks(PciData->VendorID,
|
|
|
|
PciData->DeviceID,
|
|
|
|
PciData->RevisionID,
|
|
|
|
&HackFlags)))
|
|
|
|
{
|
|
|
|
/* Check for hibernate-disable */
|
|
|
|
if (HackFlags & HAL_PCI_CHIP_HACK_DISABLE_HIBERNATE)
|
|
|
|
{
|
|
|
|
DbgPrint("HAL: Your machine has a broken PCI device which is incompatible with hibernation. This is not supported!\n");
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Check for USB controllers that generate SMIs */
|
|
|
|
if (HackFlags & HAL_PCI_CHIP_HACK_USB_SMI_DISABLE)
|
|
|
|
{
|
|
|
|
DbgPrint("HAL: Your machine has a USB controller which generates SMIs. This is not supported!\n");
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Initialize NMI Crash Flag */
|
|
|
|
HalpGetNMICrashFlag();
|
|
|
|
|
|
|
|
/* Free the registry data */
|
|
|
|
ExFreePool(PciRegistryInfo);
|
|
|
|
|
|
|
|
/* Tell PnP if this hard supports correct decoding */
|
|
|
|
HalpMarkChipsetDecode(ExtendedAddressDecoding);
|
|
|
|
DPRINT1("PCI BUS Setup complete\n");
|
|
|
|
#endif
|
[HAL]: Bus support in the HAL actually creates a further wedge between the different x86 HALs: There are actually two dinstinct implementations. On the ACPI HAL, the system is assumed not to have things like special ISA, MCA, EISA buses, and a PCI driver is used in combination with the ACPI Interface for PCI Bus support. On non-ACPI systems, the legacy "Bus Handler" library is used, and the HAL provides a core set of CMOS, EISA, ISA, MCA and PCI bus handlers, each with their own routines and specific code. Additionally, PCI IRQ Routing and other PCI bus internals are handled directly by the HAL -- on the ACPI HAL, the PCI Bus support is implemented through a "Fake"/static bus handler, just to keep the functions shared. On ReactOS, both the ACPI and non-ACPI HAL were currently using a mix of both HAL bus handling types, mostly implemented the "ACPI way" (with a fake PCI bus handler and such).
As a result, none of the Hal*Bus HALDISPATCH routines were implemented, which bus drivers expect to find when they're not on ACPI systems (ReactOS today). eVb's new PCI driver was crashing, for example.
Furthermore, legacy systems suffer, because the ACPI HAL Bus routines (that we currently have) expect perfect ACPI-style-compliant systems, not the legacy crap from the early 90ies. This works fine in VMs and new hardware, but old hardware is left behind.
This patch basically corrects the first part of the problem, by making the bus handling support separate between ACPI and non-ACPI HALs. For now, the code remains 100% the same in functionality between both.
However, I have started adding the first few elements:
[HAL]: Implement HalRegisterBusHandler HALDISPATCH routine.
[HAL]: On legacy HALs, register the CMOS, ISA, SYSTEM handlers.
[HAL]: Add cmosbus.c. Stub all bus-specific bus handler routines in the xxxbus.c files.
No real functionality change occurs with this patch, yet.
svn path=/trunk/; revision=47649
2010-06-07 01:09:41 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
VOID
|
|
|
|
NTAPI
|
|
|
|
HalpInitBusHandlers(VOID)
|
|
|
|
{
|
|
|
|
/* Register the HAL Bus Handler support */
|
|
|
|
HalpRegisterInternalBusHandlers();
|
|
|
|
}
|
2001-08-21 20:18:27 +00:00
|
|
|
|
2006-11-29 22:12:50 +00:00
|
|
|
VOID
|
|
|
|
NTAPI
|
|
|
|
HalpRegisterKdSupportFunctions(VOID)
|
|
|
|
{
|
|
|
|
/* Register PCI Device Functions */
|
|
|
|
KdSetupPciDeviceForDebugging = HalpSetupPciDeviceForDebugging;
|
|
|
|
KdReleasePciDeviceforDebugging = HalpReleasePciDeviceForDebugging;
|
|
|
|
|
|
|
|
/* Register memory functions */
|
2010-03-03 21:56:52 +00:00
|
|
|
#ifndef _MINIHAL_
|
2006-11-29 22:12:50 +00:00
|
|
|
KdMapPhysicalMemory64 = HalpMapPhysicalMemory64;
|
|
|
|
KdUnmapVirtualAddress = HalpUnmapVirtualAddress;
|
2010-03-03 21:56:52 +00:00
|
|
|
#endif
|
2006-11-29 22:12:50 +00:00
|
|
|
|
|
|
|
/* Register ACPI stub */
|
|
|
|
KdCheckPowerButton = HalpCheckPowerButton;
|
|
|
|
}
|
|
|
|
|
2006-11-27 19:26:31 +00:00
|
|
|
NTSTATUS
|
|
|
|
NTAPI
|
|
|
|
HalpAssignSlotResources(IN PUNICODE_STRING RegistryPath,
|
|
|
|
IN PUNICODE_STRING DriverClassName,
|
|
|
|
IN PDRIVER_OBJECT DriverObject,
|
|
|
|
IN PDEVICE_OBJECT DeviceObject,
|
|
|
|
IN INTERFACE_TYPE BusType,
|
|
|
|
IN ULONG BusNumber,
|
|
|
|
IN ULONG SlotNumber,
|
|
|
|
IN OUT PCM_RESOURCE_LIST *AllocatedResources)
|
2001-08-21 20:18:27 +00:00
|
|
|
{
|
2006-11-27 19:26:31 +00:00
|
|
|
BUS_HANDLER BusHandler;
|
|
|
|
PAGED_CODE();
|
|
|
|
|
|
|
|
/* Only PCI is supported */
|
|
|
|
if (BusType != PCIBus) return STATUS_NOT_IMPLEMENTED;
|
|
|
|
|
|
|
|
/* Setup fake PCI Bus handler */
|
|
|
|
RtlCopyMemory(&BusHandler, &HalpFakePciBusHandler, sizeof(BUS_HANDLER));
|
|
|
|
BusHandler.BusNumber = BusNumber;
|
|
|
|
|
|
|
|
/* Call the PCI function */
|
2007-12-14 08:53:56 +00:00
|
|
|
return HalpAssignPCISlotResources(&BusHandler,
|
|
|
|
&BusHandler,
|
|
|
|
RegistryPath,
|
|
|
|
DriverClassName,
|
|
|
|
DriverObject,
|
|
|
|
DeviceObject,
|
|
|
|
SlotNumber,
|
|
|
|
AllocatedResources);
|
2001-08-21 20:18:27 +00:00
|
|
|
}
|
|
|
|
|
2006-11-27 19:26:31 +00:00
|
|
|
BOOLEAN
|
|
|
|
NTAPI
|
|
|
|
HalpTranslateBusAddress(IN INTERFACE_TYPE InterfaceType,
|
|
|
|
IN ULONG BusNumber,
|
|
|
|
IN PHYSICAL_ADDRESS BusAddress,
|
|
|
|
IN OUT PULONG AddressSpace,
|
|
|
|
OUT PPHYSICAL_ADDRESS TranslatedAddress)
|
2001-08-21 20:18:27 +00:00
|
|
|
{
|
2006-11-27 19:26:31 +00:00
|
|
|
/* Translation is easy */
|
|
|
|
TranslatedAddress->QuadPart = BusAddress.QuadPart;
|
|
|
|
return TRUE;
|
2001-08-21 20:18:27 +00:00
|
|
|
}
|
|
|
|
|
2006-11-29 08:28:20 +00:00
|
|
|
ULONG
|
|
|
|
NTAPI
|
[HAL]: Bus support in the HAL actually creates a further wedge between the different x86 HALs: There are actually two dinstinct implementations. On the ACPI HAL, the system is assumed not to have things like special ISA, MCA, EISA buses, and a PCI driver is used in combination with the ACPI Interface for PCI Bus support. On non-ACPI systems, the legacy "Bus Handler" library is used, and the HAL provides a core set of CMOS, EISA, ISA, MCA and PCI bus handlers, each with their own routines and specific code. Additionally, PCI IRQ Routing and other PCI bus internals are handled directly by the HAL -- on the ACPI HAL, the PCI Bus support is implemented through a "Fake"/static bus handler, just to keep the functions shared. On ReactOS, both the ACPI and non-ACPI HAL were currently using a mix of both HAL bus handling types, mostly implemented the "ACPI way" (with a fake PCI bus handler and such).
As a result, none of the Hal*Bus HALDISPATCH routines were implemented, which bus drivers expect to find when they're not on ACPI systems (ReactOS today). eVb's new PCI driver was crashing, for example.
Furthermore, legacy systems suffer, because the ACPI HAL Bus routines (that we currently have) expect perfect ACPI-style-compliant systems, not the legacy crap from the early 90ies. This works fine in VMs and new hardware, but old hardware is left behind.
This patch basically corrects the first part of the problem, by making the bus handling support separate between ACPI and non-ACPI HALs. For now, the code remains 100% the same in functionality between both.
However, I have started adding the first few elements:
[HAL]: Implement HalRegisterBusHandler HALDISPATCH routine.
[HAL]: On legacy HALs, register the CMOS, ISA, SYSTEM handlers.
[HAL]: Add cmosbus.c. Stub all bus-specific bus handler routines in the xxxbus.c files.
No real functionality change occurs with this patch, yet.
svn path=/trunk/; revision=47649
2010-06-07 01:09:41 +00:00
|
|
|
HalpGetSystemInterruptVector_Acpi(IN ULONG BusNumber,
|
|
|
|
IN ULONG BusInterruptLevel,
|
|
|
|
IN ULONG BusInterruptVector,
|
|
|
|
OUT PKIRQL Irql,
|
|
|
|
OUT PKAFFINITY Affinity)
|
2006-11-29 08:28:20 +00:00
|
|
|
{
|
2007-03-27 12:55:57 +00:00
|
|
|
ULONG Vector = IRQ2VECTOR(BusInterruptLevel);
|
2006-11-29 08:28:20 +00:00
|
|
|
*Irql = (KIRQL)VECTOR2IRQL(Vector);
|
|
|
|
*Affinity = 0xFFFFFFFF;
|
|
|
|
return Vector;
|
|
|
|
}
|
|
|
|
|
2007-02-04 19:15:04 +00:00
|
|
|
BOOLEAN
|
|
|
|
NTAPI
|
|
|
|
HalpFindBusAddressTranslation(IN PHYSICAL_ADDRESS BusAddress,
|
|
|
|
IN OUT PULONG AddressSpace,
|
|
|
|
OUT PPHYSICAL_ADDRESS TranslatedAddress,
|
|
|
|
IN OUT PULONG_PTR Context,
|
|
|
|
IN BOOLEAN NextBus)
|
|
|
|
{
|
|
|
|
/* Make sure we have a context */
|
|
|
|
if (!Context) return FALSE;
|
|
|
|
|
|
|
|
/* If we have data in the context, then this shouldn't be a new lookup */
|
|
|
|
if ((*Context) && (NextBus == TRUE)) return FALSE;
|
|
|
|
|
|
|
|
/* Return bus data */
|
|
|
|
TranslatedAddress->QuadPart = BusAddress.QuadPart;
|
|
|
|
|
|
|
|
/* Set context value and return success */
|
|
|
|
*Context = 1;
|
|
|
|
return TRUE;
|
|
|
|
}
|
|
|
|
|
2006-11-27 19:26:31 +00:00
|
|
|
/* PUBLIC FUNCTIONS **********************************************************/
|
2001-08-21 20:18:27 +00:00
|
|
|
|
2006-11-27 19:26:31 +00:00
|
|
|
/*
|
|
|
|
* @implemented
|
|
|
|
*/
|
|
|
|
NTSTATUS
|
|
|
|
NTAPI
|
|
|
|
HalAdjustResourceList(IN PCM_RESOURCE_LIST Resources)
|
2001-08-21 20:18:27 +00:00
|
|
|
{
|
2006-11-27 19:26:31 +00:00
|
|
|
/* Deprecated, return success */
|
|
|
|
return STATUS_SUCCESS;
|
2001-08-21 20:18:27 +00:00
|
|
|
}
|
|
|
|
|
2006-11-27 19:26:31 +00:00
|
|
|
/*
|
|
|
|
* @implemented
|
|
|
|
*/
|
|
|
|
NTSTATUS
|
|
|
|
NTAPI
|
|
|
|
HalAssignSlotResources(IN PUNICODE_STRING RegistryPath,
|
|
|
|
IN PUNICODE_STRING DriverClassName,
|
|
|
|
IN PDRIVER_OBJECT DriverObject,
|
|
|
|
IN PDEVICE_OBJECT DeviceObject,
|
|
|
|
IN INTERFACE_TYPE BusType,
|
|
|
|
IN ULONG BusNumber,
|
|
|
|
IN ULONG SlotNumber,
|
|
|
|
IN OUT PCM_RESOURCE_LIST *AllocatedResources)
|
2001-08-21 20:18:27 +00:00
|
|
|
{
|
2006-11-27 19:26:31 +00:00
|
|
|
/* Check the bus type */
|
|
|
|
if (BusType != PCIBus)
|
|
|
|
{
|
|
|
|
/* Call our internal handler */
|
|
|
|
return HalpAssignSlotResources(RegistryPath,
|
|
|
|
DriverClassName,
|
|
|
|
DriverObject,
|
|
|
|
DeviceObject,
|
|
|
|
BusType,
|
|
|
|
BusNumber,
|
|
|
|
SlotNumber,
|
|
|
|
AllocatedResources);
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
/* Call the PCI registered function */
|
|
|
|
return HalPciAssignSlotResources(RegistryPath,
|
|
|
|
DriverClassName,
|
|
|
|
DriverObject,
|
|
|
|
DeviceObject,
|
|
|
|
PCIBus,
|
|
|
|
BusNumber,
|
|
|
|
SlotNumber,
|
|
|
|
AllocatedResources);
|
|
|
|
}
|
2001-08-21 20:18:27 +00:00
|
|
|
}
|
|
|
|
|
2006-11-27 19:26:31 +00:00
|
|
|
/*
|
|
|
|
* @implemented
|
|
|
|
*/
|
|
|
|
ULONG
|
|
|
|
NTAPI
|
|
|
|
HalGetBusData(IN BUS_DATA_TYPE BusDataType,
|
|
|
|
IN ULONG BusNumber,
|
|
|
|
IN ULONG SlotNumber,
|
|
|
|
IN PVOID Buffer,
|
|
|
|
IN ULONG Length)
|
2001-08-21 20:18:27 +00:00
|
|
|
{
|
2006-11-27 19:26:31 +00:00
|
|
|
/* Call the extended function */
|
|
|
|
return HalGetBusDataByOffset(BusDataType,
|
|
|
|
BusNumber,
|
|
|
|
SlotNumber,
|
|
|
|
Buffer,
|
|
|
|
0,
|
|
|
|
Length);
|
2001-08-21 20:18:27 +00:00
|
|
|
}
|
|
|
|
|
2006-11-27 19:26:31 +00:00
|
|
|
/*
|
|
|
|
* @implemented
|
|
|
|
*/
|
|
|
|
ULONG
|
|
|
|
NTAPI
|
|
|
|
HalGetBusDataByOffset(IN BUS_DATA_TYPE BusDataType,
|
|
|
|
IN ULONG BusNumber,
|
|
|
|
IN ULONG SlotNumber,
|
|
|
|
IN PVOID Buffer,
|
|
|
|
IN ULONG Offset,
|
|
|
|
IN ULONG Length)
|
2001-08-21 20:18:27 +00:00
|
|
|
{
|
2006-11-27 19:26:31 +00:00
|
|
|
BUS_HANDLER BusHandler;
|
|
|
|
|
|
|
|
/* Look as the bus type */
|
|
|
|
if (BusDataType == Cmos)
|
|
|
|
{
|
|
|
|
/* Call CMOS Function */
|
|
|
|
return HalpGetCmosData(0, SlotNumber, Buffer, Length);
|
|
|
|
}
|
|
|
|
else if (BusDataType == EisaConfiguration)
|
|
|
|
{
|
|
|
|
/* FIXME: TODO */
|
2008-08-24 15:48:05 +00:00
|
|
|
ASSERT(FALSE);
|
2006-11-27 19:26:31 +00:00
|
|
|
}
|
|
|
|
else if ((BusDataType == PCIConfiguration) &&
|
|
|
|
(HalpPCIConfigInitialized) &&
|
|
|
|
((BusNumber >= HalpMinPciBus) && (BusNumber <= HalpMaxPciBus)))
|
|
|
|
{
|
|
|
|
/* Setup fake PCI Bus handler */
|
|
|
|
RtlCopyMemory(&BusHandler, &HalpFakePciBusHandler, sizeof(BUS_HANDLER));
|
|
|
|
BusHandler.BusNumber = BusNumber;
|
|
|
|
|
|
|
|
/* Call PCI function */
|
2007-12-14 08:53:56 +00:00
|
|
|
return HalpGetPCIData(&BusHandler,
|
|
|
|
&BusHandler,
|
|
|
|
*(PPCI_SLOT_NUMBER)&SlotNumber,
|
|
|
|
Buffer,
|
|
|
|
Offset,
|
|
|
|
Length);
|
2006-11-27 19:26:31 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/* Invalid bus */
|
|
|
|
return 0;
|
2001-08-21 20:18:27 +00:00
|
|
|
}
|
|
|
|
|
2006-11-27 19:26:31 +00:00
|
|
|
/*
|
|
|
|
* @implemented
|
|
|
|
*/
|
|
|
|
ULONG
|
|
|
|
NTAPI
|
|
|
|
HalGetInterruptVector(IN INTERFACE_TYPE InterfaceType,
|
|
|
|
IN ULONG BusNumber,
|
|
|
|
IN ULONG BusInterruptLevel,
|
|
|
|
IN ULONG BusInterruptVector,
|
|
|
|
OUT PKIRQL Irql,
|
|
|
|
OUT PKAFFINITY Affinity)
|
2001-08-21 20:18:27 +00:00
|
|
|
{
|
2006-11-27 19:26:31 +00:00
|
|
|
/* Call the system bus translator */
|
[HAL]: Bus support in the HAL actually creates a further wedge between the different x86 HALs: There are actually two dinstinct implementations. On the ACPI HAL, the system is assumed not to have things like special ISA, MCA, EISA buses, and a PCI driver is used in combination with the ACPI Interface for PCI Bus support. On non-ACPI systems, the legacy "Bus Handler" library is used, and the HAL provides a core set of CMOS, EISA, ISA, MCA and PCI bus handlers, each with their own routines and specific code. Additionally, PCI IRQ Routing and other PCI bus internals are handled directly by the HAL -- on the ACPI HAL, the PCI Bus support is implemented through a "Fake"/static bus handler, just to keep the functions shared. On ReactOS, both the ACPI and non-ACPI HAL were currently using a mix of both HAL bus handling types, mostly implemented the "ACPI way" (with a fake PCI bus handler and such).
As a result, none of the Hal*Bus HALDISPATCH routines were implemented, which bus drivers expect to find when they're not on ACPI systems (ReactOS today). eVb's new PCI driver was crashing, for example.
Furthermore, legacy systems suffer, because the ACPI HAL Bus routines (that we currently have) expect perfect ACPI-style-compliant systems, not the legacy crap from the early 90ies. This works fine in VMs and new hardware, but old hardware is left behind.
This patch basically corrects the first part of the problem, by making the bus handling support separate between ACPI and non-ACPI HALs. For now, the code remains 100% the same in functionality between both.
However, I have started adding the first few elements:
[HAL]: Implement HalRegisterBusHandler HALDISPATCH routine.
[HAL]: On legacy HALs, register the CMOS, ISA, SYSTEM handlers.
[HAL]: Add cmosbus.c. Stub all bus-specific bus handler routines in the xxxbus.c files.
No real functionality change occurs with this patch, yet.
svn path=/trunk/; revision=47649
2010-06-07 01:09:41 +00:00
|
|
|
return HalpGetSystemInterruptVector_Acpi(BusNumber,
|
|
|
|
BusInterruptLevel,
|
|
|
|
BusInterruptVector,
|
|
|
|
Irql,
|
|
|
|
Affinity);
|
2001-08-21 20:18:27 +00:00
|
|
|
}
|
|
|
|
|
2006-11-27 19:26:31 +00:00
|
|
|
/*
|
|
|
|
* @implemented
|
|
|
|
*/
|
|
|
|
ULONG
|
|
|
|
NTAPI
|
|
|
|
HalSetBusData(IN BUS_DATA_TYPE BusDataType,
|
|
|
|
IN ULONG BusNumber,
|
|
|
|
IN ULONG SlotNumber,
|
|
|
|
IN PVOID Buffer,
|
|
|
|
IN ULONG Length)
|
2001-08-21 20:18:27 +00:00
|
|
|
{
|
2006-11-27 19:26:31 +00:00
|
|
|
/* Call the extended function */
|
|
|
|
return HalSetBusDataByOffset(BusDataType,
|
|
|
|
BusNumber,
|
|
|
|
SlotNumber,
|
|
|
|
Buffer,
|
|
|
|
0,
|
|
|
|
Length);
|
2001-08-21 20:18:27 +00:00
|
|
|
}
|
|
|
|
|
2006-11-27 19:26:31 +00:00
|
|
|
/*
|
|
|
|
* @implemented
|
|
|
|
*/
|
|
|
|
ULONG
|
|
|
|
NTAPI
|
|
|
|
HalSetBusDataByOffset(IN BUS_DATA_TYPE BusDataType,
|
|
|
|
IN ULONG BusNumber,
|
|
|
|
IN ULONG SlotNumber,
|
|
|
|
IN PVOID Buffer,
|
|
|
|
IN ULONG Offset,
|
|
|
|
IN ULONG Length)
|
2001-08-21 20:18:27 +00:00
|
|
|
{
|
2006-11-27 19:26:31 +00:00
|
|
|
BUS_HANDLER BusHandler;
|
|
|
|
|
|
|
|
/* Look as the bus type */
|
|
|
|
if (BusDataType == Cmos)
|
|
|
|
{
|
|
|
|
/* Call CMOS Function */
|
|
|
|
return HalpSetCmosData(0, SlotNumber, Buffer, Length);
|
|
|
|
}
|
|
|
|
else if ((BusDataType == PCIConfiguration) && (HalpPCIConfigInitialized))
|
|
|
|
{
|
|
|
|
/* Setup fake PCI Bus handler */
|
|
|
|
RtlCopyMemory(&BusHandler, &HalpFakePciBusHandler, sizeof(BUS_HANDLER));
|
|
|
|
BusHandler.BusNumber = BusNumber;
|
|
|
|
|
|
|
|
/* Call PCI function */
|
2007-12-14 08:53:56 +00:00
|
|
|
return HalpSetPCIData(&BusHandler,
|
|
|
|
&BusHandler,
|
|
|
|
*(PPCI_SLOT_NUMBER)&SlotNumber,
|
|
|
|
Buffer,
|
|
|
|
Offset,
|
|
|
|
Length);
|
2006-11-27 19:26:31 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/* Invalid bus */
|
|
|
|
return 0;
|
2001-08-21 20:18:27 +00:00
|
|
|
}
|
|
|
|
|
2006-11-27 19:26:31 +00:00
|
|
|
/*
|
|
|
|
* @implemented
|
|
|
|
*/
|
|
|
|
BOOLEAN
|
|
|
|
NTAPI
|
|
|
|
HalTranslateBusAddress(IN INTERFACE_TYPE InterfaceType,
|
|
|
|
IN ULONG BusNumber,
|
|
|
|
IN PHYSICAL_ADDRESS BusAddress,
|
|
|
|
IN OUT PULONG AddressSpace,
|
|
|
|
OUT PPHYSICAL_ADDRESS TranslatedAddress)
|
2001-08-21 20:18:27 +00:00
|
|
|
{
|
2006-11-27 19:26:31 +00:00
|
|
|
/* Look as the bus type */
|
|
|
|
if (InterfaceType == PCIBus)
|
|
|
|
{
|
|
|
|
/* Call the PCI registered function */
|
|
|
|
return HalPciTranslateBusAddress(PCIBus,
|
|
|
|
BusNumber,
|
|
|
|
BusAddress,
|
|
|
|
AddressSpace,
|
|
|
|
TranslatedAddress);
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
/* Translation is easy */
|
|
|
|
TranslatedAddress->QuadPart = BusAddress.QuadPart;
|
|
|
|
return TRUE;
|
|
|
|
}
|
2001-08-21 20:18:27 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/* EOF */
|