Patent Description:
Many modem vehicles rely on one or more sophisticated embedded electronics systems for various operational and safety functions, including engine performance, information, and entertainment (also referred to as infotainment), autonomous or semiautonomous driving, collision avoidance, route navigation, and/or the like. To provide the various operation and safety functions, these systems execute can software applications that are organized into multiple partitions. Each partition includes instructions executed by the software applications and/or data accessed by the software applications during execution. In certain use cases, these partitions are duplicated such that two independent sets of partitions reside in memory concurrently. Document <CIT> discloses software upgrade using a dynamically sized partition.

In one use case, having two independent sets of partitions provides improved system reliability. For example, a software application can execute in a first set of partitions when a memory error occurs in one or more partitions in the first set of partitions. The memory error could result in corruption of the instructions executed by the software application and/or the data accessed by the software application. When such a memory error occurs, the system can switch from executing the software application in the first set of partitions to executing the software application in a second set of partitions, thereby avoiding the one or more partitions that experienced the memory error.

In a second use case, a current version of the software application can execute in a first set of partitions while an update process is storing an updated version of the software application in a second set of partitions. This technique allows the system to continue to operate during the software update process. If the update process completes successfully, then the system can switch from executing the current version of the software application in the first set of partitions to executing the updated version of the software application in the second set of partitions. If the update process does not complete successfully, then the system continues to execute the current version of the software application in the first set of partitions.

A drawback with this approach for maintaining multiple sets of partitions is that the memory requirements under such an approach can be double or more relative to a system that maintains a single set of partitions. Further, an embedded system employed in a vehicle and/or other environment can have restrictions on power consumption, size, and weight such that double the amount of memory may not be feasible. In addition, the memory requirement for a software application can increase with each updated version, as features are added to the software application over time. Although the memory requirements of the original version of the software application could allow the system to maintain multiple sets of partitions of the original size, the memory requirements of subsequent updated versions may be too large to accommodate multiple sets of partitions to be stored concurrently.

As the foregoing illustrates, what is needed are more effective ways to manage memory storage for software applications in an embedded system.

One embodiment sets forth a computer-implemented method for managing memory partitions in a computing system comprising generating a first entry for a first partition table associated with a first instance of a software application, wherein the first entry is associated with a first memory partition that includes a first memory extent; determining that a first data block referenced by the first memory partition is shared with a second instance of the software application; and generating a second entry for a second partition table associated with a second instance of the software application, wherein the second entry is associated with the first memory partition that includes the first memory extent.

One embodiment sets forth a system comprising a memory including instructions; and one or more processors coupled to the memory. When executing the instructions, the one or more processors generate a first entry for a first partition table associated with a first instance of a software application, wherein the first entry is associated with a first memory partition that includes a first memory extent; determine that a first data block referenced by the first memory partition is shared with a second instance of the software application; and generate a second entry for a second partition table associated with a second instance of the software application, wherein the second entry is associated with the first memory partition that includes the first memory extent.

Further embodiments provide, among other things, one or more non-transitory computer-readable media and systems configured to implement the method set forth above.

At least one technical advantage of the disclosed approaches relative to the prior art is that, with the disclosed techniques, an embedded system can maintain a single set of relevant data areas shared between different versions of a software application in one or more partitions, thereby reducing the memory requirements relative to a system that maintains multiple sets of partitions. Further, the embedded system maintains multiple partition tables that map to the single set of partitions. As a result, the software application accesses the partitions via a particular partition table, without being aware of which partitions are duplicated and which partitions are not duplicated, thereby simplifying the software application design. These technical advantages provide one or more technological improvements over prior art approaches.

So that the manner in which the above recited features of the various embodiments can be understood in detail, a more particular description of the inventive concepts, briefly summarized above, may be had by reference to various embodiments, some of which are illustrated in the appended drawings. It is to be noted, however, that the appended drawings illustrate only typical embodiments of the inventive concepts and are therefore not to be considered limiting of scope in any way, and that there are other equally effective embodiments.

In the following description, numerous specific details are set forth to provide a more thorough understanding of the various embodiments. However, it will be apparent to one skilled in the art that the inventive concepts may be practiced without one or more of these specific details.

<FIG> is a block diagram of a computing system <NUM> configured to implement one or more aspects of the various embodiments. As shown, computing system <NUM> includes, without limitation, computing device <NUM> and input/output (I/O) device(s) <NUM>. Computing device <NUM> includes, without limitation, one or more processing units <NUM>, I/O device interface <NUM>, network interface <NUM>, interconnect (bus) <NUM>, storage <NUM>, and memory <NUM>. Memory <NUM> stores database(s) <NUM>, software application <NUM>, and partition management application <NUM>. Processing unit(s) <NUM>, I/O device interface <NUM>, network interface <NUM>, storage <NUM>, and memory <NUM> can be communicatively coupled to each other via interconnect <NUM>.

Computing device <NUM> can include processing unit(s) <NUM> and memory <NUM>. Computing device <NUM> can be a system-on-a-chip (SoC). In various embodiments, computing device <NUM> can be a head unit included in a vehicle system. In some embodiments, computing device <NUM>, or computing system <NUM> overall, can be an aftermarket system or device added to a vehicle. Generally, computing device <NUM> can be configured to coordinate the overall operation of computing system <NUM>. The embodiments disclosed herein contemplate any technically feasible system configured to implement the functionality of computing system <NUM> via computing device <NUM>. Various examples of computing device <NUM> include wearable devices (e.g., helmet, headset, glasses, etc.), vehicle computing devices (e.g., head units, in-vehicle infotainment systems, driver assistance systems, aftermarket systems), and/or the like. In some embodiments, computing system <NUM> is located in various environments including, without limitation, road vehicle environments (e.g., consumer vehicle, commercial truck, etc.), aerospace and/or aeronautical environments (e.g., airplanes, helicopters, spaceships, etc.), nautical and submarine environments, and/or the like. In some embodiments, computing system <NUM> is part of the implementation of an in-vehicle infotainment (IVI) system, a head unit, an engine control unit (ECU), and/or the like.

Processing unit(s) <NUM> can include any technically feasible form of processing device configured to process data and execute program code. In some examples, processing unit(s) <NUM> can include a central processing unit (CPU), a digital signal processing unit (DSP), a microprocessor, an application-specific integrated circuit (ASIC), a neural processing unit (NPU), a graphics processing unit (GPU), a field-programmable gate array (FPGA), and/or the like. Each processing unit <NUM> generally comprises a programmable processor that executes program instructions to manipulate input data. In some embodiments, processing unit(s) <NUM> can include any number of processing cores, memories, and/or other modules for facilitating program execution. In operation, processing unit(s) <NUM> can be a primary processor of computing device <NUM>, controlling and coordinating operations of other system components.

Storage <NUM> can include non-volatile storage for applications, software modules, and data, and can include fixed or removable disk drives, flash memory devices, and CD-ROM, DVD-ROM, Blu-Ray, HD-DVD, or other magnetic, optical, solid state storage devices, and/or the like. For example, software application <NUM>, and partition management application <NUM>, and database(s) <NUM> could be stored in storage <NUM>, and then loaded into memory <NUM> as needed.

Memory <NUM> can include a memory module or collection of memory modules. Memory <NUM> generally comprises storage chips such as random-access memory (RAM) chips that store application programs and data for processing by processing unit <NUM>. Processing unit(s) <NUM>, I/O device interface <NUM>, and network interface <NUM> can be configured to read data from and write data to memory <NUM>. Software application <NUM> and partition management application <NUM> can be loaded from storage <NUM> into memory <NUM>. While in memory <NUM>, software application <NUM> and partition management application <NUM> can be executed by processing unit(s) <NUM> to implement the functionality described according to the various embodiments in the present disclosure.

I/O device(s) <NUM> can include devices capable of receiving input (not shown) (e.g., a keyboard, a mouse, a touch-sensitive screen, pushbuttons, rotary knobs, a microphone, etc.) for providing input data to computing device <NUM>. I/O device(s) <NUM> can include devices capable of providing output (e.g., a display screen, one or more speakers, haptic devices, touchless haptic devices, and/or the like. One or more of I/O devices <NUM> can be incorporated in computing device <NUM> or can be external to computing device <NUM>. I/O devices <NUM> can interface with computing device <NUM> via I/O devices interface <NUM>. In some embodiments, computing device <NUM> and/or one or more I/O device(s) <NUM> can be components of a head unit implemented in a vehicle. In some embodiments, software application <NUM> and partition management application <NUM> can obtain information from one or more systems and/or subsystems of the vehicle (e.g., navigation system, infotainment system, driver assistance system) and display that information via computing system <NUM>. More generally, computing system <NUM> (e.g., computing device <NUM>) can interface with other systems of the vehicle to acquire information for display.

A network (not shown) can enable communications between computing device <NUM> and other devices in network via wired and/or wireless communications protocols, satellite networks, telephone networks, V2X networks, including Bluetooth, Bluetooth low energy (BLE), wireless local area network (WiFi), cellular protocols, and/or near-field communications (NFC). The network can be any technically feasible type of communications network that allows data to be exchanged between computing device <NUM> and remote systems or devices, such as a server, a cloud computing system, cloud-based storage, or other networked computing device or system. For example, the network could include a wide area network (WAN), a local area network (LAN), a wireless network (e.g., a Wi-Fi network, a cellular data network), and/or the Internet, among others. Computing device <NUM> can connect with a network via network interface <NUM>. In some embodiments, network interface <NUM> is hardware, software, or a combination of hardware and software, which is configured to connect to and interface with one or more networks.

In operation, partition management application <NUM> executing on computing device <NUM> emulates redundancy from non-critical partitions of software application <NUM> that use dynamic partitioning. Partition management application <NUM> emulates this redundancy by maintaining multiple partition tables with entries for a set of partitions, also referred to herein as memory partitions. The entries in the partition table reference the memory extents allocated to software application <NUM>. Each partition table is stored in a memory region referred to as a slot. Software application <NUM> accesses the partitions via these partition tables without being aware of which partitions actually have redundant copies and which partitions do not. Instead, software application <NUM> accesses all partitions through one of the partition tables, thereby simplifying overall system design.

As an example, a dynamic partition in a Linux Kernel associated with software application <NUM> can maintain metadata structures in the form of partition tables that specify which memory regions, also referred to as extents, are reserved for which corresponding logical partitions. Partition management application <NUM> can maintain multiple partition tables for software application <NUM>, even though only one partition table is active at a time. Corresponding logical partitions from different partition tables can reference the same extent or different extents, in any combination.

In some examples, partition management application <NUM> can maintain two partition tables for software application <NUM>, where each partition table includes the same partitions, and corresponding partitions in the two partition tables reference the same extents in memory. Partition management application <NUM> can generate a first partition table in a first slot for a first version of software application <NUM>. Partition management application <NUM> can update the partition name for each partition in the first partition table with a first version identifier, such as "<NUM>," "a," and/or the like. Partition management application <NUM> can store instructions and/or data for the different partitions in the blocks of memory referenced in the extents included in the partitions of the first partition table. Such blocks of memory are referred to herein as data blocks or, more simply, blocks. Partition management application <NUM> can copy the first partition table in the first slot to the second slot. Partition management application <NUM> can update the partition name for each partition in the second partition table with an updated version identifier, such as "<NUM>," "b," and/or the like.

During a software update of software application <NUM>, partition management application <NUM> generates partitions for the updated version of software application <NUM> in a non-active partition table, such as the second partition table described above. Partition management application <NUM> updates the second partition table to include the partitions associated with the updated version of software application <NUM>. Partition management application <NUM> can update the partition name for each updated partition and/or newly added partition in the second partition table with an updated version identifier, such as "<NUM>," "b," and/or the like. Partition management application <NUM> performs the software update process by storing instructions and/or data for the updated partitions and/or new partitions in the blocks of memory referenced in the extents included in the partitions of the second partition table.

During the software update process, computing device <NUM> continues to execute the current version of the software application via a first partition table (i.e., the currently active partition table) while the software update creates a second partition table (i.e., the software update partition table). The software update process completes successfully if computing device <NUM> can boot using data associated with the updated version of software application <NUM>, as referenced by the second partition table. Partition management application <NUM> copies the metadata area in the second partition table into the first partition table. Partition management application <NUM> can update the partition name for each partition in the first partition table with the previous version identifier, such as "<NUM>," "a," and/or the like. The end result is that both the first partition table and the second partition table have logical partitions associated with the updated software version and sharing the same extents in memory <NUM>. Therefore, each partition has only a single copy for corresponding extents in memory <NUM>. The higher-level logic of software application <NUM> accesses the partition tables as if all partitions are redundant. However, because the partitions within each partition table share the same extents in memory <NUM>, the total memory allocation is reduced relative to conventional techniques.

<FIG> illustrates a first slot <NUM> for accessing partitions associated with a software application <NUM> executed by the computing device <NUM> of <FIG>, according to various embodiments. The second slot <NUM> is shown as unused. Each entry in a partition table includes a name for a partition and a list of memory regions, or extents, where the data for the partition is stored. The extents are stored as one or more blocks in memory <NUM>. Memory <NUM> can be organized into fixed sized blocks, and each block can be referred to by a block number. In some examples, the block number is the starting address of the block. As shown, each extent specifies a multiple of <NUM> memory addresses, and each extent spans an integer number of blocks. Further, each block spans <NUM> memory addresses. Therefore, block number <NUM> includes an address range of <NUM>-<NUM>, block number <NUM> includes an address range of <NUM>-<NUM>, block number <NUM> includes an address range of <NUM>-<NUM>, and so on. Memory <NUM> can be located in any memory system, such portions of memory <NUM>, and/or the like. At the time that computing system <NUM> is manufactured and/or when the original version of software application <NUM> is provisioned, partition management application <NUM> generates the partition table in the first slot <NUM> and stores instructions and/or data for software application <NUM> in the corresponding blocks in memory <NUM>.

As shown, partition management application <NUM> generates a partition table and stores the partition table in the first slot <NUM>. The partition table includes three entries <NUM>, <NUM>, and <NUM> for three partitions included in software application <NUM>. Entry <NUM> refers to instance <NUM> of partition A, denoted as A_1, entry <NUM> refers to instance <NUM> of partition B, denoted as B_1, and entry <NUM> refers to instance <NUM> of partition C, denoted as C_1. Entry <NUM> indicates that partition A_1 includes an extent with an address range of <NUM>-<NUM>. Correspondingly, partition management application <NUM> stores instructions and/or data for this extent in block <NUM> with a block number <NUM> of <NUM> and with a block name <NUM> of A. Entry <NUM> indicates that partition B_1 includes an extent with an address range of <NUM>-<NUM>. Correspondingly, partition management application <NUM> stores instructions and/or data for this extent in block <NUM> with a block number <NUM> of <NUM> and with a block name <NUM> of B. Entry <NUM> indicates that partition C_1 includes an extent with an address range of <NUM>-<NUM>. Correspondingly, partition management application <NUM> stores instructions and/or data for this extent in block <NUM> with a block number <NUM> of <NUM> and with a block name <NUM> of C. Blocks <NUM>, <NUM>, <NUM>, <NUM>, and <NUM> are unused.

<FIG> illustrates generating a first slot <NUM> and a second slot <NUM> for the software application <NUM> using non-redundant partitions, according to various embodiments. As described herein, partition management application <NUM> generates and stores partition metadata for different instances of software application <NUM> in different respective partition tables stored in different slots. At the time that computing system <NUM> is manufactured and/or when the original version of software application <NUM> is provisioned, two instances of software application <NUM> can be installed in computing device <NUM>. Computing device <NUM> can switch between the two instances of software application. Therefore, if one instance of software application <NUM> becomes corrupted and can no longer execute, computing device <NUM> can switch to the other instance and continue to execute software application <NUM>. Software application <NUM> can include two types of partitions: critical partitions and non-critical partitions. Critical partitions are those partitions that are stored at multiple locations in memory. Critical partitions include instructions and/or data that are critical to the functioning of software application <NUM>, data that cannot be rebuilt or recomputed by software application <NUM>, and/or the like. Non-critical partitions are those partitions that are stored at one location in memory. Non-critical partitions include instructions and/or data that are not critical to the functioning of software application <NUM>, data that can be rebuilt or recomputed by software application <NUM>, and/or the like. The techniques described herein provides actual redundancy for critical partitions and apparent redundancy for non-critical partitions. Consequently, each entry in the partition table of the first slot <NUM> has a corresponding entry in in the partition table of the second slot <NUM>. Each of these corresponding partition pairs shares the same extent mapping and share the same partition names. This technique allows a computing system to switch between the first slot <NUM> and the second slot <NUM>, such as when memory corruption occurs in one or more critical partitions that are maintained through actual redundant partition sets. The multiple slots <NUM> and <NUM> provide access to non-critical partitions via multiple partition tables, where each partition table is accessed by a different instance of software application <NUM>. By providing access to non-critical partition via different partition tables, software application <NUM> does not need to be aware of which partitions are actually redundant versus which partitions are apparently redundant.

As shown, partition management application <NUM> generates a partition table and stores the partition table in the first slot <NUM>. The partition table includes three entries <NUM>, <NUM>, and <NUM> for three partitions included in software application <NUM>. Entry <NUM> refers to instance <NUM> of partition A, denoted as A_1, entry <NUM> refers to instance <NUM> of partition B, denoted as B_1, and entry <NUM> refers to instance <NUM> of partition C, denoted as C_1. Entry <NUM> indicates that partition A_1 includes a first extent with an address range of <NUM>-<NUM>. Correspondingly, partition management application <NUM> stores instructions and/or data in block <NUM> of memory <NUM> with a block number <NUM> of <NUM> and with a block name <NUM> of A. Entry <NUM> indicates that partition B_1 includes a first extent with an address range of <NUM>-<NUM>. Correspondingly, partition management application <NUM> stores instructions and/or data in block <NUM> of memory <NUM> with a block number <NUM> of <NUM> and with a block name <NUM> of B. Entry <NUM> indicates that partition C_1 includes a first extent with an address range of <NUM>-<NUM>. Correspondingly, partition management application <NUM> stores instructions and/or data in block <NUM> of memory <NUM> with a block number <NUM> of <NUM> and with a block name <NUM> of C.

Partition management application <NUM> also generates a partition table and stores the partition table in the second slot <NUM>. The partition table includes three entries <NUM>, <NUM>, and <NUM> for the three partitions included in software application <NUM>. The partitions of the second slot <NUM> reference the same partitions as the first slot <NUM>. Entry <NUM> indicates that partition A_2 includes an extent with an address range of <NUM>-<NUM>, where partition management application <NUM> stores instructions and/or data for this extent in block <NUM> of memory <NUM>. Entry <NUM> indicates that partition B_2 includes an extent with an address range of <NUM>-<NUM>, where partition management application <NUM> stores instructions and/or data for this extent in block <NUM> of memory <NUM>. Entry <NUM> indicates that partition C_2 includes an extent with an address range of <NUM>-<NUM>, where partition management application <NUM> stores instructions and/or data for this extent in block <NUM> of memory <NUM>. Blocks <NUM>, <NUM>, <NUM>, <NUM>, and <NUM> are unused.

With this configuration, software application <NUM> is able to boot using data from either the first slot <NUM> or the second slot <NUM>. This configuration provides apparent redundancy to software application <NUM>, without requiring software application <NUM> to be aware of which partitions are actually redundant versus which partitions are apparently redundant.

<FIG> illustrates modifying the second slot <NUM> for updating the software application <NUM> using a combination of redundant and non-redundant partitions, according to various embodiments. Partition management application <NUM> can receive an update of software application <NUM> from database(s) <NUM>, from storage <NUM>, over a network via network interface <NUM>, and/or the like. During the software update, software application <NUM> continues to access the current version of software application <NUM> via the first slot <NUM>. The first slot <NUM> has three partitions. Entry <NUM> indicates that partition A_1 includes an extent with an address range of <NUM>-<NUM>, where partition management application <NUM> stores instructions and/or data for this extent in block <NUM> of memory <NUM>. Entry <NUM> indicates that partition B_1 includes an extent with an address range of <NUM>-<NUM>, where partition management application <NUM> stores instructions and/or data for this extent in block <NUM> of memory <NUM>. Entry <NUM> indicates that partition C_1 includes an extent with an address range of <NUM>-<NUM>, where partition management application <NUM> stores instructions and/or data for this extent in block <NUM> of memory <NUM>.

Partition management application <NUM> generates a partition table in the second slot <NUM> for the software update of software application <NUM>. If software application <NUM> is employing non-redundant (apparently redundant) partitions, then partition management application <NUM> allocates additional extents for partitions included in the software update of software application <NUM> that are being modified by the software update. Partition management application <NUM> does not allocate additional extents for partitions included in the software update of software application <NUM> that are not being modified by the software update.

As shown, the software update of software application <NUM> includes the same three partitions as the current version of software application <NUM>. The software update of software application <NUM> includes an enlarged partition A that consumes two non-contiguous extents, whereas partition A of the current version consumes one contiguous extent. The software update of software application does not include any changes to partitions B and C. Partition management application <NUM> provides temporary redundancy for partition A so that the current version of software application <NUM> can be recovered and rebooted in the case that the software update fails and computing device <NUM> cannot boot the software update of software application <NUM>. Therefore, partition management application <NUM> generates partitions for extents included in partition A of the software update of software application <NUM>. Because partitions B and C are not being modified by the software update, partition management application <NUM> provides apparent redundancy, rather than actual redundancy, for partitions B and C.

In that regard, partition management application <NUM> generates a partition table and stores the partition table in the second slot <NUM>, where the partition table includes three entries <NUM>, <NUM>, and <NUM> for three partitions included in the software update of software application <NUM>. Entry <NUM> refers to the software update of partition A, denoted as A_2, entry <NUM> refers to the software update of partition B, denoted as B_2, and entry <NUM> refers to the software update of partition C, denoted as C_2. Entry <NUM> indicates that partition A_2 includes a first extent with an address range of <NUM>-<NUM> and a second extent with an address range of <NUM>-<NUM>. Correspondingly, partition management application <NUM> stores instructions and/or data in block <NUM> of memory <NUM> with a block number <NUM> of <NUM>, in block <NUM> of memory <NUM> with a block number <NUM> of <NUM>, and in block <NUM> of memory <NUM> with a block number <NUM> of <NUM>. Blocks <NUM>, <NUM> and <NUM> have a block name <NUM> of A.

Entry <NUM> indicates that partition B_2 includes an extent with an address range of <NUM>-<NUM>, which is the same address range as for partition B_1. Correspondingly, partition management application <NUM> stores instructions and/or data in block <NUM> of memory <NUM> with a block number <NUM> of <NUM> and with a block name <NUM> of B. Entry <NUM> indicates that partition C_2 includes a first extent with an address range of <NUM>-<NUM>, which is the same address range as for partition C_1. Correspondingly, partition management application <NUM> stores instructions and/or data in block <NUM> of memory <NUM> with a block number <NUM> of <NUM> and with a block name <NUM> of C. Blocks <NUM>, <NUM>, and <NUM> are unused. With apparent redundancy, corresponding partitions in the first slot <NUM> and the second slot <NUM> can share the same blocks in memory <NUM>, thereby reducing the storage requirements to store the current version and the software update of software application <NUM>, relative to approaches that use full redundancy.

After the software update completes, computing device <NUM> determines whether the software update of software application <NUM> can successfully boot using data from the second slot <NUM>. If the software update of software application <NUM> is unable to successfully boot from the second slot <NUM>, then software application <NUM> continues to execute from the first slot <NUM>. Further, partition management application <NUM> copies the first slot <NUM> to the second slot <NUM>, thereby reverting to the configuration shown in <FIG>. If, however, the software update of software application <NUM> is able to successfully boot using data from the second slot <NUM>, then partition management application <NUM> copies the partition table from the second slot <NUM> into the first slot <NUM>.

<FIG> illustrates copying the second slot <NUM> to the first slot <NUM> after completion of updating the software application <NUM>, according to various embodiments. As described herein, if the software update of software application <NUM> is able to successfully boot using data from the second slot <NUM>, then partition management application <NUM> copies the partition table from the second slot <NUM> into the first slot <NUM>. After copying the partition table from the second slot <NUM> into the first slot <NUM>, both the partitions of the first slot <NUM> and the partitions of the second slot <NUM> access the same blocks in memory <NUM>.

In that regard, entry <NUM> in the first slot <NUM> indicates that partition A_1 includes a first extent with an address range of <NUM>-<NUM> and a second extent with an address range of <NUM>-<NUM>. Entry <NUM> in the second slot <NUM> indicates that partition A_2 also includes a first extent with an address range of <NUM>-<NUM> and a second extent with an address range of <NUM>-<NUM>. Correspondingly, partition management application <NUM> stores instructions and/or data for entries <NUM> and <NUM> in block <NUM> in memory <NUM> with a block number of <NUM>, in block <NUM> in memory <NUM> with a block number <NUM> of <NUM>, and in block <NUM> in memory with a block number <NUM> of <NUM>. Blocks <NUM>, <NUM> and <NUM> have a block name <NUM> of A.

Entry <NUM> in the first slot <NUM> indicates that partition B_1 includes an extent with an address range of <NUM>-<NUM>. Entry <NUM> in the second slot <NUM> indicates that partition B_2 also includes an extent with an address range of <NUM>-<NUM>. Correspondingly, partition management application <NUM> stores instructions and/or data for entries <NUM> and <NUM> in block <NUM> in memory <NUM> with a block number <NUM> of <NUM> and with a block name <NUM> of B. Entry <NUM> in the first slot <NUM> indicates that partition C_1 includes an extent with an address range of <NUM>-<NUM>. Entry <NUM> in the second slot <NUM> indicates that partition C_2 also includes an extent with an address range of <NUM>-<NUM>. Correspondingly, partition management application <NUM> stores instructions and/or data for entries <NUM> and <NUM> in block <NUM> of memory <NUM> with a block number <NUM> of <NUM> and with a block name <NUM> of C. Blocks <NUM>, <NUM>, and <NUM> are unused. After copying the partition table from the second slot <NUM> to the first slot <NUM>, the configuration for the software update of software application <NUM>, as shown in <FIG>, is similar to the configuration for the current version of software application <NUM>, as shown in <FIG>.

To summarize, as shown in <FIG>, prior to the software update process, software application <NUM> can access partitions A, B, and C for the current version of software application <NUM> via either the first slot <NUM> or the second slot <NUM>. Although software application <NUM> can access the partitions via either of the two slots, the partitions include extents that reference the same blocks in memory <NUM>. Therefore, partitions A, B, and C are apparently redundant to software application <NUM>, but partitions A, B, and C are not replicated in memory <NUM>. During the software update process, as shown in <FIG>, software application <NUM> can access partition A for the current version of software application <NUM> via the first slot <NUM> and access partition A for the updated version of software application <NUM> via the second slot <NUM>. Partition A for the current version of software application <NUM> includes extents that reference different blocks in memory <NUM> than the extents include in the updated version of software application <NUM>. Partitions B and C in the first slot <NUM> and the second slot <NUM> continue to include extents that reference the same blocks in memory <NUM>. After the software update process, as shown in <FIG>, software application <NUM> can access shared partitions A, B, and C for the updated version of software application <NUM> via either the first slot <NUM> or the second slot <NUM>. Although software application <NUM> can access the partitions via either of the two slots, the partitions include extents that reference the same blocks in memory <NUM>. Therefore, partitions A, B, and C are apparently redundant to software application <NUM>, but partitions A, B, and C are not replicated in memory <NUM>.

It will be appreciated that the system shown herein is illustrative and that variations and modifications are possible. The system disclosed herein is illustrated and described as having blocks that span <NUM> memory addresses and are addressed by a block number comprising the start address of the block. However, the techniques can accommodate blocks of any size and using any block numbering and/or identifying techniques within the scope of the present disclosure. Further, the system disclosed herein is illustrated and described as having partition tables with certain numbers of partitions that include extents of certain sizes. However, the techniques can accommodate partition tables with any number of partitions, and the partitions can include extents of any size within the scope of the present disclosure. The partitions can be listed in the partition table in any order. In addition, the system disclosed herein is illustrated and described as having two slots, where each slot includes one partition table. However, the techniques can accommodate any number of slots and any number of partition tables within the scope of the present disclosure.

<FIG> set forth a flow diagram of method steps for managing memory partitions in the computing system <NUM> of <FIG>, according to various embodiments. Although the method steps are described with respect to the systems and embodiments of <FIG>, persons skilled in the art will understand that any system configured to perform the method steps, in any order, falls within the scope of the various embodiments.

As shown, a method <NUM> begins at step <NUM>, where a partition management application <NUM> executing on one or more processors generates a first partition table associated with a first version of a software application <NUM>. Partition management application <NUM> stores the first partition table for a current version of software application <NUM> in a memory region referred to as a slot. Each entry of the first partition table refers to a memory partition, where a memory partition includes one or more extents. Each extent identifies a memory region of one or more blocks where partition management application <NUM> stores instructions and/or data associated with the first version of the software application <NUM>. The extents included in a particular partition may be contiguous or not contiguous. Partition management application <NUM> updates the partition name for each partition in the first partition table with an identifier, such as "<NUM>," "a," and/or the like. The first version of the software application <NUM> accesses the extents via the first partition table. For example, <FIG> illustrates a first slot <NUM> after partition management application generates the first partition table in the first slot <NUM>.

At step <NUM>, partition management application <NUM> stores instructions and/or data for the extents included in the first partition table. Partition management application <NUM> can store instructions and/or data for the different partitions in the blocks of memory referenced by the extents included in the partitions of the first partition table. After storing the instructions and/or data for the extents, the current version of software application <NUM> can access the stored instructions and/or data via the partition table stored in the first slot.

At step <NUM>, partition management application <NUM> copies the partitions included in the entries in the first partition table into a second partition table in a second slot. Partition management application <NUM> can update the partition name for each partition in the second partition table with an identifier, such as "<NUM>," "b," and/or the like. For example, <FIG> illustrates a first slot <NUM> and a second slot <NUM> after partition management application <NUM> copies the first partition table in the first slot <NUM> to the second slot <NUM> and updates the partition name for each partition in the second partition table. As a result, entry <NUM>, <NUM>, and <NUM> include partitions A_1, B_1, and C_1, where partitions A_1, B_1, and C_1 include extents that reference blocks <NUM>, <NUM> and <NUM>, respectively. Similarly, entries <NUM>, <NUM> and <NUM> include partitions A_2, B_2, and C_2, where partitions A_2, B_2, and C_2 include extents that also reference blocks <NUM>, <NUM> and <NUM>, respectively.

At step <NUM>, partition management application <NUM> determines that a software update process to a second version of the software application <NUM> is in progress. The one or more processors execute the software update process to upgrade the software application <NUM> from the first (current) version to a second (updated) version. Like the first version, the second version of the software application <NUM> includes a number of partitions, where each partition references one or more extents. The second version of the software application <NUM> can include extents that are shared with from corresponding extents in the first version. Additionally or alternatively, the second version of the software application <NUM> can include extents that are not shared with corresponding extents in the first version. Additionally or alternatively, the second version of the software application <NUM> can include new extents that are not in the first version and/or can be missing certain extents that are in the first version. Likewise, a partition can reference extents that are shared, not shared, new, or missing with respect to the extents of the first version, in any combination.

At step <NUM>, partition management application <NUM> updates the second partition table to include the partitions associated with the second version of software application <NUM>. Partition management application <NUM> updates the partition name for each updated partition and/or newly added partition in the second partition table with an updated version identifier, such as "<NUM>," "b," and/or the like. For example, <FIG> illustrates a first slot <NUM> and a second slot <NUM> after partition management application <NUM> updates the second partition table to include the partitions associated with the second version of software application <NUM>. As a result, entry <NUM> includes partitions A_2 which, in turn, includes two extents. A first extent references block <NUM>. A second extent references blocks <NUM> and <NUM>. Entries <NUM>, <NUM>, <NUM>, <NUM>, and <NUM> remain unchanged from the corresponding entries in the partition tables of <FIG>.

At step <NUM>, partition management application <NUM> stores instructions and/or data for the partitions associated with the second version of software application <NUM>. Partition management application <NUM> stores instructions and/or data for the updated partitions and/or new partitions in the blocks of memory referenced in the extents included in the partitions of the second partition table.

At step <NUM>, partition management application <NUM> determines whether the software update process completed successfully. The software update process completed successfully if the extents associated with the second version of the software application <NUM> are stored in memory, the second partition table is stored in the second slot, and the one or more processors can successfully boot the second version of the software application <NUM> via the second slot.

If the update process completed successfully, then the method <NUM> proceeds to step <NUM>, where partition management application <NUM> copies the partitions included in the entries in the second partition table into the first partition table. Partition management application <NUM> can update the partition name for each partition in the first partition table with the previous version identifier, such as "<NUM>," "a," and/or the like. For example, <FIG> illustrates a first slot <NUM> and a second slot <NUM> after partition management application <NUM> copies the second partition table in the second slot <NUM> to the first slot <NUM> and updates the partition name for each partition in the first partition table. As a result, entry <NUM> includes partition A_2, where partition A_2 includes two extents, a first extent that references block <NUM> and a second extent that references blocks <NUM> and <NUM>. Entries <NUM> and <NUM> include partitions B_2 and C_2, where partitions B_2 and C_2 include extents that reference blocks <NUM> and <NUM>, respectively. Similarly, entry <NUM> includes partition A_1, where partition A_1 also includes two extents, a first extent that references block <NUM> and a second extent that references blocks <NUM> and <NUM>. Entries <NUM> and <NUM> include partitions B_1 and C_1, where partitions B_1 and C_1 include extents that also reference blocks <NUM> and <NUM>, respectively.

At step <NUM>, partition management application <NUM> accesses the second instances of the memory partitions associated with the second version of the software application <NUM> via the second partition table. When executing the second version of the software application <NUM>, the software application <NUM> accesses the extents of the second version via the second partition table. Additionally or alternatively, the software application <NUM> can access the first instances of the memory partitions associated with the second version of the software application <NUM> via the first partition table. In some examples, prior to copying the entries in the second partition table into the entries in the first partition table, as in step <NUM>, partition management application <NUM> can access the partitions associated with the second version of the software application <NUM> via the second partition table. After copying the entries in the second partition table into the entries in the first partition table, partition management application <NUM> can access the memory partitions associated with the second version of the software application via the first instances of the partitions included in the first partition table or via the second instances of the partitions included in the second partition table. The method <NUM> then terminates.

Returning to step <NUM>, if the update process did not complete successfully, then the method <NUM> proceeds to step <NUM>, where partition management application <NUM> copies the partitions included in the entries in the first partition table into a second partition table in the second slot, as described in conjunction with step <NUM>. At step <NUM>, partition management application <NUM> continues to access the first instances of the partitions associated with the first version of the software application via the first partition table. Additionally or alternatively, after copying the entries in the first partition table into the entries in the second partition table, partition management application <NUM> can access the second instances of the partitions via the second partition table. The method <NUM> then terminates.

In sum, an embedded electronics system emulates redundancy from non-critical partitions of a software application that use dynamic partitioning. The system emulates this redundancy by maintaining multiple partition tables that reference the memory extents allocated to software application. The software application accesses the partitions via these partition tables without being aware of which partitions actually have redundant copies and which partitions do not. Instead, the software application accesses all partitions through one of the partition tables, thereby simplifying overall system design.

During a software update, the system generates partitions for the updated software application in a non-active partition table. The system executes the current version of the software application via a first partition table (i.e., the currently active partition table) while the software update occurs via a second partition table (i.e., the software update partition table). Once the software update process completes successfully, and the system can boot from the updated software application, the system duplicates the metadata area in the second partition table into the first partition table. The end result is that both the first partition table and the second partition table have logical partitions sharing the same extents in memory. Therefore, each partition has only a single copy for corresponding extents in memory. The higher software application logic accesses the partition tables as if all partitions are redundant. However, because the partitions within each partition table share the same extents in memory, the total memory allocation is reduced.

As a result, the two partition tables have identical mapping allowing switching between partition tables. After a successful software update, the partition table from the second slot, which refers to the second version of the software application, is copied to first slot. Therefore, the second version of the software application can be accessed irrespective of which slot is active. After an unsuccessful software update, the partition table from the first slot, which refers to the first version of the software application, is copied to second slot. Therefore, the first version of the software application can be accessed irrespective of which slot is active.

Aspects of the present embodiments may be embodied as a system, method, or computer program product. Accordingly, aspects of the present disclosure may take the form of an entirely hardware embodiment, an entirely software embodiment (including firmware, resident software, micro-code, etc.) or an embodiment combining software and hardware aspects that may all generally be referred to herein as a "module" or "system. " Furthermore, aspects of the present disclosure may take the form of a computer program product embodied in one or more computer readable medium(s) having computer readable program code embodied thereon.

These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, enable the implementation of the functions/acts specified in the flowchart and/or block diagram block or blocks. Such processors may be, without limitation, general purpose processors, special-purpose processors, application-specific processors, or field-programmable processors or gate arrays.

The flowchart and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present disclosure.

Claim 1:
A computer-implemented method for managing memory partitions in a computing system comprising:
generating a first entry (<NUM>, <NUM>, <NUM>) for a first partition table (<NUM>) associated with a first instance of a software application (<NUM>), wherein the first entry is associated with a first memory partition (A_1, A_2) that includes a first memory extent (<NUM>-<NUM>);
determining that a first data block referenced by the first memory partition is shared with a second instance of the software application; and
generating a second entry for a second partition table (<NUM>) associated with a second instance of the software application, wherein the second entry is associated with the first memory partition that includes the first memory extent.