AMI - Kernel Driver Interaction¶
Initialization¶
Mapping GCQ IP/Payload¶
For each physical function during initialization, the kernel module will parse the PCIe extended capabilities to get access to the VSEC capability.
This capability contains the associated path (PCIe bar/offset & length) to the GCQ IP block and to the shared memory interface.
Partition Table¶
Using the information obtained from the VSEC capability, the driver will parse the top of the shared memory which contains a partition table populated by the AMC on initialization.
The AMI driver uses this data to get the initial AMC status, information used to initialize the GCQ driver via FAL, obtain the AMC log and to read any populated response data.
| Field | Description |
|---|---|
| Magic Number | Unique identifier |
| GCQ Ring Buffer offset/length | Used by the GCQ driver to store CQ/SQ slot data |
| AMC Status | This will be set to a value of 0x1 when the AMC is fully initialized |
| AMC Logging Payload | The offset within the shared memory to be populated with the log |
| AMC Data Payload | The offset within the shared memory to be populated with the response data |
Threading¶
Once the GCQ driver has been configured, the AMI kernel driver will spawn three different threads per physical function.
| Thread | Description |
|---|---|
| Heartbeat Thread | Periodically (every 0.5 seconds) send a message to the AMC and waits for appropriate response. On failure/timeout a bound in callback will be invoked to the upper layer of the driver. |
| Logging Thread | Periodically (every second) checks the logging buffer (in shared memory) populated by the AMC and dumps anything found to info 'dmesg' kernel log. |
| Response Thread | Handles waiting for and parsing responses from from the AMC via the FAL GCQ. |
Normal Operation¶
The AMI/AMC control layer contains the functionality to submit a synchronous request and blocks on a conditional variable waiting for the response from the AMC proxy layer.
The AMC proxy layer is used to form up the lower level requests and interact with the GCQ driver to send requests and wait on responses (via AMC response thread).
If a response isn’t received within the specified timeout the driver layer blocks any further requests as the assumption is the AMC has failed.
In this instance the failure/timeout will be added to the dmesg error log.
Supported Commands¶
The following is a list of the currently supported commands with the associated timeouts.
| Request | Description | Timeout |
|---|---|---|
GCQ_SUBMIT_CMD_GET_GCQ_VERSION | Get the GCQ version | 30 seconds |
GCQ_SUBMIT_CMD_GET_SDR | Get an SDR (Sensor Data Record) | 30 seconds |
GCQ_SUBMIT_CMD_GET_SDR_SIZE | Get an SDR Size | 30 seconds |
GCQ_SUBMIT_CMD_DOWNLOAD_PDI | Request to start PDI Download | 40 minutes |
GCQ_SUBMIT_CMD_DEVICE_BOOT | Select the bootable partition with the flash | 30 seconds |
GCQ_SUBMIT_CMD_COPY_PARTITION | Request to start copying a partition | 1 hour |
GCQ_SUBMIT_CMD_GET_HEARTBEAT | Heartbeat message (on its own thread) | 0.5 seconds |
GCQ_SUBMIT_CMD_EEPROM_READ_WRITE | Read/Write EEPROM request | 30 seconds |
Basic Flow¶
The flow for each request/response is the same which the exception of the heartbeat which has operates on it’s own thread.
The AMC control layer calls into the AMC proxy to form up a request, this request is then sent to the AMC via the FAL GCQ.
The AMC control layer is then blocked waiting for the response.
During this time the AMC response thread reads the incoming data from the FAL GCQ to check for any responses.
If a matching response is received, it is signaled back to the control layer via the conditional variable with success and the data is processed.
If no matching response is found within the timeout period, the conditional variable is signaled via a failure and returned to the calling function.
Page Revision: v. 23