Browse Prior Art Database

Identification of multi end device paths via FSI chained interface

IP.com Disclosure Number: IPCOM000240654D
Publication Date: 2015-Feb-16
Document File: 3 page(s) / 103K

Publishing Venue

The IP.com Prior Art Database

Abstract

Disclosed is a method to generate redundant device path maps from hardware team data (EX: schematics, XML...) and pass this into low level device firmware to handle redundancy algorithmically.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 34% of the total text.

Page 01 of 3

Identification of multi end device paths via FSI chained interface

Server systems generally utilize redundancy in many areas of the design. Examples of redundant hardware could include power subsystem (fans, power supplies etc.), service processors (SP), memory DIMMs, or vital product data (VPD). Redundancy in the server systems is generally managed by the service processors. The service processor functions encapsulate the redundancy such that one device is opened to communicate to end devices.

Common FRU Access Macro (CFAM) engines are used to drive device interfaces. There is no service processor code that runs within a CFAM, the CFAM is not a service processor, but rather a hardware engines to propagate and drive the varied communications interfaces (EX: UART, IIC, JTAG, etc...). Multiple CFAM engines can be used to drive communications to the same common end devices. In server systems the service processor and the CFAM engines may be packaged on multiple FRUs in multiple enclosures. Within the server design, redundant communications paths may be provided via multiple CFAMs with these redundant path CFAMs packaged on redundant FRUs to ensure concurrent maintenance capability. The service processors itself can also be redundant. Interfaces such as a FRU serial interface (FSI) can provide SPs connectivity to any CFAMs or redundant SP . Each of the redundant SPs must be able to access all of the hardware resources (smart chip, JTAG and I2C buses, GPIOs and CFAMs) .

The Figure 1 shows examples of redundant SPs (SP-A and SP-B) and redundant FRUs (FRU-A and FRU-B).

Note that CFAMs on the two redundant FRUs have different FSI links. For example SP-A to FRU-A

CFAM-S1 may be on LINK 3 and SP-A to FRU-B CFAM-S1 may be on LINK5. Note also that the IIC buses are dotted on the back side of the redundant FRUs FRU-A and FRU-B. Using FRU-1 as an example, there are two device paths using SP-A. The first is SP-A FSI:LINK 3 to FRU-A CFAM-S1 and out IIC to FRU-1. The second is SP-A FSI:LINK 5 to FRU-B CFAM-S1 and out IIC to FRU-1. These are redundant paths to the same end device.

The control drawer SP can use either redundant FRU-A or FRU-B to drive devices attached to both FRUs CFAMs. To the device driver, the multiple device paths make the end device actually look like multiple separate end devices. The underlying problem in firmware is to be able to identify and pair up the multiple redundant paths to the same end device. The proposed solution is at compile time to use schematic generated system model information to algorithmically identify redundant paths, generate redundancy mapping/pairs into a format that can be consumed by firmware and include this data in the firmware code load.

1


Page 02 of 3

Applications generally access end-devices using device paths. The kernel routes the request to end devices using associated end-device device drivers. In the case of IIC bus devices, the device is generally accessed via CFAM-S IIC bus engine which...