Support for running firmware in embedded controllers by JaiOCP · Pull Request #2319 · opencomputeproject/SAI

JaiOCP · 2026-07-21T19:15:16Z

Modern switches have embedded controller to run firmware for low latency applications.
This PR bring in support for installing and monitoring firmware based on the hardware support.

Signed-off-by: JaiOCP <jai.kumar@broadcom.com>

azure-pipelines · 2026-07-21T19:15:25Z

Azure Pipelines: There may be pipelines that require an authorized user to comment /azp run to run.

kcudnik · 2026-07-22T08:40:00Z

+     * The maximum number of characters for the name is SAI_FW_NAME_SIZE - 1 since
+     * it needs the terminating null byte ('\0') at the end.
+     *
+     * @type char


char is refering to sai_attribute_value_t::chardata which is 32 bytes, if you want longer string, use sai_s8_list_t

same SAI_FW_ATTR_LOG_FILE_AND_PATH_NAME

kcudnik · 2026-07-22T08:44:02Z

    {
        WriteSource "$val = { .chardata = { 0 } };";
    }
+    elsif ($default =~ /^0$/ and $type =~ /^(sai_fw_inst_t)/)


type eq "sai_fw_inst_t, you can merge this with

elsif ($default =~ /^0$/ and $type =~ /^(sai_timespec_t|sai_fw_inst_t)$/)

kcudnik · 2026-07-22T08:50:11Z

you have only SAI_OBJECT_TYPE_FW as readable variable you cant assign it anywhre, its possible to create any of thos objects ? is that by design ?

gananthateerta · 2026-07-23T15:03:10Z

+
+### 2.1 Firmware Object Lifecycle
+
+There are two life cycles that need to be supported.


If firmware crashes, the only way NOS finds out is by polling SAI_FW_ATTR_FW_OP_STATE and noticing it changed to ERROR.

A notification callback, consistent with how SAI handles other async events, is neeed.

Following functionality can be added:
Crash reason?
Core dump?
Auto-restart?

Accepted the feedback. Will add a callback

AnandhiDhanabalan · 2026-07-29T06:09:05Z

+     * @flags CREATE_AND_SET
+     * @default ""
+     */
+    SAI_FW_ATTR_FW_FILE_AND_PATH_NAME,


Should this be CREATE_ONLY | MANDATORY ?
When multiple firmware objects are available, how will the NOS be able to map the firmware object to a specific firmware ?

I was thinking if NOS need to modify the file name for some new encoding we should allow it run time and hence not mandatory.

AnandhiDhanabalan · 2026-07-29T06:11:15Z

+     * @flags CREATE_AND_SET
+     * @default 0
+     */
+    SAI_FW_ATTR_CORE_ID,


For CORE_ID to be changed - what is the allowed oper and admin state ? How do we establish this requirment of specific admin and operstates when CORE_ID is changed ?

Ideally this can be changed only when SAI_FW_ADMIN_STATE_UNLOAD_FW, other admin state should not allow it. Is this understanding correct ?

Some additional thoughts..
The @flags for SAI_FW_ATTR_CORE_ID should be CREATE_ONLY, not CREATE_AND_SET. Changing the core assignment of a firmware object while it is in RUNNING or LOADED state is not meaningful — the F/W is already committed to that core's memory space. To move firmware to a different core, remove and recreate the FW object. If dynamic reassignment is intended (e.g., for load balancing) a new admin state and associated semantics must be defined.

This is a good point. Lets discuss this in meeting

AnandhiDhanabalan · 2026-07-29T06:13:55Z

+     *
+     * @type sai_uint8_t
+     * @flags CREATE_AND_SET
+     * @default 0


How will NOS know supported core-ids ? Should we have a default read-only core-id list ?
Also should we support a default_internal option instead of default, if NOS wants to go with default option ?

There is a readonly attribute for MAX cores. NOS can ping a FW on an abstracted core no of 0 to max-1. This can internally be mapped by the SAI adapter.

Reason I kept it this way is mainly to provide flexibility to silicon vendor to internally id the cores as applicable. Note that cores may not be in single domain space as we talked about.

AnandhiDhanabalan · 2026-07-29T06:16:32Z

+     * @flags CREATE_AND_SET
+     * @default 0
+     */
+    SAI_FW_ATTR_CORE_ID,


Given core_id can have only single f/w object or multiple ?
If Single - how do you upgrade a f/w from say V1 to V2 - Can you give the flow ?
Should core_id be kept as key?

The design must address co-running FW constraints. Some implementations compile multiple features into a single F/W image.

The design doc should also clarify: when two F/W objects share Asic h/w resource, what is the resource arbitration contract? Is it implementation-defined or must it be modeled in SAI?

FW is an abstracted entity and may support one or more features. As I mentioned that features are exposed via separate SAI APIs and have no correlation to FW object.

If FW need to migrated to different core, then it is a destructive event. Ideally FW object should be deleted and recreated with different core id (this is where your suggestion of CREATE_ONLY for core id is valid). And this will impact all the features supported by that instance of FW.

AnandhiDhanabalan · 2026-07-29T06:17:51Z

+* Firmware state monitoring
+* Runtime firmware configuration
+
+The API is exposed through the `sai_fw_api_t` method table, using a new FW object.


How will the existing f/w switch attributes co-exist with this new infra ?

Existing Firmware attributes are very specific to Gearbox with MDIO/EEPROM load methods and can support only single firmware instance.
These attributes are not deprecated and stay such.

NOS can choose existing or the new infra based on the capability query for the device and both can be enabled at the same time if supported.

AnandhiDhanabalan · 2026-07-29T06:19:03Z

+
+    /** Firmware admin state is unload the firmware */
+    SAI_FW_ADMIN_STATE_UNLOAD_FW,
+} sai_fw_admin_state_t;


During warm boot how do we reconnect to the f/w ?
Should we have a additional admin state like sync to indicate warm boot ?

I am not clear what reconnect means? After warmboot NOS will query the admin state and op state to figure out the state of FW.

If reconnect means some kind of RPC channel then note that NOS do not open any RPC channel. If there is one it is internal to the chip vendor.

AnandhiDhanabalan · 2026-07-29T06:23:20Z

+
+    /** Firmware admin state */
+    sai_fw_admin_state_t admin_state;
+} sai_fw_inst_t;


Can we have a vendor specific read-only string added to sai_fw_inst_t ? To identify the f/w, type etc or aA firmware role/type attribute is needed to bind a FW object to its consuming SAI subsystem.

Could you specify how the relationship between SAI_OBJECT_TYPE_FW and any other object in the sai system that uses this firmware object, say SAI_OBJECT_TYPE_TAM or SAI_OBJECT_TYPE_TAM_INT is established ?

Vendor specific request was discussed in meeting. If there is a need to specify any kind of hint for SDK to pick on for some vendor specific operations that can be encoded in the FW file name.

SAI_OBJECT_TYPE_FW has a naroow focus of manaigng the life cycle of the firmware. What kind of functionality it exposes is not part of this PR.

Typically any function either by the FW or the native switch silicon is abstracted independently as a SAI API. For example TAM functions can be implemented using a firmware. In this firmware life cycle management is done by the FW object and function is exposed using the TAM object. There is no coupling between two within the SAI framework.

Good question though :)

AnandhiDhanabalan · 2026-07-29T10:05:47Z

+| SAI_FW_OP_STATE_NOT_LOADED | Firmware unavailable and not loaded|
+| SAI_FW_OP_STATE_RUNNING    | Firmware loaded and running     |
+| SAI_FW_OP_STATE_STOPPED    | Firmware loaded but stopped     |
+| SAI_FW_OP_STATE_ERROR      | Firmware loaded and encountered an error   |


For ASICs with async FW loading, transitional states are needed:

SAI_FW_OP_STATE_LOADING, // image transfer in progress SAI_FW_OP_STATE_STOPPING, // graceful shutdown in progress

Without these, the NOS has no way to distinguish "FW load not started" from "FW load in progress" when polling SAI_FW_ATTR_FW_OP_STATE. Also consider adding a notification callback (SAI_SWITCH_ATTR_FW_STATE_CHANGE_NOTIFY) so the NOS doesn't need to poll.

eladnachman · 2026-08-02T13:57:03Z

+/**
+ * @brief Defines maximum length of firmware and log file name
+ */
+#define SAI_FW_NAME_SIZE 64


Why is the limited set at 64 bytes? According to the PR documentation this is used for both the path and the file name. Under complex Linux mounting, this limit might not be enough. Consider enlarging to at least 128 if not 256.

JaiOCP added 3 commits June 24, 2026 13:12

Support for Multiple Firmware

80255ef

Signed-off-by: JaiOCP <jai.kumar@broadcom.com>

Multiple Firmware Support

c8a33e5

Signed-off-by: JaiOCP <jai.kumar@broadcom.com>

Merge branch 'opencomputeproject:master' into fw

4bc2447

kcudnik reviewed Jul 22, 2026

View reviewed changes

gananthateerta reviewed Jul 23, 2026

View reviewed changes

tjchadaga added the reviewed PR is discussed in SAI Meeting label Jul 24, 2026

AnandhiDhanabalan reviewed Jul 29, 2026

View reviewed changes

eladnachman reviewed Aug 2, 2026

View reviewed changes


		### 2.1 Firmware Object Lifecycle

		There are two life cycles that need to be supported.

Uh oh!

Conversation

JaiOCP commented Jul 21, 2026

Uh oh!

azure-pipelines Bot commented Jul 21, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

kcudnik Jul 22, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

kcudnik commented Jul 22, 2026

Uh oh!

gananthateerta Jul 23, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

AnandhiDhanabalan Jul 29, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

AnandhiDhanabalan Jul 29, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

AnandhiDhanabalan Jul 29, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

6 participants

kcudnik Jul 22, 2026 •

edited

Loading

gananthateerta Jul 23, 2026 •

edited

Loading

AnandhiDhanabalan Jul 29, 2026 •

edited

Loading

AnandhiDhanabalan Jul 29, 2026 •

edited

Loading

AnandhiDhanabalan Jul 29, 2026 •

edited

Loading