Dismiss
InnovationQ will be updated on Sunday, Oct. 22, from 10am ET - noon. You may experience brief service interruptions during that time.
Browse Prior Art Database

Method for pre-OS software to handle multiple alert-sending devices

IP.com Disclosure Number: IPCOM000009109D
Publication Date: 2002-Aug-07
Document File: 12 page(s) / 76K

Publishing Venue

The IP.com Prior Art Database

Abstract

Disclosed is a method for software that executes before the operating system (pre-OS software) to handle multiple alert-sending devices (ASDs). Benefits include improved functionality.

This text was extracted from a Microsoft Word document.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 23% of the total text.

Method for pre-OS software to handle multiple alert-sending devices

Disclosed is a method for software that executes before the operating system (pre-OS software) to handle multiple alert-sending devices (ASDs). Benefits include improved functionality.

Background

              Any basic alerting system consists of a client system (or systems) and a management console that monitors and controls the clients. Typically, the alerting systems have a network interface to the remote management console and an SMBUS interface to the local chipset on each of the clients.

              SMBUS 2.0 requires an address resolution protocol (ARP) to support plug-n-play. The PCI specification has a capability to connect SMBUS signals to PCI slots. When a new network/alert capable adapter is added to a PCI slot, SMBUS ARP identifies the card and assigns a unique SMBUS address to the device.

              Active streaming format alert-capable devices support three commands to perform the SMBUS ARP process. Pre-OS software follows these steps during an ARP:

1.           Prepare for ARP, which prepares the device for the address resolution process by clearing the AR flag in the internal registers

2.           Get UDID, which is sent to all of the SMBus devices by using address C2h. Address C2h          is the universal address used during the ARP process. The 16-byte universal device

identifier (UDID) for each of the devices is returned. The device with the first 0b in the          ID overdrives all ones (1) on the bus and is the first device detected.

3.           Assign Address, which assigns an address to a detected device. After the next device is detected, an address is assigned to the device using the Assign Address Command.
              The Get UDID and Assign Address commands process continue until all of the devices are detected and a unique SMBUS address is assigned to all ASDs.

              The following internal states and registers are specified as part of the SMBUS Specification and alert-capable devices support these states:

·        Address Resolution (AR) bit: The AR bit indicates if the slave device address is resolved by the ARP master.

·        Address Valid (AV) flag: The AV flag is internal to the device and indicates if the slave device address is valid. This bit is usually non-volatile to support the Persistent Slave Address feature.

·        Persistent Slave Address (PSA): The PSA is a non-volatile register used for storing the SMBUS address through power cycles. This feature is intended for
devices permanent to the system (for example, LAN on motherboard components). The SMBUS address is returned to the host controller during the Get UDID command, enabling the host controller to re-use the same address multiple times.

·        Universal Device Identification (UDID): The UDID format for one of the Alert capable device is presented below. This ID is read during the SMBUS ARP process and used to assign the device an address.

              The UDID register contains the following fields (see Figure 1):

·        Device capabilities (8 bits)

·        Version/revision (8 bits)

·        Vendor ID (16 bits)

·        Device ID (16...