Firmware update techniques

Examples described herein relate to a circuit board that includes a device, firmware memory, and a power controller. In some examples, the firmware memory is to store a firmware update and in response to a software-initiated command, the power controller is to reduce power to the device to cause a firmware update of the device and restore power to the device to cause execution of the firmware update. In some examples, the power controller is to reduce power solely to the device independent from power supply to at least one other device. In some examples, device configuration is saved prior to reduction of power to the device and restored to the device after power is restored to the device.

Computing devices typically include firmware responsible for hardware initialization, low-level hardware management, and managing the boot process. In addition to the platform firmware, computing devices may also include dedicated firmware for controller chips, peripheral devices, or other components. Firmware is typically read at runtime and in connection with a boot, but may be updated in connection with a specialized firmware update process.

DETAILED DESCRIPTION

A firmware update to a device can lead to a server being unavailable for large amounts of time as multiple devices are to be restarted, including device without a particular firmware update. For example, in some scenarios, a server can be unavailable for 30 minutes in connection with firmware updates. Various embodiments provide a software management console to control firmware updates to specific devices and control specifically which devices experience a power reset instead of all devices, including devices that are not subject to a firmware update. Various embodiments provide a power cycling circuit (PCC) that controls a power output to a device in connection with a firmware update. Various embodiments can reduce or eliminate the need to reboot the system for a firmware update to a device, thereby significantly reducing the amount of money lost due to server unavailability from scheduling and performing server reboots.

Various embodiments allow software to save configuration space data of a device, trigger removal of power to the device after a firmware update, restore power to the device, reload configuration space data, and resume normal operation of the device without power cycling the entire system.

FIG.1depicts an example system. The system can be used to update a firmware of one or more devices without causing a power reset to a device that is not undergoing a firmware update. Computing platforms100-0to100-N (where N≥1) can interact with platform150in connection with firmware updates. Computing platform100can refer to any or all of computing platforms100-0to100-N and any component of computing platform100-0can refer to a similar component in any or all of computing platforms100-0to100-N. In some examples, processors102can include one or more of: a central processing unit (CPU), graphics processing unit (GPU), field programmable gate array (FPGA), or application specific integrated circuit (ASIC). In some examples, a CPU can be sold or designed by Intel®, ARM®, AMD®, Qualcomm®, IBM®, Texas Instruments®, among others. Processors102-0can execute OS108-0. In some examples, OS108-0can be Linux®, Windows®, FreeBSD®, Android®, MacOS®, iOS®, or any other operating system. Memory104-0can be any type of volatile or non-volatile memory. Computing platform100can use processors102-0and memory104-0to execute operating system108-0, applications, or virtualized execution environments (VEEs). A virtualized execution environment can include at least a virtual machine or a container. A virtual machine (VM) can be software that runs an operating system and one or more applications. A VM can be defined by specification, configuration files, virtual disk file, non-volatile random access memory (NVRAM) setting file, and the log file and is backed by the physical resources of a host computing platform. A VM can be an operating system (OS) or application environment that is installed on software, which imitates dedicated hardware. The end user has the same experience on a virtual machine as they would have on dedicated hardware. Specialized software, called a hypervisor, emulates the PC client or server's CPU, memory, hard disk, network and other hardware resources completely, enabling virtual machines to share the resources. The hypervisor can emulate multiple virtual hardware platforms that are isolated from each other, allowing virtual machines to run Linux and Windows Server operating systems on the same underlying physical host.

A container can be a software package of applications, configurations and dependencies so the applications run reliably on one computing environment to another. Containers can share an operating system installed on the server platform and run as isolated processes. A container can be a software package that contains everything the software needs to run such as system tools, libraries, and settings. Containers are not installed like traditional software programs, which allows them to be isolated from the other software and the operating system itself. The isolated nature of containers provides several benefits. First, the software in a container will run the same in different environments. For example, a container that includes PHP and MySQL can run identically on both a Linux computer and a Windows machine. Second, containers provide added security since the software will not affect the host operating system. While an installed application may alter system settings and modify resources, such as the Windows registry, a container can only modify settings within the container.

Platform100-0can use network interface110-0to transmit or receive content using connection130. An administrator can use firmware update manager152executed on platform150to select devices among computing platforms100-0to100-N to receive a firmware update and which firmware update to receive. In some examples, the administrator can access a graphical user interface to select one or more devices to receive a firmware update. Upon indication of successful firmware update, an administrator can use deploy driver updates depending on the operating system. In accordance with various embodiments, platform150can issue a firmware or other software update to any computing platform100via operating system108to update at least firmware in network interface110or another device that is to undergo a firmware update without causing a disruption in operation or power reset to a device that is not to undergo a firmware update. For example, platform150can initiate a firmware or other software update on network interface110-0by sending a firmware update to network interface110-0. Computing platform100-0is alerted that an update is to occur. In some examples, computing platform100-0downloads and installs the firmware update image or receives the firmware update via packets sent by platform150.

Processors102-0can execute firmware update tool106-0to identify when an attempt to update firmware is initiated by platform150and to validate and permit an attempt to update firmware of network interface110-0or another peripheral device116-0(e.g., accelerator, video or display card, memory controller, storage controller, or any peripheral device connected through an interface (e.g., PCIe)) or deny the attempt. For a permitted firmware update, firmware update tool106-0can perform one or more of: (a) save configuration information of the device that is to be updated (e.g., PCIe configuration space information such as allocated physical functions (PFs)) into memory104-0, (b) notify a power controller114-0of the device (e.g., power controller114-0) to reduce power to zero to the device and increase the power to the device to operating power level of the device, and (c) store configuration information into the device that has been power cycled (e.g., power reduced and increased to operating power level). Thereafter the device can operate using updated firmware and without causing other devices to power cycle and disrupting operation of other devices that are not subject to firmware update. In connection with firmware updates, operating system (OS)108-0can perform disable a driver for the device during or in connection with the firmware update and enable the driver for use after the device has its firmware updated.

Connection130can be provide communications compatible or compliant with one or more of: Ethernet (IEEE 802.3), remote direct memory access (RDMA), InfiniB and, Internet Wide Area RDMA Protocol (iWARP), Transmission Control Protocol (TCP), User Datagram Protocol (UDP), quick UDP Internet Connections (QUIC), RDMA over Converged Ethernet (RoCE), Peripheral Component Interconnect (PCIe), Intel QuickPath Interconnect (QPI), Intel Ultra Path Interconnect (UPI), Intel On-Chip System Fabric (IOSF), Omnipath, Compute Express Link (CXL), HyperTransport, high-speed fabric, NVLink, Advanced Microcontroller Bus Architecture (AMBA) interconnect, OpenCAPI, Gen-Z, Cache Coherent Interconnect for Accelerators (CCIX), 3GPP Long Term Evolution (LTE) (4G), 3GPP 5G, and variations thereof. Data can be copied or stored to virtualized storage nodes using a protocol such as NVMe over Fabrics (NVMe-oF) or NVMe.

FIG.2depicts a block diagram of a system. In accordance with various embodiments, CPLD208can control power reset to merely device202that is subject to a seamless firmware update or upgrade without causing power disruption to another device that is not subject to a firmware update when merely device202receives a firmware update. For example, if device202is or includes a network interface, during a firmware update of the network interface, migration of a virtual execution environment that uses the network interface may not be performed. For example, a firmware memory update can trigger a stop mechanisms used during virtual machine live migration to ensure virtual machines are notified a PF is disabled. Virtual machines may drop packets that are to be transmitted or can continue provide to packets that are queued for transmission.

Non-volatile memory (NVM) update tool (NUT)252can update contents of firmware memory204by adding another firmware to firmware memory204. NUT252can determine if the firmware update (e.g., seamless update or seamless upgrade) involves a device power cycle or reboot for device202. For example, a power cycle can be applied to device202such as in cases where changes are internal to functionality of device202. If a reboot is to be applied, an administrator can be instructed to reboot host device250as well as device202and potentially other peripheral devices. For example, a device reboot can be used for port configuration changes (e.g., 2×100 Gbps, 4×50 Gpbs, or 8×25 Gbps). For example, a device reboot can be used to update a different number of physical functions (PFs) and the OS can restart device202in order to allocate resources properly to the new set of PFs. For example, PFs are described in single-root I/O virtualization (SR-IOV) and reboot can be performed so that the OS can re-allocate a number of available PFs. In some examples, the OS could re-allocate a number of available PFs without a reboot.

SR-IOV is a specification that describes use of a single PCIe physical device under a single root port to appear as multiple separate physical devices to a hypervisor or guest operating system. SR-IOV uses physical functions (PFs) and virtual functions (VFs) to manage global functions for the SR-IOV devices. PFs can be PCIe functions that are capable of configuring and managing the SR-IOV functionality. For example, a PF can configure or control a PCIe device, and the PF has ability to move data in and out of the PCIe device. For example, for a network adapter, the PF is a PCIe function of the network adapter that supports SR-IOV. The PF includes capability to configure and manage SR-IOV functionality of the network adapter, such as enabling virtualization and managing PCIe VFs. A VF is associated with a PCIe PF on the network adapter, and the VF represents a virtualized instance of the network adapter. A VF can have its own PCI configuration space but can share one or more physical resources on the network adapter, such as an external network port, with the PF and other PFs or other VFs.

While examples are provided for network interfaces and updating firmware, various embodiments can be applied to any hardware that requires power cycling or could also be used to enable a user to intelligently turn off/on hardware to save device power.

Device202can be an Ethernet controller, network interface, storage controller, memory controller, display engine, graphics processing unit (GPU), accelerator device, or any peripheral device. Firmware memory204can store one or multiple firmware versions that can be executed by device202. Firmware can be instructions (e.g., binary code) that controls how a device operates. Firmware can be instructions (e.g., binary code) that controls how a device operates. For example, for a network interface firmware can add or update protocol support, update physical function (PF) lists, update netlists, update Ethernet message passing (EMP) firmware (e.g., exposes and interface for software to communicate with a link management agent), update link establishment state machine (LESM), assist link management agent obtain link, Netlist (e.g., customize the configuration of the network interface ports), configure admin queue, configure network interface defaults, configure remote direct memory access (RDMA) firmware, configure preboot binary executable, configure custom analog settings, configure physical layer (PHY) firmware, and so forth. In some embodiments, firmware can include one or more of: Basic Input/Output System (BIOS), Universal Extensible Firmware Interface (UEFI), a boot loader, Converged Security and Management Engine (CSME) firmware, platform security processor firmware, and BMC firmware among others. The BIOS firmware can be pre-installed on a personal computer's system board or accessible through an SPI interface from a boot storage (e.g., flash memory). In some examples, a BIOS can be stored on a device and accessible from the device by one or more cores or CPUs using an interface such as Serial Peripheral Interface (SPI) or other interface (e.g., PCIe). BIOS can initialize and test the system hardware components and loads a boot loader from a memory device which initializes and executes an operating system. Various non-limiting examples of firmware are provided herein.

In some examples, a Universal Extensible Firmware Interface (UEFI) can be used instead or in addition to a BIOS for booting or restarting cores or processors. UEFI is a specification that defines a software interface between an operating system and platform firmware. UEFI can read from entries from disk partitions by not just booting from a disk or storage but booting from a specific boot loader in a specific location on a specific disk or storage. UEFI can support remote diagnostics and repair of computers, even with no operating system installed. A boot loader can be written for UEFI and can be instructions that a boot code firmware can execute and the boot loader is to boot the operating system(s). A UEFI bootloader can be a bootloader capable of reading from a UEFI type firmware.

OS254, in some examples, can be Linux®, Windows®, FreeBSD®, Android®, MacOS®, iOS®, or any other operating system. The OS and driver can execute on a CPU sold or designed by Intel®, ARM®, AMD®, Qualcomm®, IBM®, Texas Instruments®, among others.

Power supply206can provide voltage and/or current to device202. For example, power supply206can include one or multiple power supply devices and provide an operating voltage as an on-chip linear regulator or an off-chip source. A topology for power supply206can be consistent with a printed circuit board (PCB) board, M.2 board, field programmable gate array (FPGA)-based boards, or other circuit boards.

Complex Programmable Logic Device (CPLD)208can control an extent to which power supply206provides power to device202. In accordance with various embodiments, CPLD208can turn on or off power merely to device202to cause loading of a firmware update for device202but not cause a power disruption or reset of any other device that is not having a firmware update or change. CPLD208can include a programmable pin array. CPLD208can monitor voltage, current or power supplied to device202to determine if a power reset (e.g., reduction of power, voltage or current below one or multiple thresholds) has occurred for device202or determine if increase in power, voltage or current to or above one or multiple thresholds has occurred for device202. For example, CPLD208can apply a timer to determine if sufficient elapsed time has accrued after a power has been stopped or reduced to zero by power supply206to approximately determine if a power cycle has occurred for device202.

In some examples, CPLD208causes a power cycle to device202to cause device202to load firmware from firmware memory204. During a power loss to device202, device202can lose firmware configuration in a volatile memory and device202can determine if a firmware is available from firmware memory204. For example, firmware can be available for loading if a local area network (LAN) power available indicator or another indicator indicates to retrieve firmware from memory204. In some embodiments, CPLD208indicates to device202to load firmware from firmware memory204. CPLD208can assert RESET CPLD (e.g., PERST CPLD) to device202to cause device202to load firmware from firmware memory204and cause device202to re-connect to connector210. In some examples, CPLD208can be implemented as a Field-Effect Transistors (FETs) or voltage monitor connected to power supply206.

In some examples, device202that is subject to a firmware update can either remain active on connector210using particular logic that responds to no-op or idle commands even when the device is powered-down for the firmware update. In some examples, device202can disconnect from connector210during the power-down for the firmware update. In some examples, even if host device250does not support hotadd/remove of devices, device202can restore connection with connector210such that host device250or its OS would not know that the firmware update occurred.

Host connector210can be an interface for at least device202and CPLD208to host device250. For example, device202can be connected as a PCIe device with host device250. Host connector210can be a PCIe compatible connector, SMBus, or other interface.

If device power cycle is to be applied to device202to cause a firmware update, then one or more of the following actions can occur. At (1), NUT252identifies parameters of device202(e.g., base address register (BAR) and configuration space203(e.g., PF configurations)) of device202and saves it into memory of host device250. At (2) NUT252notifies CPLD208of a firmware update operation via a sideband signal (e.g., SMBUS). At (3), CPLD208asserts reset signal (e.g., RESET CPLD) to device202, and then causes power supply206to provide zero power to device202. At (4), after detecting power has reached zero, CPLD208enables power supply206to provide power to device202. At (5), power supply206responds to enablement and provides power to device202. At (6), after detecting power-up of device202(e.g., operating level power) being provided to device202after the power-down, CPLD208de-asserts reset signal (e.g., RESET CPLD) to device202, and indicates to NUT252that device202has reset. However, if any of (3)-(5) fail, CPLD208returns an error to NUT252and an administrator can be informed to restart the system. At (7), NUT252restores the saved configuration to device202to configuration space203. Thereafter, device202can use the updated firmware.

In some examples, device202can be part of a local area network (LAN) on motherboard (LOM) designs where devices are connected as a LAN using connections embedded in a motherboard of a server or computing instead of using a separate network interface card (e.g., Ethernet). Device202can be power controlled when a firmware update is to occur for device202. In some examples, device202can be part of a system on a chip (SoC) and power controlled when a firmware update is to occur.

FIG.3depicts an example process. The process can be used to cause a power cycle or reset to merely a device that is to undergo a firmware update. At302, flash memory device contents are updated with a firmware update. For example, an NVM update tool can be used to store a firmware update into flash memory using a PCIe interface and/or SMBus interface. At304, flash memory device contents are indicated to be updated with a firmware update. For example, an NVM update tool can indicate flash memory is updated by toggling a GPIO pin or communicating using SMBus to change a value on a CPLD pin. At306, a power controller can cause a device to enter reset state. For example, a CPLD can assert a reset signal (e.g., RESET) to cause the device to enter reset state. At308, power can be shut-off to the device. For example, the CPLD can de-assert power supply enable pin to cause the power supply to stop supplying power to the device. At310, an amount of time to achieve power dissipation to the device can elapse. For example, the CPLD can begin a timer and wait pre-determined amount of time for power to the device to fully dissipate. At312, the operating power to the device can be restored. For example, after the timer expires, the CPLD can toggle the power supply enable pin to turn on power supply to the device. At314, the device can exit reset state. For example, CPLD can wait a pre-determined amount of time and then de-assert a reset signal (e.g., RESET) to the device to cause the device to exit reset mode. The device can execute the updated firmware. At316, configuration of the device can be restored. For example, the NUT can restore configuration space content for the device (e.g., PCIe configuration space content).

FIG.4depicts an example process. The process can be used to cause a power cycle or reset to merely a device that is to undergo a firmware update. At402, device configuration can be saved. For example, a NUT or firmware update tool can save PCIe configuration space of the device. At404, device driver operation can be halted. At406, an update of firmware memory for the device can occur. For example, in some examples, the firmware update can be a newer version or an older version than the firmware the device is currently executing. The update firmware can be stored in a memory bank that is different than the memory bank which stores currently executed firmware. The memory bank can be volatile or non-volatile memory. A memory bank can represent a region in memory. A PCIe interface, SPI interface, SMBus, or other interface can be used to transport the firmware update from the host system to the firmware memory.

At408, an indication of available firmware update is provided. For example, the indication of update can be provided by a firmware update tool executing on a host system that is capable of updating the device. The indication of update can be made by toggling a general-purpose input/output (GPIO) pin or via an SMBus. At410, the device can enter a reset state. For example, a CPLD can assert RESET CPLD (e.g., PERST CPLD) to cause a power control circuit to cause a power-down of the device. At412, after device is powered-down, power is restored to the device. For example, the CPLD can wait for a time amount for power discharge or monitor voltage to the device to determine if power to the device reaches zero. To restore power to the device, the CPLD can turn on power supply to the device.

At414, device exits reset state. For example, the CPLD can de-assert RESET CPLD. After reset state is exited, the device executes the new firmware. At416, device driver can be restarted. For example, restarting the device driver can permit software interaction with the device. At418, firmware update tool restores configuration of device to state prior to power-down.

FIG.5depicts an example system. The system can use embodiments described herein to perform software-controlled power reset or cycling for a device that is to apply updated firmware. System500includes processor510, which provides processing, operation management, and execution of instructions for system500. Processor510can include any type of microprocessor, central processing unit (CPU), graphics processing unit (GPU), processing core, or other processing hardware to provide processing for system500, or a combination of processors. Processor510controls the overall operation of system500, and can be or include, one or more programmable general-purpose or special-purpose microprocessors, digital signal processors (DSPs), programmable controllers, application specific integrated circuits (ASICs), programmable logic devices (PLDs), or the like, or a combination of such devices.

In one example, system500includes interface512coupled to processor510, which can represent a higher speed interface or a high throughput interface for system components that uses higher bandwidth connections, such as memory subsystem520or graphics interface components540, or accelerators542. Interface512represents an interface circuit, which can be a standalone component or integrated onto a processor die. Where present, graphics interface540interfaces to graphics components for providing a visual display to a user of system500. In one example, graphics interface540can drive a high definition (HD) display that provides an output to a user. High definition can refer to a display having a pixel density of approximately 100 PPI (pixels per inch) or greater and can include formats such as full HD (e.g., 1080p), retina displays, 4K (ultra-high definition or UHD), or others. In one example, the display can include a touchscreen display. In one example, graphics interface540generates a display based on data stored in memory530or based on operations executed by processor510or both. In one example, graphics interface540generates a display based on data stored in memory530or based on operations executed by processor510or both.

Memory subsystem520represents the main memory of system500and provides storage for code to be executed by processor510, or data values to be used in executing a routine. Memory subsystem520can include one or more memory devices530such as read-only memory (ROM), flash memory, one or more varieties of random access memory (RAM) such as DRAM, or other memory devices, or a combination of such devices. Memory530stores and hosts, among other things, operating system (OS)532to provide a software platform for execution of instructions in system500. Additionally, applications534can execute on the software platform of OS532from memory530. Applications534represent programs that have their own operational logic to perform execution of one or more functions. Processes536represent agents or routines that provide auxiliary functions to OS532or one or more applications534or a combination. OS532, applications534, and processes536provide software logic to provide functions for system500. In one example, memory subsystem520includes memory controller522, which is a memory controller to generate and issue commands to memory530. It can be understood that memory controller522could be a physical part of processor510or a physical part of interface512. For example, memory controller522can be an integrated memory controller, integrated onto a circuit with processor510.

In one example, system500includes interface514, which can be coupled to interface512. In one example, interface514represents an interface circuit, which can include standalone components and integrated circuitry. In one example, multiple user interface components or peripheral components, or both, couple to interface514. Network interface550provides system500the ability to communicate with remote devices (e.g., servers or other computing devices) over one or more networks. Network interface550can include an Ethernet adapter, wireless interconnection components, cellular network interconnection components, USB (universal serial bus), or other wired or wireless standards-based or proprietary interfaces. Network interface550can transmit data to a device that is in the same data center or rack or a remote device, which can include sending data stored in memory. Network interface550can receive data from a remote device, which can include storing received data into memory. Various embodiments can be used in connection with network interface550, processor510, and memory subsystem520.

In one example, system500includes one or more input/output (I/O) interface(s)560. I/O interface560can include one or more interface components through which a user interacts with system500(e.g., audio, alphanumeric, tactile/touch, or other interfacing). Peripheral interface570can include any hardware interface not specifically mentioned above. Peripherals refer generally to devices that connect dependently to system500. A dependent connection is one where system500provides the software platform or hardware platform or both on which operation executes, and with which a user interacts.

In one example, system500includes storage subsystem580to store data in a nonvolatile manner. In one example, in certain system implementations, at least certain components of storage580can overlap with components of memory subsystem520. Storage subsystem580includes storage device(s)584, which can be or include any conventional medium for storing large amounts of data in a nonvolatile manner, such as one or more magnetic, solid state, or optical based disks, or a combination. Storage584holds code or instructions and data586in a persistent state (e.g., the value is retained despite interruption of power to system500). Storage584can be generically considered to be a “memory,” although memory530is typically the executing or operating memory to provide instructions to processor510. Whereas storage584is nonvolatile, memory530can include volatile memory (e.g., the value or state of the data is indeterminate if power is interrupted to system500). In one example, storage subsystem580includes controller582to interface with storage584. In one example controller582is a physical part of interface514or processor510or can include circuits or logic in both processor510and interface514.

FIG.6depicts a network interface. Embodiments described herein can be used to provide a software controlled power cycle to update firmware of the network interface. Transceiver602can be capable of receiving and transmitting packets in conformance with the applicable protocols such as Ethernet as described in IEEE 802.3, although other protocols may be used. Transceiver602can receive and transmit packets from and to a network via a network medium (not depicted). Transceiver602can include PHY circuitry614and media access control (MAC) circuitry616. PHY circuitry614can include encoding and decoding circuitry (not shown) to encode and decode data packets according to applicable physical layer specifications or standards. MAC circuitry616can be configured to assemble data to be transmitted into packets, that include destination and source addresses along with network control information and error detection hash values.

In accordance with some embodiments, link controller650controls auto negotiation and link establishment with one or more link partners to determine link speed, FEC modes and pause capabilities. Link partners can be host devices, modules (e.g., optical communication modules), or other communications chips. In some examples, link controller650can be firmware implemented into MAC circuitry616or available for use by MAC circuitry616.

Processors604can be any a combination of a: processor, core, graphics processing unit (GPU), field programmable gate array (FPGA), application specific integrated circuit (ASIC), or other programmable hardware device that allow programming of network interface600. For example, processors604can provide for identification of a resource to use to perform a workload and generation of a bitstream for execution on the selected resource. For example, a “smart network interface” can provide packet processing capabilities in the network interface using processors604.

Packet allocator624can provide distribution of received packets for processing by multiple CPUs or cores using timeslot allocation described herein or RSS. When packet allocator624uses RSS, packet allocator624can calculate a hash or make another determination based on contents of a received packet to determine which CPU or core is to process a packet.

Interrupt coalesce622can perform interrupt moderation whereby network interface interrupt coalesce622waits for multiple packets to arrive, or for a time-out to expire, before generating an interrupt to host system to process received packet(s). Receive Segment Coalescing (RSC) can be performed by network interface600whereby portions of incoming packets are combined into segments of a packet. Network interface600provides this coalesced packet to an application.

Direct memory access (DMA) engine652can copy a packet header, packet payload, and/or descriptor directly from host memory to the network interface or vice versa, instead of copying the packet to an intermediate buffer at the host and then using another copy operation from the intermediate buffer to the destination buffer.

Memory610can be any type of volatile or non-volatile memory device and can store any queue or instructions used to program network interface600. Transmit queue606can include data or references to data for transmission by network interface. Receive queue608can include data or references to data that was received by network interface from a network. Descriptor queues620can include descriptors that reference data or packets in transmit queue606or receive queue608. Interface612can provide an interface with host device (not depicted). For example, interface612can be compatible with PCI, PCI Express, PCI-x, Serial ATA, and/or USB compatible interface (although other interconnection standards may be used).

FIG.7depicts a switch. Embodiments described herein can be used to provide a software controlled power cycle to update firmware of the switch. Switch704can route packets or frames of any format or in accordance with any specification from any port702-0to702-X to any of ports706-0to706-Y (or vice versa). Any of ports702-0to702-X can be connected to a network of one or more interconnected devices. Similarly, any of ports706-0to706-X can be connected to a network of one or more interconnected devices. Switch704can decide which port to transfer packets or frames to using match-action units or a table that maps packet characteristics with an associated output port. In addition, switch704can perform packet replication for forwarding of a packet or frame to multiple ports and queuing of packets or frames prior to transfer to an output port.

FIG.8depicts an environment800includes multiple computing racks802, each including a Top of Rack (ToR) switch804, a pod manager806, and a plurality of pooled system drawers. Various embodiments can be used to control which device is subject to a power cycle in connection with a firmware update. Generally, the pooled system drawers may include pooled compute drawers and pooled storage drawers. Optionally, the pooled system drawers may also include pooled memory drawers and pooled Input/Output (I/O) drawers. In the illustrated embodiment the pooled system drawers include an Intel® XEON® pooled computer drawer808, and Intel® ATOM™ pooled compute drawer810, a pooled storage drawer812, a pooled memory drawer814, and a pooled I/O drawer816. Each of the pooled system drawers is connected to ToR switch804via a high-speed link818, such as a 40 Gigabit/second (Gb/s) or 100 Gb/s Ethernet link or a 100+Gb/s Silicon Photonics (SiPh) optical link. In one embodiment high-speed link818comprises an 800 Gb/s SiPh optical link.

Multiple of the computing racks802may be interconnected via their ToR switches804(e.g., to a pod-level switch or data center switch), as illustrated by connections to a network820. In some embodiments, groups of computing racks802are managed as separate pods via pod manager(s)806. In one embodiment, a single pod manager is used to manage all of the racks in the pod. Alternatively, distributed pod managers may be used for pod management operations.

Environment800further includes a management interface822that is used to manage various aspects of the environment. This includes managing rack configuration, with corresponding parameters stored as rack configuration data824.

In some examples, network interface and other embodiments described herein can be used in connection with a base station (e.g., 3G, 4G, 5G and so forth), macro base station (e.g., 5G networks), picostation (e.g., an IEEE 802.11 compatible access point), nanostation (e.g., for Point-to-MultiPoint (PtMP) applications), on-premises data centers, off-premises data centers, edge network elements, fog network elements, and/or hybrid data centers (e.g., data center that use virtualization, cloud and software-defined networking to deliver application workloads across physical data centers and distributed multi-cloud environments).

For example, various embodiments can be used for wired or wireless protocols (e.g., 3GPP Long Term Evolution (LTE) (4G) or 3GPP 5G), on-premises data centers, off-premises data centers, base station devices, sensor data sender or receiver devices (e.g., for autonomous vehicles or augmented reality applications), endpoint devices, servers, routers, edge network elements (computing elements provided physically closer to a base station or network access point than a data center), fog network elements (computing elements provided physically closer to a base station or network access point than a data center but further from an edge network), and/or hybrid data centers (e.g., data center that use virtualization, cloud and software-defined networking to deliver application workloads across physical data centers and distributed multi-cloud environments). Network or computing elements can be used in local area network (LAN), metropolitan area network (MAN), network with devices connected using optical fiber links, campus area network (CAN), or wide area network (WAN).