[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/isabus.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
|
|
|
|
|
HalpTranslateIsaBusAddress(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:46 +00:00
|
|
|
BOOLEAN Status;
|
2021-06-11 12:29:21 +00:00
|
|
|
|
2010-06-07 20:59:46 +00:00
|
|
|
/* Use system translation */
|
|
|
|
|
Status = HalpTranslateSystemBusAddress(BusHandler,
|
|
|
|
|
RootHandler,
|
|
|
|
|
BusAddress,
|
|
|
|
|
AddressSpace,
|
|
|
|
|
TranslatedAddress);
|
2021-06-11 12:29:21 +00:00
|
|
|
|
|
|
|
|
/* If it didn't work and it was memory address space... */
|
2010-06-07 20:59:46 +00:00
|
|
|
if (!(Status) && (*AddressSpace == 0))
|
|
|
|
|
{
|
|
|
|
|
/* Try EISA translation instead */
|
|
|
|
|
Status = HalTranslateBusAddress(Eisa,
|
|
|
|
|
BusHandler->BusNumber,
|
|
|
|
|
BusAddress,
|
|
|
|
|
AddressSpace,
|
|
|
|
|
TranslatedAddress);
|
|
|
|
|
}
|
2021-06-11 12:29:21 +00:00
|
|
|
|
2010-06-07 20:59:46 +00:00
|
|
|
/* Return the result */
|
|
|
|
|
return Status;
|
[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 */
|