Electrical computers and digital processing systems: memory – Storage accessing and control – Memory configuring
Reexamination Certificate
2002-08-07
2004-09-14
Sparks, Donald (Department: 2187)
Electrical computers and digital processing systems: memory
Storage accessing and control
Memory configuring
C711S152000, C711S156000, C711S163000, C711S215000, C710S003000, C710S008000, C713S001000, C713S100000
Reexamination Certificate
active
06792520
ABSTRACT:
BACKGROUND
Advanced Configuration and Power Interface (ACPI) is a specification that makes hardware status information available to an operating system in computers, including laptops, desktop, servers, etc. More information about ACPI may be found in the 500 page “Advanced Configuration and Power Interface Specification,” Revision 2.0a, Mar. 31, 2002, cooperatively defined by Compaq Computer Corporation, Intel Corporation, Microsoft Corporation, Phoenix Technologies Ltd., and Toshiba Corporation. The ACPI specification was developed to establish industry common interfaces enabling robust operating system (OS)-directed motherboard device configuration and power management of both devices and entire systems. ACPI is the key element in operating system-directed configuration and power management (OSPM).
ACPI is used in personal computers (PCs) running a variety of operating systems, such as Windows™, available from Microsoft® Corporation, Linux, available as open source form a variety of vendors, and HP-UX, available from Hewlett-Packard Company. ACPI also allows hardware resources to be manipulated. For example, ACPI assists in power management by allowing a computer system's peripherals to be powered on and off for improved power management. ACPI also allows the computer system to be turned on and off by external devices. For example, the touch of a mouse or the press of a key may wake up the computer system using ACPI.
Traditionally ACPI has been difficult to work with for a variety of reasons. First, ACPI is not written in the native assembly language of any computer system platform. Instead, ACPI has its own source and machine languages, i.e., ACPI Source Language (ASL) and ACPI Machine Language (AML), respectively. Because of its highly specialized use, there are relatively few ASL programmers; ASL has relatively few constructs because of its limited use. Furthermore, ACPI code is conventionally monolithic in its design. Consequently, this makes it difficult to port the ACPI code to other platforms or even to different configurations of the same platform. Thus, new ASL code needs to be written to work with newly-engineered platforms. The limited number of ASL programmers makes writing new code all the more problematic and costly.
ACPI is composed of both static and interpretable tables. At boot-up time, the system firmware (typically the BIOS, or Basic Input/Output System) constructs the static tables, which are consumed by the operating system. The interpretable tables are composed of AML, which is compiled and then merged into the system firmware. The operating system reads the AML from the interpretable tables and executes the architected interfaces, using an ACPI interpreter. In this fashion, the operating system manipulates hardware resources. Because the interpretable tables are merged into the system firmware, this conventional method lacks flexibility, and scalability, and requires considerable time to re-program to accommodate divergent system configurations.
For example, conventionally, ASL developers write ACPI code to specify a particular configuration of a platform or its variance. Unfortunately, if even a minor hardware change is performed, the design has to be modified. This requires that new AML code be written and new tables be merged into the system firmware. Thus, the conventional design is not portable or re-usable.
Furthermore, ACPI has conventionally required that a different system firmware ROM (Read Only Memory) or BIOS be used if there is a variance of the platform or if it supports more than one ACPI-aware OS system, where the OS systems have mutually exclusive ACPI requirements. A different system firmware ROM also had to be used if the same system is to support multiple operating systems. For instance, current art in personal computers uses the IA-32 instruction set. ACPI was primarily used by the Microsoft® family of operating systems, especially in systems with the IA-32 instruction set.
ACPI has been accepted by the various operating systems as the standard interface. A new instruction set architecture, IA-64, is being developed, but its advantages cannot be fully utilized with legacy ACPI code, or methods. The new Itanium® Processor Family, available from Intel® Corporation, uses the IA-64 instruction set. The ASL for each new processor in this family will need to be uniquely rewritten if current practices are utilized. Further, if multiple operating systems must run on a given processor, the ASL would need to be unique for each OS, as well.
The ACPI namespace is a hierarchical tree structure in OS-controlled memory that contains named objects. These objects may be data objects, control method objects, bus/device package objects, and so on. The OS dynamically changes the contents of the namespace at run-time by loading and/or unloading definition blocks from the ACPI Tables that reside in the ACPI BIOS. All the information in the ACPI namespace comes from the differentiated system description table (DSDT), which contains the differentiated definition block, and one or more other definition blocks. In the current art, an OEM (original equipment manufacturer) must supply a DSDT to an ACPI-compatible OS, which supplies the implementation and configuration information about the base system. The OS always inserts the DSDT information into the ACPI namespace at system boot time and never removes it.
Another ACPI construct is the secondary system description table (SSDT). SSDTs are a continuation of the DSDT. Multiple SSDTs can be used as part of a platform description. After the DSDT is loaded into the ACPI Namespace, each secondary description table with a unique OEM Table ID is loaded. This allows the OEM to provide the base support in one table, while adding smaller system options in other tables. Additional tables can only add data; they cannot overwrite data from previous tables.
Computer systems of the prior art, which use IA-32 and ACPI, typically use I/O port address space to manage the register memory maps for the various I/O devices in the computer system. While this method can be used for IA-64, it has serious drawbacks given that a server can have 500 or more devices and resources.
SUMMARY
A system and method for using memory mapped I/O (MMIO) to manage system devices is provided. A parent device in the ACPI namespace, for instance, a local bus adapter, uses (MMIO) to identify the memory addresses of its children devices. An existing, but unused, construct of ACPI is used to pass the MMIO information through the operating system (OS) to the device drivers, enabling memory to be reserved by a device, and also remain hidden to the OS. The vendor defined resource data type for long information, also known as the “vendor-long” descriptor, is used to pass the appropriate information through the OS. This method enables the memory information to be passed to the OS without the risk that the OS will mistake the addresses as being available, and reassigning them in error.
REFERENCES:
patent: 5897658 (1999-04-01), Eskesen et al.
patent: 6581148 (2003-06-01), Sadashivaiah et al.
patent: 6701421 (2004-03-01), Elnozahy et al.
patent: 2002/0059473 (2002-05-01), Oshins et al.
“Dynamic Network Reconfiguration Support for Mobile Computers,” Inouye et al, MOBICOM 97, Budapest Hungary, 1997, ACM.
Nicholes Martin O.
Qureshi Shiraz A.
Chace Christian P.
Sparks Donald
LandOfFree
System and method for using a using vendor-long descriptor... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with System and method for using a using vendor-long descriptor..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and System and method for using a using vendor-long descriptor... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3192870