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

Fuse File System Error handling for PNOR flash via Device Driver Failure mechanisms

IP.com Disclosure Number: IPCOM000240730D
Publication Date: 2015-Feb-23
Document File: 5 page(s) / 54K

Publishing Venue

The IP.com Prior Art Database

Abstract

Disclosed is the method to process error isolation in the context of Fuse File System Error for PNOR flash via Device Driver Failure mechanisms

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

Page 01 of 5

Fuse File System Error handling for PNOR flash via Device Driver Failure mechanisms

Server systems generally use PNOR flash for various purposes. Typically the firmware image that performs system initialization is loaded out of PNOR flash. The system initialization image initializes the memory subsystem, cores and power bus. The PNOR flash especially plays an important role in Initial Program Load (IPL) of the server system.

PNOR flash data could be accessed using FUSE (File-system in User-space) application programming interfaces (APIs). The FUSE module generally provides bridge to the actual kernel interfaces and is used to develop a user space filesystem framework without understanding filesystem internals. Filesystem in Userspace (FUSE) allows filesystems that are implemented in user space to be integrated as a Unix filesystem.

The problem is that the FUSE API error paths do not perform any logical error isolation, first failure data capture (FFDC), or physical FRU callout processing for errors on the underlying kernel interfaces. The use of FUSE designs provide a nice abstraction to the applications, but with it we loose the Reliability, Serviceability, Availability (RAS) desired in mid-range to high end servers.

Specifically with reference to the PNOR access we lose ability to get the desired call outs pertaining to the PNOR wiring when there is an error returned from the FUSE APIs. Typically the application firmware within service processor (SP) generates an error log when the service processor cannot interact with PNOR flash via FUSE APIs. The issue is FUSE APIs cannot help application firmware to identify or isolate problematic Field Replaceable Unit (FRU) or Manufacturing Replaceable Unit (MRU) on the wiring path between the SP and PNOR flash wiring.

Using the following diagram as a reference of one embodiment:

1


Page 02 of 5

NOTE: 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...).

The path from SP chip to the PNOR flash could cover many FRUs and MRUs. Using a high end server system as an example embodiment:
1) SP chip (MRU) - FSI interface to:
2) SP Card (FRU) - FSI interface to:
3) Intermediate Interface Card (FRU), if any - FSI interface to:
4) Primary Common FRU access macro (CFAM) card (FRU) - FSI interface to:
5) Serial flash controller (MRU) - SPI interface to:
6) Intermediate Interface Card - SPI interface to:
7) Card having PNOR flash chip (FRU) - SPI interface to:
8) PNOR flash chip (MRU)

And if any of the above FRU or MRU in the path has gone bad or the connection is broken, the SP firmware can't access PNOR flash using FUSE APIs.

The solution is required to isolate effectively the problematic FRU or MRU and once identified, it should be added to error log callouts section and f...