2018-03-20 07:58:07 -07:00
|
|
|
// SPDX-License-Identifier: GPL-2.0
|
|
|
|
/* Copyright (c) 2018, Intel Corporation. */
|
|
|
|
|
2022-01-03 19:48:27 -08:00
|
|
|
#include <linux/vmalloc.h>
|
|
|
|
|
2018-03-20 07:58:07 -07:00
|
|
|
#include "ice_common.h"
|
|
|
|
|
|
|
|
/**
|
|
|
|
* ice_aq_read_nvm
|
2019-02-19 15:04:13 -08:00
|
|
|
* @hw: pointer to the HW struct
|
2018-03-20 07:58:07 -07:00
|
|
|
* @module_typeid: module pointer location in words from the NVM beginning
|
|
|
|
* @offset: byte offset from the module beginning
|
|
|
|
* @length: length of the section to be read (in bytes from the offset)
|
|
|
|
* @data: command buffer (size [bytes] = length)
|
|
|
|
* @last_command: tells if this is the last command in a series
|
2020-03-11 18:58:11 -07:00
|
|
|
* @read_shadow_ram: tell if this is a shadow RAM read
|
2018-03-20 07:58:07 -07:00
|
|
|
* @cd: pointer to command details structure or NULL
|
|
|
|
*
|
|
|
|
* Read the NVM using the admin queue commands (0x0701)
|
|
|
|
*/
|
2024-04-19 04:08:53 -04:00
|
|
|
int ice_aq_read_nvm(struct ice_hw *hw, u16 module_typeid, u32 offset,
|
|
|
|
u16 length, void *data, bool last_command,
|
|
|
|
bool read_shadow_ram, struct ice_sq_cd *cd)
|
2018-03-20 07:58:07 -07:00
|
|
|
{
|
|
|
|
struct ice_aq_desc desc;
|
|
|
|
struct ice_aqc_nvm *cmd;
|
|
|
|
|
|
|
|
cmd = &desc.params.nvm;
|
|
|
|
|
2020-03-11 18:58:13 -07:00
|
|
|
if (offset > ICE_AQC_NVM_MAX_OFFSET)
|
2021-10-07 15:58:01 -07:00
|
|
|
return -EINVAL;
|
2018-03-20 07:58:07 -07:00
|
|
|
|
|
|
|
ice_fill_dflt_direct_cmd_desc(&desc, ice_aqc_opc_nvm_read);
|
|
|
|
|
2020-03-11 18:58:11 -07:00
|
|
|
if (!read_shadow_ram && module_typeid == ICE_AQC_NVM_START_POINT)
|
|
|
|
cmd->cmd_flags |= ICE_AQC_NVM_FLASH_ONLY;
|
|
|
|
|
2018-03-20 07:58:07 -07:00
|
|
|
/* If this is the last command in a series, set the proper flag. */
|
|
|
|
if (last_command)
|
|
|
|
cmd->cmd_flags |= ICE_AQC_NVM_LAST_CMD;
|
2018-04-16 09:55:36 -07:00
|
|
|
cmd->module_typeid = cpu_to_le16(module_typeid);
|
|
|
|
cmd->offset_low = cpu_to_le16(offset & 0xFFFF);
|
|
|
|
cmd->offset_high = (offset >> 16) & 0xFF;
|
2018-03-20 07:58:07 -07:00
|
|
|
cmd->length = cpu_to_le16(length);
|
|
|
|
|
|
|
|
return ice_aq_send_cmd(hw, &desc, data, length, cd);
|
|
|
|
}
|
|
|
|
|
2020-03-11 18:58:11 -07:00
|
|
|
/**
|
|
|
|
* ice_read_flat_nvm - Read portion of NVM by flat offset
|
|
|
|
* @hw: pointer to the HW struct
|
|
|
|
* @offset: offset from beginning of NVM
|
|
|
|
* @length: (in) number of bytes to read; (out) number of bytes actually read
|
|
|
|
* @data: buffer to return data in (sized to fit the specified length)
|
|
|
|
* @read_shadow_ram: if true, read from shadow RAM instead of NVM
|
|
|
|
*
|
|
|
|
* Reads a portion of the NVM, as a flat memory space. This function correctly
|
|
|
|
* breaks read requests across Shadow RAM sectors and ensures that no single
|
2020-09-17 13:13:44 -07:00
|
|
|
* read request exceeds the maximum 4KB read for a single AdminQ command.
|
2020-03-11 18:58:11 -07:00
|
|
|
*
|
|
|
|
* Returns a status code on failure. Note that the data pointer may be
|
|
|
|
* partially updated if some reads succeed before a failure.
|
|
|
|
*/
|
2021-10-07 15:56:57 -07:00
|
|
|
int
|
2020-03-11 18:58:11 -07:00
|
|
|
ice_read_flat_nvm(struct ice_hw *hw, u32 offset, u32 *length, u8 *data,
|
|
|
|
bool read_shadow_ram)
|
|
|
|
{
|
|
|
|
u32 inlen = *length;
|
|
|
|
u32 bytes_read = 0;
|
|
|
|
bool last_cmd;
|
2021-10-07 15:59:03 -07:00
|
|
|
int status;
|
2020-03-11 18:58:11 -07:00
|
|
|
|
|
|
|
*length = 0;
|
|
|
|
|
|
|
|
/* Verify the length of the read if this is for the Shadow RAM */
|
2020-10-01 10:31:41 -07:00
|
|
|
if (read_shadow_ram && ((offset + inlen) > (hw->flash.sr_words * 2u))) {
|
2020-09-17 13:13:46 -07:00
|
|
|
ice_debug(hw, ICE_DBG_NVM, "NVM error: requested offset is beyond Shadow RAM limit\n");
|
2021-10-07 15:58:01 -07:00
|
|
|
return -EINVAL;
|
2020-03-11 18:58:11 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
do {
|
|
|
|
u32 read_size, sector_offset;
|
|
|
|
|
2020-09-17 13:13:44 -07:00
|
|
|
/* ice_aq_read_nvm cannot read more than 4KB at a time.
|
2020-03-11 18:58:11 -07:00
|
|
|
* Additionally, a read from the Shadow RAM may not cross over
|
|
|
|
* a sector boundary. Conveniently, the sector size is also
|
2020-09-17 13:13:44 -07:00
|
|
|
* 4KB.
|
2020-03-11 18:58:11 -07:00
|
|
|
*/
|
|
|
|
sector_offset = offset % ICE_AQ_MAX_BUF_LEN;
|
|
|
|
read_size = min_t(u32, ICE_AQ_MAX_BUF_LEN - sector_offset,
|
|
|
|
inlen - bytes_read);
|
|
|
|
|
|
|
|
last_cmd = !(bytes_read + read_size < inlen);
|
|
|
|
|
|
|
|
status = ice_aq_read_nvm(hw, ICE_AQC_NVM_START_POINT,
|
|
|
|
offset, read_size,
|
|
|
|
data + bytes_read, last_cmd,
|
|
|
|
read_shadow_ram, NULL);
|
|
|
|
if (status)
|
|
|
|
break;
|
|
|
|
|
|
|
|
bytes_read += read_size;
|
|
|
|
offset += read_size;
|
|
|
|
} while (!last_cmd);
|
|
|
|
|
|
|
|
*length = bytes_read;
|
|
|
|
return status;
|
|
|
|
}
|
|
|
|
|
2020-07-23 17:22:01 -07:00
|
|
|
/**
|
|
|
|
* ice_aq_update_nvm
|
|
|
|
* @hw: pointer to the HW struct
|
|
|
|
* @module_typeid: module pointer location in words from the NVM beginning
|
|
|
|
* @offset: byte offset from the module beginning
|
|
|
|
* @length: length of the section to be written (in bytes from the offset)
|
|
|
|
* @data: command buffer (size [bytes] = length)
|
|
|
|
* @last_command: tells if this is the last command in a series
|
|
|
|
* @command_flags: command parameters
|
|
|
|
* @cd: pointer to command details structure or NULL
|
|
|
|
*
|
|
|
|
* Update the NVM using the admin queue commands (0x0703)
|
|
|
|
*/
|
2021-10-07 15:56:57 -07:00
|
|
|
int
|
2020-07-23 17:22:01 -07:00
|
|
|
ice_aq_update_nvm(struct ice_hw *hw, u16 module_typeid, u32 offset,
|
|
|
|
u16 length, void *data, bool last_command, u8 command_flags,
|
|
|
|
struct ice_sq_cd *cd)
|
|
|
|
{
|
|
|
|
struct ice_aq_desc desc;
|
|
|
|
struct ice_aqc_nvm *cmd;
|
|
|
|
|
|
|
|
cmd = &desc.params.nvm;
|
|
|
|
|
|
|
|
/* In offset the highest byte must be zeroed. */
|
|
|
|
if (offset & 0xFF000000)
|
2021-10-07 15:58:01 -07:00
|
|
|
return -EINVAL;
|
2020-07-23 17:22:01 -07:00
|
|
|
|
|
|
|
ice_fill_dflt_direct_cmd_desc(&desc, ice_aqc_opc_nvm_write);
|
|
|
|
|
|
|
|
cmd->cmd_flags |= command_flags;
|
|
|
|
|
|
|
|
/* If this is the last command in a series, set the proper flag. */
|
|
|
|
if (last_command)
|
|
|
|
cmd->cmd_flags |= ICE_AQC_NVM_LAST_CMD;
|
|
|
|
cmd->module_typeid = cpu_to_le16(module_typeid);
|
|
|
|
cmd->offset_low = cpu_to_le16(offset & 0xFFFF);
|
|
|
|
cmd->offset_high = (offset >> 16) & 0xFF;
|
|
|
|
cmd->length = cpu_to_le16(length);
|
|
|
|
|
|
|
|
desc.flags |= cpu_to_le16(ICE_AQ_FLAG_RD);
|
|
|
|
|
|
|
|
return ice_aq_send_cmd(hw, &desc, data, length, cd);
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* ice_aq_erase_nvm
|
|
|
|
* @hw: pointer to the HW struct
|
|
|
|
* @module_typeid: module pointer location in words from the NVM beginning
|
|
|
|
* @cd: pointer to command details structure or NULL
|
|
|
|
*
|
|
|
|
* Erase the NVM sector using the admin queue commands (0x0702)
|
|
|
|
*/
|
2021-10-07 15:59:03 -07:00
|
|
|
int ice_aq_erase_nvm(struct ice_hw *hw, u16 module_typeid, struct ice_sq_cd *cd)
|
2020-07-23 17:22:01 -07:00
|
|
|
{
|
|
|
|
struct ice_aq_desc desc;
|
|
|
|
struct ice_aqc_nvm *cmd;
|
|
|
|
|
|
|
|
cmd = &desc.params.nvm;
|
|
|
|
|
|
|
|
ice_fill_dflt_direct_cmd_desc(&desc, ice_aqc_opc_nvm_erase);
|
|
|
|
|
|
|
|
cmd->module_typeid = cpu_to_le16(module_typeid);
|
|
|
|
cmd->length = cpu_to_le16(ICE_AQC_NVM_ERASE_LEN);
|
|
|
|
cmd->offset_low = 0;
|
|
|
|
cmd->offset_high = 0;
|
|
|
|
|
|
|
|
return ice_aq_send_cmd(hw, &desc, NULL, 0, cd);
|
|
|
|
}
|
|
|
|
|
2018-03-20 07:58:07 -07:00
|
|
|
/**
|
|
|
|
* ice_read_sr_word_aq - Reads Shadow RAM via AQ
|
|
|
|
* @hw: pointer to the HW structure
|
|
|
|
* @offset: offset of the Shadow RAM word to read (0x000000 - 0x001FFF)
|
|
|
|
* @data: word read from the Shadow RAM
|
|
|
|
*
|
2020-03-11 18:58:11 -07:00
|
|
|
* Reads one 16 bit word from the Shadow RAM using ice_read_flat_nvm.
|
2018-03-20 07:58:07 -07:00
|
|
|
*/
|
2021-10-07 15:59:03 -07:00
|
|
|
static int ice_read_sr_word_aq(struct ice_hw *hw, u16 offset, u16 *data)
|
2018-03-20 07:58:07 -07:00
|
|
|
{
|
2020-03-11 18:58:11 -07:00
|
|
|
u32 bytes = sizeof(u16);
|
2020-03-11 18:58:10 -07:00
|
|
|
__le16 data_local;
|
2021-10-07 15:59:03 -07:00
|
|
|
int status;
|
2018-03-20 07:58:07 -07:00
|
|
|
|
2020-03-11 18:58:11 -07:00
|
|
|
/* Note that ice_read_flat_nvm takes into account the 4Kb AdminQ and
|
|
|
|
* Shadow RAM sector restrictions necessary when reading from the NVM.
|
|
|
|
*/
|
|
|
|
status = ice_read_flat_nvm(hw, offset * sizeof(u16), &bytes,
|
2020-09-17 13:13:45 -07:00
|
|
|
(__force u8 *)&data_local, true);
|
2020-03-11 18:58:11 -07:00
|
|
|
if (status)
|
|
|
|
return status;
|
2018-03-20 07:58:07 -07:00
|
|
|
|
2020-03-11 18:58:11 -07:00
|
|
|
*data = le16_to_cpu(data_local);
|
|
|
|
return 0;
|
2018-03-20 07:58:07 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* ice_acquire_nvm - Generic request for acquiring the NVM ownership
|
|
|
|
* @hw: pointer to the HW structure
|
|
|
|
* @access: NVM access type (read or write)
|
|
|
|
*
|
|
|
|
* This function will request NVM ownership.
|
|
|
|
*/
|
2021-10-07 15:59:03 -07:00
|
|
|
int ice_acquire_nvm(struct ice_hw *hw, enum ice_aq_res_access_type access)
|
2018-03-20 07:58:07 -07:00
|
|
|
{
|
2020-10-01 10:31:41 -07:00
|
|
|
if (hw->flash.blank_nvm_mode)
|
2018-03-20 07:58:07 -07:00
|
|
|
return 0;
|
|
|
|
|
2018-08-09 06:29:46 -07:00
|
|
|
return ice_acquire_res(hw, ICE_NVM_RES_ID, access, ICE_NVM_TIMEOUT);
|
2018-03-20 07:58:07 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* ice_release_nvm - Generic request for releasing the NVM ownership
|
|
|
|
* @hw: pointer to the HW structure
|
|
|
|
*
|
|
|
|
* This function will release NVM ownership.
|
|
|
|
*/
|
2020-03-11 18:58:14 -07:00
|
|
|
void ice_release_nvm(struct ice_hw *hw)
|
2018-03-20 07:58:07 -07:00
|
|
|
{
|
2020-10-01 10:31:41 -07:00
|
|
|
if (hw->flash.blank_nvm_mode)
|
2018-03-20 07:58:07 -07:00
|
|
|
return;
|
|
|
|
|
|
|
|
ice_release_res(hw, ICE_NVM_RES_ID);
|
|
|
|
}
|
|
|
|
|
ice: introduce function for reading from flash modules
When reading from the flash memory of the device, the ice driver has two
interfaces available to it. First, it can use a mediated interface via
firmware that allows specifying a module ID. This allows reading from
specific modules of the active flash bank.
The second interface available is to perform flat reads. This allows
complete access to the entire flash. However, using it requires the
software to handle calculating module location and interpret pointer
addresses.
While most data required is accessible through the convenient first
interface, certain flash contents are not. This includes the CSS header
information associated with the Option ROM and NVM banks, as well as any
access to the "inactive" banks used as scratch space for performing
flash updates.
In order to access all of the relevant flash contents, software must use
the flat reads. Rather than forcing all flows to perform flat read
calculations, introduce a new abstraction for reading from the flash:
ice_read_flash_module. This function provides an abstraction for reading
from either the active or inactive flash bank at the requested module.
This interface is very similar to the abstraction provided via firmware,
but allows access to additional modules, as well as providing
a mechanism to request access to both flash banks.
At first glance, it might make sense for this abstraction to allow
specifying precisely which bank (1st or 2nd) the caller wishes to read.
This is simpler to implement but more difficult to use. In practice,
most callers only know whether they want the active bank, or the
inactive bank. Rather than force callers to determine for themselves
which bank to read from, implement ice_read_flash_module in terms of
"active" vs "inactive". This significantly simplifies the implementation
at the caller level and is a more useful abstraction over the flash
contents.
Make use of this new interface to refactor reading of the main NVM
version information. Instead of using the firmware's mediated ShadowRAM
function, use the ice_read_flash_module abstraction.
To do this, notice that most reads of the NVM are going to be in 2-byte
word chunks. To simplify using ice_read_flash_module for this case,
ice_read_nvm_module is introduced. This is a simple wrapper around
ice_read_flash_module which takes the correct pointer address for the
NVM bank, and forces the 2-byte word format onto the caller.
When reading the NVM versions, some fields are read from the Shadow RAM.
The Shadow RAM is the first 64KB of flash memory, and is populated
during device load. Most fields are copied from a section within the
active NVM bank. In order to read this data from both the active and
inactive NVM banks, we need to read not from the first 64KB of flash,
but instead from the correct offset into the NVM bank. Introduce
ice_read_nvm_sr_copy for this purpose. This function wraps around
ice_read_nvm_module and has the same interface as the ice_read_sr_word,
with the exception of allowing the caller to specify whether to read the
active or inactive flash bank.
With this change, it is now trivial to refactor ice_get_nvm_ver_info to
read using the software mediated ice_read_flash_module interface instead
of relying on the firmware mediated interface. This will be used in the
following change to implement support for stored versions in the devlink
info report.
Additionally, the overall ice_read_flash_module interface will be used
and extended to support all three major flash banks, and additionally to
support reading the flash image security revision information.
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Tested-by: Tony Brelinski <tonyx.brelinski@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2020-10-01 10:31:43 -07:00
|
|
|
/**
|
|
|
|
* ice_get_flash_bank_offset - Get offset into requested flash bank
|
|
|
|
* @hw: pointer to the HW structure
|
|
|
|
* @bank: whether to read from the active or inactive flash bank
|
|
|
|
* @module: the module to read from
|
|
|
|
*
|
|
|
|
* Based on the module, lookup the module offset from the beginning of the
|
|
|
|
* flash.
|
|
|
|
*
|
|
|
|
* Returns the flash offset. Note that a value of zero is invalid and must be
|
|
|
|
* treated as an error.
|
|
|
|
*/
|
|
|
|
static u32 ice_get_flash_bank_offset(struct ice_hw *hw, enum ice_bank_select bank, u16 module)
|
|
|
|
{
|
|
|
|
struct ice_bank_info *banks = &hw->flash.banks;
|
|
|
|
enum ice_flash_bank active_bank;
|
|
|
|
bool second_bank_active;
|
|
|
|
u32 offset, size;
|
|
|
|
|
|
|
|
switch (module) {
|
|
|
|
case ICE_SR_1ST_NVM_BANK_PTR:
|
|
|
|
offset = banks->nvm_ptr;
|
|
|
|
size = banks->nvm_size;
|
|
|
|
active_bank = banks->nvm_bank;
|
|
|
|
break;
|
|
|
|
case ICE_SR_1ST_OROM_BANK_PTR:
|
|
|
|
offset = banks->orom_ptr;
|
|
|
|
size = banks->orom_size;
|
|
|
|
active_bank = banks->orom_bank;
|
|
|
|
break;
|
|
|
|
case ICE_SR_NETLIST_BANK_PTR:
|
|
|
|
offset = banks->netlist_ptr;
|
|
|
|
size = banks->netlist_size;
|
|
|
|
active_bank = banks->netlist_bank;
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
ice_debug(hw, ICE_DBG_NVM, "Unexpected value for flash module: 0x%04x\n", module);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
switch (active_bank) {
|
|
|
|
case ICE_1ST_FLASH_BANK:
|
|
|
|
second_bank_active = false;
|
|
|
|
break;
|
|
|
|
case ICE_2ND_FLASH_BANK:
|
|
|
|
second_bank_active = true;
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
ice_debug(hw, ICE_DBG_NVM, "Unexpected value for active flash bank: %u\n",
|
|
|
|
active_bank);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* The second flash bank is stored immediately following the first
|
|
|
|
* bank. Based on whether the 1st or 2nd bank is active, and whether
|
|
|
|
* we want the active or inactive bank, calculate the desired offset.
|
|
|
|
*/
|
|
|
|
switch (bank) {
|
|
|
|
case ICE_ACTIVE_FLASH_BANK:
|
|
|
|
return offset + (second_bank_active ? size : 0);
|
|
|
|
case ICE_INACTIVE_FLASH_BANK:
|
|
|
|
return offset + (second_bank_active ? 0 : size);
|
|
|
|
}
|
|
|
|
|
|
|
|
ice_debug(hw, ICE_DBG_NVM, "Unexpected value for flash bank selection: %u\n", bank);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* ice_read_flash_module - Read a word from one of the main NVM modules
|
|
|
|
* @hw: pointer to the HW structure
|
|
|
|
* @bank: which bank of the module to read
|
|
|
|
* @module: the module to read
|
|
|
|
* @offset: the offset into the module in bytes
|
|
|
|
* @data: storage for the word read from the flash
|
|
|
|
* @length: bytes of data to read
|
|
|
|
*
|
|
|
|
* Read data from the specified flash module. The bank parameter indicates
|
|
|
|
* whether or not to read from the active bank or the inactive bank of that
|
|
|
|
* module.
|
|
|
|
*
|
|
|
|
* The word will be read using flat NVM access, and relies on the
|
|
|
|
* hw->flash.banks data being setup by ice_determine_active_flash_banks()
|
|
|
|
* during initialization.
|
|
|
|
*/
|
2021-10-07 15:56:57 -07:00
|
|
|
static int
|
ice: introduce function for reading from flash modules
When reading from the flash memory of the device, the ice driver has two
interfaces available to it. First, it can use a mediated interface via
firmware that allows specifying a module ID. This allows reading from
specific modules of the active flash bank.
The second interface available is to perform flat reads. This allows
complete access to the entire flash. However, using it requires the
software to handle calculating module location and interpret pointer
addresses.
While most data required is accessible through the convenient first
interface, certain flash contents are not. This includes the CSS header
information associated with the Option ROM and NVM banks, as well as any
access to the "inactive" banks used as scratch space for performing
flash updates.
In order to access all of the relevant flash contents, software must use
the flat reads. Rather than forcing all flows to perform flat read
calculations, introduce a new abstraction for reading from the flash:
ice_read_flash_module. This function provides an abstraction for reading
from either the active or inactive flash bank at the requested module.
This interface is very similar to the abstraction provided via firmware,
but allows access to additional modules, as well as providing
a mechanism to request access to both flash banks.
At first glance, it might make sense for this abstraction to allow
specifying precisely which bank (1st or 2nd) the caller wishes to read.
This is simpler to implement but more difficult to use. In practice,
most callers only know whether they want the active bank, or the
inactive bank. Rather than force callers to determine for themselves
which bank to read from, implement ice_read_flash_module in terms of
"active" vs "inactive". This significantly simplifies the implementation
at the caller level and is a more useful abstraction over the flash
contents.
Make use of this new interface to refactor reading of the main NVM
version information. Instead of using the firmware's mediated ShadowRAM
function, use the ice_read_flash_module abstraction.
To do this, notice that most reads of the NVM are going to be in 2-byte
word chunks. To simplify using ice_read_flash_module for this case,
ice_read_nvm_module is introduced. This is a simple wrapper around
ice_read_flash_module which takes the correct pointer address for the
NVM bank, and forces the 2-byte word format onto the caller.
When reading the NVM versions, some fields are read from the Shadow RAM.
The Shadow RAM is the first 64KB of flash memory, and is populated
during device load. Most fields are copied from a section within the
active NVM bank. In order to read this data from both the active and
inactive NVM banks, we need to read not from the first 64KB of flash,
but instead from the correct offset into the NVM bank. Introduce
ice_read_nvm_sr_copy for this purpose. This function wraps around
ice_read_nvm_module and has the same interface as the ice_read_sr_word,
with the exception of allowing the caller to specify whether to read the
active or inactive flash bank.
With this change, it is now trivial to refactor ice_get_nvm_ver_info to
read using the software mediated ice_read_flash_module interface instead
of relying on the firmware mediated interface. This will be used in the
following change to implement support for stored versions in the devlink
info report.
Additionally, the overall ice_read_flash_module interface will be used
and extended to support all three major flash banks, and additionally to
support reading the flash image security revision information.
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Tested-by: Tony Brelinski <tonyx.brelinski@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2020-10-01 10:31:43 -07:00
|
|
|
ice_read_flash_module(struct ice_hw *hw, enum ice_bank_select bank, u16 module,
|
|
|
|
u32 offset, u8 *data, u32 length)
|
|
|
|
{
|
2021-10-07 15:56:57 -07:00
|
|
|
int status;
|
ice: introduce function for reading from flash modules
When reading from the flash memory of the device, the ice driver has two
interfaces available to it. First, it can use a mediated interface via
firmware that allows specifying a module ID. This allows reading from
specific modules of the active flash bank.
The second interface available is to perform flat reads. This allows
complete access to the entire flash. However, using it requires the
software to handle calculating module location and interpret pointer
addresses.
While most data required is accessible through the convenient first
interface, certain flash contents are not. This includes the CSS header
information associated with the Option ROM and NVM banks, as well as any
access to the "inactive" banks used as scratch space for performing
flash updates.
In order to access all of the relevant flash contents, software must use
the flat reads. Rather than forcing all flows to perform flat read
calculations, introduce a new abstraction for reading from the flash:
ice_read_flash_module. This function provides an abstraction for reading
from either the active or inactive flash bank at the requested module.
This interface is very similar to the abstraction provided via firmware,
but allows access to additional modules, as well as providing
a mechanism to request access to both flash banks.
At first glance, it might make sense for this abstraction to allow
specifying precisely which bank (1st or 2nd) the caller wishes to read.
This is simpler to implement but more difficult to use. In practice,
most callers only know whether they want the active bank, or the
inactive bank. Rather than force callers to determine for themselves
which bank to read from, implement ice_read_flash_module in terms of
"active" vs "inactive". This significantly simplifies the implementation
at the caller level and is a more useful abstraction over the flash
contents.
Make use of this new interface to refactor reading of the main NVM
version information. Instead of using the firmware's mediated ShadowRAM
function, use the ice_read_flash_module abstraction.
To do this, notice that most reads of the NVM are going to be in 2-byte
word chunks. To simplify using ice_read_flash_module for this case,
ice_read_nvm_module is introduced. This is a simple wrapper around
ice_read_flash_module which takes the correct pointer address for the
NVM bank, and forces the 2-byte word format onto the caller.
When reading the NVM versions, some fields are read from the Shadow RAM.
The Shadow RAM is the first 64KB of flash memory, and is populated
during device load. Most fields are copied from a section within the
active NVM bank. In order to read this data from both the active and
inactive NVM banks, we need to read not from the first 64KB of flash,
but instead from the correct offset into the NVM bank. Introduce
ice_read_nvm_sr_copy for this purpose. This function wraps around
ice_read_nvm_module and has the same interface as the ice_read_sr_word,
with the exception of allowing the caller to specify whether to read the
active or inactive flash bank.
With this change, it is now trivial to refactor ice_get_nvm_ver_info to
read using the software mediated ice_read_flash_module interface instead
of relying on the firmware mediated interface. This will be used in the
following change to implement support for stored versions in the devlink
info report.
Additionally, the overall ice_read_flash_module interface will be used
and extended to support all three major flash banks, and additionally to
support reading the flash image security revision information.
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Tested-by: Tony Brelinski <tonyx.brelinski@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2020-10-01 10:31:43 -07:00
|
|
|
u32 start;
|
|
|
|
|
|
|
|
start = ice_get_flash_bank_offset(hw, bank, module);
|
|
|
|
if (!start) {
|
|
|
|
ice_debug(hw, ICE_DBG_NVM, "Unable to calculate flash bank offset for module 0x%04x\n",
|
|
|
|
module);
|
2021-10-07 15:58:01 -07:00
|
|
|
return -EINVAL;
|
ice: introduce function for reading from flash modules
When reading from the flash memory of the device, the ice driver has two
interfaces available to it. First, it can use a mediated interface via
firmware that allows specifying a module ID. This allows reading from
specific modules of the active flash bank.
The second interface available is to perform flat reads. This allows
complete access to the entire flash. However, using it requires the
software to handle calculating module location and interpret pointer
addresses.
While most data required is accessible through the convenient first
interface, certain flash contents are not. This includes the CSS header
information associated with the Option ROM and NVM banks, as well as any
access to the "inactive" banks used as scratch space for performing
flash updates.
In order to access all of the relevant flash contents, software must use
the flat reads. Rather than forcing all flows to perform flat read
calculations, introduce a new abstraction for reading from the flash:
ice_read_flash_module. This function provides an abstraction for reading
from either the active or inactive flash bank at the requested module.
This interface is very similar to the abstraction provided via firmware,
but allows access to additional modules, as well as providing
a mechanism to request access to both flash banks.
At first glance, it might make sense for this abstraction to allow
specifying precisely which bank (1st or 2nd) the caller wishes to read.
This is simpler to implement but more difficult to use. In practice,
most callers only know whether they want the active bank, or the
inactive bank. Rather than force callers to determine for themselves
which bank to read from, implement ice_read_flash_module in terms of
"active" vs "inactive". This significantly simplifies the implementation
at the caller level and is a more useful abstraction over the flash
contents.
Make use of this new interface to refactor reading of the main NVM
version information. Instead of using the firmware's mediated ShadowRAM
function, use the ice_read_flash_module abstraction.
To do this, notice that most reads of the NVM are going to be in 2-byte
word chunks. To simplify using ice_read_flash_module for this case,
ice_read_nvm_module is introduced. This is a simple wrapper around
ice_read_flash_module which takes the correct pointer address for the
NVM bank, and forces the 2-byte word format onto the caller.
When reading the NVM versions, some fields are read from the Shadow RAM.
The Shadow RAM is the first 64KB of flash memory, and is populated
during device load. Most fields are copied from a section within the
active NVM bank. In order to read this data from both the active and
inactive NVM banks, we need to read not from the first 64KB of flash,
but instead from the correct offset into the NVM bank. Introduce
ice_read_nvm_sr_copy for this purpose. This function wraps around
ice_read_nvm_module and has the same interface as the ice_read_sr_word,
with the exception of allowing the caller to specify whether to read the
active or inactive flash bank.
With this change, it is now trivial to refactor ice_get_nvm_ver_info to
read using the software mediated ice_read_flash_module interface instead
of relying on the firmware mediated interface. This will be used in the
following change to implement support for stored versions in the devlink
info report.
Additionally, the overall ice_read_flash_module interface will be used
and extended to support all three major flash banks, and additionally to
support reading the flash image security revision information.
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Tested-by: Tony Brelinski <tonyx.brelinski@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2020-10-01 10:31:43 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
status = ice_acquire_nvm(hw, ICE_RES_READ);
|
|
|
|
if (status)
|
|
|
|
return status;
|
|
|
|
|
|
|
|
status = ice_read_flat_nvm(hw, start + offset, &length, data, false);
|
|
|
|
|
|
|
|
ice_release_nvm(hw);
|
|
|
|
|
|
|
|
return status;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* ice_read_nvm_module - Read from the active main NVM module
|
|
|
|
* @hw: pointer to the HW structure
|
|
|
|
* @bank: whether to read from active or inactive NVM module
|
|
|
|
* @offset: offset into the NVM module to read, in words
|
|
|
|
* @data: storage for returned word value
|
|
|
|
*
|
|
|
|
* Read the specified word from the active NVM module. This includes the CSS
|
|
|
|
* header at the start of the NVM module.
|
|
|
|
*/
|
2021-10-07 15:56:57 -07:00
|
|
|
static int
|
ice: introduce function for reading from flash modules
When reading from the flash memory of the device, the ice driver has two
interfaces available to it. First, it can use a mediated interface via
firmware that allows specifying a module ID. This allows reading from
specific modules of the active flash bank.
The second interface available is to perform flat reads. This allows
complete access to the entire flash. However, using it requires the
software to handle calculating module location and interpret pointer
addresses.
While most data required is accessible through the convenient first
interface, certain flash contents are not. This includes the CSS header
information associated with the Option ROM and NVM banks, as well as any
access to the "inactive" banks used as scratch space for performing
flash updates.
In order to access all of the relevant flash contents, software must use
the flat reads. Rather than forcing all flows to perform flat read
calculations, introduce a new abstraction for reading from the flash:
ice_read_flash_module. This function provides an abstraction for reading
from either the active or inactive flash bank at the requested module.
This interface is very similar to the abstraction provided via firmware,
but allows access to additional modules, as well as providing
a mechanism to request access to both flash banks.
At first glance, it might make sense for this abstraction to allow
specifying precisely which bank (1st or 2nd) the caller wishes to read.
This is simpler to implement but more difficult to use. In practice,
most callers only know whether they want the active bank, or the
inactive bank. Rather than force callers to determine for themselves
which bank to read from, implement ice_read_flash_module in terms of
"active" vs "inactive". This significantly simplifies the implementation
at the caller level and is a more useful abstraction over the flash
contents.
Make use of this new interface to refactor reading of the main NVM
version information. Instead of using the firmware's mediated ShadowRAM
function, use the ice_read_flash_module abstraction.
To do this, notice that most reads of the NVM are going to be in 2-byte
word chunks. To simplify using ice_read_flash_module for this case,
ice_read_nvm_module is introduced. This is a simple wrapper around
ice_read_flash_module which takes the correct pointer address for the
NVM bank, and forces the 2-byte word format onto the caller.
When reading the NVM versions, some fields are read from the Shadow RAM.
The Shadow RAM is the first 64KB of flash memory, and is populated
during device load. Most fields are copied from a section within the
active NVM bank. In order to read this data from both the active and
inactive NVM banks, we need to read not from the first 64KB of flash,
but instead from the correct offset into the NVM bank. Introduce
ice_read_nvm_sr_copy for this purpose. This function wraps around
ice_read_nvm_module and has the same interface as the ice_read_sr_word,
with the exception of allowing the caller to specify whether to read the
active or inactive flash bank.
With this change, it is now trivial to refactor ice_get_nvm_ver_info to
read using the software mediated ice_read_flash_module interface instead
of relying on the firmware mediated interface. This will be used in the
following change to implement support for stored versions in the devlink
info report.
Additionally, the overall ice_read_flash_module interface will be used
and extended to support all three major flash banks, and additionally to
support reading the flash image security revision information.
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Tested-by: Tony Brelinski <tonyx.brelinski@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2020-10-01 10:31:43 -07:00
|
|
|
ice_read_nvm_module(struct ice_hw *hw, enum ice_bank_select bank, u32 offset, u16 *data)
|
|
|
|
{
|
|
|
|
__le16 data_local;
|
2021-10-07 15:59:03 -07:00
|
|
|
int status;
|
ice: introduce function for reading from flash modules
When reading from the flash memory of the device, the ice driver has two
interfaces available to it. First, it can use a mediated interface via
firmware that allows specifying a module ID. This allows reading from
specific modules of the active flash bank.
The second interface available is to perform flat reads. This allows
complete access to the entire flash. However, using it requires the
software to handle calculating module location and interpret pointer
addresses.
While most data required is accessible through the convenient first
interface, certain flash contents are not. This includes the CSS header
information associated with the Option ROM and NVM banks, as well as any
access to the "inactive" banks used as scratch space for performing
flash updates.
In order to access all of the relevant flash contents, software must use
the flat reads. Rather than forcing all flows to perform flat read
calculations, introduce a new abstraction for reading from the flash:
ice_read_flash_module. This function provides an abstraction for reading
from either the active or inactive flash bank at the requested module.
This interface is very similar to the abstraction provided via firmware,
but allows access to additional modules, as well as providing
a mechanism to request access to both flash banks.
At first glance, it might make sense for this abstraction to allow
specifying precisely which bank (1st or 2nd) the caller wishes to read.
This is simpler to implement but more difficult to use. In practice,
most callers only know whether they want the active bank, or the
inactive bank. Rather than force callers to determine for themselves
which bank to read from, implement ice_read_flash_module in terms of
"active" vs "inactive". This significantly simplifies the implementation
at the caller level and is a more useful abstraction over the flash
contents.
Make use of this new interface to refactor reading of the main NVM
version information. Instead of using the firmware's mediated ShadowRAM
function, use the ice_read_flash_module abstraction.
To do this, notice that most reads of the NVM are going to be in 2-byte
word chunks. To simplify using ice_read_flash_module for this case,
ice_read_nvm_module is introduced. This is a simple wrapper around
ice_read_flash_module which takes the correct pointer address for the
NVM bank, and forces the 2-byte word format onto the caller.
When reading the NVM versions, some fields are read from the Shadow RAM.
The Shadow RAM is the first 64KB of flash memory, and is populated
during device load. Most fields are copied from a section within the
active NVM bank. In order to read this data from both the active and
inactive NVM banks, we need to read not from the first 64KB of flash,
but instead from the correct offset into the NVM bank. Introduce
ice_read_nvm_sr_copy for this purpose. This function wraps around
ice_read_nvm_module and has the same interface as the ice_read_sr_word,
with the exception of allowing the caller to specify whether to read the
active or inactive flash bank.
With this change, it is now trivial to refactor ice_get_nvm_ver_info to
read using the software mediated ice_read_flash_module interface instead
of relying on the firmware mediated interface. This will be used in the
following change to implement support for stored versions in the devlink
info report.
Additionally, the overall ice_read_flash_module interface will be used
and extended to support all three major flash banks, and additionally to
support reading the flash image security revision information.
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Tested-by: Tony Brelinski <tonyx.brelinski@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2020-10-01 10:31:43 -07:00
|
|
|
|
|
|
|
status = ice_read_flash_module(hw, bank, ICE_SR_1ST_NVM_BANK_PTR, offset * sizeof(u16),
|
|
|
|
(__force u8 *)&data_local, sizeof(u16));
|
|
|
|
if (!status)
|
|
|
|
*data = le16_to_cpu(data_local);
|
|
|
|
|
|
|
|
return status;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* ice_read_nvm_sr_copy - Read a word from the Shadow RAM copy in the NVM bank
|
|
|
|
* @hw: pointer to the HW structure
|
|
|
|
* @bank: whether to read from the active or inactive NVM module
|
|
|
|
* @offset: offset into the Shadow RAM copy to read, in words
|
|
|
|
* @data: storage for returned word value
|
|
|
|
*
|
|
|
|
* Read the specified word from the copy of the Shadow RAM found in the
|
|
|
|
* specified NVM module.
|
|
|
|
*/
|
2021-10-07 15:56:57 -07:00
|
|
|
static int
|
ice: introduce function for reading from flash modules
When reading from the flash memory of the device, the ice driver has two
interfaces available to it. First, it can use a mediated interface via
firmware that allows specifying a module ID. This allows reading from
specific modules of the active flash bank.
The second interface available is to perform flat reads. This allows
complete access to the entire flash. However, using it requires the
software to handle calculating module location and interpret pointer
addresses.
While most data required is accessible through the convenient first
interface, certain flash contents are not. This includes the CSS header
information associated with the Option ROM and NVM banks, as well as any
access to the "inactive" banks used as scratch space for performing
flash updates.
In order to access all of the relevant flash contents, software must use
the flat reads. Rather than forcing all flows to perform flat read
calculations, introduce a new abstraction for reading from the flash:
ice_read_flash_module. This function provides an abstraction for reading
from either the active or inactive flash bank at the requested module.
This interface is very similar to the abstraction provided via firmware,
but allows access to additional modules, as well as providing
a mechanism to request access to both flash banks.
At first glance, it might make sense for this abstraction to allow
specifying precisely which bank (1st or 2nd) the caller wishes to read.
This is simpler to implement but more difficult to use. In practice,
most callers only know whether they want the active bank, or the
inactive bank. Rather than force callers to determine for themselves
which bank to read from, implement ice_read_flash_module in terms of
"active" vs "inactive". This significantly simplifies the implementation
at the caller level and is a more useful abstraction over the flash
contents.
Make use of this new interface to refactor reading of the main NVM
version information. Instead of using the firmware's mediated ShadowRAM
function, use the ice_read_flash_module abstraction.
To do this, notice that most reads of the NVM are going to be in 2-byte
word chunks. To simplify using ice_read_flash_module for this case,
ice_read_nvm_module is introduced. This is a simple wrapper around
ice_read_flash_module which takes the correct pointer address for the
NVM bank, and forces the 2-byte word format onto the caller.
When reading the NVM versions, some fields are read from the Shadow RAM.
The Shadow RAM is the first 64KB of flash memory, and is populated
during device load. Most fields are copied from a section within the
active NVM bank. In order to read this data from both the active and
inactive NVM banks, we need to read not from the first 64KB of flash,
but instead from the correct offset into the NVM bank. Introduce
ice_read_nvm_sr_copy for this purpose. This function wraps around
ice_read_nvm_module and has the same interface as the ice_read_sr_word,
with the exception of allowing the caller to specify whether to read the
active or inactive flash bank.
With this change, it is now trivial to refactor ice_get_nvm_ver_info to
read using the software mediated ice_read_flash_module interface instead
of relying on the firmware mediated interface. This will be used in the
following change to implement support for stored versions in the devlink
info report.
Additionally, the overall ice_read_flash_module interface will be used
and extended to support all three major flash banks, and additionally to
support reading the flash image security revision information.
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Tested-by: Tony Brelinski <tonyx.brelinski@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2020-10-01 10:31:43 -07:00
|
|
|
ice_read_nvm_sr_copy(struct ice_hw *hw, enum ice_bank_select bank, u32 offset, u16 *data)
|
|
|
|
{
|
|
|
|
return ice_read_nvm_module(hw, bank, ICE_NVM_SR_COPY_WORD_OFFSET + offset, data);
|
|
|
|
}
|
|
|
|
|
2020-11-11 16:43:29 -08:00
|
|
|
/**
|
|
|
|
* ice_read_netlist_module - Read data from the netlist module area
|
|
|
|
* @hw: pointer to the HW structure
|
|
|
|
* @bank: whether to read from the active or inactive module
|
|
|
|
* @offset: offset into the netlist to read from
|
|
|
|
* @data: storage for returned word value
|
|
|
|
*
|
|
|
|
* Read a word from the specified netlist bank.
|
|
|
|
*/
|
2021-10-07 15:56:57 -07:00
|
|
|
static int
|
2020-11-11 16:43:29 -08:00
|
|
|
ice_read_netlist_module(struct ice_hw *hw, enum ice_bank_select bank, u32 offset, u16 *data)
|
|
|
|
{
|
|
|
|
__le16 data_local;
|
2021-10-07 15:59:03 -07:00
|
|
|
int status;
|
2020-11-11 16:43:29 -08:00
|
|
|
|
|
|
|
status = ice_read_flash_module(hw, bank, ICE_SR_NETLIST_BANK_PTR, offset * sizeof(u16),
|
|
|
|
(__force u8 *)&data_local, sizeof(u16));
|
|
|
|
if (!status)
|
|
|
|
*data = le16_to_cpu(data_local);
|
|
|
|
|
|
|
|
return status;
|
|
|
|
}
|
|
|
|
|
2018-03-20 07:58:07 -07:00
|
|
|
/**
|
|
|
|
* ice_read_sr_word - Reads Shadow RAM word and acquire NVM if necessary
|
|
|
|
* @hw: pointer to the HW structure
|
|
|
|
* @offset: offset of the Shadow RAM word to read (0x000000 - 0x001FFF)
|
|
|
|
* @data: word read from the Shadow RAM
|
|
|
|
*
|
|
|
|
* Reads one 16 bit word from the Shadow RAM using the ice_read_sr_word_aq.
|
|
|
|
*/
|
2021-10-07 15:56:57 -07:00
|
|
|
int ice_read_sr_word(struct ice_hw *hw, u16 offset, u16 *data)
|
2018-03-20 07:58:07 -07:00
|
|
|
{
|
2021-10-07 15:56:57 -07:00
|
|
|
int status;
|
2018-03-20 07:58:07 -07:00
|
|
|
|
|
|
|
status = ice_acquire_nvm(hw, ICE_RES_READ);
|
|
|
|
if (!status) {
|
|
|
|
status = ice_read_sr_word_aq(hw, offset, data);
|
|
|
|
ice_release_nvm(hw);
|
|
|
|
}
|
|
|
|
|
|
|
|
return status;
|
|
|
|
}
|
|
|
|
|
2020-03-11 18:58:18 -07:00
|
|
|
/**
|
|
|
|
* ice_get_pfa_module_tlv - Reads sub module TLV from NVM PFA
|
|
|
|
* @hw: pointer to hardware structure
|
|
|
|
* @module_tlv: pointer to module TLV to return
|
|
|
|
* @module_tlv_len: pointer to module TLV length to return
|
|
|
|
* @module_type: module type requested
|
|
|
|
*
|
|
|
|
* Finds the requested sub module TLV type from the Preserved Field
|
|
|
|
* Area (PFA) and returns the TLV pointer and length. The caller can
|
|
|
|
* use these to read the variable length TLV value.
|
|
|
|
*/
|
2021-10-07 15:56:57 -07:00
|
|
|
int
|
2020-03-11 18:58:18 -07:00
|
|
|
ice_get_pfa_module_tlv(struct ice_hw *hw, u16 *module_tlv, u16 *module_tlv_len,
|
|
|
|
u16 module_type)
|
|
|
|
{
|
|
|
|
u16 pfa_len, pfa_ptr;
|
|
|
|
u16 next_tlv;
|
2021-10-07 15:59:03 -07:00
|
|
|
int status;
|
2020-03-11 18:58:18 -07:00
|
|
|
|
|
|
|
status = ice_read_sr_word(hw, ICE_SR_PFA_PTR, &pfa_ptr);
|
|
|
|
if (status) {
|
|
|
|
ice_debug(hw, ICE_DBG_INIT, "Preserved Field Array pointer.\n");
|
|
|
|
return status;
|
|
|
|
}
|
|
|
|
status = ice_read_sr_word(hw, pfa_ptr, &pfa_len);
|
|
|
|
if (status) {
|
|
|
|
ice_debug(hw, ICE_DBG_INIT, "Failed to read PFA length.\n");
|
|
|
|
return status;
|
|
|
|
}
|
|
|
|
/* Starting with first TLV after PFA length, iterate through the list
|
|
|
|
* of TLVs to find the requested one.
|
|
|
|
*/
|
|
|
|
next_tlv = pfa_ptr + 1;
|
|
|
|
while (next_tlv < pfa_ptr + pfa_len) {
|
|
|
|
u16 tlv_sub_module_type;
|
|
|
|
u16 tlv_len;
|
|
|
|
|
|
|
|
/* Read TLV type */
|
|
|
|
status = ice_read_sr_word(hw, next_tlv, &tlv_sub_module_type);
|
|
|
|
if (status) {
|
|
|
|
ice_debug(hw, ICE_DBG_INIT, "Failed to read TLV type.\n");
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
/* Read TLV length */
|
|
|
|
status = ice_read_sr_word(hw, next_tlv + 1, &tlv_len);
|
|
|
|
if (status) {
|
|
|
|
ice_debug(hw, ICE_DBG_INIT, "Failed to read TLV length.\n");
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
if (tlv_sub_module_type == module_type) {
|
|
|
|
if (tlv_len) {
|
|
|
|
*module_tlv = next_tlv;
|
|
|
|
*module_tlv_len = tlv_len;
|
|
|
|
return 0;
|
|
|
|
}
|
2021-10-07 15:58:01 -07:00
|
|
|
return -EINVAL;
|
2020-03-11 18:58:18 -07:00
|
|
|
}
|
|
|
|
/* Check next TLV, i.e. current TLV pointer + length + 2 words
|
|
|
|
* (for current TLV's type and length)
|
|
|
|
*/
|
|
|
|
next_tlv = next_tlv + tlv_len + 2;
|
|
|
|
}
|
|
|
|
/* Module does not exist */
|
2021-10-07 15:58:01 -07:00
|
|
|
return -ENOENT;
|
2020-03-11 18:58:18 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* ice_read_pba_string - Reads part number string from NVM
|
|
|
|
* @hw: pointer to hardware structure
|
|
|
|
* @pba_num: stores the part number string from the NVM
|
|
|
|
* @pba_num_size: part number string buffer length
|
|
|
|
*
|
|
|
|
* Reads the part number string from the NVM.
|
|
|
|
*/
|
2021-10-07 15:59:03 -07:00
|
|
|
int ice_read_pba_string(struct ice_hw *hw, u8 *pba_num, u32 pba_num_size)
|
2020-03-11 18:58:18 -07:00
|
|
|
{
|
|
|
|
u16 pba_tlv, pba_tlv_len;
|
|
|
|
u16 pba_word, pba_size;
|
2021-10-07 15:59:03 -07:00
|
|
|
int status;
|
2020-03-11 18:58:18 -07:00
|
|
|
u16 i;
|
|
|
|
|
|
|
|
status = ice_get_pfa_module_tlv(hw, &pba_tlv, &pba_tlv_len,
|
|
|
|
ICE_SR_PBA_BLOCK_PTR);
|
|
|
|
if (status) {
|
|
|
|
ice_debug(hw, ICE_DBG_INIT, "Failed to read PBA Block TLV.\n");
|
|
|
|
return status;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* pba_size is the next word */
|
|
|
|
status = ice_read_sr_word(hw, (pba_tlv + 2), &pba_size);
|
|
|
|
if (status) {
|
|
|
|
ice_debug(hw, ICE_DBG_INIT, "Failed to read PBA Section size.\n");
|
|
|
|
return status;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (pba_tlv_len < pba_size) {
|
|
|
|
ice_debug(hw, ICE_DBG_INIT, "Invalid PBA Block TLV size.\n");
|
2021-10-07 15:58:01 -07:00
|
|
|
return -EINVAL;
|
2020-03-11 18:58:18 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
/* Subtract one to get PBA word count (PBA Size word is included in
|
|
|
|
* total size)
|
|
|
|
*/
|
|
|
|
pba_size--;
|
|
|
|
if (pba_num_size < (((u32)pba_size * 2) + 1)) {
|
|
|
|
ice_debug(hw, ICE_DBG_INIT, "Buffer too small for PBA data.\n");
|
2021-10-07 15:58:01 -07:00
|
|
|
return -EINVAL;
|
2020-03-11 18:58:18 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
for (i = 0; i < pba_size; i++) {
|
|
|
|
status = ice_read_sr_word(hw, (pba_tlv + 2 + 1) + i, &pba_word);
|
|
|
|
if (status) {
|
|
|
|
ice_debug(hw, ICE_DBG_INIT, "Failed to read PBA Block word %d.\n", i);
|
|
|
|
return status;
|
|
|
|
}
|
|
|
|
|
|
|
|
pba_num[(i * 2)] = (pba_word >> 8) & 0xFF;
|
|
|
|
pba_num[(i * 2) + 1] = pba_word & 0xFF;
|
|
|
|
}
|
|
|
|
pba_num[(pba_size * 2)] = '\0';
|
|
|
|
|
|
|
|
return status;
|
|
|
|
}
|
|
|
|
|
2020-10-01 10:31:41 -07:00
|
|
|
/**
|
|
|
|
* ice_get_nvm_ver_info - Read NVM version information
|
|
|
|
* @hw: pointer to the HW struct
|
ice: introduce function for reading from flash modules
When reading from the flash memory of the device, the ice driver has two
interfaces available to it. First, it can use a mediated interface via
firmware that allows specifying a module ID. This allows reading from
specific modules of the active flash bank.
The second interface available is to perform flat reads. This allows
complete access to the entire flash. However, using it requires the
software to handle calculating module location and interpret pointer
addresses.
While most data required is accessible through the convenient first
interface, certain flash contents are not. This includes the CSS header
information associated with the Option ROM and NVM banks, as well as any
access to the "inactive" banks used as scratch space for performing
flash updates.
In order to access all of the relevant flash contents, software must use
the flat reads. Rather than forcing all flows to perform flat read
calculations, introduce a new abstraction for reading from the flash:
ice_read_flash_module. This function provides an abstraction for reading
from either the active or inactive flash bank at the requested module.
This interface is very similar to the abstraction provided via firmware,
but allows access to additional modules, as well as providing
a mechanism to request access to both flash banks.
At first glance, it might make sense for this abstraction to allow
specifying precisely which bank (1st or 2nd) the caller wishes to read.
This is simpler to implement but more difficult to use. In practice,
most callers only know whether they want the active bank, or the
inactive bank. Rather than force callers to determine for themselves
which bank to read from, implement ice_read_flash_module in terms of
"active" vs "inactive". This significantly simplifies the implementation
at the caller level and is a more useful abstraction over the flash
contents.
Make use of this new interface to refactor reading of the main NVM
version information. Instead of using the firmware's mediated ShadowRAM
function, use the ice_read_flash_module abstraction.
To do this, notice that most reads of the NVM are going to be in 2-byte
word chunks. To simplify using ice_read_flash_module for this case,
ice_read_nvm_module is introduced. This is a simple wrapper around
ice_read_flash_module which takes the correct pointer address for the
NVM bank, and forces the 2-byte word format onto the caller.
When reading the NVM versions, some fields are read from the Shadow RAM.
The Shadow RAM is the first 64KB of flash memory, and is populated
during device load. Most fields are copied from a section within the
active NVM bank. In order to read this data from both the active and
inactive NVM banks, we need to read not from the first 64KB of flash,
but instead from the correct offset into the NVM bank. Introduce
ice_read_nvm_sr_copy for this purpose. This function wraps around
ice_read_nvm_module and has the same interface as the ice_read_sr_word,
with the exception of allowing the caller to specify whether to read the
active or inactive flash bank.
With this change, it is now trivial to refactor ice_get_nvm_ver_info to
read using the software mediated ice_read_flash_module interface instead
of relying on the firmware mediated interface. This will be used in the
following change to implement support for stored versions in the devlink
info report.
Additionally, the overall ice_read_flash_module interface will be used
and extended to support all three major flash banks, and additionally to
support reading the flash image security revision information.
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Tested-by: Tony Brelinski <tonyx.brelinski@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2020-10-01 10:31:43 -07:00
|
|
|
* @bank: whether to read from the active or inactive flash bank
|
2020-10-01 10:31:41 -07:00
|
|
|
* @nvm: pointer to NVM info structure
|
|
|
|
*
|
|
|
|
* Read the NVM EETRACK ID and map version of the main NVM image bank, filling
|
|
|
|
* in the NVM info structure.
|
|
|
|
*/
|
2021-10-07 15:56:57 -07:00
|
|
|
static int
|
ice: introduce function for reading from flash modules
When reading from the flash memory of the device, the ice driver has two
interfaces available to it. First, it can use a mediated interface via
firmware that allows specifying a module ID. This allows reading from
specific modules of the active flash bank.
The second interface available is to perform flat reads. This allows
complete access to the entire flash. However, using it requires the
software to handle calculating module location and interpret pointer
addresses.
While most data required is accessible through the convenient first
interface, certain flash contents are not. This includes the CSS header
information associated with the Option ROM and NVM banks, as well as any
access to the "inactive" banks used as scratch space for performing
flash updates.
In order to access all of the relevant flash contents, software must use
the flat reads. Rather than forcing all flows to perform flat read
calculations, introduce a new abstraction for reading from the flash:
ice_read_flash_module. This function provides an abstraction for reading
from either the active or inactive flash bank at the requested module.
This interface is very similar to the abstraction provided via firmware,
but allows access to additional modules, as well as providing
a mechanism to request access to both flash banks.
At first glance, it might make sense for this abstraction to allow
specifying precisely which bank (1st or 2nd) the caller wishes to read.
This is simpler to implement but more difficult to use. In practice,
most callers only know whether they want the active bank, or the
inactive bank. Rather than force callers to determine for themselves
which bank to read from, implement ice_read_flash_module in terms of
"active" vs "inactive". This significantly simplifies the implementation
at the caller level and is a more useful abstraction over the flash
contents.
Make use of this new interface to refactor reading of the main NVM
version information. Instead of using the firmware's mediated ShadowRAM
function, use the ice_read_flash_module abstraction.
To do this, notice that most reads of the NVM are going to be in 2-byte
word chunks. To simplify using ice_read_flash_module for this case,
ice_read_nvm_module is introduced. This is a simple wrapper around
ice_read_flash_module which takes the correct pointer address for the
NVM bank, and forces the 2-byte word format onto the caller.
When reading the NVM versions, some fields are read from the Shadow RAM.
The Shadow RAM is the first 64KB of flash memory, and is populated
during device load. Most fields are copied from a section within the
active NVM bank. In order to read this data from both the active and
inactive NVM banks, we need to read not from the first 64KB of flash,
but instead from the correct offset into the NVM bank. Introduce
ice_read_nvm_sr_copy for this purpose. This function wraps around
ice_read_nvm_module and has the same interface as the ice_read_sr_word,
with the exception of allowing the caller to specify whether to read the
active or inactive flash bank.
With this change, it is now trivial to refactor ice_get_nvm_ver_info to
read using the software mediated ice_read_flash_module interface instead
of relying on the firmware mediated interface. This will be used in the
following change to implement support for stored versions in the devlink
info report.
Additionally, the overall ice_read_flash_module interface will be used
and extended to support all three major flash banks, and additionally to
support reading the flash image security revision information.
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Tested-by: Tony Brelinski <tonyx.brelinski@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2020-10-01 10:31:43 -07:00
|
|
|
ice_get_nvm_ver_info(struct ice_hw *hw, enum ice_bank_select bank, struct ice_nvm_info *nvm)
|
2020-10-01 10:31:41 -07:00
|
|
|
{
|
|
|
|
u16 eetrack_lo, eetrack_hi, ver;
|
2021-10-07 15:56:57 -07:00
|
|
|
int status;
|
2020-10-01 10:31:41 -07:00
|
|
|
|
ice: introduce function for reading from flash modules
When reading from the flash memory of the device, the ice driver has two
interfaces available to it. First, it can use a mediated interface via
firmware that allows specifying a module ID. This allows reading from
specific modules of the active flash bank.
The second interface available is to perform flat reads. This allows
complete access to the entire flash. However, using it requires the
software to handle calculating module location and interpret pointer
addresses.
While most data required is accessible through the convenient first
interface, certain flash contents are not. This includes the CSS header
information associated with the Option ROM and NVM banks, as well as any
access to the "inactive" banks used as scratch space for performing
flash updates.
In order to access all of the relevant flash contents, software must use
the flat reads. Rather than forcing all flows to perform flat read
calculations, introduce a new abstraction for reading from the flash:
ice_read_flash_module. This function provides an abstraction for reading
from either the active or inactive flash bank at the requested module.
This interface is very similar to the abstraction provided via firmware,
but allows access to additional modules, as well as providing
a mechanism to request access to both flash banks.
At first glance, it might make sense for this abstraction to allow
specifying precisely which bank (1st or 2nd) the caller wishes to read.
This is simpler to implement but more difficult to use. In practice,
most callers only know whether they want the active bank, or the
inactive bank. Rather than force callers to determine for themselves
which bank to read from, implement ice_read_flash_module in terms of
"active" vs "inactive". This significantly simplifies the implementation
at the caller level and is a more useful abstraction over the flash
contents.
Make use of this new interface to refactor reading of the main NVM
version information. Instead of using the firmware's mediated ShadowRAM
function, use the ice_read_flash_module abstraction.
To do this, notice that most reads of the NVM are going to be in 2-byte
word chunks. To simplify using ice_read_flash_module for this case,
ice_read_nvm_module is introduced. This is a simple wrapper around
ice_read_flash_module which takes the correct pointer address for the
NVM bank, and forces the 2-byte word format onto the caller.
When reading the NVM versions, some fields are read from the Shadow RAM.
The Shadow RAM is the first 64KB of flash memory, and is populated
during device load. Most fields are copied from a section within the
active NVM bank. In order to read this data from both the active and
inactive NVM banks, we need to read not from the first 64KB of flash,
but instead from the correct offset into the NVM bank. Introduce
ice_read_nvm_sr_copy for this purpose. This function wraps around
ice_read_nvm_module and has the same interface as the ice_read_sr_word,
with the exception of allowing the caller to specify whether to read the
active or inactive flash bank.
With this change, it is now trivial to refactor ice_get_nvm_ver_info to
read using the software mediated ice_read_flash_module interface instead
of relying on the firmware mediated interface. This will be used in the
following change to implement support for stored versions in the devlink
info report.
Additionally, the overall ice_read_flash_module interface will be used
and extended to support all three major flash banks, and additionally to
support reading the flash image security revision information.
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Tested-by: Tony Brelinski <tonyx.brelinski@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2020-10-01 10:31:43 -07:00
|
|
|
status = ice_read_nvm_sr_copy(hw, bank, ICE_SR_NVM_DEV_STARTER_VER, &ver);
|
2020-10-01 10:31:41 -07:00
|
|
|
if (status) {
|
|
|
|
ice_debug(hw, ICE_DBG_NVM, "Failed to read DEV starter version.\n");
|
|
|
|
return status;
|
|
|
|
}
|
ice: introduce function for reading from flash modules
When reading from the flash memory of the device, the ice driver has two
interfaces available to it. First, it can use a mediated interface via
firmware that allows specifying a module ID. This allows reading from
specific modules of the active flash bank.
The second interface available is to perform flat reads. This allows
complete access to the entire flash. However, using it requires the
software to handle calculating module location and interpret pointer
addresses.
While most data required is accessible through the convenient first
interface, certain flash contents are not. This includes the CSS header
information associated with the Option ROM and NVM banks, as well as any
access to the "inactive" banks used as scratch space for performing
flash updates.
In order to access all of the relevant flash contents, software must use
the flat reads. Rather than forcing all flows to perform flat read
calculations, introduce a new abstraction for reading from the flash:
ice_read_flash_module. This function provides an abstraction for reading
from either the active or inactive flash bank at the requested module.
This interface is very similar to the abstraction provided via firmware,
but allows access to additional modules, as well as providing
a mechanism to request access to both flash banks.
At first glance, it might make sense for this abstraction to allow
specifying precisely which bank (1st or 2nd) the caller wishes to read.
This is simpler to implement but more difficult to use. In practice,
most callers only know whether they want the active bank, or the
inactive bank. Rather than force callers to determine for themselves
which bank to read from, implement ice_read_flash_module in terms of
"active" vs "inactive". This significantly simplifies the implementation
at the caller level and is a more useful abstraction over the flash
contents.
Make use of this new interface to refactor reading of the main NVM
version information. Instead of using the firmware's mediated ShadowRAM
function, use the ice_read_flash_module abstraction.
To do this, notice that most reads of the NVM are going to be in 2-byte
word chunks. To simplify using ice_read_flash_module for this case,
ice_read_nvm_module is introduced. This is a simple wrapper around
ice_read_flash_module which takes the correct pointer address for the
NVM bank, and forces the 2-byte word format onto the caller.
When reading the NVM versions, some fields are read from the Shadow RAM.
The Shadow RAM is the first 64KB of flash memory, and is populated
during device load. Most fields are copied from a section within the
active NVM bank. In order to read this data from both the active and
inactive NVM banks, we need to read not from the first 64KB of flash,
but instead from the correct offset into the NVM bank. Introduce
ice_read_nvm_sr_copy for this purpose. This function wraps around
ice_read_nvm_module and has the same interface as the ice_read_sr_word,
with the exception of allowing the caller to specify whether to read the
active or inactive flash bank.
With this change, it is now trivial to refactor ice_get_nvm_ver_info to
read using the software mediated ice_read_flash_module interface instead
of relying on the firmware mediated interface. This will be used in the
following change to implement support for stored versions in the devlink
info report.
Additionally, the overall ice_read_flash_module interface will be used
and extended to support all three major flash banks, and additionally to
support reading the flash image security revision information.
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Tested-by: Tony Brelinski <tonyx.brelinski@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2020-10-01 10:31:43 -07:00
|
|
|
|
2023-12-05 17:01:12 -08:00
|
|
|
nvm->major = FIELD_GET(ICE_NVM_VER_HI_MASK, ver);
|
|
|
|
nvm->minor = FIELD_GET(ICE_NVM_VER_LO_MASK, ver);
|
2020-10-01 10:31:41 -07:00
|
|
|
|
ice: introduce function for reading from flash modules
When reading from the flash memory of the device, the ice driver has two
interfaces available to it. First, it can use a mediated interface via
firmware that allows specifying a module ID. This allows reading from
specific modules of the active flash bank.
The second interface available is to perform flat reads. This allows
complete access to the entire flash. However, using it requires the
software to handle calculating module location and interpret pointer
addresses.
While most data required is accessible through the convenient first
interface, certain flash contents are not. This includes the CSS header
information associated with the Option ROM and NVM banks, as well as any
access to the "inactive" banks used as scratch space for performing
flash updates.
In order to access all of the relevant flash contents, software must use
the flat reads. Rather than forcing all flows to perform flat read
calculations, introduce a new abstraction for reading from the flash:
ice_read_flash_module. This function provides an abstraction for reading
from either the active or inactive flash bank at the requested module.
This interface is very similar to the abstraction provided via firmware,
but allows access to additional modules, as well as providing
a mechanism to request access to both flash banks.
At first glance, it might make sense for this abstraction to allow
specifying precisely which bank (1st or 2nd) the caller wishes to read.
This is simpler to implement but more difficult to use. In practice,
most callers only know whether they want the active bank, or the
inactive bank. Rather than force callers to determine for themselves
which bank to read from, implement ice_read_flash_module in terms of
"active" vs "inactive". This significantly simplifies the implementation
at the caller level and is a more useful abstraction over the flash
contents.
Make use of this new interface to refactor reading of the main NVM
version information. Instead of using the firmware's mediated ShadowRAM
function, use the ice_read_flash_module abstraction.
To do this, notice that most reads of the NVM are going to be in 2-byte
word chunks. To simplify using ice_read_flash_module for this case,
ice_read_nvm_module is introduced. This is a simple wrapper around
ice_read_flash_module which takes the correct pointer address for the
NVM bank, and forces the 2-byte word format onto the caller.
When reading the NVM versions, some fields are read from the Shadow RAM.
The Shadow RAM is the first 64KB of flash memory, and is populated
during device load. Most fields are copied from a section within the
active NVM bank. In order to read this data from both the active and
inactive NVM banks, we need to read not from the first 64KB of flash,
but instead from the correct offset into the NVM bank. Introduce
ice_read_nvm_sr_copy for this purpose. This function wraps around
ice_read_nvm_module and has the same interface as the ice_read_sr_word,
with the exception of allowing the caller to specify whether to read the
active or inactive flash bank.
With this change, it is now trivial to refactor ice_get_nvm_ver_info to
read using the software mediated ice_read_flash_module interface instead
of relying on the firmware mediated interface. This will be used in the
following change to implement support for stored versions in the devlink
info report.
Additionally, the overall ice_read_flash_module interface will be used
and extended to support all three major flash banks, and additionally to
support reading the flash image security revision information.
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Tested-by: Tony Brelinski <tonyx.brelinski@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2020-10-01 10:31:43 -07:00
|
|
|
status = ice_read_nvm_sr_copy(hw, bank, ICE_SR_NVM_EETRACK_LO, &eetrack_lo);
|
2020-10-01 10:31:41 -07:00
|
|
|
if (status) {
|
|
|
|
ice_debug(hw, ICE_DBG_NVM, "Failed to read EETRACK lo.\n");
|
|
|
|
return status;
|
|
|
|
}
|
ice: introduce function for reading from flash modules
When reading from the flash memory of the device, the ice driver has two
interfaces available to it. First, it can use a mediated interface via
firmware that allows specifying a module ID. This allows reading from
specific modules of the active flash bank.
The second interface available is to perform flat reads. This allows
complete access to the entire flash. However, using it requires the
software to handle calculating module location and interpret pointer
addresses.
While most data required is accessible through the convenient first
interface, certain flash contents are not. This includes the CSS header
information associated with the Option ROM and NVM banks, as well as any
access to the "inactive" banks used as scratch space for performing
flash updates.
In order to access all of the relevant flash contents, software must use
the flat reads. Rather than forcing all flows to perform flat read
calculations, introduce a new abstraction for reading from the flash:
ice_read_flash_module. This function provides an abstraction for reading
from either the active or inactive flash bank at the requested module.
This interface is very similar to the abstraction provided via firmware,
but allows access to additional modules, as well as providing
a mechanism to request access to both flash banks.
At first glance, it might make sense for this abstraction to allow
specifying precisely which bank (1st or 2nd) the caller wishes to read.
This is simpler to implement but more difficult to use. In practice,
most callers only know whether they want the active bank, or the
inactive bank. Rather than force callers to determine for themselves
which bank to read from, implement ice_read_flash_module in terms of
"active" vs "inactive". This significantly simplifies the implementation
at the caller level and is a more useful abstraction over the flash
contents.
Make use of this new interface to refactor reading of the main NVM
version information. Instead of using the firmware's mediated ShadowRAM
function, use the ice_read_flash_module abstraction.
To do this, notice that most reads of the NVM are going to be in 2-byte
word chunks. To simplify using ice_read_flash_module for this case,
ice_read_nvm_module is introduced. This is a simple wrapper around
ice_read_flash_module which takes the correct pointer address for the
NVM bank, and forces the 2-byte word format onto the caller.
When reading the NVM versions, some fields are read from the Shadow RAM.
The Shadow RAM is the first 64KB of flash memory, and is populated
during device load. Most fields are copied from a section within the
active NVM bank. In order to read this data from both the active and
inactive NVM banks, we need to read not from the first 64KB of flash,
but instead from the correct offset into the NVM bank. Introduce
ice_read_nvm_sr_copy for this purpose. This function wraps around
ice_read_nvm_module and has the same interface as the ice_read_sr_word,
with the exception of allowing the caller to specify whether to read the
active or inactive flash bank.
With this change, it is now trivial to refactor ice_get_nvm_ver_info to
read using the software mediated ice_read_flash_module interface instead
of relying on the firmware mediated interface. This will be used in the
following change to implement support for stored versions in the devlink
info report.
Additionally, the overall ice_read_flash_module interface will be used
and extended to support all three major flash banks, and additionally to
support reading the flash image security revision information.
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Tested-by: Tony Brelinski <tonyx.brelinski@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2020-10-01 10:31:43 -07:00
|
|
|
status = ice_read_nvm_sr_copy(hw, bank, ICE_SR_NVM_EETRACK_HI, &eetrack_hi);
|
2020-10-01 10:31:41 -07:00
|
|
|
if (status) {
|
|
|
|
ice_debug(hw, ICE_DBG_NVM, "Failed to read EETRACK hi.\n");
|
|
|
|
return status;
|
|
|
|
}
|
|
|
|
|
|
|
|
nvm->eetrack = (eetrack_hi << 16) | eetrack_lo;
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
ice: display some stored NVM versions via devlink info
The devlink info interface supports drivers reporting "stored" versions.
These versions indicate the version of an update that has been
downloaded to the device, but is not yet active.
The code for extracting the NVM version recently changed to enable
support for reading from either the active or the inactive bank. Use
this to implement ice_get_inactive_nvm_ver, which will read the NVM
version data from the inactive section of flash.
When reporting the versions via devlink info, first read the device
capabilities. Determine if there is a pending flash update, and if so,
extract relevant version information from the inactive flash. Store
these within the info context structure.
When reporting "stored" firmware versions, devlink documentation
indicates that we ought to always report a stored value, even if there
is no pending update. In this common case, the stored version should
match the running version. This means that each stored version should by
default fallback to the same value as reported by the running handler.
To support this, modify the version structure to have both a "getter"
and a "fallback". Modify the control loop so that it will use the
"fallback" function if the "getter" function does not report a version.
To report versions for which we can read the stored value, use a new
"stored()" macro. This macro will insert two entries into the version
list. The first entry is the traditional running version. The second is
the stored version, implemented with a fallback to the active version.
This is a little tricky, but reduces the overall duplication of elements
in the entry list, and ensures that running and stored values remain
consistent.
To avoid some duplication, add a combined() macro that will insert both
the running and stored versions into the version entry list.
Using this new support, add pending version reporter functions for
"fw.psid.api" and "fw.bundle_id". This enables reporting the stored
values for some of versions in the NVM module of the flash.
Reporting management versions is not implemented by this patch. The
active management version is reported to the driver via the AdminQ
mailbox during load. Although the version must be in the firmware binary
somewhere, accessing this from the inactive firmware is not trivial and
has not been implemented in this change.
Future changes will introduce support for reading the UNDI Option ROM
version and the version associated with the Netlist module.
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Tested-by: Tony Brelinski <tonyx.brelinski@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2020-11-11 16:43:28 -08:00
|
|
|
/**
|
|
|
|
* ice_get_inactive_nvm_ver - Read Option ROM version from the inactive bank
|
|
|
|
* @hw: pointer to the HW structure
|
|
|
|
* @nvm: storage for Option ROM version information
|
|
|
|
*
|
|
|
|
* Reads the NVM EETRACK ID, Map version, and security revision of the
|
|
|
|
* inactive NVM bank. Used to access version data for a pending update that
|
|
|
|
* has not yet been activated.
|
|
|
|
*/
|
2021-10-07 15:56:57 -07:00
|
|
|
int ice_get_inactive_nvm_ver(struct ice_hw *hw, struct ice_nvm_info *nvm)
|
ice: display some stored NVM versions via devlink info
The devlink info interface supports drivers reporting "stored" versions.
These versions indicate the version of an update that has been
downloaded to the device, but is not yet active.
The code for extracting the NVM version recently changed to enable
support for reading from either the active or the inactive bank. Use
this to implement ice_get_inactive_nvm_ver, which will read the NVM
version data from the inactive section of flash.
When reporting the versions via devlink info, first read the device
capabilities. Determine if there is a pending flash update, and if so,
extract relevant version information from the inactive flash. Store
these within the info context structure.
When reporting "stored" firmware versions, devlink documentation
indicates that we ought to always report a stored value, even if there
is no pending update. In this common case, the stored version should
match the running version. This means that each stored version should by
default fallback to the same value as reported by the running handler.
To support this, modify the version structure to have both a "getter"
and a "fallback". Modify the control loop so that it will use the
"fallback" function if the "getter" function does not report a version.
To report versions for which we can read the stored value, use a new
"stored()" macro. This macro will insert two entries into the version
list. The first entry is the traditional running version. The second is
the stored version, implemented with a fallback to the active version.
This is a little tricky, but reduces the overall duplication of elements
in the entry list, and ensures that running and stored values remain
consistent.
To avoid some duplication, add a combined() macro that will insert both
the running and stored versions into the version entry list.
Using this new support, add pending version reporter functions for
"fw.psid.api" and "fw.bundle_id". This enables reporting the stored
values for some of versions in the NVM module of the flash.
Reporting management versions is not implemented by this patch. The
active management version is reported to the driver via the AdminQ
mailbox during load. Although the version must be in the firmware binary
somewhere, accessing this from the inactive firmware is not trivial and
has not been implemented in this change.
Future changes will introduce support for reading the UNDI Option ROM
version and the version associated with the Netlist module.
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Tested-by: Tony Brelinski <tonyx.brelinski@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2020-11-11 16:43:28 -08:00
|
|
|
{
|
|
|
|
return ice_get_nvm_ver_info(hw, ICE_INACTIVE_FLASH_BANK, nvm);
|
|
|
|
}
|
|
|
|
|
2020-03-11 18:58:12 -07:00
|
|
|
/**
|
2020-11-11 16:43:30 -08:00
|
|
|
* ice_get_orom_civd_data - Get the combo version information from Option ROM
|
2020-03-11 18:58:12 -07:00
|
|
|
* @hw: pointer to the HW struct
|
2020-11-11 16:43:30 -08:00
|
|
|
* @bank: whether to read from the active or inactive flash module
|
|
|
|
* @civd: storage for the Option ROM CIVD data.
|
2020-03-11 18:58:12 -07:00
|
|
|
*
|
2020-11-11 16:43:30 -08:00
|
|
|
* Searches through the Option ROM flash contents to locate the CIVD data for
|
|
|
|
* the image.
|
2020-03-11 18:58:12 -07:00
|
|
|
*/
|
2021-10-07 15:56:57 -07:00
|
|
|
static int
|
2020-11-11 16:43:30 -08:00
|
|
|
ice_get_orom_civd_data(struct ice_hw *hw, enum ice_bank_select bank,
|
|
|
|
struct ice_orom_civd_info *civd)
|
2020-03-11 18:58:12 -07:00
|
|
|
{
|
2021-10-27 16:22:54 -07:00
|
|
|
u8 *orom_data;
|
2021-10-07 15:56:57 -07:00
|
|
|
int status;
|
2020-11-11 16:43:30 -08:00
|
|
|
u32 offset;
|
2020-03-11 18:58:12 -07:00
|
|
|
|
2020-11-11 16:43:30 -08:00
|
|
|
/* The CIVD section is located in the Option ROM aligned to 512 bytes.
|
|
|
|
* The first 4 bytes must contain the ASCII characters "$CIV".
|
|
|
|
* A simple modulo 256 sum of all of the bytes of the structure must
|
|
|
|
* equal 0.
|
2021-10-27 16:22:54 -07:00
|
|
|
*
|
|
|
|
* The exact location is unknown and varies between images but is
|
|
|
|
* usually somewhere in the middle of the bank. We need to scan the
|
|
|
|
* Option ROM bank to locate it.
|
|
|
|
*
|
|
|
|
* It's significantly faster to read the entire Option ROM up front
|
|
|
|
* using the maximum page size, than to read each possible location
|
|
|
|
* with a separate firmware command.
|
2020-03-11 18:58:12 -07:00
|
|
|
*/
|
2021-10-27 16:22:54 -07:00
|
|
|
orom_data = vzalloc(hw->flash.banks.orom_size);
|
|
|
|
if (!orom_data)
|
|
|
|
return -ENOMEM;
|
|
|
|
|
|
|
|
status = ice_read_flash_module(hw, bank, ICE_SR_1ST_OROM_BANK_PTR, 0,
|
|
|
|
orom_data, hw->flash.banks.orom_size);
|
|
|
|
if (status) {
|
2022-04-02 10:17:15 +08:00
|
|
|
vfree(orom_data);
|
2021-10-27 16:22:54 -07:00
|
|
|
ice_debug(hw, ICE_DBG_NVM, "Unable to read Option ROM data\n");
|
|
|
|
return status;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Scan the memory buffer to locate the CIVD data section */
|
2020-11-11 16:43:30 -08:00
|
|
|
for (offset = 0; (offset + 512) <= hw->flash.banks.orom_size; offset += 512) {
|
2021-10-27 16:22:54 -07:00
|
|
|
struct ice_orom_civd_info *tmp;
|
2020-11-11 16:43:30 -08:00
|
|
|
u8 sum = 0, i;
|
2020-03-11 18:58:12 -07:00
|
|
|
|
2021-10-27 16:22:54 -07:00
|
|
|
tmp = (struct ice_orom_civd_info *)&orom_data[offset];
|
2020-11-11 16:43:30 -08:00
|
|
|
|
|
|
|
/* Skip forward until we find a matching signature */
|
2021-10-27 16:22:54 -07:00
|
|
|
if (memcmp("$CIV", tmp->signature, sizeof(tmp->signature)) != 0)
|
2020-11-11 16:43:30 -08:00
|
|
|
continue;
|
|
|
|
|
2021-10-27 16:22:54 -07:00
|
|
|
ice_debug(hw, ICE_DBG_NVM, "Found CIVD section at offset %u\n",
|
|
|
|
offset);
|
|
|
|
|
2020-11-11 16:43:30 -08:00
|
|
|
/* Verify that the simple checksum is zero */
|
2021-10-27 16:22:54 -07:00
|
|
|
for (i = 0; i < sizeof(*tmp); i++)
|
|
|
|
sum += ((u8 *)tmp)[i];
|
2020-11-11 16:43:30 -08:00
|
|
|
|
|
|
|
if (sum) {
|
|
|
|
ice_debug(hw, ICE_DBG_NVM, "Found CIVD data with invalid checksum of %u\n",
|
|
|
|
sum);
|
2021-10-27 16:22:54 -07:00
|
|
|
goto err_invalid_checksum;
|
2020-11-11 16:43:30 -08:00
|
|
|
}
|
|
|
|
|
2021-10-27 16:22:54 -07:00
|
|
|
*civd = *tmp;
|
|
|
|
vfree(orom_data);
|
2020-11-11 16:43:30 -08:00
|
|
|
return 0;
|
2020-03-11 18:58:12 -07:00
|
|
|
}
|
|
|
|
|
2021-10-27 16:22:54 -07:00
|
|
|
ice_debug(hw, ICE_DBG_NVM, "Unable to locate CIVD data within the Option ROM\n");
|
|
|
|
|
|
|
|
err_invalid_checksum:
|
|
|
|
vfree(orom_data);
|
2021-10-07 15:58:01 -07:00
|
|
|
return -EIO;
|
2020-11-11 16:43:30 -08:00
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* ice_get_orom_ver_info - Read Option ROM version information
|
|
|
|
* @hw: pointer to the HW struct
|
|
|
|
* @bank: whether to read from the active or inactive flash module
|
|
|
|
* @orom: pointer to Option ROM info structure
|
|
|
|
*
|
|
|
|
* Read Option ROM version and security revision from the Option ROM flash
|
|
|
|
* section.
|
|
|
|
*/
|
2021-10-07 15:56:57 -07:00
|
|
|
static int
|
2020-11-11 16:43:30 -08:00
|
|
|
ice_get_orom_ver_info(struct ice_hw *hw, enum ice_bank_select bank, struct ice_orom_info *orom)
|
|
|
|
{
|
|
|
|
struct ice_orom_civd_info civd;
|
|
|
|
u32 combo_ver;
|
2021-10-07 15:59:03 -07:00
|
|
|
int status;
|
2020-11-11 16:43:30 -08:00
|
|
|
|
|
|
|
status = ice_get_orom_civd_data(hw, bank, &civd);
|
2020-03-11 18:58:12 -07:00
|
|
|
if (status) {
|
2020-11-11 16:43:30 -08:00
|
|
|
ice_debug(hw, ICE_DBG_NVM, "Failed to locate valid Option ROM CIVD data\n");
|
2020-03-11 18:58:12 -07:00
|
|
|
return status;
|
|
|
|
}
|
|
|
|
|
2020-11-11 16:43:30 -08:00
|
|
|
combo_ver = le32_to_cpu(civd.combo_ver);
|
2020-03-11 18:58:12 -07:00
|
|
|
|
2023-12-05 17:01:12 -08:00
|
|
|
orom->major = FIELD_GET(ICE_OROM_VER_MASK, combo_ver);
|
|
|
|
orom->patch = FIELD_GET(ICE_OROM_VER_PATCH_MASK, combo_ver);
|
|
|
|
orom->build = FIELD_GET(ICE_OROM_VER_BUILD_MASK, combo_ver);
|
2020-03-11 18:58:12 -07:00
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2020-11-11 16:43:30 -08:00
|
|
|
/**
|
|
|
|
* ice_get_inactive_orom_ver - Read Option ROM version from the inactive bank
|
|
|
|
* @hw: pointer to the HW structure
|
|
|
|
* @orom: storage for Option ROM version information
|
|
|
|
*
|
|
|
|
* Reads the Option ROM version and security revision data for the inactive
|
|
|
|
* section of flash. Used to access version data for a pending update that has
|
|
|
|
* not yet been activated.
|
|
|
|
*/
|
2021-10-07 15:56:57 -07:00
|
|
|
int ice_get_inactive_orom_ver(struct ice_hw *hw, struct ice_orom_info *orom)
|
2020-11-11 16:43:30 -08:00
|
|
|
{
|
|
|
|
return ice_get_orom_ver_info(hw, ICE_INACTIVE_FLASH_BANK, orom);
|
|
|
|
}
|
|
|
|
|
2020-05-05 15:55:37 -07:00
|
|
|
/**
|
2020-11-11 16:43:29 -08:00
|
|
|
* ice_get_netlist_info
|
2020-05-05 15:55:37 -07:00
|
|
|
* @hw: pointer to the HW struct
|
2020-11-11 16:43:29 -08:00
|
|
|
* @bank: whether to read from the active or inactive flash bank
|
|
|
|
* @netlist: pointer to netlist version info structure
|
2020-05-05 15:55:37 -07:00
|
|
|
*
|
2020-11-11 16:43:29 -08:00
|
|
|
* Get the netlist version information from the requested bank. Reads the Link
|
|
|
|
* Topology section to find the Netlist ID block and extract the relevant
|
|
|
|
* information into the netlist version structure.
|
2020-05-05 15:55:37 -07:00
|
|
|
*/
|
2021-10-07 15:56:57 -07:00
|
|
|
static int
|
2020-11-11 16:43:29 -08:00
|
|
|
ice_get_netlist_info(struct ice_hw *hw, enum ice_bank_select bank,
|
|
|
|
struct ice_netlist_info *netlist)
|
2020-05-05 15:55:37 -07:00
|
|
|
{
|
2020-11-11 16:43:29 -08:00
|
|
|
u16 module_id, length, node_count, i;
|
|
|
|
u16 *id_blk;
|
2021-10-07 15:59:03 -07:00
|
|
|
int status;
|
2020-05-05 15:55:37 -07:00
|
|
|
|
2020-11-11 16:43:29 -08:00
|
|
|
status = ice_read_netlist_module(hw, bank, ICE_NETLIST_TYPE_OFFSET, &module_id);
|
|
|
|
if (status)
|
|
|
|
return status;
|
2020-05-05 15:55:37 -07:00
|
|
|
|
2020-11-11 16:43:29 -08:00
|
|
|
if (module_id != ICE_NETLIST_LINK_TOPO_MOD_ID) {
|
|
|
|
ice_debug(hw, ICE_DBG_NVM, "Expected netlist module_id ID of 0x%04x, but got 0x%04x\n",
|
|
|
|
ICE_NETLIST_LINK_TOPO_MOD_ID, module_id);
|
2021-10-07 15:58:01 -07:00
|
|
|
return -EIO;
|
2020-11-11 16:43:29 -08:00
|
|
|
}
|
|
|
|
|
|
|
|
status = ice_read_netlist_module(hw, bank, ICE_LINK_TOPO_MODULE_LEN, &length);
|
|
|
|
if (status)
|
|
|
|
return status;
|
|
|
|
|
|
|
|
/* sanity check that we have at least enough words to store the netlist ID block */
|
|
|
|
if (length < ICE_NETLIST_ID_BLK_SIZE) {
|
|
|
|
ice_debug(hw, ICE_DBG_NVM, "Netlist Link Topology module too small. Expected at least %u words, but got %u words.\n",
|
|
|
|
ICE_NETLIST_ID_BLK_SIZE, length);
|
2021-10-07 15:58:01 -07:00
|
|
|
return -EIO;
|
2020-11-11 16:43:29 -08:00
|
|
|
}
|
|
|
|
|
|
|
|
status = ice_read_netlist_module(hw, bank, ICE_LINK_TOPO_NODE_COUNT, &node_count);
|
|
|
|
if (status)
|
|
|
|
return status;
|
|
|
|
node_count &= ICE_LINK_TOPO_NODE_COUNT_M;
|
2020-05-05 15:55:37 -07:00
|
|
|
|
2020-11-11 16:43:29 -08:00
|
|
|
id_blk = kcalloc(ICE_NETLIST_ID_BLK_SIZE, sizeof(*id_blk), GFP_KERNEL);
|
|
|
|
if (!id_blk)
|
2021-10-07 15:58:01 -07:00
|
|
|
return -ENOMEM;
|
2020-05-05 15:55:37 -07:00
|
|
|
|
2020-11-11 16:43:29 -08:00
|
|
|
/* Read out the entire Netlist ID Block at once. */
|
|
|
|
status = ice_read_flash_module(hw, bank, ICE_SR_NETLIST_BANK_PTR,
|
|
|
|
ICE_NETLIST_ID_BLK_OFFSET(node_count) * sizeof(u16),
|
|
|
|
(u8 *)id_blk, ICE_NETLIST_ID_BLK_SIZE * sizeof(u16));
|
|
|
|
if (status)
|
2020-05-05 15:55:37 -07:00
|
|
|
goto exit_error;
|
|
|
|
|
2020-11-11 16:43:29 -08:00
|
|
|
for (i = 0; i < ICE_NETLIST_ID_BLK_SIZE; i++)
|
|
|
|
id_blk[i] = le16_to_cpu(((__force __le16 *)id_blk)[i]);
|
|
|
|
|
|
|
|
netlist->major = id_blk[ICE_NETLIST_ID_BLK_MAJOR_VER_HIGH] << 16 |
|
|
|
|
id_blk[ICE_NETLIST_ID_BLK_MAJOR_VER_LOW];
|
|
|
|
netlist->minor = id_blk[ICE_NETLIST_ID_BLK_MINOR_VER_HIGH] << 16 |
|
|
|
|
id_blk[ICE_NETLIST_ID_BLK_MINOR_VER_LOW];
|
|
|
|
netlist->type = id_blk[ICE_NETLIST_ID_BLK_TYPE_HIGH] << 16 |
|
|
|
|
id_blk[ICE_NETLIST_ID_BLK_TYPE_LOW];
|
|
|
|
netlist->rev = id_blk[ICE_NETLIST_ID_BLK_REV_HIGH] << 16 |
|
|
|
|
id_blk[ICE_NETLIST_ID_BLK_REV_LOW];
|
|
|
|
netlist->cust_ver = id_blk[ICE_NETLIST_ID_BLK_CUST_VER];
|
2020-05-05 15:55:37 -07:00
|
|
|
/* Read the left most 4 bytes of SHA */
|
2020-11-11 16:43:29 -08:00
|
|
|
netlist->hash = id_blk[ICE_NETLIST_ID_BLK_SHA_HASH_WORD(15)] << 16 |
|
|
|
|
id_blk[ICE_NETLIST_ID_BLK_SHA_HASH_WORD(14)];
|
2020-05-05 15:55:37 -07:00
|
|
|
|
|
|
|
exit_error:
|
2020-11-11 16:43:29 -08:00
|
|
|
kfree(id_blk);
|
|
|
|
|
|
|
|
return status;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* ice_get_inactive_netlist_ver
|
|
|
|
* @hw: pointer to the HW struct
|
|
|
|
* @netlist: pointer to netlist version info structure
|
|
|
|
*
|
|
|
|
* Read the netlist version data from the inactive netlist bank. Used to
|
|
|
|
* extract version data of a pending flash update in order to display the
|
|
|
|
* version data.
|
|
|
|
*/
|
2021-10-07 15:56:57 -07:00
|
|
|
int ice_get_inactive_netlist_ver(struct ice_hw *hw, struct ice_netlist_info *netlist)
|
2020-11-11 16:43:29 -08:00
|
|
|
{
|
|
|
|
return ice_get_netlist_info(hw, ICE_INACTIVE_FLASH_BANK, netlist);
|
2020-05-05 15:55:37 -07:00
|
|
|
}
|
|
|
|
|
2020-03-11 18:58:13 -07:00
|
|
|
/**
|
|
|
|
* ice_discover_flash_size - Discover the available flash size.
|
|
|
|
* @hw: pointer to the HW struct
|
|
|
|
*
|
|
|
|
* The device flash could be up to 16MB in size. However, it is possible that
|
|
|
|
* the actual size is smaller. Use bisection to determine the accessible size
|
|
|
|
* of flash memory.
|
|
|
|
*/
|
2021-10-07 15:56:57 -07:00
|
|
|
static int ice_discover_flash_size(struct ice_hw *hw)
|
2020-03-11 18:58:13 -07:00
|
|
|
{
|
|
|
|
u32 min_size = 0, max_size = ICE_AQC_NVM_MAX_OFFSET + 1;
|
2021-10-07 15:56:57 -07:00
|
|
|
int status;
|
2020-03-11 18:58:13 -07:00
|
|
|
|
|
|
|
status = ice_acquire_nvm(hw, ICE_RES_READ);
|
|
|
|
if (status)
|
|
|
|
return status;
|
|
|
|
|
|
|
|
while ((max_size - min_size) > 1) {
|
|
|
|
u32 offset = (max_size + min_size) / 2;
|
|
|
|
u32 len = 1;
|
|
|
|
u8 data;
|
|
|
|
|
|
|
|
status = ice_read_flat_nvm(hw, offset, &len, &data, false);
|
2021-10-07 15:58:01 -07:00
|
|
|
if (status == -EIO &&
|
2020-03-11 18:58:13 -07:00
|
|
|
hw->adminq.sq_last_status == ICE_AQ_RC_EINVAL) {
|
2020-09-17 13:13:46 -07:00
|
|
|
ice_debug(hw, ICE_DBG_NVM, "%s: New upper bound of %u bytes\n",
|
2020-03-11 18:58:13 -07:00
|
|
|
__func__, offset);
|
|
|
|
status = 0;
|
|
|
|
max_size = offset;
|
|
|
|
} else if (!status) {
|
2020-09-17 13:13:46 -07:00
|
|
|
ice_debug(hw, ICE_DBG_NVM, "%s: New lower bound of %u bytes\n",
|
2020-03-11 18:58:13 -07:00
|
|
|
__func__, offset);
|
|
|
|
min_size = offset;
|
|
|
|
} else {
|
|
|
|
/* an unexpected error occurred */
|
|
|
|
goto err_read_flat_nvm;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2020-09-17 13:13:46 -07:00
|
|
|
ice_debug(hw, ICE_DBG_NVM, "Predicted flash size is %u bytes\n", max_size);
|
2020-03-11 18:58:13 -07:00
|
|
|
|
2020-10-01 10:31:41 -07:00
|
|
|
hw->flash.flash_size = max_size;
|
2020-03-11 18:58:13 -07:00
|
|
|
|
|
|
|
err_read_flat_nvm:
|
|
|
|
ice_release_nvm(hw);
|
|
|
|
|
|
|
|
return status;
|
|
|
|
}
|
|
|
|
|
2020-10-01 10:31:42 -07:00
|
|
|
/**
|
|
|
|
* ice_read_sr_pointer - Read the value of a Shadow RAM pointer word
|
|
|
|
* @hw: pointer to the HW structure
|
|
|
|
* @offset: the word offset of the Shadow RAM word to read
|
|
|
|
* @pointer: pointer value read from Shadow RAM
|
|
|
|
*
|
|
|
|
* Read the given Shadow RAM word, and convert it to a pointer value specified
|
|
|
|
* in bytes. This function assumes the specified offset is a valid pointer
|
|
|
|
* word.
|
|
|
|
*
|
|
|
|
* Each pointer word specifies whether it is stored in word size or 4KB
|
|
|
|
* sector size by using the highest bit. The reported pointer value will be in
|
|
|
|
* bytes, intended for flat NVM reads.
|
|
|
|
*/
|
2021-10-07 15:59:03 -07:00
|
|
|
static int ice_read_sr_pointer(struct ice_hw *hw, u16 offset, u32 *pointer)
|
2020-10-01 10:31:42 -07:00
|
|
|
{
|
2021-10-07 15:56:57 -07:00
|
|
|
int status;
|
2020-10-01 10:31:42 -07:00
|
|
|
u16 value;
|
|
|
|
|
|
|
|
status = ice_read_sr_word(hw, offset, &value);
|
|
|
|
if (status)
|
|
|
|
return status;
|
|
|
|
|
|
|
|
/* Determine if the pointer is in 4KB or word units */
|
|
|
|
if (value & ICE_SR_NVM_PTR_4KB_UNITS)
|
|
|
|
*pointer = (value & ~ICE_SR_NVM_PTR_4KB_UNITS) * 4 * 1024;
|
|
|
|
else
|
|
|
|
*pointer = value * 2;
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* ice_read_sr_area_size - Read an area size from a Shadow RAM word
|
|
|
|
* @hw: pointer to the HW structure
|
|
|
|
* @offset: the word offset of the Shadow RAM to read
|
|
|
|
* @size: size value read from the Shadow RAM
|
|
|
|
*
|
|
|
|
* Read the given Shadow RAM word, and convert it to an area size value
|
|
|
|
* specified in bytes. This function assumes the specified offset is a valid
|
|
|
|
* area size word.
|
|
|
|
*
|
|
|
|
* Each area size word is specified in 4KB sector units. This function reports
|
|
|
|
* the size in bytes, intended for flat NVM reads.
|
|
|
|
*/
|
2021-10-07 15:59:03 -07:00
|
|
|
static int ice_read_sr_area_size(struct ice_hw *hw, u16 offset, u32 *size)
|
2020-10-01 10:31:42 -07:00
|
|
|
{
|
2021-10-07 15:56:57 -07:00
|
|
|
int status;
|
2020-10-01 10:31:42 -07:00
|
|
|
u16 value;
|
|
|
|
|
|
|
|
status = ice_read_sr_word(hw, offset, &value);
|
|
|
|
if (status)
|
|
|
|
return status;
|
|
|
|
|
|
|
|
/* Area sizes are always specified in 4KB units */
|
|
|
|
*size = value * 4 * 1024;
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* ice_determine_active_flash_banks - Discover active bank for each module
|
|
|
|
* @hw: pointer to the HW struct
|
|
|
|
*
|
|
|
|
* Read the Shadow RAM control word and determine which banks are active for
|
|
|
|
* the NVM, OROM, and Netlist modules. Also read and calculate the associated
|
|
|
|
* pointer and size. These values are then cached into the ice_flash_info
|
|
|
|
* structure for later use in order to calculate the correct offset to read
|
|
|
|
* from the active module.
|
|
|
|
*/
|
2021-10-07 15:59:03 -07:00
|
|
|
static int ice_determine_active_flash_banks(struct ice_hw *hw)
|
2020-10-01 10:31:42 -07:00
|
|
|
{
|
|
|
|
struct ice_bank_info *banks = &hw->flash.banks;
|
|
|
|
u16 ctrl_word;
|
2021-10-07 15:59:03 -07:00
|
|
|
int status;
|
2020-10-01 10:31:42 -07:00
|
|
|
|
|
|
|
status = ice_read_sr_word(hw, ICE_SR_NVM_CTRL_WORD, &ctrl_word);
|
|
|
|
if (status) {
|
|
|
|
ice_debug(hw, ICE_DBG_NVM, "Failed to read the Shadow RAM control word\n");
|
|
|
|
return status;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Check that the control word indicates validity */
|
2023-12-05 17:01:12 -08:00
|
|
|
if (FIELD_GET(ICE_SR_CTRL_WORD_1_M, ctrl_word) !=
|
|
|
|
ICE_SR_CTRL_WORD_VALID) {
|
2020-10-01 10:31:42 -07:00
|
|
|
ice_debug(hw, ICE_DBG_NVM, "Shadow RAM control word is invalid\n");
|
2021-10-07 15:58:01 -07:00
|
|
|
return -EIO;
|
2020-10-01 10:31:42 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
if (!(ctrl_word & ICE_SR_CTRL_WORD_NVM_BANK))
|
|
|
|
banks->nvm_bank = ICE_1ST_FLASH_BANK;
|
|
|
|
else
|
|
|
|
banks->nvm_bank = ICE_2ND_FLASH_BANK;
|
|
|
|
|
|
|
|
if (!(ctrl_word & ICE_SR_CTRL_WORD_OROM_BANK))
|
|
|
|
banks->orom_bank = ICE_1ST_FLASH_BANK;
|
|
|
|
else
|
|
|
|
banks->orom_bank = ICE_2ND_FLASH_BANK;
|
|
|
|
|
|
|
|
if (!(ctrl_word & ICE_SR_CTRL_WORD_NETLIST_BANK))
|
|
|
|
banks->netlist_bank = ICE_1ST_FLASH_BANK;
|
|
|
|
else
|
|
|
|
banks->netlist_bank = ICE_2ND_FLASH_BANK;
|
|
|
|
|
|
|
|
status = ice_read_sr_pointer(hw, ICE_SR_1ST_NVM_BANK_PTR, &banks->nvm_ptr);
|
|
|
|
if (status) {
|
|
|
|
ice_debug(hw, ICE_DBG_NVM, "Failed to read NVM bank pointer\n");
|
|
|
|
return status;
|
|
|
|
}
|
|
|
|
|
|
|
|
status = ice_read_sr_area_size(hw, ICE_SR_NVM_BANK_SIZE, &banks->nvm_size);
|
|
|
|
if (status) {
|
|
|
|
ice_debug(hw, ICE_DBG_NVM, "Failed to read NVM bank area size\n");
|
|
|
|
return status;
|
|
|
|
}
|
|
|
|
|
|
|
|
status = ice_read_sr_pointer(hw, ICE_SR_1ST_OROM_BANK_PTR, &banks->orom_ptr);
|
|
|
|
if (status) {
|
|
|
|
ice_debug(hw, ICE_DBG_NVM, "Failed to read OROM bank pointer\n");
|
|
|
|
return status;
|
|
|
|
}
|
|
|
|
|
|
|
|
status = ice_read_sr_area_size(hw, ICE_SR_OROM_BANK_SIZE, &banks->orom_size);
|
|
|
|
if (status) {
|
|
|
|
ice_debug(hw, ICE_DBG_NVM, "Failed to read OROM bank area size\n");
|
|
|
|
return status;
|
|
|
|
}
|
|
|
|
|
|
|
|
status = ice_read_sr_pointer(hw, ICE_SR_NETLIST_BANK_PTR, &banks->netlist_ptr);
|
|
|
|
if (status) {
|
|
|
|
ice_debug(hw, ICE_DBG_NVM, "Failed to read Netlist bank pointer\n");
|
|
|
|
return status;
|
|
|
|
}
|
|
|
|
|
|
|
|
status = ice_read_sr_area_size(hw, ICE_SR_NETLIST_BANK_SIZE, &banks->netlist_size);
|
|
|
|
if (status) {
|
|
|
|
ice_debug(hw, ICE_DBG_NVM, "Failed to read Netlist bank area size\n");
|
|
|
|
return status;
|
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2018-03-20 07:58:07 -07:00
|
|
|
/**
|
|
|
|
* ice_init_nvm - initializes NVM setting
|
2019-02-19 15:04:13 -08:00
|
|
|
* @hw: pointer to the HW struct
|
2018-03-20 07:58:07 -07:00
|
|
|
*
|
|
|
|
* This function reads and populates NVM settings such as Shadow RAM size,
|
|
|
|
* max_timeout, and blank_nvm_mode
|
|
|
|
*/
|
2021-10-07 15:56:57 -07:00
|
|
|
int ice_init_nvm(struct ice_hw *hw)
|
2018-03-20 07:58:07 -07:00
|
|
|
{
|
2020-10-01 10:31:41 -07:00
|
|
|
struct ice_flash_info *flash = &hw->flash;
|
2018-03-20 07:58:07 -07:00
|
|
|
u32 fla, gens_stat;
|
|
|
|
u8 sr_size;
|
2021-10-07 15:59:03 -07:00
|
|
|
int status;
|
2018-03-20 07:58:07 -07:00
|
|
|
|
2019-02-19 15:04:13 -08:00
|
|
|
/* The SR size is stored regardless of the NVM programming mode
|
2018-03-20 07:58:07 -07:00
|
|
|
* as the blank mode may be used in the factory line.
|
|
|
|
*/
|
|
|
|
gens_stat = rd32(hw, GLNVM_GENS);
|
2023-12-05 17:01:12 -08:00
|
|
|
sr_size = FIELD_GET(GLNVM_GENS_SR_SIZE_M, gens_stat);
|
2018-03-20 07:58:07 -07:00
|
|
|
|
|
|
|
/* Switching to words (sr_size contains power of 2) */
|
2020-10-01 10:31:41 -07:00
|
|
|
flash->sr_words = BIT(sr_size) * ICE_SR_WORDS_IN_1KB;
|
2018-03-20 07:58:07 -07:00
|
|
|
|
|
|
|
/* Check if we are in the normal or blank NVM programming mode */
|
|
|
|
fla = rd32(hw, GLNVM_FLA);
|
|
|
|
if (fla & GLNVM_FLA_LOCKED_M) { /* Normal programming mode */
|
2020-10-01 10:31:41 -07:00
|
|
|
flash->blank_nvm_mode = false;
|
2019-10-09 07:09:42 -07:00
|
|
|
} else {
|
|
|
|
/* Blank programming mode */
|
2020-10-01 10:31:41 -07:00
|
|
|
flash->blank_nvm_mode = true;
|
2020-09-17 13:13:46 -07:00
|
|
|
ice_debug(hw, ICE_DBG_NVM, "NVM init error: unsupported blank mode.\n");
|
2021-10-07 15:58:01 -07:00
|
|
|
return -EIO;
|
2018-03-20 07:58:07 -07:00
|
|
|
}
|
|
|
|
|
2020-10-01 10:31:41 -07:00
|
|
|
status = ice_discover_flash_size(hw);
|
2018-03-20 07:58:07 -07:00
|
|
|
if (status) {
|
2020-10-01 10:31:41 -07:00
|
|
|
ice_debug(hw, ICE_DBG_NVM, "NVM init error: failed to discover flash size.\n");
|
2018-03-20 07:58:07 -07:00
|
|
|
return status;
|
|
|
|
}
|
|
|
|
|
2020-10-01 10:31:42 -07:00
|
|
|
status = ice_determine_active_flash_banks(hw);
|
|
|
|
if (status) {
|
|
|
|
ice_debug(hw, ICE_DBG_NVM, "Failed to determine active flash banks.\n");
|
|
|
|
return status;
|
|
|
|
}
|
|
|
|
|
ice: introduce function for reading from flash modules
When reading from the flash memory of the device, the ice driver has two
interfaces available to it. First, it can use a mediated interface via
firmware that allows specifying a module ID. This allows reading from
specific modules of the active flash bank.
The second interface available is to perform flat reads. This allows
complete access to the entire flash. However, using it requires the
software to handle calculating module location and interpret pointer
addresses.
While most data required is accessible through the convenient first
interface, certain flash contents are not. This includes the CSS header
information associated with the Option ROM and NVM banks, as well as any
access to the "inactive" banks used as scratch space for performing
flash updates.
In order to access all of the relevant flash contents, software must use
the flat reads. Rather than forcing all flows to perform flat read
calculations, introduce a new abstraction for reading from the flash:
ice_read_flash_module. This function provides an abstraction for reading
from either the active or inactive flash bank at the requested module.
This interface is very similar to the abstraction provided via firmware,
but allows access to additional modules, as well as providing
a mechanism to request access to both flash banks.
At first glance, it might make sense for this abstraction to allow
specifying precisely which bank (1st or 2nd) the caller wishes to read.
This is simpler to implement but more difficult to use. In practice,
most callers only know whether they want the active bank, or the
inactive bank. Rather than force callers to determine for themselves
which bank to read from, implement ice_read_flash_module in terms of
"active" vs "inactive". This significantly simplifies the implementation
at the caller level and is a more useful abstraction over the flash
contents.
Make use of this new interface to refactor reading of the main NVM
version information. Instead of using the firmware's mediated ShadowRAM
function, use the ice_read_flash_module abstraction.
To do this, notice that most reads of the NVM are going to be in 2-byte
word chunks. To simplify using ice_read_flash_module for this case,
ice_read_nvm_module is introduced. This is a simple wrapper around
ice_read_flash_module which takes the correct pointer address for the
NVM bank, and forces the 2-byte word format onto the caller.
When reading the NVM versions, some fields are read from the Shadow RAM.
The Shadow RAM is the first 64KB of flash memory, and is populated
during device load. Most fields are copied from a section within the
active NVM bank. In order to read this data from both the active and
inactive NVM banks, we need to read not from the first 64KB of flash,
but instead from the correct offset into the NVM bank. Introduce
ice_read_nvm_sr_copy for this purpose. This function wraps around
ice_read_nvm_module and has the same interface as the ice_read_sr_word,
with the exception of allowing the caller to specify whether to read the
active or inactive flash bank.
With this change, it is now trivial to refactor ice_get_nvm_ver_info to
read using the software mediated ice_read_flash_module interface instead
of relying on the firmware mediated interface. This will be used in the
following change to implement support for stored versions in the devlink
info report.
Additionally, the overall ice_read_flash_module interface will be used
and extended to support all three major flash banks, and additionally to
support reading the flash image security revision information.
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Tested-by: Tony Brelinski <tonyx.brelinski@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2020-10-01 10:31:43 -07:00
|
|
|
status = ice_get_nvm_ver_info(hw, ICE_ACTIVE_FLASH_BANK, &flash->nvm);
|
2020-03-11 18:58:13 -07:00
|
|
|
if (status) {
|
2020-10-01 10:31:41 -07:00
|
|
|
ice_debug(hw, ICE_DBG_INIT, "Failed to read NVM info.\n");
|
2020-03-11 18:58:13 -07:00
|
|
|
return status;
|
|
|
|
}
|
|
|
|
|
2020-11-11 16:43:30 -08:00
|
|
|
status = ice_get_orom_ver_info(hw, ICE_ACTIVE_FLASH_BANK, &flash->orom);
|
|
|
|
if (status)
|
2020-03-11 18:58:12 -07:00
|
|
|
ice_debug(hw, ICE_DBG_INIT, "Failed to read Option ROM info.\n");
|
2019-10-09 07:09:42 -07:00
|
|
|
|
2020-05-05 15:55:37 -07:00
|
|
|
/* read the netlist version information */
|
2020-11-11 16:43:29 -08:00
|
|
|
status = ice_get_netlist_info(hw, ICE_ACTIVE_FLASH_BANK, &flash->netlist);
|
2020-05-05 15:55:37 -07:00
|
|
|
if (status)
|
|
|
|
ice_debug(hw, ICE_DBG_INIT, "Failed to read netlist info.\n");
|
|
|
|
|
2019-10-09 07:09:42 -07:00
|
|
|
return 0;
|
2018-03-20 07:58:07 -07:00
|
|
|
}
|
2018-12-19 10:03:24 -08:00
|
|
|
|
2019-04-16 10:30:43 -07:00
|
|
|
/**
|
|
|
|
* ice_nvm_validate_checksum
|
|
|
|
* @hw: pointer to the HW struct
|
|
|
|
*
|
|
|
|
* Verify NVM PFA checksum validity (0x0706)
|
|
|
|
*/
|
2021-10-07 15:56:57 -07:00
|
|
|
int ice_nvm_validate_checksum(struct ice_hw *hw)
|
2019-04-16 10:30:43 -07:00
|
|
|
{
|
|
|
|
struct ice_aqc_nvm_checksum *cmd;
|
|
|
|
struct ice_aq_desc desc;
|
2021-10-07 15:56:57 -07:00
|
|
|
int status;
|
2019-04-16 10:30:43 -07:00
|
|
|
|
|
|
|
status = ice_acquire_nvm(hw, ICE_RES_READ);
|
|
|
|
if (status)
|
|
|
|
return status;
|
|
|
|
|
|
|
|
cmd = &desc.params.nvm_checksum;
|
|
|
|
|
|
|
|
ice_fill_dflt_direct_cmd_desc(&desc, ice_aqc_opc_nvm_checksum);
|
|
|
|
cmd->flags = ICE_AQC_NVM_CHECKSUM_VERIFY;
|
|
|
|
|
|
|
|
status = ice_aq_send_cmd(hw, &desc, NULL, 0, NULL);
|
|
|
|
ice_release_nvm(hw);
|
|
|
|
|
|
|
|
if (!status)
|
|
|
|
if (le16_to_cpu(cmd->checksum) != ICE_AQC_NVM_CHECKSUM_CORRECT)
|
2021-10-07 15:58:01 -07:00
|
|
|
status = -EIO;
|
2019-04-16 10:30:43 -07:00
|
|
|
|
|
|
|
return status;
|
|
|
|
}
|
2020-07-23 17:22:01 -07:00
|
|
|
|
|
|
|
/**
|
|
|
|
* ice_nvm_write_activate
|
|
|
|
* @hw: pointer to the HW struct
|
ice: support immediate firmware activation via devlink reload
The ice hardware contains an embedded chip with firmware which can be
updated using devlink flash. The firmware which runs on this chip is
referred to as the Embedded Management Processor firmware (EMP
firmware).
Activating the new firmware image currently requires that the system be
rebooted. This is not ideal as rebooting the system can cause unwanted
downtime.
In practical terms, activating the firmware does not always require a
full system reboot. In many cases it is possible to activate the EMP
firmware immediately. There are a couple of different scenarios to
cover.
* The EMP firmware itself can be reloaded by issuing a special update
to the device called an Embedded Management Processor reset (EMP
reset). This reset causes the device to reset and reload the EMP
firmware.
* PCI configuration changes are only reloaded after a cold PCIe reset.
Unfortunately there is no generic way to trigger this for a PCIe
device without a system reboot.
When performing a flash update, firmware is capable of responding with
some information about the specific update requirements.
The driver updates the flash by programming a secondary inactive bank
with the contents of the new image, and then issuing a command to
request to switch the active bank starting from the next load.
The response to the final command for updating the inactive NVM flash
bank includes an indication of the minimum reset required to fully
update the device. This can be one of the following:
* A full power on is required
* A cold PCIe reset is required
* An EMP reset is required
The response to the command to switch flash banks includes an indication
of whether or not the firmware will allow an EMP reset request.
For most updates, an EMP reset is sufficient to load the new EMP
firmware without issues. In some cases, this reset is not sufficient
because the PCI configuration space has changed. When this could cause
incompatibility with the new EMP image, the firmware is capable of
rejecting the EMP reset request.
Add logic to ice_fw_update.c to handle the response data flash update
AdminQ commands.
For the reset level, issue a devlink status notification informing the
user of how to complete the update with a simple suggestion like
"Activate new firmware by rebooting the system".
Cache the status of whether or not firmware will restrict the EMP reset
for use in implementing devlink reload.
Implement support for devlink reload with the "fw_activate" flag. This
allows user space to request the firmware be activated immediately.
For the .reload_down handler, we will issue a request for the EMP reset
using the appropriate firmware AdminQ command. If we know that the
firmware will not allow an EMP reset, simply exit with a suitable
netlink extended ACK message indicating that the EMP reset is not
available.
For the .reload_up handler, simply wait until the driver has finished
resetting. Logic to handle processing of an EMP reset already exists in
the driver as part of its reset and rebuild flows.
Implement support for the devlink reload interface with the
"fw_activate" action. This allows userspace to request activation of
firmware without a reboot.
Note that support for indicating the required reset and EMP reset
restriction is not supported on old versions of firmware. The driver can
determine if the two features are supported by checking the device
capabilities report. I confirmed support has existed since at least
version 5.5.2 as reported by the 'fw.mgmt' version. Support to issue the
EMP reset request has existed in all version of the EMP firmware for the
ice hardware.
Check the device capabilities report to determine whether or not the
indications are reported by the running firmware. If the reset
requirement indication is not supported, always assume a full power on
is necessary. If the reset restriction capability is not supported,
always assume the EMP reset is available.
Users can verify if the EMP reset has activated the firmware by using
the devlink info report to check that the 'running' firmware version has
updated. For example a user might do the following:
# Check current version
$ devlink dev info
# Update the device
$ devlink dev flash pci/0000:af:00.0 file firmware.bin
# Confirm stored version updated
$ devlink dev info
# Reload to activate new firmware
$ devlink dev reload pci/0000:af:00.0 action fw_activate
# Confirm running version updated
$ devlink dev info
Finally, this change does *not* implement basic driver-only reload
support. I did look into trying to do this. However, it requires
significant refactor of how the ice driver probes and loads everything.
The ice driver probe and allocation flows were not designed with such
a reload in mind. Refactoring the flow to support this is beyond the
scope of this change.
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Tested-by: Gurucharan G <gurucharanx.g@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2021-10-27 16:22:55 -07:00
|
|
|
* @cmd_flags: flags for write activate command
|
|
|
|
* @response_flags: response indicators from firmware
|
2020-07-23 17:22:01 -07:00
|
|
|
*
|
|
|
|
* Update the control word with the required banks' validity bits
|
|
|
|
* and dumps the Shadow RAM to flash (0x0707)
|
ice: support immediate firmware activation via devlink reload
The ice hardware contains an embedded chip with firmware which can be
updated using devlink flash. The firmware which runs on this chip is
referred to as the Embedded Management Processor firmware (EMP
firmware).
Activating the new firmware image currently requires that the system be
rebooted. This is not ideal as rebooting the system can cause unwanted
downtime.
In practical terms, activating the firmware does not always require a
full system reboot. In many cases it is possible to activate the EMP
firmware immediately. There are a couple of different scenarios to
cover.
* The EMP firmware itself can be reloaded by issuing a special update
to the device called an Embedded Management Processor reset (EMP
reset). This reset causes the device to reset and reload the EMP
firmware.
* PCI configuration changes are only reloaded after a cold PCIe reset.
Unfortunately there is no generic way to trigger this for a PCIe
device without a system reboot.
When performing a flash update, firmware is capable of responding with
some information about the specific update requirements.
The driver updates the flash by programming a secondary inactive bank
with the contents of the new image, and then issuing a command to
request to switch the active bank starting from the next load.
The response to the final command for updating the inactive NVM flash
bank includes an indication of the minimum reset required to fully
update the device. This can be one of the following:
* A full power on is required
* A cold PCIe reset is required
* An EMP reset is required
The response to the command to switch flash banks includes an indication
of whether or not the firmware will allow an EMP reset request.
For most updates, an EMP reset is sufficient to load the new EMP
firmware without issues. In some cases, this reset is not sufficient
because the PCI configuration space has changed. When this could cause
incompatibility with the new EMP image, the firmware is capable of
rejecting the EMP reset request.
Add logic to ice_fw_update.c to handle the response data flash update
AdminQ commands.
For the reset level, issue a devlink status notification informing the
user of how to complete the update with a simple suggestion like
"Activate new firmware by rebooting the system".
Cache the status of whether or not firmware will restrict the EMP reset
for use in implementing devlink reload.
Implement support for devlink reload with the "fw_activate" flag. This
allows user space to request the firmware be activated immediately.
For the .reload_down handler, we will issue a request for the EMP reset
using the appropriate firmware AdminQ command. If we know that the
firmware will not allow an EMP reset, simply exit with a suitable
netlink extended ACK message indicating that the EMP reset is not
available.
For the .reload_up handler, simply wait until the driver has finished
resetting. Logic to handle processing of an EMP reset already exists in
the driver as part of its reset and rebuild flows.
Implement support for the devlink reload interface with the
"fw_activate" action. This allows userspace to request activation of
firmware without a reboot.
Note that support for indicating the required reset and EMP reset
restriction is not supported on old versions of firmware. The driver can
determine if the two features are supported by checking the device
capabilities report. I confirmed support has existed since at least
version 5.5.2 as reported by the 'fw.mgmt' version. Support to issue the
EMP reset request has existed in all version of the EMP firmware for the
ice hardware.
Check the device capabilities report to determine whether or not the
indications are reported by the running firmware. If the reset
requirement indication is not supported, always assume a full power on
is necessary. If the reset restriction capability is not supported,
always assume the EMP reset is available.
Users can verify if the EMP reset has activated the firmware by using
the devlink info report to check that the 'running' firmware version has
updated. For example a user might do the following:
# Check current version
$ devlink dev info
# Update the device
$ devlink dev flash pci/0000:af:00.0 file firmware.bin
# Confirm stored version updated
$ devlink dev info
# Reload to activate new firmware
$ devlink dev reload pci/0000:af:00.0 action fw_activate
# Confirm running version updated
$ devlink dev info
Finally, this change does *not* implement basic driver-only reload
support. I did look into trying to do this. However, it requires
significant refactor of how the ice driver probes and loads everything.
The ice driver probe and allocation flows were not designed with such
a reload in mind. Refactoring the flow to support this is beyond the
scope of this change.
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Tested-by: Gurucharan G <gurucharanx.g@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2021-10-27 16:22:55 -07:00
|
|
|
*
|
2022-08-11 15:05:34 +02:00
|
|
|
* cmd_flags controls which banks to activate, the preservation level to use
|
|
|
|
* when activating the NVM bank, and whether an EMP reset is required for
|
|
|
|
* activation.
|
|
|
|
*
|
|
|
|
* Note that the 16bit cmd_flags value is split between two separate 1 byte
|
|
|
|
* flag values in the descriptor.
|
ice: support immediate firmware activation via devlink reload
The ice hardware contains an embedded chip with firmware which can be
updated using devlink flash. The firmware which runs on this chip is
referred to as the Embedded Management Processor firmware (EMP
firmware).
Activating the new firmware image currently requires that the system be
rebooted. This is not ideal as rebooting the system can cause unwanted
downtime.
In practical terms, activating the firmware does not always require a
full system reboot. In many cases it is possible to activate the EMP
firmware immediately. There are a couple of different scenarios to
cover.
* The EMP firmware itself can be reloaded by issuing a special update
to the device called an Embedded Management Processor reset (EMP
reset). This reset causes the device to reset and reload the EMP
firmware.
* PCI configuration changes are only reloaded after a cold PCIe reset.
Unfortunately there is no generic way to trigger this for a PCIe
device without a system reboot.
When performing a flash update, firmware is capable of responding with
some information about the specific update requirements.
The driver updates the flash by programming a secondary inactive bank
with the contents of the new image, and then issuing a command to
request to switch the active bank starting from the next load.
The response to the final command for updating the inactive NVM flash
bank includes an indication of the minimum reset required to fully
update the device. This can be one of the following:
* A full power on is required
* A cold PCIe reset is required
* An EMP reset is required
The response to the command to switch flash banks includes an indication
of whether or not the firmware will allow an EMP reset request.
For most updates, an EMP reset is sufficient to load the new EMP
firmware without issues. In some cases, this reset is not sufficient
because the PCI configuration space has changed. When this could cause
incompatibility with the new EMP image, the firmware is capable of
rejecting the EMP reset request.
Add logic to ice_fw_update.c to handle the response data flash update
AdminQ commands.
For the reset level, issue a devlink status notification informing the
user of how to complete the update with a simple suggestion like
"Activate new firmware by rebooting the system".
Cache the status of whether or not firmware will restrict the EMP reset
for use in implementing devlink reload.
Implement support for devlink reload with the "fw_activate" flag. This
allows user space to request the firmware be activated immediately.
For the .reload_down handler, we will issue a request for the EMP reset
using the appropriate firmware AdminQ command. If we know that the
firmware will not allow an EMP reset, simply exit with a suitable
netlink extended ACK message indicating that the EMP reset is not
available.
For the .reload_up handler, simply wait until the driver has finished
resetting. Logic to handle processing of an EMP reset already exists in
the driver as part of its reset and rebuild flows.
Implement support for the devlink reload interface with the
"fw_activate" action. This allows userspace to request activation of
firmware without a reboot.
Note that support for indicating the required reset and EMP reset
restriction is not supported on old versions of firmware. The driver can
determine if the two features are supported by checking the device
capabilities report. I confirmed support has existed since at least
version 5.5.2 as reported by the 'fw.mgmt' version. Support to issue the
EMP reset request has existed in all version of the EMP firmware for the
ice hardware.
Check the device capabilities report to determine whether or not the
indications are reported by the running firmware. If the reset
requirement indication is not supported, always assume a full power on
is necessary. If the reset restriction capability is not supported,
always assume the EMP reset is available.
Users can verify if the EMP reset has activated the firmware by using
the devlink info report to check that the 'running' firmware version has
updated. For example a user might do the following:
# Check current version
$ devlink dev info
# Update the device
$ devlink dev flash pci/0000:af:00.0 file firmware.bin
# Confirm stored version updated
$ devlink dev info
# Reload to activate new firmware
$ devlink dev reload pci/0000:af:00.0 action fw_activate
# Confirm running version updated
$ devlink dev info
Finally, this change does *not* implement basic driver-only reload
support. I did look into trying to do this. However, it requires
significant refactor of how the ice driver probes and loads everything.
The ice driver probe and allocation flows were not designed with such
a reload in mind. Refactoring the flow to support this is beyond the
scope of this change.
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Tested-by: Gurucharan G <gurucharanx.g@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2021-10-27 16:22:55 -07:00
|
|
|
*
|
|
|
|
* On successful return of the firmware command, the response_flags variable
|
|
|
|
* is updated with the flags reported by firmware indicating certain status,
|
|
|
|
* such as whether EMP reset is enabled.
|
2020-07-23 17:22:01 -07:00
|
|
|
*/
|
2022-08-11 15:05:34 +02:00
|
|
|
int ice_nvm_write_activate(struct ice_hw *hw, u16 cmd_flags, u8 *response_flags)
|
2020-07-23 17:22:01 -07:00
|
|
|
{
|
|
|
|
struct ice_aqc_nvm *cmd;
|
|
|
|
struct ice_aq_desc desc;
|
ice: support immediate firmware activation via devlink reload
The ice hardware contains an embedded chip with firmware which can be
updated using devlink flash. The firmware which runs on this chip is
referred to as the Embedded Management Processor firmware (EMP
firmware).
Activating the new firmware image currently requires that the system be
rebooted. This is not ideal as rebooting the system can cause unwanted
downtime.
In practical terms, activating the firmware does not always require a
full system reboot. In many cases it is possible to activate the EMP
firmware immediately. There are a couple of different scenarios to
cover.
* The EMP firmware itself can be reloaded by issuing a special update
to the device called an Embedded Management Processor reset (EMP
reset). This reset causes the device to reset and reload the EMP
firmware.
* PCI configuration changes are only reloaded after a cold PCIe reset.
Unfortunately there is no generic way to trigger this for a PCIe
device without a system reboot.
When performing a flash update, firmware is capable of responding with
some information about the specific update requirements.
The driver updates the flash by programming a secondary inactive bank
with the contents of the new image, and then issuing a command to
request to switch the active bank starting from the next load.
The response to the final command for updating the inactive NVM flash
bank includes an indication of the minimum reset required to fully
update the device. This can be one of the following:
* A full power on is required
* A cold PCIe reset is required
* An EMP reset is required
The response to the command to switch flash banks includes an indication
of whether or not the firmware will allow an EMP reset request.
For most updates, an EMP reset is sufficient to load the new EMP
firmware without issues. In some cases, this reset is not sufficient
because the PCI configuration space has changed. When this could cause
incompatibility with the new EMP image, the firmware is capable of
rejecting the EMP reset request.
Add logic to ice_fw_update.c to handle the response data flash update
AdminQ commands.
For the reset level, issue a devlink status notification informing the
user of how to complete the update with a simple suggestion like
"Activate new firmware by rebooting the system".
Cache the status of whether or not firmware will restrict the EMP reset
for use in implementing devlink reload.
Implement support for devlink reload with the "fw_activate" flag. This
allows user space to request the firmware be activated immediately.
For the .reload_down handler, we will issue a request for the EMP reset
using the appropriate firmware AdminQ command. If we know that the
firmware will not allow an EMP reset, simply exit with a suitable
netlink extended ACK message indicating that the EMP reset is not
available.
For the .reload_up handler, simply wait until the driver has finished
resetting. Logic to handle processing of an EMP reset already exists in
the driver as part of its reset and rebuild flows.
Implement support for the devlink reload interface with the
"fw_activate" action. This allows userspace to request activation of
firmware without a reboot.
Note that support for indicating the required reset and EMP reset
restriction is not supported on old versions of firmware. The driver can
determine if the two features are supported by checking the device
capabilities report. I confirmed support has existed since at least
version 5.5.2 as reported by the 'fw.mgmt' version. Support to issue the
EMP reset request has existed in all version of the EMP firmware for the
ice hardware.
Check the device capabilities report to determine whether or not the
indications are reported by the running firmware. If the reset
requirement indication is not supported, always assume a full power on
is necessary. If the reset restriction capability is not supported,
always assume the EMP reset is available.
Users can verify if the EMP reset has activated the firmware by using
the devlink info report to check that the 'running' firmware version has
updated. For example a user might do the following:
# Check current version
$ devlink dev info
# Update the device
$ devlink dev flash pci/0000:af:00.0 file firmware.bin
# Confirm stored version updated
$ devlink dev info
# Reload to activate new firmware
$ devlink dev reload pci/0000:af:00.0 action fw_activate
# Confirm running version updated
$ devlink dev info
Finally, this change does *not* implement basic driver-only reload
support. I did look into trying to do this. However, it requires
significant refactor of how the ice driver probes and loads everything.
The ice driver probe and allocation flows were not designed with such
a reload in mind. Refactoring the flow to support this is beyond the
scope of this change.
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Tested-by: Gurucharan G <gurucharanx.g@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2021-10-27 16:22:55 -07:00
|
|
|
int err;
|
2020-07-23 17:22:01 -07:00
|
|
|
|
|
|
|
cmd = &desc.params.nvm;
|
|
|
|
ice_fill_dflt_direct_cmd_desc(&desc, ice_aqc_opc_nvm_write_activate);
|
|
|
|
|
2022-08-11 15:05:34 +02:00
|
|
|
cmd->cmd_flags = (u8)(cmd_flags & 0xFF);
|
|
|
|
cmd->offset_high = (u8)((cmd_flags >> 8) & 0xFF);
|
2020-07-23 17:22:01 -07:00
|
|
|
|
ice: support immediate firmware activation via devlink reload
The ice hardware contains an embedded chip with firmware which can be
updated using devlink flash. The firmware which runs on this chip is
referred to as the Embedded Management Processor firmware (EMP
firmware).
Activating the new firmware image currently requires that the system be
rebooted. This is not ideal as rebooting the system can cause unwanted
downtime.
In practical terms, activating the firmware does not always require a
full system reboot. In many cases it is possible to activate the EMP
firmware immediately. There are a couple of different scenarios to
cover.
* The EMP firmware itself can be reloaded by issuing a special update
to the device called an Embedded Management Processor reset (EMP
reset). This reset causes the device to reset and reload the EMP
firmware.
* PCI configuration changes are only reloaded after a cold PCIe reset.
Unfortunately there is no generic way to trigger this for a PCIe
device without a system reboot.
When performing a flash update, firmware is capable of responding with
some information about the specific update requirements.
The driver updates the flash by programming a secondary inactive bank
with the contents of the new image, and then issuing a command to
request to switch the active bank starting from the next load.
The response to the final command for updating the inactive NVM flash
bank includes an indication of the minimum reset required to fully
update the device. This can be one of the following:
* A full power on is required
* A cold PCIe reset is required
* An EMP reset is required
The response to the command to switch flash banks includes an indication
of whether or not the firmware will allow an EMP reset request.
For most updates, an EMP reset is sufficient to load the new EMP
firmware without issues. In some cases, this reset is not sufficient
because the PCI configuration space has changed. When this could cause
incompatibility with the new EMP image, the firmware is capable of
rejecting the EMP reset request.
Add logic to ice_fw_update.c to handle the response data flash update
AdminQ commands.
For the reset level, issue a devlink status notification informing the
user of how to complete the update with a simple suggestion like
"Activate new firmware by rebooting the system".
Cache the status of whether or not firmware will restrict the EMP reset
for use in implementing devlink reload.
Implement support for devlink reload with the "fw_activate" flag. This
allows user space to request the firmware be activated immediately.
For the .reload_down handler, we will issue a request for the EMP reset
using the appropriate firmware AdminQ command. If we know that the
firmware will not allow an EMP reset, simply exit with a suitable
netlink extended ACK message indicating that the EMP reset is not
available.
For the .reload_up handler, simply wait until the driver has finished
resetting. Logic to handle processing of an EMP reset already exists in
the driver as part of its reset and rebuild flows.
Implement support for the devlink reload interface with the
"fw_activate" action. This allows userspace to request activation of
firmware without a reboot.
Note that support for indicating the required reset and EMP reset
restriction is not supported on old versions of firmware. The driver can
determine if the two features are supported by checking the device
capabilities report. I confirmed support has existed since at least
version 5.5.2 as reported by the 'fw.mgmt' version. Support to issue the
EMP reset request has existed in all version of the EMP firmware for the
ice hardware.
Check the device capabilities report to determine whether or not the
indications are reported by the running firmware. If the reset
requirement indication is not supported, always assume a full power on
is necessary. If the reset restriction capability is not supported,
always assume the EMP reset is available.
Users can verify if the EMP reset has activated the firmware by using
the devlink info report to check that the 'running' firmware version has
updated. For example a user might do the following:
# Check current version
$ devlink dev info
# Update the device
$ devlink dev flash pci/0000:af:00.0 file firmware.bin
# Confirm stored version updated
$ devlink dev info
# Reload to activate new firmware
$ devlink dev reload pci/0000:af:00.0 action fw_activate
# Confirm running version updated
$ devlink dev info
Finally, this change does *not* implement basic driver-only reload
support. I did look into trying to do this. However, it requires
significant refactor of how the ice driver probes and loads everything.
The ice driver probe and allocation flows were not designed with such
a reload in mind. Refactoring the flow to support this is beyond the
scope of this change.
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Tested-by: Gurucharan G <gurucharanx.g@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2021-10-27 16:22:55 -07:00
|
|
|
err = ice_aq_send_cmd(hw, &desc, NULL, 0, NULL);
|
|
|
|
if (!err && response_flags)
|
|
|
|
*response_flags = cmd->cmd_flags;
|
|
|
|
|
|
|
|
return err;
|
2020-07-23 17:22:01 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* ice_aq_nvm_update_empr
|
|
|
|
* @hw: pointer to the HW struct
|
|
|
|
*
|
|
|
|
* Update empr (0x0709). This command allows SW to
|
|
|
|
* request an EMPR to activate new FW.
|
|
|
|
*/
|
2021-10-07 15:56:57 -07:00
|
|
|
int ice_aq_nvm_update_empr(struct ice_hw *hw)
|
2020-07-23 17:22:01 -07:00
|
|
|
{
|
|
|
|
struct ice_aq_desc desc;
|
|
|
|
|
|
|
|
ice_fill_dflt_direct_cmd_desc(&desc, ice_aqc_opc_nvm_update_empr);
|
|
|
|
|
|
|
|
return ice_aq_send_cmd(hw, &desc, NULL, 0, NULL);
|
|
|
|
}
|
|
|
|
|
|
|
|
/* ice_nvm_set_pkg_data
|
|
|
|
* @hw: pointer to the HW struct
|
|
|
|
* @del_pkg_data_flag: If is set then the current pkg_data store by FW
|
|
|
|
* is deleted.
|
|
|
|
* If bit is set to 1, then buffer should be size 0.
|
|
|
|
* @data: pointer to buffer
|
|
|
|
* @length: length of the buffer
|
|
|
|
* @cd: pointer to command details structure or NULL
|
|
|
|
*
|
|
|
|
* Set package data (0x070A). This command is equivalent to the reception
|
|
|
|
* of a PLDM FW Update GetPackageData cmd. This command should be sent
|
|
|
|
* as part of the NVM update as the first cmd in the flow.
|
|
|
|
*/
|
|
|
|
|
2021-10-07 15:56:57 -07:00
|
|
|
int
|
2020-07-23 17:22:01 -07:00
|
|
|
ice_nvm_set_pkg_data(struct ice_hw *hw, bool del_pkg_data_flag, u8 *data,
|
|
|
|
u16 length, struct ice_sq_cd *cd)
|
|
|
|
{
|
|
|
|
struct ice_aqc_nvm_pkg_data *cmd;
|
|
|
|
struct ice_aq_desc desc;
|
|
|
|
|
|
|
|
if (length != 0 && !data)
|
2021-10-07 15:58:01 -07:00
|
|
|
return -EINVAL;
|
2020-07-23 17:22:01 -07:00
|
|
|
|
|
|
|
cmd = &desc.params.pkg_data;
|
|
|
|
|
|
|
|
ice_fill_dflt_direct_cmd_desc(&desc, ice_aqc_opc_nvm_pkg_data);
|
|
|
|
desc.flags |= cpu_to_le16(ICE_AQ_FLAG_RD);
|
|
|
|
|
|
|
|
if (del_pkg_data_flag)
|
|
|
|
cmd->cmd_flags |= ICE_AQC_NVM_PKG_DELETE;
|
|
|
|
|
|
|
|
return ice_aq_send_cmd(hw, &desc, data, length, cd);
|
|
|
|
}
|
|
|
|
|
|
|
|
/* ice_nvm_pass_component_tbl
|
|
|
|
* @hw: pointer to the HW struct
|
|
|
|
* @data: pointer to buffer
|
|
|
|
* @length: length of the buffer
|
|
|
|
* @transfer_flag: parameter for determining stage of the update
|
|
|
|
* @comp_response: a pointer to the response from the 0x070B AQC.
|
|
|
|
* @comp_response_code: a pointer to the response code from the 0x070B AQC.
|
|
|
|
* @cd: pointer to command details structure or NULL
|
|
|
|
*
|
|
|
|
* Pass component table (0x070B). This command is equivalent to the reception
|
|
|
|
* of a PLDM FW Update PassComponentTable cmd. This command should be sent once
|
|
|
|
* per component. It can be only sent after Set Package Data cmd and before
|
|
|
|
* actual update. FW will assume these commands are going to be sent until
|
|
|
|
* the TransferFlag is set to End or StartAndEnd.
|
|
|
|
*/
|
|
|
|
|
2021-10-07 15:56:57 -07:00
|
|
|
int
|
2020-07-23 17:22:01 -07:00
|
|
|
ice_nvm_pass_component_tbl(struct ice_hw *hw, u8 *data, u16 length,
|
|
|
|
u8 transfer_flag, u8 *comp_response,
|
|
|
|
u8 *comp_response_code, struct ice_sq_cd *cd)
|
|
|
|
{
|
|
|
|
struct ice_aqc_nvm_pass_comp_tbl *cmd;
|
|
|
|
struct ice_aq_desc desc;
|
2021-10-07 15:56:57 -07:00
|
|
|
int status;
|
2020-07-23 17:22:01 -07:00
|
|
|
|
|
|
|
if (!data || !comp_response || !comp_response_code)
|
2021-10-07 15:58:01 -07:00
|
|
|
return -EINVAL;
|
2020-07-23 17:22:01 -07:00
|
|
|
|
|
|
|
cmd = &desc.params.pass_comp_tbl;
|
|
|
|
|
|
|
|
ice_fill_dflt_direct_cmd_desc(&desc,
|
|
|
|
ice_aqc_opc_nvm_pass_component_tbl);
|
|
|
|
desc.flags |= cpu_to_le16(ICE_AQ_FLAG_RD);
|
|
|
|
|
|
|
|
cmd->transfer_flag = transfer_flag;
|
|
|
|
status = ice_aq_send_cmd(hw, &desc, data, length, cd);
|
|
|
|
|
|
|
|
if (!status) {
|
|
|
|
*comp_response = cmd->component_response;
|
|
|
|
*comp_response_code = cmd->component_response_code;
|
|
|
|
}
|
|
|
|
return status;
|
|
|
|
}
|