18.12.2012 Views

Advanced Configuration and Power Interface Specification

Advanced Configuration and Power Interface Specification

Advanced Configuration and Power Interface Specification

SHOW MORE
SHOW LESS

Create successful ePaper yourself

Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.

<strong>Advanced</strong> <strong>Configuration</strong> <strong>and</strong> <strong>Power</strong> <strong>Interface</strong> <strong>Specification</strong><br />

For example, a Baseboard Management Controller will support power metering capabilities at the<br />

network function 0x30, <strong>and</strong> IPMI comm<strong>and</strong>s to query the BMC device information at the network<br />

function 0x06.<br />

The following ASL code shows the use of the OperationRegion term to describe these IPMI<br />

functions:<br />

Device (IPMI)<br />

{<br />

Name(_HID, "IPI0001") // IPMI device<br />

Name(_IFT, 0x1) // KCS system interface type<br />

OperationRegion(DEVC, IPMI, 0x0600, 0x100) // Device info network function<br />

OperationRegion(POWR, IPMI, 0x3000, 0x100) // <strong>Power</strong> network function<br />

:<br />

}<br />

Notice that these operation regions in this example are defined within the immediate context of the<br />

‘owning’ IPMI device. This ensures the correct operation region h<strong>and</strong>ler will be used, based on the<br />

value returned by the _IFT object. Each definition corresponds to a separate network function, <strong>and</strong><br />

happens to use an initial comm<strong>and</strong> value offset of zero (0).<br />

5.5.2.4.3.1 Declaring IPMI Fields<br />

As with other regions, IPMI operation regions are only accessible via the Field term. Each field<br />

element is assigned a unique comm<strong>and</strong> value <strong>and</strong> represents a virtual comm<strong>and</strong> for the targeted<br />

network function.<br />

The syntax for the Field term (from Section 19.5.40, “Event (Declare Event Synchronization<br />

Object]”) is described below.<br />

Field(�<br />

RegionName, // NameString=>OperationRegion�<br />

AccessType, // AccessTypeKeyword - BufferAcc�<br />

LockRule, // LockRuleKeyword�<br />

UpdateRule // UpdateRuleKeyword – ignored�<br />

) {FieldUnitList}<br />

Where:<br />

• RegionName specifies the operation region name previously defined for the network function.<br />

• AccessType must be set to BufferAcc. This indicates that access to field elements will be done<br />

using a region-specific data buffer. For this access type, the field h<strong>and</strong>ler is not aware of the data<br />

buffer’s contents which may be of any size. When a field of this type is used as the source<br />

argument in an operation it simply evaluates to a buffer. When used as the destination, however,<br />

the buffer is passed bi-directionally to allow data to be returned from write operations. The<br />

modified buffer then becomes the response message of that comm<strong>and</strong>. This is slightly different<br />

than the normal case in which the execution result is the same as the value written to the<br />

destination. Note that the source is never changed, since it only represents a virtual register for a<br />

particular IPMI comm<strong>and</strong>.<br />

• LockRule indicates if access to this operation region requires acquisition of the Global Lock for<br />

synchronization. This field should be set to Lock on system with firmware that may access the<br />

BMC via IPMI, <strong>and</strong> NoLock otherwise.<br />

• UpdateRule is not applicable to IPMI operation regions since each virtual register is accessed in<br />

its entirety. This field is ignored for all IPMI field definitions.<br />

Hewlett-Packard/Intel/Microsoft/Phoenix/Toshiba 201

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!