Flash

Table of Contents

• Features Supported
• SysConfig Features
• Features NOT Supported
• Flash Quirks
  • Boot Quirks
    • Example Implementation
  • Configuration Quirks
    • Example Implementation
  • Configuring Quirks in SysConfig
• Important Usage Guidelines
• Example Usage
• API

The Flash driver provides API to read and write to xSPI based flash devices present in the board.

The driver takes care of all sequencing necessary to perform writes across pages and the application need not take care of the programming intricacies.

Features Supported

• APIs to read and write to a flash offset
• Provides API to return flash attributes like block size, page size etc
• API for block erases
• Fallback mechanism in case of PHY tuning failure is currently only supported for the 8d_8d_8d protocol configuration

SysConfig Features

Note

It is strongly recommend to use SysConfig where it is available instead of using direct SW API calls. This will help simplify the SW application and also catch common mistakes early in the development cycle.

• Option to select flash type based on board
• Supported flash devices
  • S28HS512T
  • S25HL512T
  • MX25LM25645G

Features NOT Supported

NA

Flash Quirks

The flash driver provides quirk functions to handle flash-specific configuration requirements and recovery mechanisms. These quirks ensure proper flash initialization and reliable operation across different flash devices and protocols.

These quirk APIs can be passed to the flash driver via SysConfig in the Flash section as board configurations. This allows board-specific implementations to be plugged into the flash initialization sequence.

Boot Quirks

Boot quirks are invoked at the start of flash initialization. The primary function of boot quirks is to:

• Set the flash device into 1s-1s-1s (Single SDR) mode for reliable initial communication
• If the mode switch fails, attempt to recover the flash based on the recovery mechanism specified in the flash device datasheet
• Ensure the flash is in a known good state before proceeding with further configuration

This mechanism is critical during boot to recover from potential flash configuration issues that may have occurred during previous operations or power cycles.

For S28HS512T and S25HL512T flash devices, the SDK provides the following boot quirk APIs:

• Flash_quirkOSPIEarlyFixup - Boot quirk for OSPI interface
• Flash_quirkQSPIEarlyFixup - Boot quirk for QSPI interface

The implementation of these APIs is available in source/board/flash/ospi/flash_nor_ospi.c. These APIs can be configured in SysConfig as the boot quirk function for the respective flash devices.

Example Implementation

int32_t Flash_myBootQuirk(Flash_Config *config)
{
    int32_t status = SystemP_SUCCESS;
    Flash_Attrs *attrs = config->attrs;
 
    /* Your code for handling quirks goes here */
    /* Set the flash in basic configuration */
    /* Recovery mechanism as per flash datasheet */
 
    return status;
}

Configuration Quirks

Configuration quirks are invoked at the end of flash initialization. These quirks handle:

• Flash device-specific configuration requirements
• Protocol-specific settings and optimizations

Configuration quirks ensure that the flash is properly configured for the intended protocol and operational mode after the initial boot sequence completes.

Example Implementation

int32_t Flash_myConfigQuirk(Flash_Config *config)
{
    int32_t status = SystemP_SUCCESS;
    Flash_Attrs *attrs = config->attrs;
 
    /* Your code for handling quirks goes here */
    /* For example: modify flash timing parameters, handle special initialization, etc. */
 
    return status;
}

Configuring Quirks in SysConfig

The boot quirk and configuration quirk function pointers can be configured in the SysConfig Flash module under board configurations. This allows vendor-specific quirk implementations to be registered during flash initialization without modifying the core flash driver code.

Flash Quirk Functions

Important Usage Guidelines

• Typically before writing to an offset, erase the block which corresponds to the offset
• Flashes support multiple erase sizes, conditionally. We provide 2 APIs for this cause in case the flash supports 2 different erase sizes:
  • Flash_eraseBlk()
  • Flash_eraseSector() The larger size can be thought of as a 'block' and the smaller size as a 'sector'. In a flash where both are supported, one can make use of both. In some flashes, the sector configuration has to be fixed before-hand. In such cases the way erase sizes supported will be subject to this configuration. Take care in the flash configuration and the application to make sure the erase APIs are called only with the right configuration.
• Flash writes can only be done to a page size aligned offset, otherwise the write API returns an error
• The sbl_ospi will be typically flashed at location 0x00000000 in the flash memory. So applications using flash should refrain from using this offset. Similarly, the starting of the last block of the flash is used for storing attackVector patterns later used for PHY tuning. So avoid using this offset as well.

Example Usage

Include the below file to access the APIs

#include <board/flash.h>

Flash Read API

    uint32_t offset;
 
    /* Set offset to read from */
    offset = 0;
 
    /* Do the read */
    status = Flash_read(handle, offset, buffer, 100);
    DebugP_assert(SystemP_SUCCESS == status);

Flash Write API

    uint32_t offset;
 
    /* Set offset to write to */
    offset = 0;
 
    /* Do the write */
    status = Flash_write(handle, offset, buffer, 100);
    DebugP_assert(SystemP_SUCCESS == status);

Flash Erase API

    uint32_t offset, blk, page;
 
    /* Set offset to erase */
    offset = 0;
 
    /* Find the block number corresponding to the offset */
    status = Flash_offsetToBlkPage(handle, offset, &blk, &page);
    DebugP_assert(SystemP_SUCCESS == status);
 
    /* Erase the block */
    status = Flash_eraseBlk(handle,blk);
    DebugP_assert(SystemP_SUCCESS == status);

API

APIs for FLASH APIs for FLASH