Patent Description:
Modern computer systems may have several firmware components. Firmware updates or patches can be provided to computer systems for a variety of reasons. Firmware updates may provide more efficient operation of devices, fix bugs, and/or enhance operational capabilities. Security attacks on firmware components can be a problem, and may result in loss of revenue, loss of productivity, and/or leaks of information such as business data.

Firmware updates may improve the security of computers/computer systems. Mitigating firmware attacks can be done by sending firmware updates and/or patches in-field.

The patent publication <CIT> titled "System and Method to Secure Embedded Controller Flashing Process" discusses a technique in which an embedded controller (EC) can receive an EC firmware update from a central processing unit (CPU), save it in a buffer region of a flash memory medium using a first bus that connects the EC and the flash memory medium. The EC firmware update is then verified and stored in the primary region of the flash memory medium. Finally, the verified EC firmware update is loaded into the EC memory medium via the first bus.

However, other possible examples are not limited to the features of these examples described in detail.

Herein methods and apparatuses for firmware patching are disclosed. It is disclosed that apparatuses, such as electronic devices, can be configured to control and/or execute the methods disclosed herein. Herein are disclosed apparatuses which include circuitry which is configured to control the methods of updating firmware of a device.

Herein a trailing (s) indicates one or more. For example, "device(s)" or "a device(s)" refers to one or more devices.

Herein patch and update may be used interchangeably. The methods of updating and/or managing an update described herein may be managed by an apparatus that remains in a working state through the managing/updating process. The device with firmware for updating may be communicatively coupled to the apparatus or may be considered to be part of the apparatus. For example, the apparatus may update/manage the update of a device without rebooting the apparatus. The device may be reset without resetting the apparatus. The apparatus may be a system on a chip and/or include a computer processor. The apparatus may continually run an operating system throughout the managing/updating of the firmware for the device. The term "managing a firmware update" may be used interchangeably with "handling a firmware update" and may optionally include rejecting the update, e.g. if operation of the device using the firmware update causes errors.

Herein, update mode may be used interchangeably with updating state. For example, when a device is being updated and/or in a state in which the device is being updated, it is in an "updating state" or in "update mode.

<FIG> illustrates a method of handling a firmware update for a device. <FIG> shows a device <NUM> which can have updatable firmware.

The method <NUM> of handling the update can include storing <NUM> the firmware update in a reserved memory <NUM> (see also <FIG>). The device <NUM> can be tested <NUM> using the firmware update in the reserved memory <NUM>. After the testing <NUM>, the firmware update can be written <NUM> to nonvolatile memory <NUM> for the device <NUM>.

<FIG> shows a device <NUM> which can have updatable firmware. The device <NUM> can be part of another device such as an apparatus <NUM> such as a system on a chip <NUM> (SoC). Alternatively/additionally, the apparatus <NUM> can be communicatively coupled to the device <NUM> and/or may manage the firmware update of the device. The device <NUM> can be communicatively coupled to volatile memory <NUM> and/or nonvolatile memory <NUM>. The volatile memory <NUM> can include reserved memory <NUM>, which can have multiple portions such as a first portion <NUM> and second portion <NUM>. The portions <NUM>, <NUM> may be regarded as primary and secondary firmware banks, respectively.

The reserved memory <NUM> can be a portion of volatile memory <NUM>, such as DRAM and/or SRAM. The reserved memory <NUM> can be a component on a system on a chip <NUM> (SoC). By storing the firmware update <NUM> in a reserved memory <NUM>, it can be possible to quickly test the update, such as before storing the update in the nonvolatile memory <NUM>.

The device <NUM> can be communicatively coupled to a system on a chip <NUM> (SoC) and/or is a component of a SoC <NUM>.

The nonvolatile memory <NUM> for the device can be located on the device <NUM> and/or elsewhere, such as on a circuit board and/or system on a chip <NUM> (SoC). The nonvolatile memory <NUM> can be flash memory, SPINOR memory (serial peripheral interface NOR flash memory), and/or NAND memory. Flash and/or SPINOR memory is particularly contemplated as being used as nonvolatile memory <NUM> to store firmware for the device <NUM> which can be many kinds of devices that have updatable firmwares, e.g. including updated and tested firmware as described herein.

The reserved memory <NUM> can be reserved such that writing to the reserved memory <NUM> is forbidden other than by the firmware update <NUM> and/or from the nonvolatile memory <NUM>. The firmware update <NUM> may undergo a security verification process before being written/stored <NUM> to the reserved memory <NUM>, including possibly a security verification by an external device. Alternatively/additionally, there can be a security verification before the firmware update <NUM> is written <NUM> to nonvolatile memory <NUM>.

The firmware update <NUM> can include code for operating the device <NUM>.

Testing <NUM> (see the method of <FIG>) can include using a portion of a previous firmware which can be copied to the reserved memory <NUM> from the nonvolatile memory <NUM>. The firmware update <NUM> and at least a portion of the previous firmware for the device <NUM> can be stored in the reserved memory <NUM> simultaneously. The testing <NUM> can test operation of the device <NUM> based on the firmware update <NUM> in combination with the portion of the previous firmware (e.g. the portion of the previous firmware that is stored in/copied to the reserved memory <NUM> prior to the test). For example, the update can affect one or more (but possibly not all) operations of the device <NUM>. The testing <NUM> can determine if the device's operation is as expected when the update is included in the code for operation of the device <NUM>. If the device's operation is as expected (e.g. the test is passed), for example, the firmware update <NUM> can be written <NUM> to the nonvolatile memory <NUM>, e.g. such that the update is stored along with the portion of the previous firmware that was used for the passed test.

For example, testing <NUM> can include comparing an actual service provided by the device <NUM> with an expected service of the device <NUM>. If the comparison is favorable, then the test <NUM> can be regarded as being passed. For example, for certain inputs, an expected output exists; when the certain inputs are provided to the device <NUM>, the actual output may match the expected output, which may be used as at least one component of a successful test result.

It is possible that the firmware update, such as the testing <NUM> of the firmware update, is delayed. For example, the update may be for a device <NUM> which is in use. The device <NUM> may be operating using the previous firmware while the firmware update is stored in a secondary firmware bank <NUM> before the testing. The secondary firmware bank <NUM> can be a portion of the reserved memory <NUM>. Referring to <FIG>, storing <NUM> can include storing the firmware update in a secondary firmware bank <NUM> before testing <NUM>. For example, if the device <NUM> is busy when the firmware update <NUM> is received (and/or determined to be available), it may be stored <NUM> in reserved memory <NUM>, such as the secondary firmware bank <NUM>, before testing <NUM>, security verification of the firmware update <NUM>, and/or operation of the device <NUM> using the update <NUM>.

It may be convenient to have a secondary firmware bank <NUM> in the reserved memory <NUM> that can be for storing firmware updates <NUM>, e.g. before implementation and/or testing of the update <NUM>.

<FIG> illustrates a method of handling a firmware update for a device. The method <NUM> of updating the firmware may include initializing <NUM> the device <NUM> using the previous version of firmware. Other devices may also be initialized. The method <NUM> may also include determining <NUM> the state of the device. The state(s) of other device(s) may also be determined.

It is possible to determine <NUM> the state of the device <NUM> before optional testing <NUM> and/or writing <NUM> to nonvolatile memory <NUM>. For example, when a busy state of the device is determined <NUM>, the testing <NUM> and/or writing <NUM> to nonvolatile memory <NUM> can be delayed, e.g. which can include storing <NUM> the firmware update, e.g. in the volatile memory <NUM> (e.g. the reserved memory <NUM>, particularly in the secondary firmware bank <NUM>). The busy state can be the device <NUM> operating using the previous firmware. The device <NUM> can be operated using the previous firmware (which may be in the primary firmware bank <NUM> while the device <NUM> is operated using the previous firmware) while the firmware update is stored <NUM>, e.g. in the secondary firmware bank <NUM>.

The apparatus <NUM> may manage the firmware update, such as determining the device <NUM> to be in an updatable state, then causing the device <NUM> to be set to an updating state. The apparatus <NUM> can receive the firmware update and/or determine that the firmware update is available. The apparatus <NUM> can cause the firmware update code to be written in reserved memory, and cause testing <NUM> of the device which can include operation of the device based on the firmware update code (e.g. after the firmware update code is written in the reserved memory). The apparatus can cause writing of the firmware update code to nonvolatile memory, particularly when the test is passed. If the test if failed, the firmware update can be rejected or postponed. The operational state of the apparatus <NUM> can be uninterrupted during the management of the firmware update of the device <NUM> (e. g the apparatus can remain in an operational state while the firmware update is stored, written into memory, tested, etc).

The updatable state of the device <NUM> can be a D1, D2, or D3 state, for example. Alternatively/additionally the updatable state can include at least one of: an idle state, a low power state, a power conserving state, a paused state, a condition of the device after a notice that the device is ready to change states, or an off state. The state designations which are updatable may not be mutually exclusive. A power manager and/or advanced configuration and power interface may determine the state of the device and/or control the state of the device <NUM>.

<FIG> illustrates a method <NUM> of handling a firmware update for a device. The device may not be in an updatable state, e.g. when the device <NUM> is busy, working, and/or providing a service. It is possible to determine <NUM> an end of the busy state, e.g. before testing <NUM> the device. After the end of the busy state is determined <NUM>, and before optional testing <NUM>, the firmware update <NUM> can be relocated <NUM> from the secondary firmware bank <NUM> to the primary firmware bank <NUM> of the reserved memory <NUM>, e.g. where the firmware for operation of the device <NUM> is at least partially stored during the operation of the device <NUM>.

The reserved memory <NUM>, including the primary bank <NUM> which can be used for storing the firmware update <NUM> (during testing <NUM> and/or operation of the device <NUM>), and/or the secondary firmware bank <NUM>, may be protected from being written to by a security controller and/or other device or process.

The apparatus <NUM> can determine the device <NUM> to be in a working state, for example. The apparatus <NUM> can cause the firmware update code to be stored in the secondary firmware bank <NUM> of the reserved memory <NUM> after determining the device <NUM> to be in the working state, and until the determination (e.g. a subsequent determination) that the device <NUM> is in an updatable state. The apparatus <NUM> can cause relocating of the firmware update code out of the secondary firmware bank <NUM> to the primary firmware bank <NUM> of the reserved memory <NUM> before causing the test <NUM>, e.g. after the device <NUM> is determined to be in an updatable state and/or put into the updating state (which may include the determination of the test result <NUM>).

It is possible that when the firmware update is determined available and/or received, the device <NUM> is busy. For example, the apparatus <NUM> can cause the storing of the context of the device (e.g. when the update becomes available), and cause the device to halt service. The apparatus <NUM> can cause the device <NUM> to reset (e.g. after storing the context). After the reset, the device <NUM> can load the firmware update (e.g. from reserved memory <NUM>). Alternatively/additionally, the device <NUM> can restore the context and/or resume the service (e.g. the previously halted service).

It is also contemplated that more than one device can be affected by the firmware update <NUM>. For example, more than one device may be tested <NUM> using the firmware update.

<FIG> illustrates an apparatus <NUM> which can have updatable firmware. Some devices may have their operation(s) directly affected by the firmware update. The device apparatus of <FIG> is shown to have two devices, a primary device <NUM> and a secondary device <NUM>. Devices that have their operation directly impacted by a firmware update <NUM> may also have, at least potentially, their interaction with other devices impacted. A primary device <NUM> that is updated may have the interaction between the primary device <NUM> and a secondary device <NUM> which may be communicatively coupled to the primary device <NUM> impacted. Alternatively/additionally, a firmware update <NUM> applied and/or available to a first device <NUM> may impact the operation of a second device <NUM> (e.g. when installed and/or during testing).

Secondary devices, such as secondary device <NUM> shown in <FIG>, may be at least potentially impacted by a firmware update to a primary device <NUM> which may have its operation directly altered by the firmware update <NUM>. A secondary device <NUM> may be one that transmits and/or receives data <NUM> and/or input/output with the primary device <NUM>. For example, the firmware update <NUM> is for a first device <NUM> and may change the operation of the first device. Referring to <FIG>, the optional testing <NUM> can include testing the first device <NUM> and a second device <NUM>, such as before writing <NUM> the firmware update <NUM> to nonvolatile memory <NUM> for the first device <NUM> (e.g. using the firmware update code in reserved memory <NUM>). The testing <NUM> can include testing a plurality of devices which include the first and second devices <NUM>, <NUM>.

In an example, the apparatus <NUM> can cause a second test of a second device <NUM> which is communicatively coupled to a first device <NUM> (e.g. in addition to a first test such as a test of the first or primary device <NUM>). The apparatus <NUM> can determine a result of the second test and/or the first test. If the second test (e.g. each of the first and second tests) is passed, the apparatus <NUM> can cause the writing <NUM> of the firmware update code to the nonvolatile memory. If the second test is failed, the apparatus can cause the firmware update to be rejected and/or postponed.

For example, the second test includes comparing an expected service and an actual service of the second device when determining the result of the second test.

In another example, an update request can be transmitted to the device <NUM>, which may include a state matching query. Such an update request can be done before the device <NUM> is set to an updatable state. When the state matching query is positive, it may be possible to enter an update mode (e.g. the device can enter an update mode and/or updatable state). The state matching query may be such that the state of the device is determined to be suitable (or unsuitable) for an update, such as being in a quiescent state and/or an unpowered state (or working state). For example, a suitable state can be a state other than a D0 state. An example of an unsuitable state is a D0 state.

For example, when the state matching query is positive, the apparatus can cause copying of the context of the device into a system memory. The device can be set to the updating state. After setting the device <NUM> to the updating state, the device can be determined to be ready for the update. Alternatively/additionally, the device <NUM> may undergo additional operations in the updating state before the device is ready (e.g. copying of the context and/or resetting of the device). For example, there is first a state matching query that is positive, then there is a determination that the device is ready for the update.

When the device is ready for the update; the device can be set to the updating state. If the device is not ready, the firmware update can be postponed, e.g. until after the context is stored and/or resetting of the device.

If the state matching query is negative, the update can be postponed, e.g. until a positive state matching query result.

The update mode (e.g. the updating state) may include operations that are otherwise impossible if the state matching query is negative and/or the state of the device is unsuitable for updating. It can be undesirable to try to update the firmware for a device <NUM> that is under operation.

When the device is in the update mode, or updating state, the context of the device (sometimes referred to as state of the device, device state, and/or device context) can be copied into volatile memory, such as the reserve memory.

The copying of the state and/or device context may allow for suspension and/or delay of the operation of the device, such as in order to begin to execute the update, e.g. the testing of the update firmware. Alternatively/additionally, when the device is reset, which may be after the firmware update is stored in the reserved memory, the device can load the firmware update from the reserved memory.

In an example, when the update is postponed, the apparatus can cause the firmware update code to be stored in a secondary firmware bank <NUM>, e.g. at least temporarily (such as until the update can proceed, at which time the firmware update code can be put in the primary firmware bank <NUM>, e.g. during testing <NUM>).

<FIG> shows an apparatus for managing handling of a firmware update for a device. The apparatus <NUM> and device <NUM> described with reference to <FIG> is expressly combinable with those described elsewhere herein, particularly those described with reference to <FIG>. The methods described herein can be performed by the apparatuses and/or devices described herein, e.g. those of <FIG>, and <FIG>, as well.

The apparatus <NUM> can determine a device <NUM> to be in an updatable state, and may cause the device <NUM> to be set into an updating state after determining the updatable state. After the device is in the updating state, the apparatus <NUM> can cause the firmware update <NUM> (e.g. the code thereof) to be written to a memory <NUM> for the device (e.g. a reserved memory <NUM>). After writing the firmware update to memory <NUM>, the device is switchable to a working state in which the device operates based on the firmware update. An advanced configuration and power interface can be present, e.g. as part of the apparatus <NUM>, for determination of the updatable state of the device <NUM>.

It is possible that, while the device <NUM> is in the updating state, any access request(s) can be queued. For example, the apparatus <NUM> causes the access requests for the service(s) of the device <NUM> to be queued, e.g. during the updating process. Once the updating is complete, the queued requests can be handled by the device <NUM>, e.g. serially.

Before the device is determined to be in the updatable state, the device can be switched into at least one of: an idle state, a low power state, a power conserving state, or an off state; subsequently, the device <NUM> can be regarded as being in an updatable state.

In the examples herein, it can be possible that the device <NUM> is switchable to the working state, e.g. after the firmware is updated for the operation of the device <NUM>, without a reboot of the apparatus <NUM>.

The apparatus <NUM> can transmit an update request to the device <NUM> which includes a state matching query. When the query is positive, the device can be caused to enter the updating state. If negative, the update can be postponed.

In the updating state, the apparatus may cause copying of a context of the device into a system memory. The apparatus may determine if the device is ready for the update. If the device is ready, the apparatus <NUM> can cause the device <NUM> to be flagged as being in an updating state. If the device is not ready, the apparatus <NUM> can postpone the update.

When the device <NUM> is updated with the firmware update, the device <NUM> can resume operation. For example, the device <NUM> can reload the context that was saved, and resume operation. In another example, the update is rejected, and the context that was saved is reloaded and the operation of the device <NUM> resumes using the previous firmware before the update.

It can be desirable to be able test the firmware update and resume operation of the device <NUM> without rebooting the apparatus <NUM>, e.g. regardless of the outcome of the test <NUM>.

When the test <NUM> is passed, it is possible to write the firmware update to nonvolatile memory. For example, the apparatus <NUM> can cause the writing of a the firmware update to nonvolatile memory <NUM>. In another example, the firmware update can be partitioned. For example, a first part of the firmware update is written to a serial peripheral interface NOR memory, and a second part of the firmware update is written to a boot partition. The first part can be is data (which may be less likely to be altered and/or updated later) and the second part is can be code (which may be more likely to be altered and/or updated later). Alternatively/additionally, the first part is configured for more infrequent updating than the second part.

<FIG> illustrates a method of managing a firmware update for a device. The method <NUM> described with respect to <FIG> can be combined with other methods described herein, for example, with that of <FIG>, and/or 2B, and with the apparatuses and devices described elsewhere herein, e.g. at least <FIG>, and <FIG>. The features described with respect to the methods illustrated in <FIG>, and <FIG> are expressly combinable and such combinations are particularly contemplated, also with the functions described with respect to the devices and apparatus described herein, particularly <FIG>, and <FIG>.

The method <NUM> can include maintaining <NUM> an operational state of a managing apparatus during the management of the firmware update. The method can include determining <NUM> a device to be in an updatable state, and setting <NUM> the device to an updating state. The method can include storing <NUM> a firmware update code in reserved memory. The method can include testing <NUM> the device based on the firmware update code (e.g. the code in the reserved memory which may be volatile memory, RAM, DRAM and/or SRAM). The method can include determining <NUM> a result of the test. For a pass, the firmware update code can be written <NUM> to nonvolatile memory. For a fail, the firmware update can be postponed and/or rejected.

The method <NUM> can alternatively/additionally include determining the device to be in a working state before determining the device to be in the updatable state. The firmware update code can be stored in a secondary firmware bank of the reserved memory before determining the device to be in an updatable state. The method can include relocating the firmware update code out of the secondary firmware bank to a primary firmware bank of the reserved memory before the testing.

The method <NUM> can alternatively/additionally include halting operation of the device, saving a context of the device, resetting the device, loading the firmware update code from a primary firmware bank of the reserved memory, restoring the context of the device, and/or resuming the operation of the device.

The methods described herein can be carried out by a computer. Instructions for the methods described herein can be stored in computer readable format which, when executed can cause an apparatus or device to operate as described herein. For example, computer instructions may cause an apparatus to manage a firmware update for a device, as described herein. Computer instructions for executing the methods herein may alternatively/additionally take the form of an update driver and/or agent. For example, a drier may be packaged with a firmware update. Alternatively/additionally, a firmware update agent may be utilized. The agent may act as an interface to the driver, receiving and responding to notifications on new updates. The agent may
verify the firmware update before the update is downloaded to the respective apparatuses and/or devices. The agent may download the verified firmware into a reserved memory (e.g. a protected memory region). The agent may determine, receive or transmit information that the update is available. The agent may host and/or initiate tests, e.g. function targeted BIST testing process to the device(s), particularly while monitoring response of such BIST results (test results).

Herein, the firmware update can be downloaded to a reserved memory (e.g. a protected memory), such as by the update agent. The reserved memory can be, for example, a region in the system DRAM, which may have limited access. For example, the reserved memory is accessible only to the update agent, the device being updated, and/or static RAM inside the device. The reserved memory may be a temporary memory location for storing the firmware update prior to being written into nonvolatile memory.

Herein, the term "IP" may be used interchangeably with a device which is possible to update with a firmware update. The device may be a hardware device or a virtual device such as one defined by software, e.g. a functionality or group of functionalities coded in software.

Herein, the apparatus can include a computer processor, a central processing unit, a system on a chip, a hardware microcontroller, and/or a security engine, for example.

Returning to <FIG> as an aid to understanding, the apparatus <NUM> can, such as after causing copying and/or storing of the firmware update code in the reserve memory <NUM>, determine if the device <NUM> is ready for a firmware update, particularly if the device is ready for testing of the firmware update. For example, the device <NUM> may be reset, e.g. put into a quiescent state such as an initial state. The device can be flagged as being in an updating state, e.g. after the determination that the device is ready and/or the reset. Being flagged as being in an update state may protect the test from being corrupted by inputs/outputs and/or data transfers with the device other than those which are part of the test. For example, when the device in normal operation, the device may communicate via inputs/outputs. Communications with the device can be suppressed, delayed, queued, and/or refused while the device is in the updating state and/or when the testing is underway. For example, processes (e.g. externally linked processes) which might alter inputs/outputs to the device that are not part of the testing <NUM> may be canceled, refused, queued, and/or delayed.

It is also possible that, after a state matching query is determined positive, the device <NUM> is determined to be unready for the update. In such a case, the update can be postponed/delayed. Similarly, when the state matching query is negative, the update can be postponed/delayed. Postponing/delaying the update can trigger another logical setting which can result in a later state matching query. During postponement/delay of the update (e.g. postponement/delay of the testing <NUM>), the firmware update can be stored in the secondary firmware bank <NUM>.

The testing <NUM> of the device using the firmware update in the reserved memory <NUM> can include confirming the operation of the device, such as by comparing expected outputs with actual outputs. For example, a test-input is provided to the device and the device is operated using the firmware update to generate an actual output. The actual output is compared to an expected output. The comparison may result in a pass or fail result. For example, the update can proceed with writing the firmware to nonvolatile memory upon a pass result. In the case of a fail result, the firmware update is possibly rejected. When the test fails, the update can be canceled, for example. Alternatively/additionally, a communication and/or log that the test failed can be sent/recorded.

Alternatively/additionally, if any difference between the actual output and the expected output is tolerable, e.g. within an acceptable error, the test can be passed. It is possible that the acceptable error is <NUM> such that the actual output is exactly as the expected output otherwise the test fails. When the test fails, the update can be canceled, rejected, and/or postponed, for example. When the test succeeds, the firmware update can be written to nonvolatile memory. The device can be exited from its updating state. The device can be made ready for normal operation using the updated firmware.

As mentioned herein, there may be more than one device impacted directly and/or indirectly by an update. For example, one or more primary device may each be directly impacted by a firmware update, such as when a firmware update includes code and/or data for updating the firmware for the operation of the primary device(s). One or more secondary device may each be directly impacted by a firmware update, such as when a firmware update includes code and/or data for updating the firmware for the operation of a primary device(s) which is communicatively coupled to one or more secondary device(s). For example, when a primary device and a secondary device communicate such as transfer and/or share data, the secondary device may be operated such that the data received from the primary device is expected to be in a first format. If the data received from the primary device is actually in a different format, such as a second format, the secondary device may be unable to correctly function and/or be unable to provide sensible output. The testing may determine if the firmware update alters the format of data output from the primary device; alternatively/additionally, the testing may determine if the operation of the secondary device is changed such as if the secondary device is functioning correctly when the primary device is operated based on the firmware update. During testing, the secondary device may be determined to be functioning correctly when the actual output of the secondary device matches or is within a tolerable range of an expected output.

A firmware update which is directed toward updating the function of a primary device may possibly alter the format of one or more outputs. The testing <NUM> may determine that the firmware update changes the format of the output of the primary device.

When a test fails, the firmware update can be rejected. For example, when the testing <NUM> shows that the actual output of at least one of the primary or secondary devices is not within a tolerable range of an expected output, the test fails. When the test fails, the previous firmware of the nonvolatile memory may be left intact. The previous firmware, e.g. the firmware for the device which was stored before the update firmware update was received, may be used to operate the device. A communication can be sent which indicates the rejection of the update, the failure of the test, and/or that the firmware update is not written to nonvolatile memory.

When the test succeeds, the firmware update can be accepted such as by writing the firmware update to nonvolatile memory such that the device is configured to operate using the updated version of firmware. A communication can be sent which indicates the acceptance of the update, the passing of the test, and/or that the firmware update is written to nonvolatile memory. Writing the firmware update to the nonvolatile memory can be delayed, for example, until services and/or operations of the device are completed. For example, while the testing was performed, the instructions for operation of the device were received; the instructions may be delayed and/or held until the testing <NUM> is accomplished; the device may be operated based on the delayed and/or held instructions after the testing, using the updated firmware (e.g. when testing succeeded) or the previous firmware (e.g. when testing failed) in the reserved memory, e.g. before the writing of the firmware update to the nonvolatile memory (e.g. when testing succeeded).

When writing the firmware update to the nonvolatile memory, the firmware update can be split into at least two parts. A first part can be written to a nonvolatile memory component such as flash memory such as SPINOR. A second part may be written to, for example, a SSD, hard drive, boot memory, and/or boot partition. For example, the first part can be a data block of the firmware update, such as data and/or data which is relatively seldom updated. The second part can be code which is relatively more frequently updated. the second part can be written to a SSD, hard drive, boot memory, and/or boot partition. The first part can be data which is relatively seldom updated in comparison to the second part which is more frequently updated in comparison to the first part.

Herein are disclosed methods for firmware patching, as well as apparatuses for firmware patching. The methods herein may reduce difficulties encountered with the updating of devices. Firmware updates are sometimes ignored by users due to the inconvenience of updating. This can leave computer systems and devices vulnerable to security breaches, for example. The methods, apparatuses, and devices disclosed herein may improve security of devices and systems and/or reduce inconvenience to users.

Modern computer systems can have several firmware components, for example basic input/output system (BIOS), security controller firmware, microcode, power management firmware, etc.. Security attacks on firmware components, which may include below the operating system (OS) attacks, are on the rise and this results in loss of revenue to businesses due to hazards to productivity and leaks of business data. Mitigating these attacks can be done by sending firmware updates or patches to the systems in-field.

Typical in-field patching may involve several steps, starting from implementation, validation, and deployment, followed by original equipment manufacturer (OEM) validation and deployment, and finally launching an update through OEM or update portals or enterprise IT.

<FIG> shows a firmware patch deployment. A patch is validated <NUM>, released <NUM>. An OEM/ODM may integrate and validate the patch <NUM>, and subsequently deploy <NUM> it. There may be a further validation, e.g. an enterprise IT validation <NUM>, then the patch is launched on a user system <NUM>. Finally, in the example of <FIG>, the user accepts and installs the patch <NUM>.

<FIG> shows an apparatus <NUM>, such as a system on a chip <NUM>. As seen in <FIG>, a system on a chip (SOC) <NUM> can have a number of firmware components. Firmware may be on nonvolatile memory <NUM>, such as the platform flash <NUM>. Firmware may be updated at boot time, for example. Herein, it is possible to update firmware of devices possibly without rebooting the apparatus <NUM>.

The apparatus may include one or more of a CPU <NUM>, security controller <NUM>, power management controller <NUM>, and memory controller <NUM>, which may be in communication with nonvolatile memory, e.g. the flash <NUM>. The apparatus may additionally include or be in communication with devices such as an audio controller, sensing unit <NUM>, artificial intelligence (AI) chip <NUM>, imaging unit <NUM>, and/or graphics processor <NUM>, which may be in communication with system memory <NUM>. Additional devices <NUM>-<NUM> can also be in communication with the apparatus <NUM>, such as trusted platform module(s) (TPMs), wireless wide area network (WWAN), storage, keyboard(s), mouse(s), and/or camera(s).

Attempts to make firmware patching simpler and in runtime is difficult. Attempts can have failed in the past due to lack of trusted runtime services to access serial peripheral interface NOR (e.g. SPI-NOR flash, SPI-NOR, or SPINOR) from operating system (OS) layer to update device firmware (IP FW). Some device firmware (herein also referred to as IP FW) can be part of BIOS image hence it can possibly be necessary to reboot the system to pursue OS initiated BIOS update using HOST CPU based loading.

If due to some reasons, updated BIOS fails to boot to OS, it can possibly be necessary to roll back to older BIOS. Rollback can be undesirable, e.g. for wasting time by writing into SPINOR for BIOS update (including IP firmware like discrete graphics (GFX) or artificial intelligence (AI) chip). Such rollback/recovery can be disruptive to users and can contribute to a perception that there is risk to firmware updates.

Firmware patching can imply writing mutable code in the nonvolatile storage (NVStorage) in the field (e.g. after the platform has shipped). The process of writing the firmware to the NV Storage can be critical for platform boot, e.g. subsequent platform boot. The patching process can be atomic, or may be expected to be atomic. A failed write can brick the platform. If the patching process is aborted before completion, the platform can go into an un-recoverable state, thereby damaging the user experience of the platform. As the size and complexity of firmware increases, it becomes harder to enforce the atomicity while minimizing the errors in the firmware. Since PCs support multiple NV Storage devices, there can be multiple mechanisms of delivering the firmware to the field and even more complex mechanisms of writing the firmware to appropriate NV Storage. It is possible to minimize the probability of bricking the system by testing the firmware in volatile memory before committing it to NV storage, as described herein.

Firmware patching can be complex in nature, such as in comparison to software updates. Firmware patching/updating can include writing to platform non-volatile storage (e.g. flash) on a target device, such as is described herein. A failure during or post update could result in failure of system to boot. This can incur significant cost to the OEM to fix the systems, and can lead to loss of business productivity. Therefore, OEMs and IT may invest efforts in validation before the patch is deployed. Costs can be driven up due to the effort of meeting validation goals before updates/patches are released.

Some OEMs may be unable to bear the cost of extensive validation. Patches/updates may ship much later in the life of the product. There can be risk to the end users that possess unpatched systems, such as against public vulnerabilities. Furthermore, there can be a general hesitation among users to apply a patch to their system, out of fear of failure. Systems can be at risk despite all the cost and effort put into mitigating vulnerabilities.

Herein, reduction of the risk associated with in-field firmware patching is sought by providing a better architecture for easier pre-deployment and validation of firmware patches on end user systems. Alternatively/additionally, by addressing the possible inability to service device and/or IP firmware at runtime today through device and/or apparatus (e.g. SOC) architecture differentiation, higher adoption of the firmware patches amongst OEMs and end users may be possible. Greater adoption of firmware updates, such as by downstream parties such as OEMs and/or users, may make devices and/or computer systems more secure.

Herein are described methods and apparatuses which may reduce the need for additional backup firmware, such as may use additional flash space on the device.

Herein is described software-based patching which may include firmware patches stored in reserved and/or temporary memory (e.g. DRAM). It is possible to use hardware architecture to load and run firmware from reserved, temporary, and/or protected memory (e.g. during runtime). The use of reserved, temporary, and/or protected memory may be in addition to the use of flash, or may be instead of flash (such as during boot).

Described herein are apparatuses and methods which may allow staging of firmware on the end user platform. Opportunities for rollback may be possible if the firmware is unfit for the platform. The methods and apparatuses described herein may increase user confidence and adoption, and/or may improve the health of the platforms in the field. It also may be possible to implement crowd sourced validation by enrolling beta testers in the field.

It may be possible to reduce the bill of materials using the apparatuses and/or methods as described herein. The devices and/or apparatuses disclosed herein can aid in a seamless firmware update. For example, it may be possible to forgo a shutdown or reboot. A device may be updated without interruption, and/or so that the user is not aware of any interruption of device capabilities. It may be possible to have a single write into SPINOR upon successful completion of firmware (FW) update, which can be an improvement over methods that may use multiple writes (into SPINOR, for example). It may be possible to simplify development and/or validation, for example. The apparatuses and/or methods described herein may be applied to at least one of hardware (HW), FW and software (SW). The apparatus may be included in a SoC.

Herein is disclosed a firmware update architecture. The architecture can include one or more of an update driver, an update agent, a reserved memory, and a device. The driver can be a signed driver and/or a firmware update driver, that can be packaged with the firmware patch, e.g. a firmware update for updating in the system. The update agent can be a hardware component on the SOC. The update agent can have multiple roles in the architecture. The update agent can do any one or more of the following (a through e):.

The role of update agent can be included in the apparatuses as described herein, e.g. in a System on a Chip (SOC), a Converged Security Engine (CSE) and/or a processor (such as a CPU). A CSE can expose a runtime interface to a host to receive the firmware payload. Alternatively/additionally, the CSE can provide security services for verification. The Update Agent, CSE, and/or processor can write to flash storage to update the firmware.

Alternatively/additionally, the update agent described herein can be coded into a machine readable instructions, and optionally included in an apparatus such as those described herein. The update agent may work synergistically with a firmware update which may include an update driver as described herein, to manage the firmware update for the device.

A protected memory and/or reserved memory may be present, such as in system dynamic random access memory (DRAM). The protected memory may include a memory region which can be where the Update Agent downloads the firmware (e.g. to a reserved region which, as described herein, may be partitioned). Alternatively/additonally, the firmware can be downloaded to a temporary memory location. For example, a region in the System DRAM which is accessible to the Update Agent, the firmware can be used, or a Static RAM of the device for which the firmware update is intended.

The device can be a component on an apparatus such as one including a SOC, for example, or may be a device communicatively coupled to the apparatus. The firmware may be directed toward updating the code and/or data for operating the device. Herein, it is shown to be possible to load and run firmware from reserved memory during runtime instead of flash (during boot).

<FIG> illustrates a method of updating. Alternatively/additionally, <FIG> may be regarded as a high level flow of runtime patching. Firmware patching can include signing and deploying a new firmware update driver which may be packaged along with the firmware patch.

The update may start with signing and deploying the driver and/or patch.

The update driver can be subsequently installed in the apparatus and/or system. As part of installation, the driver may install the firmware and/or firmware package in memory. The Update Agent may be notified of the firmware being installed in memory (e.g. the reserved memory). Alternatively/additionally, there may be notice to the update agent of the availability of the firmware update. The Update Agent can verify the firmware update and/or download it to a memory location, e.g. reserved memroy. The Update Agent can communicate with the device such as to notify the device of the firmware update. The device can do any one or more of: halt ongoing services, save the current context of the device, and be reset, such as by self-action. Alternatively/additionally, the apparatus (e.g. by operation of the update agent) directly or indirectly causes the device to halt, save context, and/or reset. At a next reset, the device can load the verified firmware from memory. The device can restore the context and possibly resume previous services. For example, the following sequence can occur after the update agent verifies and/or downloads the firmware update. (Herein "IP" and "device" may be used interchangeably.

In an example, there is a driver based update of platform firmware. Driver updates can be used to update device specific drivers, and/or device firmware. A system driver can update platform firmware components like Security controller firmware, and/or I/O firmware.

Herein is disclosed an update method that uses temporary memory. A rollback to a previous firmware can be similar to that of a driver rollback. By selecting a previous version of the firmware update driver, the user can easily rollback to the older driver and/or the previous version of the firmware package that is part of the driver. The firmware download as part of the rollback flow, will go through verification and/or notification processes, such as is described herein (e.g. with <FIG>).

Device quiescing and device Only Reset are possible. It is possible to use the capability of devices to reset themselves and re-fetch their firmware on power up. When a device is performing services, such as services that cannot be paused (e.g. critical services), the update agent can download the firmware to a secondary firmware bank.

In another example, device runtime patching is implemented.

For example, during the SoC boot up phase, several devices can be performing their initialization operation. There may be a mode, such as "FW Init Mode. " In the FW Init mode, the device may not be able to provide runtime services, e.g. the device may be busy. It is possible that, prior to handing over to the OS, all devices will enter "Normal Operational Mode", where it can support runtime communication.

The challenge in this mode compare to "FW Init Mode" is that, during runtime, IP might need to support normal runtime communication and provide a way to perform FW update without impacting the user scenarios.

<FIG> illustrates, schematically, an apparatus <NUM>. <FIG> may represent a high level architectural diagram that supports an update mode (or updating state).

In an example, after Power-ON reset (<NUM>, top right of <FIG>), along with HOST-CPU (top left), the firmware sitting in the device may start its execution.

The device ("IP") can remain in "Init Mode" (<NUM> in <FIG>) At this stage, the device may not be ready for host-based communication. During the initialization process, the device can update its device register space which may reside in the device memory, e.g. without being shadowed and/or copied into system memory.

Based on design recommendation, the host CPU (<NUM> in <FIG>) can attempt to send a communication, which can be a first communication. The host CPU can enumerate the device resources into system memory, e.g. so that the CPU can be ready to perform runtime operations. This stage can be known as "Normal Operational Mode" for device. At this stage, the host CPU may not be booted to OS.

After receiving the new FW update, the host CPU can send (<NUM> of <FIG>) a firmware update request (e.g. a runtime firmware update request) based on device usage knowledge/information, e.g. after determining the state of the device, e.g. whether it is in an updatable state and/or if a state matching query is positive. For example, see also <FIG>.

For example, if the desired device state for the FW update is matching (see <NUM> of <FIG>) with current IP device state, the OS updater driver can perform the register programing, e.g. as part of _PSU to allow the device to enter "Updater Mode". In Updater Mode mode, device firmware can copy its device context into system memory. Copying context into system memory can allow performance of the runtime operational request and/or initiate the FW update. Upon successful completion of FW firmware update (e.g. if test(s) are passed), the device can refresh the register (e.g. the device specific register space) and/or the firmware update can be written to nonvolatile memory. The device can enter "Normal Operational Mode".

The "FW Update mode" can be alternatively/additionally known as "DxUpdate" for OS drivers, e.g. an operational mode (alternatively/additionally an updating state). In the DxUpdate, updating state, and/or FW Update mode, the device may be partially inactive, and still get enough power to preserve the device context to support driver restoration. Alternatively/additionally, the device is powered adequately to perform the self-update. For example, in the state known as DxUpdate, the 'x' can refer to the "desire device state for update".

The DxUpdate mode may be such that the end user scenario is not negatively impacted. For example, the OS updater may have knowledge of the device state, e.g. the operational stage, so that IP Firmware can switch to "Updater Mode" without impacting any functional usage. In another example, device Firmware can be split, such as based on criticality. Splitting the device FW can be such that both the device FW code and data region are not part of SPINOR. It is possible that the device firmware is designed in such a way that IP FW data block is a separate entity than a bigger code region. The data block may be smaller in size, and may not need upgrading over time. The data block may fit into SPINOR. The bigger block may be the code region, which may need periodic update. The code region may reside in block device boot partitions. For example, the device firmware includes an updatable block and a nonupdatable block; the nonupdatable block is configured to be stored in the SPINOR. The updatable block can be stored boot partitions, e.g. of a SSD.

The device FW code block can get be updated using the OS runtime interface.

<FIG> illustrate a comparison between device FW design. <FIG> shows the IP FW code region on the SPINOR. <FIG> shows the IP FW Code region in the device boot partition. For example, making a device FW data block reside in SPINOR can help to reduce the SPINOR growth year over year. Alternatively/additionally, not having IP FW update during boot phase would help to reduce the chances of higher boot time.

<FIG> shows a schematic of system and device power state transitions. <FIG> shows states G0, G1, G2, G3; S0, S1, S2, S3, S4; C0, C1, C2, Cn; D0, D1, D2, D3 of devices.

In another example, there is a device low power mode based update. A device and/or IP component, such as one embedded into SoC or hardware, may be visible to firmware or higher-level system software as a Device. A combination of devices can make a system. Each device can have power states, e.g. D0 (fully operational) to D3 (off) and intermediate device operational state as below. For example,.

Herein is also disclosed a device state known as "DxUpdate" which may be used to support runtime IP firmware update and/or ensure runtime device context preservation. Preserving device context may support at least some active communication with the device and/or a buffer associated with the device, such as the device at a lower power state. the device and/or buffer associated therewith can use device context copied into system memory.

For example, it is possible to avoid having a conflict of resources when OS updater performs an update of device FW while IP device is in use. Such as conflict may result in unpredictable behavior in the device operational state and may eventually impact user scenarios. Determining the device state before performing the update may be desirable in order to avoid unpredictable device behavior. For example, the device state and/or context is determined and stored prior to the update, e.g. prior to updating/replacing the firmware and/or testing the firmware.

For example, the state and/or context of at least one device (such as a plurality of devices of the SoC and/or hardware) and/or firmware codes for the device(s) is determined. The state(s) and/or context(s) may be gathered for up to all of the underlying devices/Ips, e.g. those devices embedded in the SoC or underlying hardware. Gathering the state(s) and/or context(s) can allow for scaling into various operating system, possibly without further modification. Advanced Configuration and Power Interface (ACPI) may be the underlying runtime layer between system firmware and system software (OS). The ACPI may gather the information, e.g. the state(s) and/or context(s) of device(s).

For example from the ACPI view, the devices can provide information, (e.g. context(s) and/or state(s)) about underlying hardware. The device(s) may also have associated access method(s), e.g. so that OS drivers can use the device(s) in generic way(s).

It is possible to extend the same concept for determining/knowing the required "Power State for Update" (_PSU). An object can evaluate a device power state. The device can accept the firmware/IP update. It is also possible to put the device into "DxUpdate" mode (e.g. the update includes information for putting the device in the DxUpdate mode). The IP FW itself can perform self-update and preserve its device context without any additional help required from system software layer.

Here is an example of the implementation of the _PSU ACPI Object.

"Device_State_for_update" can be an Integer that contains the device state information that can be used for issuing IP FW update. If device current operating state is not matching with "Device_State_for_update" then OS updater won't issue a FW update to that device/IP. For many devices, the "Device_State_for_update" can be > D0, which can ensure that the FW update will not impact the device working state, e.g. interrupt ongoing operations and/or cause unpredictable response.

"Update_Info" can be a package, such as one that includes information such as any one or more of: MSR, MMIO access, IO access, and PCI configuration access method to put the IP into "DxUpdate" mode.

Here is another illustrative example:
Device (FOO) {
OperationRegion (MFOO, PCI_Config, <NUM>, 0xFF)
Field (MFOO, AnyAcc, NoLock, Preserve)
{
Offset (0x60),
FUPD, <NUM>,
Name (_PSU, Package () {<NUM>, Package ()
{FUPD, <NUM>}}) // Here '<NUM>' can refer as D3 is minimum
requirement for device to accept IP FW
update, Write '<NUM>' into PCI configuration space offset
(0x60) bit <NUM> help to put the IP into DxUpdate state.

Another example involves functional testing (BIST) prior to committing an update.

The integrity of the firmware can be tested and/or verified at runtime, for example. Functional verification may be traditionally handled during boot or by use of a target IP function. Devices can report dependencies/resource/services the device provides and/or receives from other IPs. Dependency mapping can be used to test compatibility of the runtime update firmware, such as by confirming that expected services vs. provided services (e.g. those services that are provided between devices) are compatible.

An example illustrates a device that expects services from security IP, thunderbolt IP, and/or storage IP. If an expected service from IP in category #<NUM> of <FIG> ("expected services") requests a service in an unexpected format to IP from category #<NUM> ("provided services"), this may compromise the cross IP functions. This can be handled by manual use-case testing by vendors and OEMs. As described herein, the dependency/API mapping can be tested, e.g. at runtime, as part of qualifying the update prior to committing the update, e.g. by writing to nonvolatile memory such as flash.

The test can confirm that devices maintain compatibility, e.g. a first and second device and/or primary and/or secondary device.

For example, when a device is updated such that there is a firmware change internal to that device, without impacting the interface to other devices, the API versioning may not be affected. In another example, when the update of the device FW changes the way services are provided between the device (e.g. a primary device) and another device (e.g. a secondary device and/or dependent device), then API versioning can be used to trace the change dependency and/or used during compatibility BIST test.

Another example is a method to implement a single write into the SPINOR on success.

Herein is disclosed a runtime mechanism to update device FW. There are, for example, types of device FW including code in the SPINOR that may be updatable. For example, a code update pointer may reside in SPINOR. The code update pointer may be updated. It is desirable to forego a reboot which may be part of In the existing processes of updating. For example, a reboot may allow a host CPU to update device/IP FW in SPINOR.

An update may involve multiple writes into SPINOR, such as writing based on corrections/changes in the update process. System firmware may be unable to boot to OS after updating IP FW into SPINOR. In such a case, a roll back may occur. It is possible that there are multiple SPI transactions and/or multiple writes to SPINOR. It is desirable to avoid wasting system resources and boot time.

<FIG> shows an apparatus. The apparatus of <FIG> is operable in a trusted execution environment (TEE). <FIG> shows a TEE based mechanism to update SPINOR based on success of "on the fly" update. Herein is disclosed a method of updating which uses a trusted execution environment (TEE) as per <FIG>. For example, during System Firmware boot, BIOS can reserve a portion of memory (such as system memory, RAM, DRAM, and/or SRAM) to support an update of IP boot FW. The method described herein may avoid multiple writes into SPINOR. The TEE layer, which may be inside the OS, can access the reserved memory (e.g. reserved memory that may have been reserved by BIOS). The OS updater can copy the new system firmware in the reserved memory (e.g. a region of reserved memory) and/or perform a jump into this address. The address can work like a zeroth based reset vector patched into system memory, and can be responsible for CPU, chipset initialization, and/or IP FW update, e.g. without corrupting the BIOS image flashed into SPINOR. Upon successful completion of the BIOS operation, system firmware can boot to OS. After successful booting to TEE (e.g. <NUM> seconds after booting successfully to TEE), SPINOR driver as part of TEE can write the same system firmware (e.g. the update FW) in the SPINOR. The method disclosed herein can ensure that firmware updates are trusted and verified. Furthermore, it is possible to avoid having a dual copy of SPINOR which can reduce the bill of materials (BOM).

<FIG> illustrates a block diagram of an electronic apparatus. The apparatus <NUM> can include any of the devices described herein such as device <NUM> described with respect to <FIG>. The apparatus <NUM> can be configured to perform any of the methods described herein such as that described with respect to <FIG>.

The apparatus <NUM> can include at least one electronic assembly <NUM> and/or method described herein. Electronic apparatus <NUM> is merely one example of an electronic apparatus in which forms of the devices, other apparatuses, and/or methods described herein may be used. Examples of an electronic apparatus <NUM> include, but are not limited to, personal computers, tablet computers, mobile telephones, game devices, MP3 or other digital music players, etc. In this example, electronic apparatus <NUM> comprises a data processing system that includes a system bus <NUM> to couple the various components of the electronic apparatus <NUM>. System bus <NUM> provides communications links among the various components of the electronic apparatus <NUM> and may be implemented as a single bus, as a combination of busses, or in any other suitable manner.

An electronic assembly <NUM> as describe herein may be coupled to system bus <NUM>. The electronic assembly <NUM> may include any circuit or combination of circuits. In one embodiment, the electronic assembly <NUM> includes a processor <NUM> which can be of any type. As used herein, "processor" means any type of computational circuit, such as but not limited to a microprocessor, a microcontroller, a complex instruction set computing (CISC) microprocessor, a reduced instruction set computing (RISC) microprocessor, a very long instruction word (VLIW) microprocessor, a graphics processor, a digital signal processor (DSP), multiple core processor, or any other type of processor or processing circuit.

Other types of circuits that may be included in electronic assembly <NUM> are a custom circuit, an application-specific integrated circuit (ASlC), or the like, such as, for example, one or more circuits (such as a communications circuit <NUM>) for use in wireless devices like mobile telephones, tablet computers, laptop computers, two-way radios, and similar electronic systems. The IC can perform any other type of function.

The electronic apparatus <NUM> may also include an external memory <NUM>, which in turn may include one or more memory elements suitable to the particular application, such as a main memory <NUM> in the form of random access memory (RAM), one or more hard drives <NUM>, and/or one or more drives that handle removable media <NUM> such as compact disks (CD), flash memory cards, digital video disk (DVD), and the like.

The electronic apparatus <NUM> may also include a display device <NUM>, one or more speakers <NUM>, and a keyboard and/or controller <NUM>, which can include a mouse, trackball, touch screen, voice-recognition device, or any other device that permits a system user to input information into and receive information from the electronic apparatus <NUM>.

For example, the electronic assembly <NUM>, possibly in combination with reserved memory which can be in the main memory <NUM>, may be configured to execute the methods described herein, such as manage a firmware update for a device such as the electronic apparatus <NUM>. Herein, "IP" and "device" may be used interchangeably.

Furthermore, in further examples, a single step, function, process or operation may include and/or be broken up into several substeps, -functions, -processes or -operations.

Claim 1:
An apparatus (<NUM>; <NUM>; <NUM>) for managing a firmware update (<NUM>; <NUM>; <NUM>) of a device (<NUM>; <NUM>; <NUM>), configured to:
determine a device (<NUM>; <NUM>; <NUM>) to be in an updatable state;
cause the device to be set to an updating state; and
cause a firmware update code to be written in reserved memory (<NUM>; <NUM>);
cause a functional test (<NUM>) to test the integrity of the firmware update code during runtime of the of the device which includes operation of the device based on the firmware update code after the firmware update code is written in the reserved memory;
determine a result of the test; and
for a pass, cause writing of the firmware update code to nonvolatile memory (<NUM>), and
for a fail, reject or postpone the firmware update.