[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
|
|
|
/*
|
|
|
|
* PROJECT: ReactOS HAL
|
|
|
|
* LICENSE: GPL - See COPYING in the top level directory
|
2015-11-04 13:30:52 +00:00
|
|
|
* FILE: hal/halx86/legacy/bus/sysbus.c
|
[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
|
|
|
* PURPOSE:
|
|
|
|
* PROGRAMMERS: Stefan Ginsberg (stefan.ginsberg@reactos.org)
|
|
|
|
*/
|
|
|
|
|
|
|
|
/* INCLUDES *******************************************************************/
|
|
|
|
|
|
|
|
#include <hal.h>
|
|
|
|
#define NDEBUG
|
|
|
|
#include <debug.h>
|
|
|
|
|
|
|
|
/* GLOBALS ********************************************************************/
|
|
|
|
|
|
|
|
/* PRIVATE FUNCTIONS **********************************************************/
|
|
|
|
|
|
|
|
BOOLEAN
|
|
|
|
NTAPI
|
|
|
|
HalpTranslateSystemBusAddress(IN PBUS_HANDLER BusHandler,
|
2021-06-11 12:29:21 +00:00
|
|
|
IN PBUS_HANDLER RootHandler,
|
[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
|
|
|
IN PHYSICAL_ADDRESS BusAddress,
|
|
|
|
IN OUT PULONG AddressSpace,
|
|
|
|
OUT PPHYSICAL_ADDRESS TranslatedAddress)
|
|
|
|
{
|
2010-06-07 20:59:00 +00:00
|
|
|
PSUPPORTED_RANGE Range = NULL;
|
2021-06-11 12:29:21 +00:00
|
|
|
|
2010-06-07 20:59:00 +00:00
|
|
|
/* Check what kind of address space this is */
|
|
|
|
switch (*AddressSpace)
|
|
|
|
{
|
|
|
|
/* Memory address */
|
|
|
|
case 0:
|
2021-06-11 12:29:21 +00:00
|
|
|
|
2015-06-06 08:37:53 +00:00
|
|
|
/* Loop all prefetch memory */
|
2010-06-07 20:59:00 +00:00
|
|
|
for (Range = &BusHandler->BusAddresses->PrefetchMemory;
|
|
|
|
Range;
|
|
|
|
Range = Range->Next)
|
|
|
|
{
|
|
|
|
/* Check if it's in a valid range */
|
|
|
|
if ((BusAddress.QuadPart >= Range->Base) &&
|
|
|
|
(BusAddress.QuadPart <= Range->Limit))
|
|
|
|
{
|
|
|
|
/* Get out */
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
2021-06-11 12:29:21 +00:00
|
|
|
|
2010-06-07 20:59:00 +00:00
|
|
|
/* Check if we haven't found anything yet */
|
|
|
|
if (!Range)
|
|
|
|
{
|
|
|
|
/* Loop all bus memory */
|
|
|
|
for (Range = &BusHandler->BusAddresses->Memory;
|
|
|
|
Range;
|
|
|
|
Range = Range->Next)
|
|
|
|
{
|
|
|
|
/* Check if it's in a valid range */
|
|
|
|
if ((BusAddress.QuadPart >= Range->Base) &&
|
|
|
|
(BusAddress.QuadPart <= Range->Limit))
|
|
|
|
{
|
|
|
|
/* Get out */
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
2021-06-11 12:29:21 +00:00
|
|
|
|
2010-06-07 20:59:00 +00:00
|
|
|
/* Done */
|
|
|
|
break;
|
2021-06-11 12:29:21 +00:00
|
|
|
|
2010-06-07 20:59:00 +00:00
|
|
|
/* I/O Space */
|
|
|
|
case 1:
|
|
|
|
|
|
|
|
/* Loop all bus I/O memory */
|
|
|
|
for (Range = &BusHandler->BusAddresses->IO;
|
|
|
|
Range;
|
|
|
|
Range = Range->Next)
|
|
|
|
{
|
|
|
|
/* Check if it's in a valid range */
|
|
|
|
if ((BusAddress.QuadPart >= Range->Base) &&
|
|
|
|
(BusAddress.QuadPart <= Range->Limit))
|
|
|
|
{
|
|
|
|
/* Get out */
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
2021-06-11 12:29:21 +00:00
|
|
|
|
2010-06-07 20:59:00 +00:00
|
|
|
/* Done */
|
|
|
|
break;
|
|
|
|
}
|
2021-06-11 12:29:21 +00:00
|
|
|
|
2010-06-07 20:59:00 +00:00
|
|
|
/* Check if we found a range */
|
|
|
|
if (Range)
|
|
|
|
{
|
|
|
|
/* Do the translation and return the kind of address space this is */
|
|
|
|
TranslatedAddress->QuadPart = BusAddress.QuadPart + Range->SystemBase;
|
|
|
|
if ((TranslatedAddress->QuadPart != BusAddress.QuadPart) ||
|
|
|
|
(*AddressSpace != Range->SystemAddressSpace))
|
|
|
|
{
|
|
|
|
/* Different than what the old HAL would do */
|
|
|
|
DPRINT1("Translation of %I64x is %I64x %s\n",
|
|
|
|
BusAddress.QuadPart, TranslatedAddress->QuadPart,
|
|
|
|
Range->SystemAddressSpace ? "In I/O Space" : "In RAM");
|
|
|
|
}
|
|
|
|
*AddressSpace = Range->SystemAddressSpace;
|
|
|
|
return TRUE;
|
|
|
|
}
|
2021-06-11 12:29:21 +00:00
|
|
|
|
2010-06-07 20:59:00 +00:00
|
|
|
/* Nothing found */
|
|
|
|
DPRINT1("Translation of %I64x failed!\n", BusAddress.QuadPart);
|
[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 FALSE;
|
|
|
|
}
|
|
|
|
|
|
|
|
ULONG
|
|
|
|
NTAPI
|
|
|
|
HalpGetSystemInterruptVector(IN PBUS_HANDLER BusHandler,
|
|
|
|
IN PBUS_HANDLER RootHandler,
|
|
|
|
IN ULONG BusInterruptLevel,
|
|
|
|
IN ULONG BusInterruptVector,
|
|
|
|
OUT PKIRQL Irql,
|
|
|
|
OUT PKAFFINITY Affinity)
|
|
|
|
{
|
2010-06-07 20:34:41 +00:00
|
|
|
ULONG Vector;
|
2021-06-11 12:29:21 +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
|
|
|
/* Get the root vector */
|
2010-06-07 20:34:41 +00:00
|
|
|
Vector = HalpGetRootInterruptVector(BusInterruptLevel,
|
|
|
|
BusInterruptVector,
|
|
|
|
Irql,
|
|
|
|
Affinity);
|
2021-06-11 12:29:21 +00:00
|
|
|
|
2010-06-07 20:34:41 +00:00
|
|
|
/* Check if the vector is owned by the HAL and fail if it is */
|
|
|
|
if (HalpIDTUsageFlags[Vector].Flags & IDT_REGISTERED) DPRINT1("Vector %lx is ALREADY IN USE!\n", Vector);
|
|
|
|
return (HalpIDTUsageFlags[Vector].Flags & IDT_REGISTERED) ? 0 : Vector;
|
[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
|
|
|
}
|
|
|
|
|
|
|
|
/* EOF */
|