Skip to content
Snippets Groups Projects
Select Git revision
  • master default protected
  • test-all-kernels
  • varodek_develop_fmc-sw
  • v1.1.10
  • v1.1.9
  • v1.1.8
  • v1.1.7
  • v1.1.6
  • v1.1.5
  • v1.1.4
  • v1.1.3
  • v1.1.2
  • v1.1.1
  • v1.1.0
  • v1.0.4
  • v1.0.3
  • v1.0.2
  • v1.0.1
  • v1.0.0
  • v0.9.1
  • v0.9.0
21 results
Find file Blame History Permalink
fmc-introduction.rst 5.62 KiB
Author: Federico Vaga <federico.vaga@cern.ch>

A Summary Of The FMC Standard

Warning

Part of this document assumes that you have access to the VITA-57.1 standard.

Introduction

This framework aims to provide standard support for FMC mezzanine module and FMC carriers as described in VITA-57.1.

The FMC standard describes a generic way to connect IO mezzanines to a carrier with an FPGA on it. How the FPGA gets programmed is not within the scope of this standard because despite the fact that FMC has been thought with an FPGA on one side, this is not an hard requirement.

From a software prospective, and in particular from the prospective of a generic FMC abstraction in kernel, what is interesting is the access to the I2C EEPROM on FMC modules (Rule 5.69). This EEPROM contains identification data (Observation 5.20), which can useful to decide what FPGA code can be loaded or not in order to avoid electrical problems. The identification data format is described by the "Platform Management FRU Information Storage Definition V1.0" (Rule 5.74)

This framework does not implement any cleaver algorithm or data structure to handle the FMC modules or carriers. What it offers is a standardized access to the FMC resources. In order to not re-invent yet another wheel, it reuses internal kernel drivers: I2C adapters, I2C EEPROMs, IPMI FRU.

Ingredients

I2C Bus

Any FMC carrier must provide at least one I2C master. This is necessary to access the FMC module's EEPROM (Rule 5.69) and, optionally, other I2C devices (Rule 5.81).

There is not an explicit limit to the number of FMC slots; the limit imposed is to have no more than four FMC slots per I2C bus. This means, that 8 slots require at least two distinct I2C buses (Rule 5.82).

The I2C buses layout of the FMC carrier is unknown to this framework. For this reason this implementation does not handle it directly. Indeed, other I2C devices on the carrier card can be connected and only the carrier knows what to do with them or other specialized drivers. The FMC carrier driver developer must instantiate all necessary I2C buses (adapters) and inform the FMC framework about which ones to be used for FMC purposes.

The standard is not very rigid on this side, so we have to be flexible on the kernel side. In other words, we have to support the worst case scenario where each FMC slot has a dedicated I2C bus.

I2C EEPROM And Other I2C Devices

The FMC standard says that an I2C EEPROM is mandatory on FMC modules (Rule 5.69). The standard reserves for this EEPROM the address b10100xx (Rule 5.81), where the last two bits (GA[0..1]) are used for geographical addressing within the same I2C bus (Rule 5.82). Other devices can be connected to that bus but they must not use the address prefix reserved for the I2C EEPROM (Rule 5.84).

After a discussion with VITA standards board members about VITA-57.1 Rule 5.69, it was acknowledged that the current standard is not completely clear about what kind of EEPROM is mandatory. Despite the lack of clarity in VITA-57.1, there is some implicit specification via Rule 5.74. This rule says that the EEPROM content must be compliant with the "Platform Management FRU Information Storage Definition V1.0", and here is stated that the EEPROM to use must be 24C02 compatible.

Because of the lack of clarity about the EEPROM type, we cannot assume that all the FMC modules around are using a 24C02-compatible EEPROM. For this reason this framework will automatically instantiate a 24C02 EEPROM for each slot, but it will also offer a mechanism to replace this instance with another one. All standard FMC modules that follow this rule will work out of the box, and the AT24 driver will be used to driver the EEPROM; those which do not respect the standard will need user intervention.

IPMI FRU

The EEPROM content must be formatted as "Platform Management FRU Information Storage Definition V1.0" (Rule 5.74) and it must contain at least the BOARD_INFO area (rule 5.75)

This framework does not provide any direct support to this. If an in-kernel user (e.g. a driver) needs this information, it can access the EEPROM data and parse it using the ipmi-fru API.

This framework will only validate the EEPROM content. This means that it will check if the EEPROM contains, at least, a valid FRU header table.

IPMI Basic Commands

It is not mandatory, and for this reason it is not implemented yet.

Presence

The standard dedicate a signal to detect if an IO mezzanine is present or not (Chapter 5.7: Rule 5.85, Rule 5.86, Rule 5.87). This means that, on software side, we should expect this information to be available through the carrier interface.

Observations

  • As you can see, it is evident that the role of an FMC framework is to glue together different components in order to provides a standardized interface to FMC carriers and mezzanines.
  • The standard says Geographical Addresses when it speaks about the signals GA[0..1]. This does not really work as a carrier geographical addressing schema because the standard does not explicitly say that the number of FMC slots on a carrier is limited to 4. Therefore, this schema works in groups of 4 FMC slots and not for all the available FMC slots (if more than 4). So the geographical addressing must take into account a software schema to distinguish the different I2C buses (the I2C bus number).