Memory efficient upgrade temporary storage

Abstract

The disclosed technology generally relates to upgrade temporary storage of memory. In one example of the technique, temporary storage is performed on at least two priority packets, and temporary storage of each higher priority packet is completed prior to temporary storage of lower priority packets, including the following actions for each priority packet. A list of installation targets for the priority packet is generated based on the software for installation in the memory and the list of software present in the memory. A list for priority packet clear targets is generated based on a list of software for installation in memory and software present in memory. The installation target is downloaded to a backup partition of the memory. Updates to the software in the memory are caused based on the installation target. And deleting the clear target from the memory. And deleting the installation target from the backup partition.

Description

[0001] Related Applications

[0002] This application is a divisional application of the invention patent application with an international application date of June 14, 2019, which entered the Chinese national stage on December 17, 2020, with Chinese national application number 201980040754.0, and invention name “Efficient upgrade temporary storage of memory”. Technical Field

[0003] Embodiments of the present disclosure relate to temporary storage of memory upgrades. Background Art

[0004] The Internet of Things ("IoT") generally refers to a system of devices that are able to communicate over a network. These devices can include everyday items such as toasters, coffee makers, thermostat systems, washers, dryers, lights, cars, etc. Network communications can be used to automate devices, capture data, provide alerts, personalize settings, and many other applications. Summary of the invention

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

[0006] Briefly, the disclosed technology generally relates to embedded device updates. In one example of the technology, staging is performed on at least two priority groups, and staging of each higher priority group is completed before staging of the lower priority group, 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 for installation in the memory and software present in the memory. In some examples, a list of purge targets for the priority group is generated based on a list of software for installation in the memory and software present in the memory. In some examples, the installation target is downloaded to a backup partition of the memory. In some examples, based on the installation target, an update of the software in the memory is caused. In some examples, the purge target is deleted from the memory. In some examples, the installation target is deleted from the backup partition.

[0007] Other aspects and applications of the disclosed technology will be understood upon reading and understanding the drawings and specification. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0009] For a better understanding of the present 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 is a block diagram illustrating one example of a suitable environment in which aspects of the present technology may be employed;

[0011] Figure 2 is a block diagram illustrating one example of a suitable computing device in accordance with aspects of the disclosed technology;

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

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

[0014] Figure 5A-Figure 5B is a flow chart illustrating an example process according to aspects of the present disclosure. DETAILED DESCRIPTION

[0015] The following description provides specific details for thoroughly understanding and implementing the description of various examples of the technology. Those skilled in the art will appreciate that the technology can be implemented without many of these details. In some cases, well-known structures and functions are not shown or described in detail to avoid unnecessarily obscuring the description of the examples of the technology. The terms used in this disclosure are intended to be interpreted in their broadest reasonable manner, even if they are used together with the detailed description of some examples of the technology. Although certain terms may be emphasized below, any term intended to be interpreted in any restricted manner will be clearly and specifically defined in the "Detailed Description" section. Throughout the specification and claims, unless otherwise indicated by the context, the following terms at least adopt the meanings clearly associated herein. The meanings determined below do not necessarily limit the terms, but only 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 options based on other factors, some of which may not be described in this article. 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 in this article. The meaning of "in" includes "in" and "on". The phrases "in one embodiment" or "in one example" used herein may not necessarily refer to the same embodiment or example, although they may. The use of specific textual numerical indicators does not indicate the presence of numerical indicators with lower values. For example, the statement "a widget selected from a group including a third foo and a fourth bar" does not itself indicate that there are at least three foos, nor does it indicate that there are at least four bar elements. Unless multiple references are explicitly excluded, singular references are only for the clarity of reading and include plural references. 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 include various combinations of hardware, software, or hardware and software. Thus, for example, a system or component can be a process, a process executed on a computing device, a computing device, or a part thereof.

[0016] Briefly, the disclosed technology generally relates to embedded device updates. In one example of the technology, staging is performed on at least two priority groups, and staging of each higher priority group is completed before staging of the lower priority group, 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 for installation in the memory and software present in the memory. In some examples, a list of purge targets for the priority group is generated based on a list of software for installation in the memory and software present in the memory. In some examples, the installation target is downloaded to a backup partition of the memory. In some examples, based on the installation target, an update of the software in the memory is caused. In some examples, the purge target is deleted from the memory. In some examples, the installation target is deleted from the backup partition.

[0017] In some examples, before executing an embedded device upgrade, the upgrade is staged, i.e., the update is downloaded and placed where it needs to be in the appropriate partitions before the actual installation of the update. Handling staging can be challenging when there is insufficient space to store the entire update and when there are complex prioritization issues.

[0018] A list indicating the software that should be present once the update is complete may be received or generated in some manner. This list may be used during staging, as discussed in more detail below.

[0019] In some examples, staging is prioritized in multiple ways. As a type of prioritization, in some examples, staging is organized into prioritized priority groups, such that the priority group with the highest priority is staging first in its entirety before proceeding to the next priority group, and then the next highest priority group is staging in its entirety before proceeding to the next priority group, and so on, until every priority group is staging.

[0020] Each priority grouping may be staged as follows. For the priority grouping being staged, a list indicating software that should be present once the update is complete is compared to software currently present in persistent memory. A list of installation targets is generated based on the comparison, wherein the list includes software that is not currently present in memory in the staged priority grouping and software versions that need to be updated relative to the software currently present in memory. A list of purge targets may then be generated based on the comparison, wherein for the current priority grouping, the purge targets include software that is currently present in memory but is not in the list of software that should be present once the update is complete.

[0021] Then, the software corresponding to the installation target can be downloaded. In some examples, then, based on the installation target, the software of the current priority grouping is caused to be updated. In addition, the purge target can be deleted. In some examples, once the installation is complete, the installation target is deleted from the memory because there may not be enough memory to temporarily store the entire update at once.

[0022] Staging can vary and include additional steps in various examples, for example, to include rolling back to a last known good state, to allow testing of an application, and / or for other reasons, as discussed in more detail below.

[0023] Illustrative Equipment / Operating Environment

[0024] Figure 1 1 is a diagram of an environment 100 in which aspects of the present technology may be implemented. As shown, the environment 100 includes a computing device 110 and a network node 120 connected via a network 130. Figure 1 Specific components of environment 100 are shown in FIG. 1 , 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 in various locations, including indoors, in the cloud, etc. For example, the computing device 110 can be on the client side, on the server side, etc.

[0025] like Figure 1As shown, the network 130 may include one or more network nodes 120, one or more network nodes 120 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, the network node 120 may include a switch, a router, a hub, a network controller or other network elements. In some examples, the computing devices 110 may be organized into racks, action zones (zones), groups, sets or other suitable divisions. For example, in the example shown, the computing devices 110 are grouped into three host groups, which are identified as first, second and third host groups 112a-112c, respectively. In the example shown, each host group in the host groups 112a-112c is operably coupled to a corresponding network node 120a-120c, respectively, which are generally referred to as "top of rack" or "TOR" network nodes. The TOR network nodes 120a-120c can then be operably coupled to additional network nodes 120 to form a computer network of a hierarchical, flat, mesh, or other suitable type of topology that allows communication between the computing device 110 and the external network 140. In other examples, multiple host groups 112a-112c can share a single network node 120. The 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 smart phones. However, in a data center environment, these computing devices can be server devices, such as application server computers, virtual computing host computers, or file server computers. In addition, the computing devices 110 can be configured separately to provide computing, storage, and / or other suitable computing services.

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

[0027] Illustrative Computing Devices

[0028] Figure 2 2 is a diagram illustrating one example of a computing device 200 in which aspects of the present technology may be implemented. The computing device 200 may be virtually any type of general-purpose or special-purpose computing device. For example, the computing device 200 may be a user device, such as a desktop computer, a laptop computer, a tablet computer, a display device, a camera, a printer, or a smart phone. Likewise, the computing device 200 may also be a server device, such as an application server computer, a virtual computing host computer, or a file server computer. For example, the computing device 200 may be Figure 1The computing device 200 may also be an IoT device connected to the network to receive IoT services. Similarly, the computing device 200 may be an example of a computing device 110 or a network node 120. Figure 3-5B Examples of any device shown or referenced in the drawings, as discussed in more detail below. Figure 2 As shown, computing device 200 includes processing circuit 210, operating memory 220, memory controller 230, data storage memory 250, input interface 260, output interface 270, and network adapter 280. Each of these aforementioned components of computing device 200 includes at least one hardware element.

[0029] The computing device 200 includes at least one processing circuit 210 configured to execute instructions, such as instructions for implementing the workloads, processes, or techniques described herein. The processing circuit 210 may include a microprocessor, a microcontroller, a graphics processor, a coprocessor, a field programmable gate array, a programmable logic device, a signal processor, or any other circuit suitable for processing data. The processing circuit 210 is an example of a kernel. The above instructions and other data (e.g., data sets, metadata, operating system instructions, etc.) can be stored in the operating memory 220 during the runtime of the computing device 200. The operating memory 220 can 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, when the computing device 200 is powered off, the operating memory 220 does not retain information. Instead, as part of a boot or other loading process, the computing device 200 can be configured to transfer instructions from a non-volatile data storage component (e.g., data storage memory 250) to the operating memory 220. In some examples, other forms of execution may be employed, such as directly from data storage memory 250 , for example, execute-in-place (XIP).

[0030] The operating memory 220 may include a fourth generation double data rate (DDR4) memory, a third generation double data rate (DDR3) memory, other dynamic random access memory (DRAM), a high bandwidth memory (HBM), a hybrid memory cube memory, a 3D stacked memory, a static random access memory (SRAM), a magnetoresistive random access memory (MRAM), a pseudo-static random access memory (PSRAM), or other memory, and such memory may include one or more memory circuits integrated into a DIMM, a SIMM, a SODIMM, a known good die (KGD), or other packaging. Such operating memory modules or devices may be organized according to channels, ranks, and libraries. For example, the operating memory device may be coupled to the processing circuit 210 via a memory controller 230 in a channel. An example of the computing device 200 may include one or two DIMMs per channel, each channel having one or two ranks. The operating memory within a rank may operate with a shared clock, a shared address, and a command bus. Moreover, the operating memory device may be organized into several banks, which may be considered as arrays addressed by rows and columns. Based on this organization of the operating memory, physical addresses within the operating memory can be referenced by a tuple of channel, rank, bank, row, and column.

[0031] Notwithstanding the above discussion, operational memory 220 specifically does not include or contain communications media, any communications media, or any signals per se.

[0032] The memory controller 230 is configured to interface the processing circuit 210 to the operating memory 220. For example, the memory controller 230 may be configured to interface commands, addresses, and data between the operating memory 220 and the processing circuit 210. The memory controller 230 may also be configured to abstract or otherwise manage certain aspects of memory management from or for the processing circuit 210. Although the memory controller 230 is shown as a single memory controller separate from the processing circuit 210, in other examples, multiple memory controllers may be employed, the memory controller(s) may be integrated with the operating memory 220, and so on. Further, the memory controller(s) may be integrated into the processing circuit 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 circuit 210 via bus 240. Figure 2The bus 240 is shown as a single passive bus, but other configurations (such as a collection of buses, a collection of point-to-point links, input / output controllers, bridges, other interface circuits, or any collection thereof) may also be appropriately used to interface the data storage memory 250, input interface 260, output interface 270, or network adapter 280 to the processing circuit 210.

[0034] In the computing device 200, the data storage memory 250 is used for long-term non-volatile data storage. The 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, the data storage memory 250 specifically does not include or contain a communication medium, any communication medium or any signal itself. In contrast to the operating memory 220, the data storage memory 250 is used by the computing device 200 for non-volatile long-term data storage, rather than for runtime data storage. In some examples, the performance counter 475 can also be configured to measure the delay from the core to the target (such as from the MCU 462 to the SRAM 458).

[0035] In addition, the computing device 200 may include or be coupled to any type of processor-readable media, such as processor-readable storage media (e.g., operating memory 220 and data storage memory 250) and communication media (e.g., communication signals and radio waves). Although the term processor-readable storage medium includes operating memory 220 and data storage memory 250, the term "processor-readable storage medium", whether used in the singular or plural form, throughout the specification and claims is defined herein so that the term "processor-readable storage medium" specifically excludes and does not include communication media, any communication media, 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. In addition, 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 processor or an accelerator, and is configured to render a display for presentation on a separate visual display device (such as a monitor, a projector, a 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), etc. In addition, 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 example shown, 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, SigFox, LoRa, a powerline, or a 5G adapter.

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

[0039] Some examples of computing device 200 include at least one memory (e.g., operating memory 220) suitable for storing runtime data and at least one processor (e.g., processing circuitry 210) suitable for executing processor executable code, which in some examples enables computing device 200 to perform actions in response to execution.

[0040] Descriptive System

[0041] Some examples of the present 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. Examples of the present disclosure may also be used in other suitable contexts. Figure 4 and Figure 5A-Figure 5B Specific examples of the present disclosure used in the context of a multi-core microcontroller included in an IoT device, used as a device controller for the IoT device, are discussed.

[0042] Figure 3 300 . The system 300 may include a network 330 , and an IoT support service 351 , IoT devices 341 and 342 , and an application backend 313 , all of which are connected to the network 330 .

[0043] The term "IoT device" refers to a device that is intended to utilize IoT services. IoT devices can actually include any device that is 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, a peer or a local system, or a peer and a local system and the cloud, or in any other suitable manner. IoT devices can include everyday items such as toasters, coffee machines, thermostat systems, washing machines, dryers, lights, cars, etc. IoT devices can also include, for example, various devices in "smart" buildings, including lights, temperature sensors, humidity sensors, occupancy sensors, etc. IoT services for IoT devices can be used for equipment automation, data capture, providing alarms, personalization of settings, and many other applications.

[0044] The term "IoT Support Services" refers to a device, a portion of at least one device, or multiple devices, such as a distributed system, to which, in some examples, IoT devices connect over a network to obtain IoT services. In some examples, the IoT Support Services are IoT hubs. In some examples, the IoT hub is excluded, and the IoT devices communicate with the application backend directly or through one or more intermediaries without including the IoT hub, and the software components in the application backend operate as IoT Support Services. The IoT devices receive IoT services via communication with the IoT Support Services. In some examples, the IoT Support Services may be embedded inside the device or in local infrastructure.

[0045] Application backend 313 refers to a device or multiple devices, such as a distributed system, that performs actions that enable data collection, storage, and / or actions to be performed based on IoT data, including user access and control, data analysis, data display, data storage control, automatic operations based on IoT data, etc. 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 performed by applications running in application backend 313.

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

[0047] One or more of the IoT devices 341 and 342 may include a device controller 345 that can operate to control the IoT device. 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] The network 330 may include one or more computer networks, including wired and / or wireless networks, each of which 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 are used as links between LANs to enable messages to be sent from one to another. In addition, the communication links within the LAN typically include twisted pairs or coaxial cables, while the 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 networks (ISDN), digital subscriber lines (DSL), wireless links including satellite links, or other communication links known to those skilled in the art. In addition, remote computers and other related electronic devices may be remotely connected to a LAN or WAN via a modem and a temporary telephone link. The network 330 may include various 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 devices via a network different from other IoT devices in the network 330. Essentially, network 330 includes any communication method by 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 devices / services shown only communicate with some other devices / services shown via one or more intermediary devices. In addition, although network 330 is shown as one network, in some examples, network 330 may instead include multiple networks that may or may not be connected to each other, with some devices shown as communicating with each other via one of the multiple networks, while other devices are shown as communicating with each other using different ones of the multiple networks.

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

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

[0051] System 300 may include more than what is shown by way of example only. Figure 3More or less equipment than shown.

[0052] Illustrative equipment

[0053] Figure 4 445 is a block diagram showing an example of a device controller 445. The device controller 445 may be used as Figure 3 An example of a device controller 345 is adopted. The 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, a flash memory 456, a radio block 457, a secure static random access memory (SRAM) 458, an interface 459, an MCU 461, an MCU 462, a primary advanced extensible interface (AXI) bus 463, an auxiliary AXI bus 464, bridges 465 and 466, an AXI to advanced peripheral bus (APB) bridge for each peripheral 467, an interface 471, a 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 in which device controller 445 is included to function as an IoT device (such as Figure 3 IoT device 341 or 342) is operated. In some examples, device controller 445 is a multi-core microcontroller. In some examples, device controller 445 runs a high-level operating system. In some examples, 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, device controller 445 provides not only network connectivity, but also various other functions, including hardware and software security, monitored operating systems, cryptographic functions, peripheral device control, telemetry, etc. In addition, device controller 445 may include: technology for allowing device controller 445 to be booted in a secure manner, technology for allowing device controller 445 to be securely updated, technology for ensuring that appropriate software is running on device controller 445, technology for allowing device controller 445 to operate correctly as an IoT device, etc.

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

[0056] In some examples, CPU 453 runs a high-level operating system. In some examples, CPU 453 has two independent 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 functions. In some examples, the "secure world" execution environment of CPU 453 is also part of the trusted computing base of the system. 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 security MCU of security complex 451 for special 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 components shown. In some examples, bridges 465, 466, and 467 bridge the components shown. 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, IO subsystem 1 461 and IO subsystem 2 462 are I / O subsystems for general I / O connectivity. In some examples, IO subsystem 1 461 and IO subsystem 2 462 each include an MCU.

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

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

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

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

[0063] In some examples, the "secure world" execution environment of CPU 453 is also part of the trusted computing base of the system. For example, in some examples, the "secure world" runtime ("secure world" RT) of CPU 453 has unfettered 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 internals of the core security complex of security complex 451, but relies on the MCU in security complex 451 for special 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 for code running in this environment, but it is not as trusted as code running on an MCU in 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 MCUs in security complex 451 and less trusted than CPU 453. In some examples, radio block 457 may include a core, which may be an MCU in some examples. Radio block 457 may provide Wi-Fi functionality and connectivity to the Internet and cloud services (such as IoT services). In some examples, radio block 457 may provide communications via Bluetooth, near field communication (NFC), ZigBee, long term evolution (LTE), and / or other connectivity technologies. In some examples, the core in radio block 457 does not have any access to unencrypted secrets and is not able to compromise the execution of CPU 453.

[0066] In some examples, each independent execution environment is managed by a single software component that executes in a separate execution environment called the "parent" of the execution environment. In such examples, an exception may 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 adopted. Management operations may include: booting and restoring the target environment, monitoring and handling 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 an 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 security complex 451 manages the “secure world” RT of CPU 453, components in the “secure world” RT in CPU 453 manage the “normal world” OS of CPU 453, components in the “normal world” OS of CPU 453 manage the “normal world” user mode of CPU 453, and the “normal world” user mode services of CPU 453 manage MCUs 461 and 462 and cores in radio block 457.

[0068] In some examples, not only are the isolated execution environments managed by software components from a more trusted execution environment, but different functions are assigned to different isolated execution environments, with more sensitive functions assigned to more trusted isolated execution environments. In a particular example, an isolated execution environment that is less trusted than the assigned isolated execution environment has limited access to the function. In this way, in some examples, the isolated execution environments implement defense in depth based on a hierarchy 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 secure MCU in core security complex 451 is next in the hierarchy and is assigned to control power, the secure world RT of CPU 453 is next in the hierarchy and is assigned to storage and write access to the real-time clock (RTC), the normal world OS of CPU 453 is next in the hierarchy and is assigned to Wi-Fi, the normal world user mode applications of CPU 453 is 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 peripherals. In other examples, functionality is assigned to independent execution environments in different ways.

[0070] In some examples, each level of the trust hierarchy, except for the bottom (i.e., least trusted) level of the hierarchy, has control over accepting or rejecting requests from less trusted levels, and is able to rate limit or audit requests from less trusted levels, and is able to verify requests from lower levels, for example, to ensure that the requests are correct and authentic, e.g., when implementing support for the software at their disposal. Additionally, as previously described, in some examples, except for the top (i.e., most trusted) level, each level of the hierarchy has a parent that is responsible for managing the lower (i.e., less trusted) levels, including monitoring whether the software at the lower levels is functioning properly.

[0071] Some examples of device controller 455 may be a multi-core microprocessor, which includes, for example, at least one CPU and at least one microcontroller, and flash memory with multiple memory 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 systems, cryptographic functions, peripheral device control, telemetry, and the like. In addition, device controller 455 may include: technology for allowing device controller 455 to be booted in a secure manner, technology for allowing devices to be securely updated, technology for ensuring that "proper" software is running on the device, technology for allowing the device to operate correctly as an IoT device, and the like. Security complex 451 may include a hardware root of trust for device controller 455 as the basis for security functions provided by device controller 455.

[0072] In some examples, flash memory 456 is an external NOR flash memory that includes a flash controller and parallel dual quad serial common interface (QSPI) NOR flash memory devices (two banks in this example), where each flash memory bank is a separate integrated circuit accessed via a separate channel. However, the present disclosure is not limited thereto, and any suitable memory configuration and / or suitable memory group may be employed.

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

[0074] In some examples, verification of the storage bank in order to allow access can be performed as follows. The security complex 451 can read in a portion of one of the unrestricted storage banks, such as the first storage bank in some examples. In some examples, the portion of the flash memory can be 16kb, 52kb, etc. Then, the hardware block in the security complex 451 can compare the loaded portion of the unrestricted flash storage bank with a special hardware fuse, and the verification is unsuccessful unless the loaded portion matches the fuse. In some examples, the hardware key can also be used to verify that the code is a trusted code. Comparing the portion of the unrestricted portion of the flash memory against the hardware fuse using the hardware block in the security complex 451 can be used to prevent loading of previously valid but now older code with vulnerabilities. As the corresponding unrestricted portion of the flash memory is changed, the fuse can be blown to prevent such older code from being subsequently verified and to prevent access to the 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 for the 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 bank. In some examples, flash memory 456 has two banks and / or other compartments in the memory, but is still a single image memory in which the compartments are not accessible.

[0076] In some examples, flash memory 456 is protected from corruption using examples of erasure coding schemes as described herein. Although the erasure coding scheme is described herein with respect to flash memory 456, the erasure coding scheme may also be used with any suitable memory or collection of data. In some examples, the erasure coding scheme described herein may be particularly beneficial for embedded devices that have a single image memory and do not have enough space to store a complete backup, for which it is desirable to prevent a large number of consecutive corruptions, accidental overwrites, etc. In some examples, the erasure coding scheme is used with flash memory to prevent flash memory corruption.

[0077] In some examples, various applications and / or pieces of firmware are dynamically erasure coded using a different erasure coding scheme for each different application and / or piece of software, with flexibility based on the size of each application and / or piece of firmware being encoded.

[0078] In some examples, an erasure coding scheme may be used where the memory is erasure coded based on fixed-size contiguous stripes, possibly leaving partial stripes if the memory size cannot be evenly divided by the stripe size.

[0079] In some examples, an erasure coding scheme may be used where the memory is erasure coded based on fixed-size non-contiguous stripes, potentially leaving a partial stripe if the memory size is not evenly divisible by the stripe size. For example, in some examples, the erasure coding scheme may use stripes in a "checkerboard" pattern where each data block is divided by the number of stripes, e.g., to stripe data blocks within a stripe across all other stripes.

[0080] In this way, in some examples, in the case of N stripes, a first data block of size S is divided into N stripes, wherein the first S / N data belongs to the first stripe, the next S / N data belongs to the second stripe, and so on, wherein 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 may belong to the first block, and the second block data is corded as stripe size*block size*stripe number.

[0081] For example, in one example, with 16MB of memory, 8MB of which is dedicated to applications, 8MB of applications can be erasure coded using 8k data blocks with 64kb stripes. Therefore, in this example, there are 8MB / 64kb stripes, i.e., 133 stripes. Therefore, in this example, the first stripe starts with the first 8MB / (8kb*133) data, the second stripe starts with the 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 offsets, and then the stripes are input to the erasure coding algorithm. In this way, in this example, the memory can recover from up to 1MB of continuous damage. However, the amount of damage that can be recovered from it depends on the number of erasure coding blocks generated (e.g., the fault tolerance model selected). Likewise, in some examples, while adjustments are made to prevent corruption of contiguous portions of memory, this does not prevent tolerance to random corruption. For example, some instances of random corruption can be prevented by the disclosed techniques.

[0082] In some examples, a hash or checksum is stored for each individual block of data that is erasure coded. In some examples, the checksum or hash is not stored in the data itself, but there is a separate block hash partition, file, or other data structure that tracks the hashes.

[0083] Fault tolerance can be selected, where greater fault tolerance requires greater overhead. For example, in some examples, an erasure coding algorithm tolerates two bad blocks per stripe instead of one, with greater overhead than if the algorithm tolerated one bad block per stripe. In some examples, a trade-off is made between fault tolerance and overhead.

[0084] If there is a partial stripe, e.g., a stripe with less data than a full stripe, the partial stripe may be handled differently in different examples. In some examples, phantom blocks may be used, where the remaining blocks are zeros that are not actually stored. This scheme may be less fault-tolerant, e.g., because the partial stripe can only tolerate the amount of continuous corruption associated with the chosen fault-tolerance mechanism. Alternatively, for greater fault-tolerance, a full backup of the partial stripe may be kept.

[0085] In some examples, in erasure code generation, the inputs are the amount of storage being erasure coded, the erasure coding scheme to use, the stripe size, the block size, how to handle any partial stripes, and fault tolerance (i.e., how many bad blocks can be recovered per stripe).

[0086] In some examples, after receiving the input, for all data for which no partial stripes exist, the number of stripes is counted and each stripe is generated as described above based on the calculated offset to generate each stripe and provide the stripe to the erasure coding algorithm. If the memory is byte-addressable NOR flash memory, 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 the other mechanism can be reused using erasure coding.

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

[0089] In some examples, during the repair process, bad blocks are first determined by checking the blocks against hash values. In some examples, along the known bad flash range, for each block in the flash range, the stripe in which the block is located is calculated, all addresses in the stripe are found, and for these blocks, the hash values ​​of these blocks are checked against the known hash values. In some examples, for each hash value that does not match, the corresponding block is declared bad for the stripe.

[0090] Next, in some examples, the number of bad blocks is compared to the 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 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 tolerance, the bad blocks are repaired, for example, by invoking the selected erasure coding scheme using the stripe data and the erasure coding block.

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

[0092] In some examples, each block in the range is repaired in this manner, or skipped because it is not corrupt. Once completed, in some examples, a confirmation can be made as to whether the range is still corrupt. For example, in one example, a range is found to be corrupt based on mismatched signatures, the range can be sent to the entity that originally performed the signature check, which can then check to determine whether the range is still corrupt, such as by re-running the signature check and confirming that it now verifies.

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

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

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

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

[0097] In some examples, a hardware stock keeping unit (SKU) is used as part of the process of describing a hardware update policy 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 the specific configuration (color, model, function, country / region, etc.) of the device being sold. In one example, the hardware SKU for each IoT device includes a device SKU and a chip SKU. In some examples, there may be more than two descriptive SKUs, so that three or more types of SKUs provide a hierarchy with three or more levels. The chip SKU may define the specific type of chip running within the IoT device and the function of the chip. A serial number, public key, or device ID may be used to uniquely identify a single instance of a chip.

[0098] A device SKU can be used as an identifier that describes the type of IoT device that uses a chip. A SKU might be one used by a product manufacturer to identify a specific model and configuration within their product line. Each device SKU can have a set of attributes that describe software-related characteristics. Additionally, each device SKU can have attributes that describe a unique chip SKU that all devices with that device SKU contain. These attributes can also be defined and stored in an IoT service solution in a SKU registry. These attributes can also describe characteristics that manufacturers use to differentiate IoT device models (i.e., washer vs. dryer, tan vs. stainless steel), but there are also some of the subtle differences that make up an IoT device (the hardware SKU of the motor used, the type of LED panel connected to a 4×4 chip). In some examples, there are two SKU registries; one for device SKUs and another for chip SKUs.

[0099] A distribution describes binary content that can be made available by a device. A distribution is a coherent set of image binaries for some target. In some examples, a distribution consists of at least four different 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, a component ID collects all images that apply to a single component. Distributions can be coherent because they are pre-tested to ensure that all binaries in the distribution work together.

[0100] In some examples, a release is not available to an IoT device until after the release is deployed. In some examples, a deployment bundles a set of releases with a set of constraints that define properties of the devices targeted by the deployment. In some examples, after the deployment is registered and activated, how is it ultimately calculated in a query which releases are used for the IoT device.

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

[0102] In some examples, software engineers can also define new distributions around specific SKUs and register them with the IoT update service. Engineers can also be able to increment the distribution version number, write a set of image binaries for the next version of the distribution, confirm that the written image binaries meet all constraints provided by the metadata of each image, and receive suggestions for image binaries that are compatible with the constraints. For any given distribution, software engineers can use query tools to view the set of IoT devices that are currently using the distribution, using the distribution as a backup, or for which the distribution is available. In addition, engineers can be able to query a specific group of devices and determine the set of deployments and distributions that the group is currently using.

[0103] After a new release is defined, 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 recently updated image binary. After the deployment is activated, it can be available to the IoT device when the IoT device next checks for updates. Under normal circumstances, an IoT device can request the service to send it the release it should currently have on some regular cadence (for example, once a week). Engineers can also proactively request that the device make this request immediately, rather than on a regular cadence.

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

[0105] In some examples, when a release is made available to a group of IoT devices via deployment, it will not be made available to all IoT devices in the group at the same time. Instead, in these examples, each release is made available in a rolling deployment. For example, a rolling deployment can start with a deployment to a small portion of the target IoT devices. As the update completes successfully, 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) as to whether there is a new device update currently available for the IoT device. In some examples, the daemon is included in the NW of the IoT device. Next, the NW daemon on the IoT device can receive information related to IoT device updates from the cloud service. In some examples, the information includes an indication of the release that the IoT device should have, and includes metadata associated with the indicated release (such as a semantic version) and metadata associated with each image binary file in the indicated release (such as an ID, version, etc.). In some examples, secure transport is used in communications between the IoT device and the cloud service.

[0107] In some cases, upon receiving an indication related to an update of the IoT device, the IoT device verifies the update. In some examples, the IoT device verifies the update by verifying whether the update is correctly signed. In some examples, the IoT device also determines whether a new version should be downloaded by comparing the image binary files to be installed for the update with the image binary files already installed in the IoT device. In some examples, the IoT device then determines which image binary files should be downloaded from the cloud service to be ultimately installed as part of the update process. In some examples, for each image binary file 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 file. In some examples, the cloud service sends the location of each download to the daemon in response to a request for the location of each image binary file, and the daemon then sends a request to the indicated location to download each image binary file.

[0108] In some examples, the IoT device then receives the requested image binary files from the cloud service. In some examples, there is not enough RAM on the IoT device to store the image binary files in memory, so instead, each image binary file is streamed to the IoT device. The total collection of image binary files received by the IoT device comprises the release. In some examples, a secure transport is used between the cloud service and the IoT device. Further, in some examples, a compressed version of the update is downloaded because there is not enough space to store the uncompressed version.

[0109] In some examples, before the update is executed, the update is staged. Staging can refer to downloading the update and placing it in the appropriate partition where it needs to be before the actual installation of the update. Handling staging can be challenging in situations where there is insufficient space to store the entire update and in situations where there are complex prioritization issues. In some examples, staging is performed in a specific manner and has multiple prioritization levels. Staging is 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 manner. The list can be used during the staging and update process. In some examples, the list is a list received by the IoT device from the cloud service, where the list is a list provided to the IoT device from 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 via an identifier such as an image ID. In other examples, the list is received or generated in some other manner.

[0111] The device controller 445 and the corresponding flash memory may be divided into multiple partitions. In some examples, the partitions are physical partitions, while in other examples, the partitions are logical partitions. Figure 4 In the example of the device controller 455 shown, the partitions are physical partitions, including a firmware partition, an OS partition, and an application partition. 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 completing an update to one portion of the partition at one time and another portion of the partition at another time. In some examples, particularly where there are inter-partition dependencies, partitions can be updated atomically in a particular order to ensure that a recently updated partition does not have an updated functional dependency on another partition that has not yet been updated. In some examples, the upgrade is complete after each partition is atomically upgraded, and in cases where an order based on inter-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 tolerant to power failures and / or other failures. In some examples, there are two partition tables in each partition, a primary partition table and a backup partition table. In some examples, there are two tables because if a power and / or other failure occurs while writing one partition table, the other partition table remains valid. In some examples, each partition table has an entry for each image on the partition, and each entry includes information about the image, such as, in some examples, the offset of the image in flash memory. The information may also include the status of the image, including whether the image has been installed. In some examples, the table uses some mechanism (such as a hash) to determine whether the table is consistent or corrupted.

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

[0115] After the installation for the partition has been staged, the updated version is written to the partition. Next, the updated version is verified. After the updated version is verified, the current partition table is copied to storage. The original entry pointing to the original version is deleted, and then a new entry pointing to the current version is added to the copy. At this point, the copy is now an updated partition table. The updated partition table is then written to the backup partition table. Then, at 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 both the primary partition table and the secondary partition table are not corrupted, but the primary partition table and the secondary partition table are different from each other, it indicates that there was a power failure and / or other failure between the writing of the primary partition table and the secondary partition table, and therefore, the primary partition table is then overwritten with the backup partition table. If both the primary partition table and the backup partition table are corrupted, the partition tables can be corrected by other methods (such as erasure coding), as discussed in more detail below, otherwise the upgrade fails.

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

[0118] First, the memory allocator is used to determine the offset of each image in the flash memory in 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, even taking into account the fragmented space, in this case the update will fail.

[0119] However, if there is enough space when taking into account the fragmented space, the non-updated image can be copied to the backup partition. Next, the empty table can be written to flash memory, writing both the primary partition table and the backup partition table. If a power and / or other failure occurs after the empty table is written, the installation can simply resume from where it was interrupted after the first time.

[0120] Next, the non-updated image can be copied back to the flash memory along with the new image to be updated, thus tightly packing the images. The steps can then proceed as usual.

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

[0122] The above discussion 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 to the partition table. In some examples, in order to upgrade the partitions in a way that prevents failures and corruption, the erasure coding blocks are also updated in the correct order.

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

[0124] First, the installation is staged. Next, both the primary partition table and the backup partition table are modified to be installed to add an indication that the installation is in progress. In some examples, the indication is an "installing" entry in the primary partition table and the backup partition table. The "installing" entry includes the data range that is modified during the installation.

[0125] In some examples, after adding the entry being installed to both tables, the backup partition table is written so that the backup partition table includes entries for the installation target, etc. In some examples, next, the erase code for the backup partition table is regenerated, and a hash is generated for the backup partition table. In some examples, next, the primary partition table is 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 stored in a separate area in flash memory that tracks block hashes.

[0126] In some examples, if at any time the backup partition is successfully written 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 installed, all erasure coded blocks described by the entry being installed that are within the data range specified in the entry being installed will be regenerated, and then the erasure coded blocks of the partition table will also be regenerated.

[0127] In some examples, next, as described above, if there is not enough free space for the updated version, the above steps can be performed. In some examples, after performing these steps or skipping these steps, if there is enough free space in the memory, the updated version is written to the partition. In some examples, next, the updated version is verified.

[0128] In some examples, after verifying that the updated version has been passed, the erasure coding blocks are updated for the image. In some examples, the hash is also updated. In some examples, next, the entries being installed are deleted from both partition tables.

[0129] In some examples, next, the current partition table is copied to storage. In some examples, the original version of the partition table is deleted from the copy, and the current version is then added to the copy. In some examples, at this point, the copy is now an updated partition table. In some examples, the updated partition table is then written to the backup partition table. In some examples, the erasure coded blocks 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 is next booted.

[0131] In some examples, next, a boot health check is performed, wherein after the boot health check is performed, the steps proceed as described in the previous examples. If both the primary partition table and the backup partition table are damaged, some other repair methods may be used, such as erasure code repair or the like.

[0132] In some examples, the erasure coded blocks for the backup partition table are then updated. In some examples, the hash of the backup partition table is then updated.

[0133] As described above, in some examples, staging is performed prior to updating. In some examples, staging is prioritized in a variety of ways. Staging can be organized into prioritized priority groups, such that the priority group with the highest priority is staging first in its entirety, then proceeding to the next priority group, then, before proceeding to the next priority group, the next highest priority group is staging in its entirety, until each priority group is staging. And so on, until each priority group is staging.

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

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

[0136] In some examples, priority groupings may be based at least in part on dependencies. For example, in some examples, a level of software may depend on a more trusted layer of software. 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 the software "depending on" the other software. Conversely, in some examples, software that is "dependent on" by software is described as "providing" the software that depends on the software. In some examples, the "provides" layer is always updated before the "depends on" layer. In some examples, the priority layers ensure that this is correct because higher priority layers are staged before lower priority layers.

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

[0138] Each priority grouping can be temporarily stored as follows. For the priority grouping being temporarily stored, a list indicating software that should be present once the update is complete is compared with the software currently present in the memory. A list of missing installation targets is generated based on the comparison, wherein the list includes software that is not currently present in the memory in the temporarily stored priority grouping or software versions that need to be updated relative to the software currently present in the 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. After the target is downloaded, it is no longer missing.

[0139] A list of purge targets can then be generated based on the comparison, where for the current priority grouping, the purge targets include software that is currently present in memory but is not in the list of software that should be present 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 install target or a purge target.

[0140] Then, the software corresponding to the installation target can be obtained, such as by downloading. In some examples, the obtained software can only be trusted if it is verified. 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 a missing installation target to an installation target (because, by definition, the target is no longer missing).

[0141] In some examples, then, based on the installation target, causing the software of the current priority group to be updated. In addition, the purge target can be deleted. In some examples, once the installation is completed, the installation target is deleted from the memory because there may not be enough memory to temporarily store the entire update at once.

[0142] Once the installation of a priority group is complete, or once the installation target is acquired, a reboot may be required. For example, in some examples, the installation of updates for certain priority groups may require a reboot, while the installation of updates for other priority groups may not require a reboot. In these examples, in response to the installation of updates for priority groups that require a reboot upon completion, the device will be rebooted prior to staging of the next priority group. In some examples, the acquisition of installation targets may require a reboot for certain priority groups, while the acquisition of installation targets for other priority groups may not require a reboot.

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

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

[0145] In some examples, just like the missing installation target, for the downloaded missing rollback target, the downloaded software can only be trusted after verification. The verification of the missing rollback target can include comparing the identity of the image with the expected identity in the missing rollback target. If the identity is not the expected identity (i.e., the component ID and the 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 a missing rollback target to a rollback target (because by definition, the target is no longer missing). In some examples, once all rollback targets of a particular priority grouping are downloaded, the installation targets are downloaded or otherwise acquired in the manner described above. As described above, in some examples, the targets are compressed.

[0146] In some examples, as an exception to the normal process, if a particular current priority group has not changed, but the priority group before the current priority group has changed, then for the current priority group, each rollback target of 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 can avoid fragmentation. In this case, there is no installation target, so no installation work is performed.

[0147] In some examples, the staging process may also be modified to accommodate the testing software.

[0148] For example, in some examples, certain applications (such as test software) should be marked as temporary applications. For example, this can include test software that has been loaded into a device in a factory and will never be updated through the cloud. The manufacturer can mark such an application as temporary. If an application is marked as a temporary application, in some examples, for ongoing updates, the temporary application does not require a rollback target, but is simply cleared. Therefore, in some examples, during the staging period, the application marked as temporary does not have a rollback target, but is marked as a clear target.

[0149] If a rollback to a previous known good state is needed later, in some examples, the rollback target is converted to an installation target and the installation process is then 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 be rolled back (because rolling back would break the dependency), and then, if that layer depends on another layer, that other layer must be rolled back (because rolling back would break the dependency), and so on.

[0150] Illustrative Process

[0151] For the sake of clarity, the processes described herein are described according to operations performed in a particular 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 different orders, performed in parallel, omitted, or supplemented by additional actions or features, regardless of whether such order, parallelism, actions or features are described herein. Similarly, any technology described in this disclosure may be incorporated into the described process or other processes, regardless of whether the technology is specifically described in conjunction with the process. The disclosed process 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, for example, as a processor-readable instruction 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] Figure 5A-Figure 5B An example data flow of process (580) is shown. In some examples, process 580 is performed by a device controller (e.g., Figure 4 In other examples, process 580 may be performed in other suitable devices. In some examples, steps 581-586 include temporarily storing the current priority group, and temporarily storing each higher priority group before temporarily storing the lower priority group.

[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 the list of software for installation in the memory and the software existing in the memory. As shown, in some examples, step 582 occurs next. In step 582, in some examples, a list of purge targets for priority groups is generated based on the list of software for installation in the memory and the software existing in the 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 the memory.

[0154] As shown, in some examples, step 584 occurs next. In some examples, at step 584, based on the installation target, an update to the software in the memory is caused. As shown, in some examples, step 585 occurs next. In some examples, at step 585, the clear target is deleted from the memory. As shown, in some examples, step 586 occurs next. In some examples, at step 586, the installation target is deleted from the backup partition. As shown, in some examples, 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, in which other processing is resumed.

[0155] in conclusion

[0156] Although the above “Detailed Description” describes some examples of the present technology and describes the expected best mode, no matter how detailed it is described above in the text, the technology can be implemented in many ways. The details can vary in implementation while still being included in the technology described in this article. As mentioned above, specific terms used when describing certain features or aspects of the present technology should not be taken as implying that the term is redefined herein to be limited to any specific feature, characteristic, or aspect associated with the term. In general, the terms used in the following claims should not be interpreted as limiting the technology to the specific examples disclosed herein unless such terms are explicitly 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. A device comprising: A memory and a processor, wherein the memory and the processor are respectively configured to store and execute instructions to cause the device to perform actions, the actions comprising: Installing update software for the device, the update software for the device at least including update software of a first priority group and update software of a second priority group, wherein installing the update software for the device comprises: Temporarily storing the installation of the update software of the first priority group includes: generating a list of installation targets for the updated software grouped by the first priority; generating a list of purge targets for the update software of the first priority group; downloading the installation target of the update software for the first priority group to a partition of the memory, the partition of the memory being smaller than the entirety of the update software for the device; installing the downloaded installation targets of the updated software for the first priority grouping from the partition; deleting the purge target of the update software for the first priority group from the memory; and deleting the installation target of the update software for the first priority group from the partition; and After temporarily storing the installation of the update software of the first priority group, temporarily storing the installation of the update software of the second priority group, comprises: generating a list of installation targets for the updated software grouped by the second priority level; generating a list of purge targets for the update software of the second priority group; downloading the installation target of the update software for the second priority group to the partition; installing the downloaded installation targets of the update software for the second priority grouping from the partition; deleting the purge target of the update software for the second priority group from the memory; and The installation target of the update software for the second priority group is deleted from the partition.

2. The device of claim 1, wherein the installation of the updated software for the device further comprises: After temporarily storing the installation of the update software of the second priority group, temporarily storing the installation of the update software of the third priority group, comprises: generating a list of installation targets of the updated software for the third priority group; generating a list of purge targets for the update software of the third priority group; downloading the installation target of the update software for the third priority group to the partition; installing the downloaded installation target of the update software for the third priority group from the partition; deleting the purge target of the update software for the third priority group from the memory; and The installation target of the update software for the third priority group is deleted from the partition.

3. The apparatus of claim 1, wherein the first priority grouping and the second priority grouping are elements of a set of priority groups, and wherein the set of priority groups comprises a security keystore. 4 . The apparatus of claim 1 , wherein the first priority grouping and the second priority grouping are elements of a set of priority groups, and wherein the set of priority groups includes a boot loader.

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

6. The apparatus of claim 1, wherein said staging of said installation of said update software of said first priority grouping further comprises: A list of rollback targets for the updated software of the first priority group is generated.

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

8. The apparatus of claim 6, wherein said staging of said installation of said update software of said first priority grouping further comprises: For the software in the memory that is marked as temporary, the temporary software is marked as a clearing target.

9. The apparatus of claim 1, wherein the first priority grouping and the second priority grouping are elements of a set of priority groups, and wherein the set of priority groups comprises a set of partitions.

10. The apparatus 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 device of claim 10, wherein at least two of the set of independent execution environments run on a general core having functions different from each other, and wherein the general core having functions different from each other includes at least a first microcontroller and a first central processing unit (CPU).

12. A method comprising: Installing update software for a computing device, the update software for the computing device comprising 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 comprises: Temporarily storing the installation of the update software of the first priority group includes: providing a list of installation targets for the updated software for the first priority grouping; providing a list of purge targets for the updated software of the first priority group; downloading the installation target of the update software for the first priority group to a partition of a memory of the computing device, the partition of the memory being smaller than the entirety of the update software for the computing device; deleting the purge target of the update software for the first priority group from the memory; and In response to an update of the software of the first priority group, deleting the installation target for the updated software of the first priority group from the partition; and After temporarily storing the installation of the update software of the first priority group, temporarily storing the installation of the update software of the second priority group, comprises: providing a list of installation targets for the updated software grouped by the second priority level; providing a list of purge targets for the updated software of the second priority group; downloading the installation target of the update software for the second priority group to the partition; deleting the purge target of the update software for the second priority group from the memory; and In response to the updating of the software of the second priority group, the installation target for the updated software of the second priority group is deleted from the partition.

13. The method of claim 12, wherein the installing of the updated software for the computing device further comprises: After temporarily storing the installation of the update software of the second priority group, temporarily storing the installation of the update software of the third priority group, comprises: providing a list of installation targets for the updated software grouped by the third priority level; providing a list of purge targets for the updated software grouped by the third priority level; downloading the installation target of the update software for the third priority group to the partition; deleting the purge target of the update software for the third priority group from the memory; and In response to the updating of the software of the third priority group, the installation target for the updated software of the third priority group is deleted from the partition.

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

15. The method of claim 12, wherein said staging of said installation of said updated software of said first priority group further comprises: A list of rollback targets for the updated software of the first priority grouping is provided.

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

17. A processor-readable storage medium having a processor-executable code stored thereon, wherein after the processor-executable code is executed on a computing device, the computing device is caused to perform an action, the action comprising: installing updated software for the computing device, the updated software for the computing device comprising updated software for each priority grouping in a plurality of priority groupings, and wherein the installing of the updated software for the computing device comprises: Temporarily storing the installation of the update software for each priority group in the plurality of priority groups, comprising: before starting the temporary storage of the installation of the update software for the lower priority group, completing the temporary storage of the installation of the update software for the higher priority group, the temporary storage of the installation of the update software for each priority group comprising: generating a list of installation targets for the update software grouped by priority; generating a list of purge targets for the update software grouped by priority; downloading the installation targets of the update software for the priority grouping to a partition of a memory of the computing device; installing the downloaded installation targets of the update software for the priority group; deleting the purge target of the update software for the priority group from the memory; and deleting the installation targets of the update software of the priority group from the partition; and A partition table of the memory is updated to reflect the completion of the installation of the updated software for the computing device.

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

19. The processor-readable storage medium of claim 17, wherein said temporary storage of said installation of said update software for each priority group further comprises: A list of rollback targets for the updated software grouped by priority is generated.

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

Images