High-efficiency upgrade buffer for memory

Abstract

The disclosed technology generally relates to memory upgrade staging. In one example of this technology, staging is performed on at least two priority groups, with staging of each higher priority group completed before staging of lower priority groups, including the following actions for each priority group: Generating a list of installation targets for the priority group based on a list of software to be installed in the memory and a list of software present in the memory. Generating a list of cleanup targets for the priority group based on the list of software to be installed in the memory and a list of software present in the memory. Downloading the installation targets to a backup partition of the memory. Initiating an update to the software in the memory based on the installation targets. Removing the cleanup targets from the memory. Removing the installation targets from the backup partition.

Description

[0001] Related applications

[0002] This application is a divisional application of the invention patent application with the international filing date of June 14, 2019, which entered the Chinese national phase on December 17, 2020, with the Chinese national application number 201980040754.0 and the invention title "Efficient Upgrade Temporary Storage for Memory". Technical Field

[0003] Embodiments of this disclosure relate to memory upgrade staging. Background Technology

[0004] The Internet of Things (“IoT”) generally refers to a system of devices that can communicate via a network. These devices can include everyday items such as toasters, coffee makers, thermostat systems, washing machines, dryers, lights, cars, and more. Network communication can be used for device automation, data capture, providing alerts, personalization settings, and many other applications. Summary of the Invention

[0005] This "Summary" is provided to introduce some concepts in a simplified form, which will be further described in the "Detailed Description" below. This "Summary" is not intended to identify key or essential features of the claimed subject matter, nor is it intended to limit the scope of the claimed subject matter.

[0006] In brief, the disclosed technology generally relates to embedded device updates. In one example of this technology, staging is performed on at least two priority groups, with staging of each higher priority group completed before staging of lower priority groups, including the following actions for each priority group: In some examples, a list of installation targets for the priority group is generated based on a list of software to be installed in memory and a list of software present in memory. In some examples, a list of purge targets for the priority group is generated based on a list of software to be installed in memory and a list of software present in memory. In some examples, the installation targets are downloaded to a backup partition of memory. In some examples, an update to the software in memory is triggered based on the installation targets. In some examples, the purge targets are removed from memory. In some examples, the installation targets are removed from the backup partition.

[0007] After reading and understanding the accompanying drawings and specifications, one will be able to understand other aspects and applications of the disclosed technology. Attached Figure Description

[0008] Non-limiting and non-exhaustive examples of this disclosure are described with reference to the accompanying drawings. In the drawings, unless otherwise stated, the same reference numerals refer to the same parts in each drawing. These drawings are not necessarily drawn to scale.

[0009] To better understand this disclosure, reference will be made to the following “Detailed Description”, which should be read in conjunction with the accompanying drawings, in which:

[0010] Figure 1 This is a block diagram illustrating an example of a suitable environment in which various aspects of this technology can be employed;

[0011] Figure 2 This is a block diagram illustrating an example of a suitable computing device according to various aspects of the disclosed technology;

[0012] Figure 3 This is a block diagram illustrating an example of a system used for data security;

[0013] Figure 4 It is shown Figure 3 A block diagram of an example device controller; and

[0014] Figures 5A-5B This is a flowchart illustrating example processes according to various aspects of this disclosure. Detailed Implementation

[0015] The following description provides specific details of the description of various examples for a thorough understanding and implementation of the technology. Those skilled in the art will understand that the technology can be implemented without many of these details. In some cases, well-known structures and functions have not been shown or described in detail to avoid unnecessarily obscuring the description of examples of the technology. The terminology used in this disclosure is intended to be interpreted in its broadest and most reasonable manner, even when used in conjunction with detailed descriptions of some examples of the technology. Although certain terms may be emphasized below, any term intended to be interpreted in any limiting manner will be explicitly and specifically defined in the “Detailed Description” section. Throughout the specification and claims, unless the context otherwise indicates, the following terms will have at least the meaning explicitly relevant herein. The meanings determined below are not necessarily limiting of the terms, but merely provide illustrative examples of the terms. For example, each of the terms “based on” and “based upon” is not exclusive and is equivalent to the term “based, at least in part, on”, and includes the option of being based on other factors, some of which may not be described herein. As another example, the term “via” is not exclusive and is equivalent to the term “at least partially via”, and includes the selection of additional factors, some of which may not be described herein. The meaning of “in” includes both “in” and “on”. The phrases “in one embodiment” or “in one example” as used herein may, but do not necessarily, refer to the same embodiment or example. The use of a specific textual numeric indicator does not imply the existence of a numeric indicator with a lower value. For example, the statement “a widget selected from the group including the third foo and the fourth bar” does not by itself imply the existence of at least three foos or at least four bar elements. Singular references are included solely for clarity of reading unless explicitly excluded. Unless otherwise explicitly stated, the term “or” is an inclusive “or” operator. For example, the phrase “A or B” means “A, B, or A and B”. As used herein, the terms “component” and “system” are intended to encompass hardware, software, or various combinations of hardware and software. Thus, for example, a system or component can be a process, a process performed on a computing device, a computing device, or a portion thereof.

[0016] In brief, the disclosed technology generally relates to embedded device updates. In one example of this technology, staging is performed on at least two priority groups, with staging of each higher priority group completed before staging of lower priority groups, including the following actions for each priority group: In some examples, a list of installation targets for the priority group is generated based on a list of software to be installed in memory and a list of software present in memory. In some examples, a list of purge targets for the priority group is generated based on a list of software to be installed in memory and a list of software present in memory. In some examples, the installation targets are downloaded to a backup partition of memory. In some examples, an update to the software in memory is triggered based on the installation targets. In some examples, the purge targets are removed from memory. In some examples, the installation targets are removed from the backup partition.

[0017] In some examples, the upgrade is stalled before being performed on the embedded device; that is, the update is downloaded and placed in the appropriate partition where it needs to be before the actual installation. Handling stalling can be challenging when there is insufficient space to store the entire update or when there are complex prioritization issues.

[0018] It is possible to receive or generate, in some way, a list of software that should exist once the update is complete. This list can be used during the staging period, as discussed in more detail below.

[0019] In some examples, the temporary blocks are prioritized in several ways. As one type of priority prioritization, in some examples, the temporary blocks are organized as priority groups ordered by priority, such that the priority group with the highest priority is prioritized first, then the next priority group is moved on, then the second highest priority group is prioritized before moving on to the next priority group, and so on, until each priority group is prioritized.

[0020] Each priority group can be temporarily stored as follows. For a priority group being temporarily stored, a list of software that should exist once the update is complete is compared with the software currently existing in persistent storage. An installation target list is generated based on the comparison, where the list includes software that is not currently in storage for the temporarily stored priority group and software versions that need to be updated relative to the software currently existing in storage. Then, a purge target list can be generated based on the comparison, where, for the current priority group, purge targets include software that currently exists in storage but is no longer in the list of software that should exist once the update is complete.

[0021] Then, the software corresponding to the installation target can be downloaded. In some examples, the software in the current priority group is then updated based on the installation target. Alternatively, the target can be deleted. In some examples, the installation target is removed from storage once installation is complete, because there may not be enough storage to temporarily store the entire update at once.

[0022] The staging can be modified and, in various examples, may include additional steps, such as to include a rollback to the last known good state to allow testing of the application, and / or for other reasons, as discussed in more detail below.

[0023] Descriptive equipment / operating environment

[0024] Figure 1 This is a diagram of an environment 100 that enables various aspects of this technology. As shown, environment 100 includes computing devices 110 and network nodes 120 connected via network 130. Even Figure 1 The specific components of environment 100 are shown, but in other examples, environment 100 may also include additional and / or different components. For example, in some examples, environment 100 may also include a network storage device, a maintenance manager, and / or other suitable components (not shown). Figure 1 The computing device 110 shown can be located in various places, including indoors, in the cloud, etc. For example, the computing device 110 can be on the client side, the server side, etc.

[0025] like Figure 1As shown, network 130 may include one or more network nodes 120 that interconnect multiple computing devices 110 and connect the computing devices 110 to an external network 140 (e.g., the Internet or an intranet). For example, network node 120 may include a switch, router, hub, network controller, or other network element. In some examples, computing devices 110 may be organized into racks, zones, groups, sets, or other suitable partitions. For example, in the example shown, computing devices 110 are grouped into three host groups, which are identified as host groups 112a-112c, respectively. In the example shown, each host group 112a-112c is operatively coupled to a corresponding network node 120a-120c, which are typically referred to as "top-of-rack" or "TOR" network nodes. Then, TOR network nodes 120a-120c can be operatively coupled to additional network nodes 120 to form a hierarchical, flat, mesh, or other suitable type of topology computer network that allows communication between computing device 110 and external network 140. In other examples, multiple host groups 112a-112c may share a single network node 120. Computing device 110 can be virtually any type of general-purpose or special-purpose computing device. For example, these computing devices can be user devices such as desktop computers, laptop computers, tablet computers, display devices, cameras, printers, or smartphones. However, in a data center environment, these computing devices can be server devices such as application server computers, virtual machine computers, or file server computers. Furthermore, computing device 110 can be configured individually to provide computing, storage, and / or other suitable computing services.

[0026] In some examples, one or more of the computing devices 110 are IoT devices, devices that include some or all of IoT support services, devices that include some or all of the application backend, etc., as discussed in more detail below.

[0027] Explanatory computing devices

[0028] Figure 2 This diagram illustrates an example of a computing device 200 in which various aspects of the present technology can be implemented. The computing device 200 can, in fact, be any type of general-purpose or special-purpose computing device. For example, the computing device 200 can be a user device, such as a desktop computer, laptop computer, tablet computer, display device, camera, printer, or smartphone. Similarly, the computing device 200 can also be a server device, such as an application server computer, virtual computing host computer, or file server computer. For example, the computing device 200 can be… Figure 1Examples of computing device 110 or network node 120. Computing device 200 can also be an IoT device connected to the network to receive IoT services. Similarly, computer device 200 can be... Figures 3-5B Examples of any devices shown or referenced herein are discussed in more detail below. Figure 2 As shown, computing device 200 includes processing circuitry 210, operating memory 220, memory controller 230, data storage memory 250, input interface 260, output interface 270, and network adapter 280. Each of these components listed above in computing device 200 includes at least one hardware element.

[0029] Computing device 200 includes at least one processing circuitry 210 configured to execute instructions, such as instructions for implementing the workloads, processes, or techniques described herein. Processing circuitry 210 may include a microprocessor, microcontroller, graphics processor, coprocessor, field-programmable gate array, programmable logic device, signal processor, or any other circuitry suitable for processing data. Processing circuitry 210 is an example of a kernel. The aforementioned instructions, along with other data (e.g., datasets, metadata, operating system instructions, etc.), may be stored in operational memory 220 during runtime of computing device 200. Operational memory 220 may also include any of a variety of data storage devices / components, such as volatile memory, semi-volatile memory, random access memory, static memory, cache, buffer, or other media for storing runtime information. In one example, operational memory 220 does not retain information when computing device 200 is powered off. Instead, as part of a boot or other loading process, computing device 200 may be configured to transfer instructions from a non-volatile data storage component (e.g., data storage memory 250) to operational memory 220. In some examples, execution may take other forms, such as execution directly from data storage memory 250, for example, execution in-place (XIP).

[0030] Operational memory 220 may include fourth-generation double data rate (DDR4) memory, third-generation double data rate (DDR3) memory, other dynamic random access memory (DRAM), high-bandwidth memory (HBM), hybrid memory cube memory, 3D stacked memory, static random access memory (SRAM), magnetoresistive random access memory (MRAM), pseudo static random access memory (PSRAM), or other memory, and such memory may include one or more memory circuits integrated onto DIMMs, SIMMs, SODIMMs, known qualified wafers (KGD), or other packaging. Such operational memory modules or devices can be organized according to channels, tiers, and libraries. For example, operational memory devices may be coupled to processing circuitry 210 via a memory controller 230 in a channel. An example of computing device 200 may include one or two DIMMs per channel, with each channel having one or two tiers. Operational memory within a tier may operate with a shared clock, shared address, and command bus. Moreover, operational memory devices may be organized into several banks, which can be considered as arrays addressed by rows and columns. Based on this organization of operational memory, physical addresses within operational memory can be referenced by tuples of channels, levels, banks, rows, and columns.

[0031] Despite the foregoing discussion, the operational memory 220 specifically does not include or contain a communication medium, any communication medium or any signal itself.

[0032] Memory controller 230 is configured to interface processing circuitry 210 to operational memory 220. For example, memory controller 230 may be configured to interface commands, addresses, and data between operational memory 220 and processing circuitry 210. Memory controller 230 may also be configured to abstract or otherwise manage certain aspects of memory management from or for processing circuitry 210. Although memory controller 230 is shown as a single memory controller separate from processing circuitry 210, in other examples, multiple memory controllers may be employed, one or more memory controllers may be integrated with operational memory 220, and so on. Furthermore, one or more memory controllers may be integrated into processing circuitry 210. These and other variations are possible.

[0033] In computing device 200, data storage memory 250, input interface 260, output interface 270, and network adapter 280 are interfaced to processing circuitry 210 via bus 240. Although Figure 2Bus 240 is shown as a single passive bus, but other configurations (such as bus sets, sets of point-to-point links, input / output controllers, bridges, other interface circuitry, or any set thereof) may also be suitably used to interface data storage memory 250, input interface 260, output interface 270, or network adapter 280 to processing circuitry 210.

[0034] In computing device 200, data storage memory 250 is employed for long-term non-volatile data storage. Data storage memory 250 may include any of a variety of non-volatile data storage devices / components, such as non-volatile memory, disk, disk drive, hard disk drive, solid-state drive, or any other medium that can be used for non-volatile storage of information. However, data storage memory 250 specifically does not include or includes communication media, any communication medium, or any signal itself. Unlike operational memory 220, data storage memory 250 is employed by computing device 200 for long-term non-volatile data storage, rather than for runtime data storage. In some examples, performance counter 475 may also be configured to measure latency from core to target (such as from MCU 462 to SRAM 458).

[0035] Furthermore, computing device 200 may include or be coupled to any type of processor-readable medium, such as processor-readable storage medium (e.g., operational memory 220 and data storage memory 250) and communication medium (e.g., communication signals and radio waves). While the term processor-readable storage medium includes operational memory 220 and data storage memory 250, the term "processor-readable storage medium," used throughout the specification and claims, whether in the singular or plural form, is defined herein to specifically exclude and not include communication media, any communication medium, or any signal itself. However, the term "processor-readable storage medium" does include processor cache, random access memory (RAM), registered memory, etc.

[0036] The computing device 200 also includes an input interface 260, which can be configured to enable the computing device 200 to receive input from a user or from other devices. Additionally, the computing device 200 includes an output interface 270, which can be configured to provide output from the computing device 200. In one example, the output interface 270 includes a frame buffer, a graphics processor, a graphics processing unit, or an accelerator, and is configured to render a display for presentation on a separate visual display device, such as a monitor, projector, virtual computing client computer, etc. In another example, the output interface 270 includes a visual display device and is configured to render and present a display for viewing. In yet another example, the input interface 260 and / or the output interface 270 may include a Universal Asynchronous Receiver / Transmitter (“UART”), a Serial Peripheral Interface (“SPI”), an Internal Integrated Circuit (“I2C”), a General Purpose Input / Output (GPIO) device, etc. Furthermore, the input interface 260 and / or the output interface 270 may include or be interfaced to any number or type of peripheral devices.

[0037] In the illustrated example, computing device 200 is configured to communicate with other computing devices or entities via network adapter 280. Network adapter 280 may include a wired network adapter, such as an Ethernet adapter, a Token Ring adapter, or a Digital Subscriber Line (DSL) adapter. Network adapter 280 may also include a wireless network adapter, such as a Wi-Fi adapter, a Bluetooth adapter, a ZigBee adapter, a Long Term Evolution (LTE) adapter, a SigFox adapter, a LoRa adapter, a powerline adapter, or a 5G adapter.

[0038] Although computing device 200 is shown as having certain components configured in a particular arrangement, these components and arrangements are merely one example of computing devices that can employ this technology. In other examples, data storage memory 250, input interface 260, output interface 270, or network adapter 280 may be directly coupled to processing circuitry 210, or coupled to processing circuitry 210 via input / output controllers, bridges, or other interface circuitry. Other variations of this technology are possible.

[0039] Some examples of computing device 200 include at least one memory (e.g., operational memory 220) adapted to store runtime data and at least one processor (e.g., processing circuitry 210) adapted to execute processor-executable code, which in some examples enables computing device 200 to perform actions in response to execution.

[0040] Explanatory System

[0041] Some examples of this disclosure are used in the context of a multi-core microcontroller included in an IoT device and used as a device controller for the IoT device. The examples of this disclosure can also be used in other suitable contexts. The following is about... Figure 4 and Figures 5A-5B This disclosure is discussed in the context of a multi-core microcontroller included in an IoT device and used as a device controller for the IoT device.

[0042] Figure 3 This is a block diagram illustrating an example of system (300). System 300 may include network 330, and IoT support services 351, IoT devices 341 and 342, all connected to network 330, and application backend 313.

[0043] The term "IoT device" refers to a device designed to utilize IoT services. An IoT device can actually include any device connected to a network to use IoT services, including for telemetry collection or any other purpose. IoT devices include any device that can be connected to a network to utilize IoT services. In various examples, IoT devices can communicate with the cloud, peers or local systems, or peers and local systems and the cloud, or communicate in any other suitable manner. IoT devices can include everyday items such as toasters, coffee makers, thermostat systems, washing machines, dryers, lights, cars, etc. IoT devices can also include various devices in, for example, "smart" buildings, including lights, temperature sensors, humidity sensors, occupancy sensors, etc. IoT services for IoT devices can be used for device automation, data capture, providing alerts, personalizing settings, and many other applications.

[0044] The term "IoT support service" refers to a device, at least one part of a device, or multiple devices, such as a distributed system, to which IoT devices connect on a network to obtain IoT services. In some examples, the IoT support service is an IoT hub. In some examples, the IoT hub is excluded, and the IoT device communicates directly or through one or more intermediaries with the application backend, without the IoT hub, and software components in the application backend operate as the IoT support service. The IoT device receives IoT services via communication with the IoT support service. In some examples, the IoT support service may be embedded within the device or in the local infrastructure.

[0045] Application backend 313 refers to one or more devices, such as a distributed system, that perform actions that enable data collection, storage, and / or actions based on IoT data, including user access and control, data analysis, data display, data storage control, and automated operations based on IoT data. Application backend 313 can also be one or more virtual machines deployed in a public or private cloud. In some examples, at least some of the actions performed by the application backend can be executed by an application running within application backend 313.

[0046] Each of IoT devices 341 and 342 and / or the device and / or application backend 313 including IoT support service 351 may include Figure 2 Examples of computing devices 200. The term "IoT support service" is not limited to a specific type of IoT service, but refers to a device with which an IoT device communicates after it has been supplied, in relation to at least one IoT solution or IoT service. That is, the term "IoT support service" as used throughout the specification and claims is generic for any IoT solution. The term "IoT support service" refers to a portion of the IoT solution / IoT service with which the supplied IoT device communicates. In some examples, communication between the IoT device and one or more application backends occurs accompanied by an IoT support service as an intermediary. Figure 3 and the instructions Figure 3 The corresponding description illustrates an example system for illustrative purposes, which does not limit the scope of this disclosure.

[0047] One or more of IoT devices 341 and 342 may include a device controller 345, which can operate to control the IoT devices. Each device controller 345 may include multiple execution environments. The device controller 345 may be a multi-core microcontroller. In some examples, the device controller 345 is an integrated circuit with multiple cores, such as at least one central processing unit (CPU) and at least one microcontroller (MCU).

[0048] Network 330 may include one or more computer networks, including wired and / or wireless networks, where each network may be, for example, a wireless network, a local area network (LAN), a wide area network (WAN), and / or a global network such as the Internet. On a set of interconnected LANs, including LANs based on different architectures and protocols, routers act as links between LANs to enable messages to be sent from one to another. Furthermore, communication links within a LAN typically include twisted-pair or coaxial cable, while communication links between networks may utilize analog telephone lines, all or part of dedicated digital lines including T1, T2, T3, and T4, Integrated Services Digital Network (ISDN), Digital Subscriber Line (DSL), wireless links including satellite links, or other communication links known to those skilled in the art. Additionally, remote computers and other associated electronic devices may be remotely connected to the LAN or WAN via modems and temporary telephone links. Network 330 may include a variety of other networks, such as one or more networks using local network protocols (such as 6LoWPAN, ZigBee, etc.). Some IoT devices may be connected to user equipment via a network within Network 330 that is different from other IoT devices. Essentially, network 330 includes any communication methods through which information can travel between IoT support services 351, IoT devices 341 and 342, and application backend 313. Although each device or service is shown as being connected to network 330, this does not mean that each device communicates with every other device shown. In some examples, some of the devices / services shown communicate only with some other devices / services shown via one or more intermediary devices. Furthermore, while network 330 is shown as a single network, in some examples, network 330 may instead comprise multiple networks that may or may not be connected to each other, with some devices shown communicating with each other through one of the multiple networks, while other devices are shown communicating with each other using different networks among the multiple networks.

[0049] As an example, IoT devices 341 and 342 are devices designed to utilize IoT services provided by IoT support service 351.

[0050] Device updates for IoT devices, such as IoT devices 341 and 342, can occur at various times. For example, applications, other software, and / or firmware on the IoT devices can be updated. Updates can be delivered from IoT support services (e.g., IoT support service 351 or application backend 313, etc.) to IoT devices (e.g., 341 and 342) via network 330. IoT devices can be configured to perform updates and perform temporary storage for updates in a memory-efficient manner, including specific priority ordering.

[0051] System 300 may include more than those shown by way of example only. Figure 3The number of devices shown may be more or less.

[0052] Explanatory equipment

[0053] Figure 4 This is a block diagram illustrating an example of a device controller 445. The device controller 445 can be used as... Figure 3 An example of device controller 345 is used. Device controller 445 may include a security complex 451, a CPU 453, a direct memory access (DMA) block 454, a trust zone (TZ) DMA block 455, flash memory 456, a radio block 457, secure static random access memory (SRAM) 458, an interface 459, an MCU 461, an MCU 462, a primary advanced scalable interface (AXI) bus 463, an auxiliary AXI bus 464, bridges 465 and 466, an AXI to an advanced peripheral bus (APB) bridge for each peripheral device 467, an interface 471, GPIO 472, an analog-to-digital converter (ADC) 473, a real-time clock (RTC) 474, and a performance counter 475.

[0054] In some examples, device controller 445 enables a device that includes device controller 445 to function as an IoT device (such as...). Figure 3 The device controller 445 operates via IoT devices 341 or 342. In some examples, the device controller 445 is a multi-core microcontroller. In some examples, the device controller 445 runs a high-level operating system. In some examples, the device controller 445 may have at least 4MB of RAM and at least 4MB of flash memory, and may be a single integrated circuit. In some examples, the device controller 445 provides not only network connectivity but also a variety of other functions, including hardware and software security, monitored operating system, cryptographic functions, peripheral device control, telemetry, etc. Additionally, the device controller 445 may include: technologies for allowing secure booting of the device controller 445, technologies for allowing secure updates to the device controller 445, technologies for ensuring appropriate software runs on the device controller 445, technologies for allowing the device controller 445 to function correctly as an IoT device, etc.

[0055] In some examples, security complex 451 includes a core security complex (CSC), which is a hardware root of trust in device controller 445. In some examples, the core security complex is directly connected to the security MCU in security complex 451. In some examples, the security MCU in security complex 451 has very high trust, but is not as trustworthy as the core security complex in security complex 451. In some examples, security complex 451 drives the entire system when booted.

[0056] In some examples, CPU 453 runs a high-level operating system. In some examples, CPU 453 has two separate execution environments: a "secure world" execution environment and a "normal world" execution environment. The term "secure world" is widely used to refer to a trusted environment and is not limited to special security features. In some examples, the "secure world" execution environment of CPU 453 is also part of the system's trusted computing library. For example, in some examples, the "secure world" execution environment of CPU 453 has unrestricted access to reprogrammed hardware protection mechanisms, such as firewalls in some examples. However, in some examples, the "secure world" execution environment of CPU 453 does not have access to the internals of the core security complex of security complex 451 and relies on the secure MCU of security complex 451 for specific security-sensitive operations.

[0057] Radio block 457 can provide Wi-Fi communication. Primary AXI bus 463 and secondary AXI bus 464 can be buses connecting the illustrated components. In some examples, bridges 465, 466, and 467 bridge the illustrated components. RTC block 474 can operate as a real-time clock. In some examples, all components in device controller 345 can read from RTC block 474, but not all components have write access to RTC block 474. Device controller 445 can include various forms of memory, including flash memory and SRAM, such as flash memory 456 and secure SRAM 458.

[0058] In some examples, I / O subsystem 1 461 and I / O subsystem 2 462 are I / O subsystems for general I / O connectivity. In some examples, each of I / O subsystem 1 461 and I / O subsystem 2 462 includes an MCU.

[0059] DMA block 454 can be used to manage data movement for the "normal world" execution environment of CPU 453. Trust zone (TZ) DMA block 455 can be used to manage data movement for the "secure world" execution environment of CPU 453. In some examples, each I / O subsystem also has its own DMA block. Each DMA block can be configured to support data movement between the core, peripherals, other components, etc.

[0060] Each core can have a bidirectional mailbox to support inter-processor communication. Performance counter 475 can be configured to count read requests, write requests, and data type requests for performance monitoring. In some examples, performance counter 475 can also be configured to measure latency from the core to the target (such as from the MCU 462 to the SRAM 458).

[0061] In some examples, the interface at box 459 includes two inter-integrated-system audio (I2S) interfaces: one for audio input and one for audio output. In other examples, different configurations of the interface may be used, and in various examples, box 459 may include any suitable interface.

[0062] In some examples, the MCU in security complex 451 has very high trust, but not as high trust as the core security complex in security complex 451. In these examples, the MCU in security complex 451 controls one or more functions associated with very high trust. In one example, the MCU in security complex 451 controls power for device controller 445 and / or IoT devices.

[0063] In some examples, the "Secure World" execution environment of CPU 453 is also part of the system's trusted computing library. For example, in some examples, the "Secure World" runtime ("Secure World" RT) of CPU 453 has unrestricted access to reprogram hardware protection mechanisms (such as firewalls in some examples). However, in some examples, the "Secure World" RT does not have access to the interior of the core security complex of security complex 451, but instead relies on the MCU in security complex 451 for specific security-sensitive operations.

[0064] The “normal world” execution environment of CPU 453 can be configured to have limited access to on-chip resources such as memory. In some examples, various security and quality standards (e.g., relatively high standards) can be enforced against code running in this environment, but not as trustworthy as code running on the MCU in the security complex 451 or code running in the “secure world” of CPU 453.

[0065] In some examples, MCUs 461 and 462 are less trusted than the MCU in the secure complex 451 and less trusted than the CPU 453. In some examples, the radio block 457 may include a core, which in some examples may be an MCU. The radio block 457 can provide Wi-Fi functionality and connectivity to the Internet and cloud services such as IoT services. In some examples, the radio block 457 can provide communication via Bluetooth, Near Field Communication (NFC), ZigBee, Long Term Evolution (LTE), and / or other connectivity technologies. In some examples, the core in the radio block 457 does not have any access to unencrypted secrets and cannot impair the execution of the CPU 453.

[0066] In some examples, each independent execution environment is managed by a single software component, which executes in a separate execution environment referred to as the "parent" of the execution environment. An exception to such examples could be that the hardware root of trust (in this example, the core security complex of security complex 451) has no parent. In a particular example, each parent executes in an environment that is at least as trusted as the environment it manages. In other examples, other suitable security measures may be employed. Management operations may include booting and restoring the target environment, monitoring and disposing of resets in the target environment, and configuring access policies for the target environment. In some cases, certain management operations are performed by components other than the parent. For example, in some examples, the "normal world" of CPU 453 is the environment that manages MCUs 461 and 462 but receives assistance from the "secure world" of CPU 453.

[0067] For example, in some examples, the MCU of the security complex 451 manages the "secure world" RT of the CPU 453, the components in the "secure world" RT of the CPU 453 manage the "normal world" OS of the CPU 453, the components in the "normal world" OS of the CPU 453 manage the "normal world" user mode of the CPU 453, and the "normal world" user mode service of the CPU 453 manages the cores in MCUs 461 and 462 and radio block 457.

[0068] In some examples, not only are standalone execution environments managed by software components from more trusted execution environments, but different functions are assigned to different standalone execution environments, with more sensitive functions assigned to the more trusted ones. In one particular example, access to a function is restricted in a standalone execution environment less trusted than the one to which it was assigned. In this way, in some examples, standalone execution environments implement defense-in-depth based on layers of trust.

[0069] For example, in some examples, the core security complex of security complex 451 is at the top of the hierarchy and is assigned to secrets (e.g., encryption keys); the security MCU in core security complex 451 is the next in the hierarchy and is assigned to control power; the security world RT of CPU 453 is the next in the hierarchy and is assigned to store and write access to the real-time clock (RTC); the normal world OS of CPU 453 is the next in the hierarchy and is assigned to Wi-Fi; the normal world user-mode application of CPU 453 is the next in the hierarchy and is assigned to applications; and MCUs 461 and 462 are at the bottom of the hierarchy and are assigned to peripheral devices. In other examples, functions are assigned to independent execution environments in different ways.

[0070] In some examples, such as when supporting software implementations that address them, each level of the trust hierarchy, except for the bottom (i.e., least trusted) level, has control by accepting or rejecting requests from less trusted levels, and is able to rate-limit or audit requests from less trusted levels, and verify requests from lower levels to, for example, ensure that the requests are correct and authentic. Additionally, as mentioned earlier, in some examples, each level of the hierarchy, except for the top (i.e., most trusted) level, has a parent level that manages the lower (i.e., less trusted) levels, including monitoring whether the software at the lower levels is functioning correctly.

[0071] Some examples of device controller 455 may be a multi-core microprocessor, including, for example, at least one CPU and at least one microcontroller, and flash memory with multiple storage banks as described above. In some examples, the multi-core processor may be an integrated circuit with multiple cores. In some examples, the multi-core processor may be used to provide functionality for connected devices. In some examples, device controller 455 may provide network connectivity to connected devices and may also provide various other functions such as hardware and software security, monitored operating system, cryptographic functions, peripheral device control, telemetry, etc. Additionally, device controller 455 may include: technologies for allowing secure booting of device controller 455, technologies for allowing secure updates to the device, technologies for ensuring “appropriate” software runs on the device, technologies for allowing the device to function correctly as an IoT device, etc. Security complex 451 may include a hardware root of trust for device controller 455 as the basis for the security functions provided by device controller 455.

[0072] In some examples, Flash 456 is an external NOR flash memory that includes a flash controller and two parallel dual quad-channel Serial Common Interface (QSPI) NOR flash memory devices (two banks in this example), each of which is a separate integrated circuit accessed via a separate channel. However, this disclosure is not limited thereto, and any suitable memory configuration and / or suitable memory group may be employed.

[0073] During normal boot, the processor can boot in a secure manner, beginning with a security complex that includes a hardware root of trust for device controller 455. In some examples, a first bootloader is read from ROM, and a public key can be used by security complex 451 to verify that the first bootloader has been properly digitally signed. In some examples, verifying the signature of the first bootloader is a cryptographic operation performed in hardware. In some examples, the first bootloader is not loaded until and unless its digital signature has been verified, and access to all flash memory is blocked. In some examples, the first bootloader is loaded once its signature has been verified, and access to all flash memory is allowed. In some examples, further verification beyond the verification of the first bootloader may be required to grant access to all flash memory. This can be used to prevent, for example, loading of valid older code with vulnerabilities.

[0074] In some examples, to allow access for verification of the memory bank, the following can be performed. Security complex 451 can read a portion of one of the unrestricted memory banks, such as a first memory bank in some examples. In some examples, this portion of the flash memory could be 16kb, 52kb, etc. The hardware block in security complex 451 can then compare the loaded portion of the unrestricted flash memory bank with a special hardware fuse; verification fails unless the loaded portion matches the fuse. In some examples, a hardware key can also be used to verify that the code is trusted. Using the hardware block in security complex 451 to compare a portion of the unrestricted flash memory bank against a hardware fuse can be used to prevent the loading of previously valid but now older code that is vulnerable. By changing the corresponding unrestricted portion of the flash memory, the fuse can be blown to prevent such older code from being subsequently verified and to prevent access to secrets stored in the secure portion of the flash memory, where the corresponding unrestricted portion of the flash memory is the portion to be checked against a hardware fuse to be matched with the updated fuse.

[0075] In some examples, flash memory 456 is a single-image memory. In some examples, flash memory 456 has one memory bank. In some examples, flash memory 456 has two memory banks and / or other intervals in the memory, but is still a single-image memory in which the intervals are not accessible.

[0076] In some examples, an erasure coding scheme, as described herein, is used to protect the flash memory 456 from damage. Although an erasure coding scheme is described herein with respect to flash memory 456, it can also be used with any suitable memory or data set. In some examples, the erasure coding scheme described herein may be particularly beneficial for embedded devices with a single image memory that does not have sufficient space to store a complete backup, for which it is desirable to protect against a large number of consecutive failures, accidental overwriting, etc. In some examples, the erasure coding scheme is used in conjunction with flash memory to prevent flash memory corruption.

[0077] In some examples, different erasure coding schemes are used for each different application and / or piece of software to dynamically erase and encode the pieces of each application and / or firmware, with flexibility based on the size of the piece of each application and / or firmware being encoded.

[0078] In some examples, erasure coding schemes can be used, where the memory is erased based on consecutive stripes of a fixed size, and if the memory size cannot be evenly divided by the stripe size, some stripes may be left behind.

[0079] In some examples, an erasure coding scheme can be used where the memory is erased based on non-contiguous stripes of a fixed size, leaving some stripes if the memory size is not divisible by the stripe size. For example, in some examples, the erasure coding scheme can use stripes in a "chessboard" pattern, where each data block is divided by the number of stripes, for example, to stripe the data blocks within the stripes in all other stripes.

[0080] In this way, in some examples with N stripes, a first data block of size S is divided into N stripes, where the first S / N data belongs to the first stripe, the next S / N data belongs to the second stripe, and so on. The first S / N data of the second data block is the next S / N data of the first stripe, and so on. In another example, a first data block of size S is divided into N stripes, the first S / N data can belong to the first block, and the second block data is bound to stripe size * block size * stripe number.

[0081] For example, in one example, with 16MB of memory, where 8MB is dedicated to an application, the 8MB application can be erase-coded using 64kb stripes with 8k data blocks. Therefore, in this example, there are 8MB / 64kb stripes, or 133 stripes. Thus, in this example, the first stripe starts with a first 8MB / (8kb*133) data, the second stripe starts with a second 8MB / (8kb*133) data, and so on. In this example, after the first block of each of the 133 stripes, the first stripe then continues with the next 8MB / (8kb*133) data, and so on. In some examples, the offset of each stripe is calculated, and the stripes are stitched together based on the calculated offset before being fed into the erasure coding algorithm. In this way, in this example, the memory can be recovered from at most 1MB of consecutive corruption. However, the amount of corruption that can be recovered depends on the number of erase-coded blocks generated (e.g., the fault-tolerance model chosen). Similarly, in some examples, while adjustments are made to prevent damage to contiguous portions of the memory, this does not prevent tolerance to random damage. For example, some situations where random damage can be prevented can be addressed using the disclosed techniques.

[0082] In some examples, the hash or checksum of each individual data block, after being erased and encoded, is stored. In other examples, the checksum or hash is not stored in the data itself, but rather in a separate block hash partition, file, or other hash-tracking data structure.

[0083] Fault tolerance can be selected, but greater fault tolerance requires greater overhead. For example, in some examples, the erase coding algorithm allows two bad blocks per stripe instead of one, which has greater overhead compared to the algorithm allowing one bad block per stripe. In some examples, a trade-off is made between fault tolerance and overhead.

[0084] If a partial stripe exists—for example, a stripe contains less data than the full stripe—this partial stripe can be handled differently in different examples. In some examples, phantom blocks can be used, where the remaining blocks are zeros that are not actually stored. This approach may have lower fault tolerance, for example, because the partial stripe can only tolerate successive corruption of the amount associated with the chosen fault tolerance mechanism. Alternatively, for greater fault tolerance, a complete backup of the partial stripe can be retained.

[0085] In some examples, during erase code generation, the inputs are the amount of memory being erased, the erase coding scheme to be used, the stripe size, the block size, how to handle any part of the stripe, and fault tolerance (i.e., how many bad blocks can be recovered per stripe).

[0086] In some examples, after receiving input, for all data lacking partial stripes, the number of stripes is counted, and each stripe is generated based on the calculated offset as described above, to generate each stripe and provide it to the erase coding algorithm. If the memory is byte-addressable NOR flash, the address can be read directly using a pointer based on the calculated offset.

[0087] In some examples, a hash value is also calculated. In some examples, the hash value is calculated from another mechanism, and the hash value calculated and stored from another mechanism can be reused using erasure encoding.

[0088] The erasure code generation process has been discussed above. If corruption occurs, the corrupted data can be repaired using the generated erasure codes based on the erasure code repair process. The repair process can be initiated based on corruption detected in memory, which can occur in various ways across different examples. In some examples, corruption is detected in a file or executable binary in some way (such as via hash value or signature verification), which may lead to the initiation of a repair process.

[0089] In some examples, during the repair process, bad blocks are first identified by checking the blocks against their hash values. In other examples, along the known corrupted flash memory range, for each block within the range, the stripe containing that block is calculated to find all addresses within that stripe, and for those blocks, their hash values ​​are checked against known hash values. In still other examples, for each mismatched hash value, the corresponding block for that stripe is declared bad.

[0090] Next, in some examples, the number of bad blocks is compared to the fault tolerance. If there are zero bad blocks, in some examples, the process continues to the next stripe. In some examples, if there are one or more bad blocks, and the number of bad blocks is greater than the fault tolerance, the stripe cannot be repaired. In some examples, if there are one or more bad blocks, and the number of bad blocks is less than or equal to the fault tolerance, the bad blocks are repaired, for example, by invoking the selected erasure coding scheme using the stripe data and the erase coding block.

[0091] In some examples, to repair bad blocks, the filled stripe, along with an indication of which block is bad, is passed through the erasure coding algorithm, and a pointer to the erasure-coded block for that stripe is also passed to the algorithm. In some examples, the algorithm then returns the repaired block. In some examples, the hash value of the repaired block is recalculated, and it is determined whether that hash value matches the stored hash value for that block. In some examples, if a mismatch exists, the repair fails or the stored block hash value is bad.

[0092] In some examples, each block in the range is repaired in this way, or skipped because it is not corrupt. Once completed, in some examples, it can be verified whether the range is still corrupt. For example, in one example, if a range is found to be corrupt based on a mismatched signature, the range can be sent to the entity that initially performed the signature check, which can then check to determine whether the range is still corrupt, for example, by rerunning the signature check and confirming that it now passes verification.

[0093] When the data content of the memory protected by the erase code changes, the erase code can also be updated. First, in some examples, the range of the input memory is changed. In some examples, for each block, the erase-coded data is regenerated using the same process described above for erase code generation. In some examples, each generated erase-coded block is overwritten by the new block.

[0094] In other examples, each block within the range is compared to the stored block hash. In these examples, only the erase-coded data of blocks with different hash values ​​is regenerated, and these blocks are overwritten. In some examples, blocks with matching hash values ​​are skipped; for example, if the data of a block within the stripe has not changed, the erase-coded block of the stripe is not updated.

[0095] Device updates to the device controller 455 may occur frequently. For example, applications, other software, and / or firmware on the device controller 455 may be updated. Updates may consist of a set of binary files referred to as images or image binaries. In some examples, each image binary file has associated metadata, referred to as image metadata. In some examples, image metadata may include the image's name, version, signature, etc. In some examples, image metadata is stored in the cloud, for example, to make it queryable.

[0096] In some examples, image metadata is also embedded within the image binary itself, for example, to ensure that any image binary file is self-describing. This can be achieved by uploading the metadata as a separate file, where the service repackages the image binary file and the metadata together. Alternatively, the metadata can be pre-packaged inside the image binary file and then unpacked by the service.

[0097] In some examples, a Hardware Stock Unit (SKU) is used as part of the process describing a hardware update strategy and allowing it to be implemented effectively. In some examples, the Hardware SKU is not a unique identifier for a single chip or device. Instead, in these examples, the Hardware SKU uniquely identifies a specific configuration (color, model, features, country, etc.) of the device being sold. In one example, each IoT device's Hardware SKU includes a Device SKU and a Chip SKU. In some examples, there may be more than two descriptive SKUs, allowing three or more types of SKUs to provide a hierarchy with three or more levels. A Chip SKU can define the specific type of chip running within an IoT device and the chip's functionality. A serial number, public key, or Device ID can be used to uniquely identify a single instance of the chip.

[0098] Device SKUs can serve as identifiers describing the type of IoT device using a chip. An SKU might be used by a product manufacturer to identify a specific model and configuration within its product line. Each device SKU can have a set of attributes describing software-related characteristics. Additionally, each device SKU can have attributes describing a unique chip SKU, which is present in all devices using that device SKU. These attributes can also be defined and stored in an IoT service solution within an SKU registry. These attributes can also describe features manufacturers use to differentiate IoT device models (i.e., washer vs. dryer, tan vs. stainless steel), but there are also subtle differences that constitute IoT devices (the hardware SKU of the motor used, the type of LED panel connected to the 4x4 chip). In some examples, there are two SKU registries; one for device SKUs and another for chip SKUs.

[0099] A distribution can be described by binary content available to a device. A distribution is a coherent set of image binaries for certain purposes. In some examples, a distribution consists of at least four distinct entities: a set of image binaries, a single SKU, a component ID, and a semantic version. In some examples, each IoT device has at least two different distributions installed. In some examples, the component ID collects all images applied to a single component. Distributions can be coherent because they are pre-tested to ensure that all binaries within the distribution work together.

[0100] In some examples, a distribution is not available to IoT devices until it has been deployed. In other examples, a deployment binds a set of distributions to a set of constraints that define the attributes of the devices the deployment targets. In still other examples, after registration and activation of the deployment, the query ultimately calculates which distributions are used for IoT devices.

[0101] In some examples, to initiate the update process, the software engineer registers the new image binary file from the local machine and uploads it to the IoT update service associated with the IoT support service for the IoT device. In some examples, the uploaded image binary file should be signed, as it is only verified if it is signed. In some examples, image signing allows each image binary file to be authenticated as signed by a trusted entity.

[0102] In some examples, software engineers can also define new releases around specific SKUs and register them with the IoT Update Service. Engineers can also increment release version numbers, write a set of image binaries for the next version of the release, verify that the written image binaries meet all constraints provided by the metadata for each image, and receive recommendations for image binaries with compatible constraints. For any given release, software engineers can use query tools to see the collection of IoT devices currently using that release, using it as a backup, or for which that release is available. Furthermore, engineers can query specific groups of devices and determine the set of deployments and releases currently in use for that group.

[0103] After defining a new release, engineers can target that release to a set of machines by defining a deployment. Engineers can target a single SKU (across releases) or all SKUs that depend on the most recently updated image binary. Once the deployment is activated, it can be used by the IoT devices when they subsequently check for updates. Under normal circumstances, IoT devices can request the service at a regular pace (e.g., weekly) to receive the release they should currently have. Engineers can also proactively request the device to make the request immediately, rather than at a regular pace.

[0104] In some examples, the cloud service can initiate release upgrades and downgrades. In some examples, the cloud can force IoT devices to roll back to an older release. As discussed in more detail below, in some examples, the IoT device includes a backup copy of a previously updated release. In some examples, the cloud can force the IoT device to downgrade to a previous updated release stored as a backup copy on the IoT device. In some examples, there is not enough space to store an uncompressed backup copy, and a backup copy of the last known good version is stored in a compressed state.

[0105] In some examples, when a distribution is made available to a group of IoT devices via deployment, it will not be made available to all IoT devices in that group simultaneously. Instead, in these examples, each distribution is made available in a rolling deployment manner. For example, a rolling deployment might begin with a deployment to a small subset of the target IoT devices. As the update successfully completes, the number of IoT devices available for deployment will increase.

[0106] In some examples, one or more IoT devices each include a daemon that sends a query to a cloud service (e.g., an IoT support service) regarding whether a new device update is currently available for the IoT device. In some examples, the daemon is included in the IoT device's NW (Network Window). The NW daemon on the IoT device can then receive information related to IoT device updates from the cloud service. In some examples, this information includes an indication of the release the IoT device should have, and includes metadata associated with the indicated release (such as semantic version) and metadata associated with each image binary in the indicated release (such as ID, version, etc.). In some examples, secure transport is used in the communication between the IoT device and the cloud service.

[0107] In some cases, upon receiving an instruction related to an update for an IoT device, the IoT device verifies the update. In some examples, the IoT device verifies the update by checking that it is correctly signed. In some examples, the IoT device also determines whether a new version should be downloaded by comparing the image binary to be installed for the update with the image binaries already installed on the IoT device. In some examples, the IoT device then determines which image binaries should be downloaded from the cloud service to be ultimately installed as part of the update process. In some examples, for each image binary that the IoT device determines should be downloaded from the cloud service, the daemon sends a corresponding request to the cloud service to download the image binary. In some examples, the cloud service, in response to a request for the location of each image binary, sends the location of each download to the daemon, and the daemon then sends a request to the indicated location to download each image binary.

[0108] In some examples, the IoT device then receives the requested image binary file from the cloud service. In some examples, the IoT device does not have enough RAM to store the image binary file in memory; therefore, instead, each image binary file is streamed to the IoT device. The total collection of image binary files received by the IoT device includes the distribution. In some examples, secure transmission is used between the cloud service and the IoT device. Furthermore, in some examples, due to insufficient space to store the uncompressed version, an updated compressed version is downloaded.

[0109] In some examples, updates are staged before execution. Staged updates can refer to downloading the update and placing it in the appropriate partition location before the actual installation. Handling staged updates can be challenging when there isn't enough space to store the entire update or when there are complex prioritization issues. In some examples, staged updates are performed in a specific way and have multiple priority levels. Staged updates will be discussed in detail below.

[0110] In some examples, as part of the update process, after the update is complete, a list indicating the software that should be present can be received or generated in some way. This list can be used during staging and the update process. In some examples, this list is a list received by the IoT device from a cloud service, where the list is provided to the IoT device by the cloud service, the list has been signed, and the list is a list of software that should be present after the update is complete, where the software is identified by identifiers such as image IDs. In other examples, the list is received or generated in some other way.

[0111] The device controller 445 and the corresponding flash memory can be divided into multiple partitions. In some examples, the partitions are physical partitions, while in others, they are logical partitions. Figure 4 In the example of device controller 455 shown, the partitions are physical partitions, including firmware partitions, OS partitions, and application partitions. Other suitable partitions may be used in other examples.

[0112] In some examples, partitions are updated atomically. In some examples, updating a partition "atomically" means updating the partition as a single unit, rather than updating one part of the partition in one go and another part in another. In some examples, particularly where partition dependencies exist, partitions may be updated atomically in a specific order to ensure that a newly updated partition does not depend on dependencies on another partition that has not yet been updated. In some examples, after each partition is atomically upgraded, the upgrade is complete, where, where an order based on partition dependencies is required, the atomic partition upgrades are performed in the appropriate order.

[0113] In some examples, partition tables are used to ensure that partition upgrades are tolerable for power failures and / or other faults. In some examples, there are two partition tables per partition: a primary partition table and a backup partition table. In some examples, two tables exist because if a power failure and / or other fault occurs while writing to one partition table, the other partition table remains valid. In some examples, each partition table has entries for each image on that partition, and each entry includes information about that image, such as, in some examples, the image's offset in flash memory. This information may also include the image's status, including whether the image has been mounted. In some examples, the tables use some mechanism (such as hashing) to determine whether the table is consistent or corrupted.

[0114] In some examples, updating a partition atomically can be done as follows.

[0115] After the installation for the partition has been temporarily saved, the updated version is written to the partition. Next, the updated version is verified. After successful verification, the current partition table is copied to storage. The original entries pointing to the original version are deleted, and new entries pointing to the current version are added to the copy. At this point, the copy now has the updated partition table. The updated partition table is then written to the backup partition table. Finally, on the next boot, the updated partition table is written to the primary partition table.

[0116] Next, a boot health check is performed. If the boot health check succeeds, the partition update is complete. If the boot health check fails, the following actions are performed: If the primary partition table is corrupted, the primary partition table is overwritten with the backup partition table. If the backup partition table is corrupted, the backup partition table is overwritten with the primary partition table. If neither the primary nor the secondary partition table is corrupted, but they differ from each other, this indicates a power failure and / or other fault in the writing of the primary and secondary partition tables, and therefore, the primary partition table is then overwritten with the backup partition table. If both the primary and backup partition tables are corrupted, the partition tables can be corrected using other methods (such as erase coding), as discussed in more detail below; otherwise, the upgrade fails.

[0117] The method above describes an example of image updates when there is enough free space available for the updated version. If there is not enough free space available for the updated version, the following steps can be performed first.

[0118] First, a memory allocator is used to determine the offset of each image in the flash memory within the partition. Next, a virtual layout is created in the memory. The virtual layout is used to determine if there is enough total space in the flash memory, but the free space is fragmented. In some examples, if there is not enough space in the flash memory, the update will fail even if fragmented space is taken into account.

[0119] However, if there is sufficient space to account for fragmentation, the outdated image can be copied to the backup partition. Next, an empty table can be written to both the flash memory, the primary partition table, and the backup partition table. If a power and / or other failure occurs after writing the empty table, the installation can be easily resumed from the point of interruption after the initial setup.

[0120] Next, the unupdated image can be copied back to the flash memory along with the new image to be updated, thus tightly encapsulating the images. Then, these steps can proceed as usual.

[0121] Although the above discussion focused on using a memory allocator when free space is insufficient, in some examples, the memory allocator tracks the available free space in each case.

[0122] The discussion above describes an update method that tolerates power and other failures. In some examples, the partition table can also be protected from corruption by erasure coding. Each partition table can be hashed, and the hash can be used to detect corruption of the partition table. In some examples, to prevent failures and corruption during partition upgrades, the erasure coding blocks are also updated in the correct order.

[0123] An example of an update method that also tolerates corruption is as follows.

[0124] First, the installation is paused. Next, both the primary partition table and the backup partition table are modified to indicate that an installation is in progress. In some examples, this indication is a "Installing" entry in both the primary and backup partition tables. The "Installing" entry includes the range of data modified during the installation process.

[0125] In some examples, after adding the entries being installed to both tables, the backup partition table is written, making it include entries for the installation target, etc. In some examples, the erase code for the backup partition table is then regenerated, and a hash is generated for the backup partition table. In some examples, the primary partition table is then written, the erase code for the primary partition table is regenerated, and a hash is generated for the primary partition table. Additionally, in some examples, a hash is generated for each block in the partition, and this hash is stored in a separate area of ​​flash memory that tracks the block hashes.

[0126] In some examples, if a backup partition is successfully written to at any time instead of the primary partition table (as indicated by a mismatch between the primary and backup partition tables), then if there is an entry being mounted, all erase-coded blocks within the data range specified in the entry being mounted, as described by the entry being mounted, will be regenerated, and then the erase-coded blocks of the partition table will also be regenerated.

[0127] In some examples, the next step, as described above, is to perform the steps outlined above if there is insufficient free space for the updated version. In some examples, after performing or skipping these steps, the updated version is written to the partition if there is sufficient free space in memory. In some examples, the updated version is then verified.

[0128] In some examples, after verifying the updated version, the erased encoding block is updated for the image. In some examples, the hash is also updated. In some examples, the entry being installed is then removed from both partition tables.

[0129] In some examples, the current partition table is then copied to storage. In some examples, the original version of the partition table is removed from the copy, and the current version is then added to the copy. In some examples, at this point, the copy now has an updated partition table. In some examples, the updated partition table is then written to the backup partition table. In some examples, the erase-coded blocks used for the backup partition table are then updated. In some examples, the hash of the backup partition table is then updated.

[0130] In some examples, the updated partition table is written to the primary partition table after the device's next boot.

[0131] In some examples, the next step is to perform a boot health check, after which the steps are performed as described in the previous examples. If both the primary partition table and the backup partition table are corrupted, certain other repair methods, such as erase code repair, can be used.

[0132] In some examples, the erase-coded block used to back up the partition table is then updated. In some examples, the hash of the backup partition table is then updated.

[0133] As mentioned above, in some examples, a staging process is performed before the update. In some examples, staging is prioritized in several ways. Staging can be organized as priority groups ordered by priority, such that the highest priority group is staged first, then the next highest priority group is staged, then the next highest priority group is staged before proceeding to the next highest priority group, and so on, until every priority group is staged.

[0134] In some examples, priority groups may include partitions, and may also include priority groups independent of partitions. Partitions may include some or all of the trust levels in the defense-in-depth hierarchy, and the priority of a priority group may be the same as the trust level in the defense-in-depth hierarchy.

[0135] In some examples, priority groups may include: a trusted keystore, as the priority group with the highest priority level; a bootloader, as the priority group with the second priority level; and the remaining priority groups as partitions, wherein the priority of the partitions is ordered in the same way as the priority of trusts in the corresponding trust level. For example, in some examples, the priority group as a partition corresponding to a trust level has a higher priority than the priority group as a partition corresponding to a trust level with a lower level of trust.

[0136] In some examples, priority grouping can be at least partially based on dependencies. For example, in some examples, a software level may depend on a more trusted software layer. In some examples, metadata describes such dependencies as "depends on" or "provides." That is, in some examples, software that depends on another software is described as that software "depends on" another software. Conversely, in some examples, software that is "depended on" by another software is described as "provides" software that depends on that software. In some examples, the "provides" layer is always updated before the "depends on" layer. In some examples, the priority layer ensures this is correct because higher priority layers are staged before lower priority layers.

[0137] In some examples, priority groups and their priorities relative to each other are defined in a policy file. In some examples, the policy file can be updated dynamically, such that, for example, the priorities of priority groups relative to each other can be updated dynamically.

[0138] Each priority group can be temporarily stored as follows. For a priority group being temporarily stored, a list of software that should be present once the update is complete is compared with the software currently present in memory. Based on the comparison, a list of missing installation targets is generated, which includes software in the temporarily stored priority group that is not currently present in memory or software versions that need to be updated relative to the software currently present in memory. A missing target is a target that should be downloaded but has not yet been downloaded. For example, a missing installation target is an installation target that has not yet been downloaded. Once the target is downloaded, it is no longer considered missing.

[0139] Then, a list of targets to be removed can be generated based on comparisons, where, for the current priority group, targets to be removed include software currently present in memory but no longer in the list of software that should exist once the update is complete. If the software to be installed already exists, in some examples, the installer can preserve the existing installation by simply not generating an installation target or removing targets.

[0140] Then, the software corresponding to the installation target can be obtained, for example, by downloading. In some examples, the obtained software can only be trusted after verification. In some examples, after the target is verified, its signature is verified. If the signature is valid, in some examples, it is determined whether the target is a missing installation target with the correct priority. If not, in some examples, the target is discarded. If the target is a missing installation target with the correct priority, in some examples, the target changes its type from missing installation target to installation target (because by definition, the target is no longer missing).

[0141] In some examples, the software in the current priority group is then updated based on the installation target. Alternatively, the cleanup target can be removed. In some examples, the installation target is removed from storage once installation is complete, because there may not be enough storage to temporarily store the entire update at once.

[0142] Once the installation of a priority group is complete, or once the installation target has been retrieved, a reboot may be required. For example, in some cases, the update installation of certain priority groups may require a reboot, while the update installation of other priority groups may not. In these cases, in response to the update installation of a priority group that requires a reboot upon completion, the device will be rebooted before the next priority group is paused. In some cases, retrieving the installation target may require a reboot for certain priority groups, while retrieving the installation target for other priority groups may not require a reboot.

[0143] In various examples, this staging can be modified and can include additional steps, such as "missing rollback target" for the rollback target, including rolling back to the last known good state to allow testing of the application and / or for other reasons.

[0144] For example, in some examples, for processes that also include rolling back to the last known good state, the staging process can be performed as follows. As part of staging priority groups, missing rollback targets are determined for priority groups before determining missing installation targets, such that a missing rollback target exists for each software installed for the current priority group. After generating the missing rollback targets, the missing installation targets can be generated. In some examples, the missing rollback targets for a priority group are fully downloaded before the missing installation targets are downloaded. This is an example of priority sorting by entry type. In some examples, multiple priority sorting levels are performed. Missing rollback targets and missing installation targets are two examples of entry types, where the missing rollback target entry type for a given priority group takes precedence over the missing installation targets for the same priority group. In this way, in some examples, multiple priority sorting levels include priority sorting by priority group and priority sorting by entry type.

[0145] In some examples, similar to missing install targets, the downloaded software can only be trusted after verification for any missing rollback target downloaded. Verification of a missing rollback target may include comparing the identity of an image with the expected identity in the missing rollback target. If the identity is not the expected identity (i.e., the component ID and image ID do not match), the image is rejected. In some examples, once the missing rollback target is verified, its signature is verified. If the signature is valid, in some examples, it is determined whether the missing rollback target is a missing rollback target with the correct priority. In some examples, if not, the target is discarded. In some examples, if the target is a missing rollback target with the correct priority, the target changes its type from missing rollback target to rollback target (because by definition, the target is no longer missing). In some examples, once all rollback targets in a specific priority group have been downloaded, the download of the install target in the manner described above or otherwise acquired begins. As mentioned above, in some examples, the target is compressed.

[0146] In some examples, as an exception to the normal process, if a particular current priority group has not changed, but the priority groups preceding that current priority group have changed, then for the current priority group, each rollback target in the current group will be temporarily converted to a missing rollback target. In this way, in these examples, these missing rollback targets are re-downloaded and then converted to rollback targets again. This avoids fragmentation. In this case, there are no installation targets, so no installation work is performed.

[0147] In some examples, the staging process can also be modified to suit the test software.

[0148] For example, in some cases, certain applications (such as test software) should be marked as temporary applications. This could include, for instance, test software that has already been loaded onto a factory device and will never be updated via the cloud. Manufacturers can mark such applications as temporary. If an application is marked as temporary, in some cases, for ongoing updates, the temporary application does not need to be rolled back to its target but is simply removed. Therefore, in some examples, during the staging period, applications marked as temporary are not rolled back to their target but are instead marked for removal.

[0149] If a rollback to a previously known good state is needed later, in some examples, the rollback target is transformed into an installation target, and then the installation process is run. In some examples, cascading rollbacks are used based on dependencies. In a cascading rollback, if a specific layer is to be rolled back, the layers that the current layer depends on must also be rolled back (because rolling back would break dependencies), then if that layer depends on another layer, that other layer must be rolled back (because rolling back would break dependencies), and so on.

[0150] Explanatory process

[0151] For clarity, the processes described herein are described in accordance with operations performed in a specific order by a particular device or component of the system. However, it should be noted that other processes are not limited to the stated sequence, device, or component. For example, certain actions may be performed in a different order, in parallel, omitted, or supplemented by additional actions or features, regardless of whether such order, parallelism, actions, or features are described herein. Similarly, any techniques described in this disclosure may be incorporated into the described process or other processes, whether or not such techniques are specifically described in conjunction with the process. The disclosed processes may also be performed on or by other devices, components, or systems, regardless of whether such devices, components, or systems are described herein. These processes may also be implemented in a variety of ways. For example, they may be embodied in an article of art, for example, as processor-readable instructions stored in a processor-readable storage medium, or as a computer-implemented process. As an alternative example, these processes may be encoded as processor-executable instructions and transmitted via a communication medium.

[0152] Figures 5A-5B An example data flow for process (580) is shown. In some examples, process 580 is controlled by a device controller (e.g., Figure 4 The process is executed by the device controller 445. In other examples, process 580 may be executed in other suitable devices. In some examples, steps 581-586 include pausing the current priority group, and pausing each higher priority group before pausing the lower priority groups.

[0153] In the example shown, step 581 occurs first. In step 581, in some examples, a list of installation targets for priority groups is generated based on a list of software to be installed in memory and a list of software present in memory. As shown, in some examples, step 582 occurs next. In step 582, in some examples, a list of cleanup targets for priority groups is generated based on a list of software to be installed in memory and a list of software present in memory. As shown, in some examples, step 583 occurs next. In some examples, in step 583, the installation targets are downloaded to a backup partition of memory.

[0154] As shown in the figure, in some examples, step 584 occurs next. In some examples, in step 584, an update to the software in memory is initiated based on the installation target. As shown in the figure, in some examples, step 585 occurs next. In some examples, in step 585, the cleanup target is removed from memory. As shown in the figure, in some examples, step 586 occurs next. In some examples, in step 586, the installation target is removed from the backup partition. As shown in the figure, in some examples, a decision step 587 occurs next. In some examples, in decision step 587, it is determined whether there are more priority groups to be temporarily stored. If so, the process returns to step 581 for the next priority group. Otherwise, the process can then proceed to the return box, where other processing resumes.

[0155] in conclusion

[0156] While the foregoing “Detailed Description” describes some examples of the technology and outlines the expected best mode, the technology can be implemented in a variety of ways, regardless of how detailed it is described above. Details may vary in implementation while still being included in the technology described herein. As noted above, specific terms used in describing certain features or aspects of the technology should not be construed as implying that such terms are redefined herein as limited to any particular feature, characteristic, or aspect associated with that term. Generally, the terms used in the following claims should not be construed as limiting the technology to the specific examples disclosed herein, unless such terms are expressly defined in the “Detailed Description”. Therefore, the actual scope of the technology includes not only the disclosed examples but also all equivalent ways of practicing or implementing the technology.

Claims

1. An electronic device, comprising: A memory and a processor, wherein the memory and the processor are respectively configured to store and execute instructions for causing the device to perform actions, the actions including: Installing update software for the device, wherein the update software for the device includes at least update software of a first priority group and update software of a second priority group, wherein installing the update software for the device includes: Temporarily storing the installation of the updated software for the first priority group includes: Generate a list of installation targets for the updated software for the first priority group; Generate a list of removal targets for the updated software for the first priority group; The installation target of the update software for the first priority group is downloaded to a partition of the memory, the partition of the memory being smaller than the entire update software for the device; The downloaded installation target installs the update software from the partition for the first priority group; The purge target for the update software targeting the first priority group is deleted from the memory; and Remove the installation target of the update software for the first priority group from the partition; and After the installation of the update software in the first priority group is temporarily stored, the installation of the update software in the second priority group is temporarily stored, including: Generate a list of installation targets for the updated software for the second priority group; Generate a list of removal targets for the updated software for the second priority group; The installation target of the updated software for the second priority group is downloaded to the partition; The downloaded installation target installs the update software from the partition for the second priority group; The purge target for the updated software in the second priority group is deleted from the memory; and Remove the installation target of the update software for the second priority group from the partition.

2. The electronic device of claim 1, wherein the installation of the update software for the device further comprises: After the installation of the update software in the second priority group is temporarily stored, the installation of the update software in the third priority group is performed, including: Generate a list of installation targets for the updated software for the third priority group; Generate a list of removal targets for the updated software in the third priority group; The installation target of the update software for the third priority group is downloaded to the partition; The downloaded installation target installs the update software from the partition for the third priority group; The purge target for the update software targeting the third priority group is deleted from the memory; and Remove the installation target of the update software for the third priority group from the partition.

3. The electronic device of claim 1, wherein the first priority group and the second priority group are elements of a set of priority groups, and wherein the set of priority groups includes a security keystore.

4. The electronic device of claim 1, wherein the first priority group and the second priority group are elements of a set of priority groups, and wherein the set of priority groups includes a bootloader.

5. The electronic device of claim 1, wherein the memory is a flash memory of an integrated circuit having multiple cores, the multiple cores including at least one central processing unit and at least one microcontroller.

6. The electronic device of claim 1, wherein the temporary storage of the installation of the update software in the first priority group further includes: Generate a list of rollback targets for the updated software for the first priority group.

7. The electronic device of claim 6, wherein the installation of the update software for the device further comprises: Rolling back to the last known good version of the software in the first priority group includes: changing the rollback target for the updated software in the first priority group to the installation target for the updated software in the first priority group.

8. The electronic device of claim 6, wherein the temporary storage of the installation of the update software in the first priority group further includes: For software in the memory that is marked as temporary, mark the temporary software as a target for removal.

9. The electronic device of claim 1, wherein the first priority group and the second priority group are elements of a set of priority groups, and wherein the set of priority groups includes a set of partitions.

10. The electronic device of claim 9, wherein the set of partitions corresponds to a set of independent execution environments configured with a defense-in-depth hierarchy.

11. The electronic device of claim 10, wherein at least two of the set of independent execution environments operate on a general-purpose core having different functions from each other, and wherein the general-purpose core having different functions from each other includes at least a first microcontroller and a first central processing unit (CPU).

12. A method for upgrading temporary storage in memory, comprising: Installing update software for a computing device, wherein the update software for the computing device includes at least update software of a first priority group and update software of a second priority group, wherein installing the update software for the computing device includes: Temporarily storing the installation of the updated software for the first priority group includes: Provide a list of installation targets for the updated software for the first priority group; Provide a list of removal targets for the updated software for the first priority group; The installation target of the update software for the first priority group is downloaded to a partition of the memory of the computing device, the partition of the memory being smaller than the entire update software for the computing device; The purge target for the update software targeting the first priority group is deleted from the memory; and In response to an update to the software in the first priority group, the installation target for the updated software in the first priority group is removed from the partition; and After the installation of the update software in the first priority group is temporarily stored, the installation of the update software in the second priority group is temporarily stored, including: Provide a list of installation targets for the updated software for the second priority group; Provide a list of removal targets for the updated software for the second priority group; The installation target of the updated software for the second priority group is downloaded to the partition; The purge target for the updated software in the second priority group is deleted from the memory; and In response to an update to the software in the second priority group, the installation target for the updated software in the second priority group is removed from the partition.

13. The method of claim 12, wherein the installation of the updated software for the computing device further comprises: After the installation of the update software in the second priority group is temporarily stored, the installation of the update software in the third priority group is performed, including: Provide a list of installation targets for the updated software for the third priority group; Provide a list of removal targets for the updated software in the third priority group; The installation target of the update software for the third priority group is downloaded to the partition; The purge target for the update software targeting the third priority group is deleted from the memory; and In response to an update to the software in the third priority group, the installation target for the updated software in the third priority group is removed from the partition.

14. The method of claim 12, wherein the first priority group and the second priority group are elements of a set of priority groups, wherein the set of priority groups includes a set of partitions.

15. The method of claim 12, wherein the temporary storage of the installation of the updated software in the first priority group further comprises: Provide a list of rollback targets for the updated software for the first priority group.

16. The method of claim 15, wherein the installation of the updated software for the computing device further comprises: Rolling back to the last known good version of the software in the first priority group includes: changing the rollback target for the updated software in the first priority group to the installation target for the updated software in the first priority group.

17. A processor-readable storage medium having processor-executable code stored thereon, the processor-executable code, when executed on a computing device, causing the computing device to perform an action, the action comprising: Installing update software for the computing device, the update software for the computing device including update software for each of a plurality of priority groups, and wherein the installation of the update software for the computing device includes: Temporarily storing the installation of the update software for each of the plurality of priority groups includes: completing the temporary storage for the installation of the update software for higher priority groups before starting the temporary storage for the installation of the update software for lower priority groups, wherein the temporary storage for the installation of the update software for each priority group includes: Generate a list of installation targets for the updated software based on the priority group; Generate a list of removal targets for the updated software based on the priority group; The installation target of the updated software grouped according to the priority is downloaded to a partition of the memory of the computing device; The downloaded installation target installs the updated software for the priority group; The purge target for the update software corresponding to the priority group is deleted from the memory; and The installation target of the update software is removed from the partition, along with the priority group of the partition. The partition table of the memory is updated to reflect the completion of the installation of the update software for the computing device.

18. The processor-readable storage medium of claim 17, wherein each priority group is an element of a set of priority groups, wherein the set of priority groups includes a set of partitions.

19. The processor-readable storage medium of claim 17, wherein the temporary storage for the installation of the updated software in each priority group further comprises: Generate a list of rollback targets for the updated software based on the priority group.

20. The processor-readable storage medium of claim 19, wherein the installation of the update software for the computing device further comprises: Rolling back to the last known good version of the software for a first priority group of the priority group includes: changing the rollback target of the updated software for the first priority group to the installation target of the software for the first priority group.

21. A computer program product comprising computer-executable instructions, wherein the computer-executable instructions, when executed by a processor, implement the method as described in any one of claims 12 to 16.

Images