Unified package for embedded systems

Abstract

Methods, apparatus, and systems that relate to a unified approach for packaging, installing / updating, and loading of system images onto an embedded system regardless of different partition types. In one example aspect, a method for installing or updating at least one of a firmware or an operating system on an embedded system includes accessing a package that comprises information for the at least one of the firmware or the operating system. The structure of the package remains same across multiple partition types for installing or updating the at least one of the firmware or the operating system. The method includes receiving an indication of a partition type selected from the multiple partition types and installing at least part of the information in the package to a non-transitory memory of the embedded system according to the selected partition type.

Description

UNIFIED PACKAGE FOR EMBEDDED SYSTEMSTECHNICAL FIELD

[0001] This patent document is directed to packaging, installing / updating, and loading system images on embedded systems.BACKGROUND

[0002] An embedded system is a computer system having a combination of a computer processor, computer memory, and input / output peripheral devices that has a dedicated function within a larger system. Embedded systems are commonly found in consumer, industrial, automotive, home appliances, medical, telecommunication, commercial, aerospace, and military applications.SUMMARY

[0003] This patent document describes, among other things, techniques related to a unified approach for packaging, installing / updating, and loading of system images (e.g., firmware and / or an operating system) suitable for different partition types onto an embedded system.

[0004] In one example aspect, a method for installing or updating at least one of a firmware or an operating system on an embedded system is disclosed. The method includes accessing a package that comprises information for the at least one of the firmware or the operating system. The structure of the package remains same across multiple partition types for installing or updating the at least one of the firmware or the operating system. The method includes receiving an indication of a partition type selected from the multiple partition types and installing at least part of the information in the package to a non-transitory memory of the embedded system according to the selected partition type.

[0005] In yet another example aspect, a non-transitory, computer-readable storage medium as a package for installing or updating at least one of a firmware or an operating system on an embedded system is disclosed. The package includes partition information that corresponds to multiple partition types for installing or updating the at least one of the firmware or the operating system. The non-transitory, computer-readable storage medium also includes one or more image files that correspond to the at least one of the firmware or the operating system. The structure of  the package remains same across the multiple partition types.

[0006] In another example aspect, a device is disclosed. The device includes one or more processors and a non-transitory memory that comprises instructions recorded thereon. The instructions, when executed by the one or more processors, cause the one or more processors to determine a partition structure of one or more images based on a partition table stored in the non-transitory memory, determine a partition type based on the partition structure of the one or more images, and load the firmware or the operating system based on the partition type. The one or more images correspond to a firmware or an operating system installed on the device.

[0007] These, and other, aspects are described in the present document.BRIEF DESCRIPTION OF DRAWINGS

[0008] FIG. 1 is a block diagram of an example architecture of a microprocessor.

[0009] FIG. 2A illustrates an example non-A / B partition type in which a single copy of each partition exists in a system.

[0010] FIG. 2B illustrates an example A / B partition type in which two copies of each partition exist in a system.

[0011] FIG. 3 illustrates an example Over-The-Air (OTA) update using the A / B partition type.

[0012] FIG. 4 illustrates an example partition of a system image using the virtual A / B partition scheme.

[0013] FIG. 5A illustrates an example structure of a system image package in accordance with one or more embodiments of the present technology.

[0014] FIG. 5B illustrates another example structure of a system image package in accordance with one or more embodiments of the present technology.

[0015] FIG. 6A illustrates an example user interface in accordance with one or more embodiments of the present technology.

[0016] FIG. 6B illustrates another example user interface in accordance with one or more embodiments of the present technology.

[0017] FIG. 7A illustrates an example installing process in accordance with one or more embodiments of the present technology.

[0018] FIG. 7B illustrates another example installing process in accordance with one or more  embodiments of the present technology.

[0019] FIG. 8 is a flowchart representation of a method for installing or updating at least one of a firmware or an operating system on an embedded system in accordance with one or more embodiments of the present technology.DETAILED DESCRIPTION

[0020] Some details below are described with reference to Android systems for ease of understanding, and the described technology may be implemented in different embedded systems that use various types of microprocessors, including microcontrollers and application processors.

[0021] The origins of embedded systems can be traced back to the integrated circuit, which is an integrated circuit chip fabricated from metal-oxide-semiconductor field-effect transistors (MOSFETs) . Modern embedded systems are often based on microprocessors (e.g., application processors and / or microcontrollers) that have integrated memory and peripheral interfaces. FIG. 1 is a block diagram of an example architecture 100 of a microprocessor. The microprocessor includes a processor core 101 with computational logic units such as the arithmetic logic unit (ALU) , internal memory subcomponents such as Read-Only Memory (ROM) 103 and Random-Access Memory (RAM) 105, and Input / Out (I / O) subcomponents 107. The microprocessor can also include a memory management unit (MMU) 109 that handles memory and caching operations. For example, application processors often include MMU (s) to provide support for the demand of a full operating system (OS) .

[0022] Numerous microcontrollers and application processors have been developed for embedded systems to meet various application needs. As with other computer systems, embedded system designers need tools to help developers develop embedded system software, especially when the developers need to design and deploy custom software programs onto the systems. Take mobile devices running on the Android platform as an example. Android is a mobile operating system based on a modified version of the Linux kernel and other open-source software. Android provides tools (e.g., Android Flash Tool, Fastboot, etc. ) that allow developers to install and boot a specific system image to the device for development and testing. A system image can include at least one of the firmware and / or the operating system of the device.

[0023] To support seamless updates of the Android system, Android also uses an A / B system update architecture (also referred to as A / B partition) to ensure a workable booting system  remains on the disk during an Over-The-Air (OTA) update. FIG. 2A illustrates an example non-A / B partition type in which a single copy of each partition (e.g., boot, etc. ) exists in the system. FIG. 2B illustrates an example A / B partition type in which two copies (referred to as A slot and B slot) of each partition (e.g., boot_a, boot_b) exist in the system. FIG. 3 illustrates an example OTA update using the A / B partition type. As shown in FIG. 3, partition A was active before the update. The update was applied to the mirror copy of the system-partition B-such that the system can seamlessly function by switching the active partition to partition B after the update.

[0024] The A / B partition brings benefits for regular users but can make custom modifications to system images more difficult to deploy and load. Storage usage of A / B partition also becomes a concern. To reduce code complexity and enhance the update process, Android also uses a virtual A / B partition type to bring seamless updates to devices with a lower cost of storage. However, devices that use virtual A / B must be configured as an A / B device and must launch with dynamic partitions using a super partition. FIG. 4 illustrates an example partition of the system image using virtual A / B partition scheme. As shown in FIG. 4, certain partitions (e.g., system_a / b, vendor_a / b) can be dynamically allotted in a partition called super (the super partition) . Android has shown that the use of virtual A / B partition can reduce the factory image from 9GB super to 4.5GB super (with an additional 3.8GB usage during OTA) .

[0025] Given the fast pace of Android development, coexistence of virtual A / B partition, A / B partition, and non-A / B partition schemes will soon disappear as newer Android devices (e.g., Android 11 or later) are mandated to support A / B partition. However, for other embedded systems with custom changes (either at the hardware level using custom microprocessors or at the software level using custom firmware changes) , various partition types will continue to coexist due to the benefits of A / B partition (e.g., ease of OTA for users) and the difficulty in backward compatibility. Furthermore, additional partition types for different types of use scenarios may emerge in the future.

[0026] Currently, whether a system image should be generated, installed, and loaded as A / B partition, non-A / B partition, or virtual A / B partition is determined prior to the compilation of the system image. The partition type is predetermined and “hardcoded” for every step of the compilation, generation, and loading process. Separate loading programs suitable for respective partition types are also needed as different bootloaders. For a system image that needs to be loaded on both A / B type and non-A / B type of systems, two separate system images are created,  and two separate bootloaders are compiled with respective logics. The conventional procedure thus creates redundant and unnecessary work for embedded system providers because various versions of the same system image need to be made available to developers. The conventional procedure also places additional burden on developers as the developers need to download multiple copies of same system image when a partition type change occurs or when multiple partition types are supported. Thus, there exists a need for a unified approach to handle different partition types of a system image, particularly for custom embedded systems.

[0027] This patent document discloses techniques that can be implemented in various embodiments to provide a unified approach for packaging, installing / updating, and loading of system images (e.g., firmware and / or operating system) for different partition types. It is noted that, in this document, the installing and / or updating of the system images is also referred to as flashing.

[0028] To provide a unified approach to handle different partition types of a system image, a unified package (also referred to as a package or a system image package) that includes the image files (e.g., images of firmware and / or the operating system) and partition information suitable for different partition types can be provided to the developers and / or tech-savvy users to flash onto the devices. For example, the developers can download a system image package from a website operated by an embedded system provider. The package corresponds to a particular system image release (e.g., a specific release of the operating system) and can be flashed to different devices, old or new, based on different partition types. FIG. 5A illustrates an example structure of a system image package in accordance with one or more embodiments of the present technology. This example system image package includes several partition files, each including a partition structure corresponding to a respective partition type. Each partition file can also be referred to as a partition table. For example, the partition file can be implemented in the format of a Globally Unique Identifier GUID Partition Table (GPT) . The system image package also includes one or more image files needed for flashing the system. For example, the image files can include boot. img, dtbo. img, system. img, etc. that are needed to flash the system. In FIG. 5A, the partition files are positioned at the beginning of the package. In other embodiments, the partition files can also be positioned in other predefined location (s) in the system image package (e.g., at the end of the system image package) . In some embodiments, as shown in FIG. 5A, the system image package further includes a custom bootloader that is capable of loading the flashed  system image on devices configured with different partition types.

[0029] FIG. 5B illustrates another example structure of a system image package in accordance with one or more embodiments of the present technology. In this example, the partition information includes different partition structures corresponding to different partition types. The different partition structures are organized as partition information in a same file or a same data block according to the partition types. The partition information can be positioned at the beginning of the system image package, as shown in FIG. 5B, or at other predefined location (s) in the system image package. In some embodiments, as shown in FIG. 5B, the system image package further includes a custom bootloader that is capable of loading the flashed system image on devices configured with different partition types.

[0030] After obtaining the unified package from the embedded system provider, developers can use a specific flashing tool to flash the desired image files included in the package onto the system. In some embodiments, the flashing tool can be a command line tool. For example, a tool similar to fastboot and / or adb on Android can be provided to users to allow a user to turn a device into a ready-to-flash state. Command line options can be provided to allow the user to select a suitable partition type to flash the system. Table 1 shows an example of command line option.

[0031] Table 1: Example Command Line Option

[0032] In some embodiments, instead of specifying a command line option, a configuration file can be provided as an input to the flashing tool. The configuration file can include information regarding the partition type. The configuration file can also include additional configuration information suitable for each package. Table 2 shows an example of command line configuration. In this example, the configuration file partition. cfg can include a configuration field specifying that the partition type is A / B partition.

[0033] Table 2: Example Command Line Configuration

[0034] In some embodiments, the flashing tool can include a user interface. For example,  when a compatible version of the flashing tool already exists on an embedded device, the user can view a simple user interface on the device to select the appropriate partition type for flashing the system image. FIG. 6A illustrates an example user interface in accordance with one or more embodiments of the present technology. The display shows menu options for the user to select the approach partition type (e.g., A / B, non-A / B, or virtual A / B) .

[0035] In some embodiments, the flashing tool is installed on a separate device and is in communication with the embedded device that needs to be flashed. In those cases, a more complex Graphics User Interface (GUI) can be provided to enable easy selection of the partition type. FIG. 6B illustrates another example user interface in accordance with one or more embodiments of the present technology. In some embodiments, the GUI can include UI controls that allow the user to specify a configuration file.

[0036] During the system flashing process, the flashing tool examines the package and identifies the correct partition structure to be used for flashing the image. FIG. 7A illustrates an example flashing process in accordance with one or more embodiments of the present technology. In this particular example, the partition type is set to A / B partition. Information included in the partition file can be organized and stored as the GPT at logical block addressing (LBA) 1, with the protective Master Boot Record (MBR) stored at LBA 0. A redundant and backup copy of the GPT is stored at the final LBA. Based on the A / B partition type, each partition content included in the package needs to be flashed (e.g., decompressed and / or copied) to two copies: A copy (slot A) and B copy (slot B) .

[0037] It is noted that, using the disclosed techniques, a small system image package is needed because the initial mirror copies (A / B slots) of the partitions are identical. As shown in FIG. 7A, during system flashing, boot_a is identical to boot_b, dtbo_a is identical to dtbo_b, and system_a is identical to system_b. Therefore, the package only needs to include a single copy of the partitions yet is still able to create a system that supports A / B partition. The package is thus much smaller as compared to the conventional factory image of an A / B partition system. The package can also be smaller than the conventional factory image of a virtual A / B partition system because no redundant copy is needed for partitions such as boot, dtbo, recovery, etc. (e.g., referring back to FIG. 4) .

[0038] FIG. 7B illustrates another example flashing process in accordance with one or more embodiments of the present technology. In this particular example, the partition type is set to  non-A / B partition. Information included in the partition file can be organized and stored as the GPT at logical block addressing (LBA) 1, with the protective Master Boot Record (MBR) stored at LBA 0. A redundant and backup copy of the GPT is stored at the final LBA. Based on the non-A / B partition type, each partition content included in the package needs to be flashed (e.g., decompressed and / or copied) to a single copy.

[0039] During system flashing, the custom bootloader that is capable of loading the flashed system image for different partition types is stored into a special system partition referred to as Extensible Firmware Interface (EFI) system partition (ESP) based on the Unified EFI (UEFI) interface. After the system flash completes, the custom bootloader can examine, as the first-stage bootloader (also referred to as the secondary program loader, SPL) , the GPT information to determine the partition type of the system-no additional information needs to be stored on the disk to make the partition type determination. For example, the bootloader can check whether a recovery partition exists. In some systems, such as Android, the recovery partition only exists when the partition type is non-A / B partition, thereby allowing the bootloader to ascertain the partition type when it finds the recovery partition. As another example, the bootloader can examine whether both A and B slots exist for one or more partitions. If at least one partition has both A and B slots, the bootloader can determine that the partition type is either A / B partition or virtual A / B partition. The bootloader then further examines which partition (s) has a single slot, thereby making a final determination regarding whether the A / B partition applies or the virtual A / B partition applies. In some embodiments, the bootloader can check whether the super partition exists to determine whether the partition type is virtual A / B. For other partition types, the bootloader can check the characteristics in the GPT to decide the corresponding partition type. Once the bootloader decides the partition type, it can invoke the corresponding boot logic to load and boot with the specified images flashed onto the system. The same bootloader can be used across different systems that support different partition types.

[0040] FIG. 8 is a flowchart representation of a method for installing or updating at least one of a firmware or an operating system on an embedded system in accordance with one or more embodiments of the present technology. In some embodiments, the method can be implemented as a custom flashing tool. The method 800 includes, at operation 810, accessing a package that comprises information for the at least one of the firmware or the operating system. A structure of the package remains same for multiple partition types for installing or updating the at least one of  the firmware or the operating system. The method 800 includes, at operation 820, receiving an indication of a partition type selected from the multiple partition types. The method 800 includes, at operation 830, installing at least part of the information in the package to a non-transitory memory of the embedded system according to the selected partition type.

[0041] Some preferred embodiments according to the disclosed technology adopt the following solutions.

[0042] 1. A method for installing or updating at least one of a firmware or an operating system on an embedded system, comprising: accessing a package that comprises information for the at least one of the firmware or the operating system, wherein a structure of the package remains same across multiple partition types for installing or updating the at least one of the firmware or the operating system; receiving an indication of a partition type selected from the multiple partition types; and copying at least part of the information in the package to a non-transitory memory of the embedded system according to the selected partition type.

[0043] 2. The method of solution 1, wherein the package comprises partition information corresponding to the multiple partition types and one or more image files corresponding to the at least one of the firmware or the operating system.

[0044] 3. The method of solution 2, wherein the partition information comprises multiple partition tables, each corresponding to one of the multiple partition types.

[0045] 4. The method of any of solutions 1 to 3, wherein the multiple partition types comprise at least one of: A / B partition type, non-A / B partition type, or virtual A / B partition type.

[0046] 5. The method of any of solutions 1 to 4, wherein the indication of the partition type is received via a command line option.

[0047] 6. The method of any of solutions 1 to 5, wherein the indication of the partition type is received via a user interface.

[0048] 7. The method of any of solutions 1 to 6, wherein the package further comprises a bootloader program, the method comprising: copying the bootloader program to the non-transitory memory of the embedded system to enable the bootloader program to load the at least one of the firmware or the operating system according to the selected partition type.

[0049] 8. A non-transitory, computer-readable storage medium implemented as a package for installing or updating at least one of a firmware or an operating system on an embedded system, comprising: partition information that corresponds to multiple partition types for installing or  updating the at least one of the firmware or the operating system; and one or more image files that correspond to the at least one of the firmware or the operating system, wherein a structure of the package remains same across the multiple partition types.

[0050] 9. The non-transitory, computer-readable storage medium of solution 8, wherein the partition information comprises multiple partition tables, each corresponding to one of the multiple partition types.

[0051] 10. The non-transitory, computer-readable storage medium of solution 8 or 9, wherein the multiple partition types comprise at least one of: A / B partition type, non-A / B partition type, or virtual A / B partition type.

[0052] 11. The non-transitory, computer-readable storage medium of any of solutions 8 to 10, further comprising: instructions recorded thereon that, when executed by at least one processor of the embedded system, cause the embedded system to load the firmware or the operating system based on a partition type.

[0053] 12. The non-transitory, computer-readable storage medium of solution 11, wherein the instructions, when executed by at least one processor of the embedded system, cause the embedded system to: determine a partition structure of the one or more image files based on a partition table stored in a non-transitory memory of the embedded system, and determine the partition type based on the partition structure.

[0054] 13. A device, comprising: one or more processors, and a non-transitory memory that comprises instructions recorded thereon that, when executed by the one or more processors, cause the one or more processors to: determine a partition structure of one or more images based on a partition table stored in the non-transitory memory, wherein the one or more images correspond to a firmware or an operating system installed on the device; determine a partition type from multiple partition types based on the partition structure of the one or more images; and load the firmware or the operating system based on the partition type.

[0055] 14. The device of solution 13, wherein the partition table comprises a Globally Unique Identifier GUID Partition Table (GPT) .

[0056] 15. The device of solution 13 or 14, wherein the partition table is stored at logical block addressing (LBA) 1 of the non-transitory memory.

[0057] 16. The device of any of solutions 13 to 15, wherein the instructions are part of a secondary program loader.

[0058] 17. The device of any of solutions 13 to 16, wherein the multiple partition types comprise at least one of: A / B partition type, non-A / B partition type, or virtual A / B partition type.

[0059] 18. The device of solution 17, wherein the instructions recorded thereon, when executed by the one or more processors, cause the one or more processors to: determine that the partition type is the non-A / B partition type upon detecting a recovery image based on the partition structure of the one or more images.

[0060] 19. The device of solution 17, wherein the instructions recorded thereon, when executed by the one or more processors, cause the one or more processors to: determine that the partition type is the virtual A / B partition type upon detecting a super partition based on the partition structure of the one or more images.

[0061] 20. The device of solution 17, wherein the instructions recorded thereon, when executed by the one or more processors, cause the one or more processors to: determine that the partition type is the A / B partition type or the virtual A / B partition type upon detecting a mirror image for at least one of the one or more images.

[0062] The disclosed and other embodiments, modules, and functional operations described in this document can be implemented in digital electronic circuitry, or in computer software, firmware, or hardware, including the structures disclosed in this document and their structural equivalents, or in combinations of one or more of them. The disclosed and other embodiments can be implemented as one or more computer program products, i.e., one or more modules of computer program instructions encoded on a computer-readable medium for execution by, or to control the operation of, data processing apparatus. The computer-readable medium can be a machine-readable storage device, a machine-readable storage substrate, a memory device, a composition of matter effecting a machine-readable propagated signal, or a combination of one or more of them. The term “data processing apparatus” encompasses all apparatus, devices, and machines for processing data, including by way of example a programmable processor, a computer, or multiple processors or computers. The apparatus can include, in addition to hardware, code that creates an execution environment for the computer program in question, e.g., code that constitutes processor firmware, a protocol stack, a database management system, an operating system, or a combination of one or more of them. A propagated signal is an artificially generated signal, e.g., a machine-generated electrical, optical, or electromagnetic signal, that is generated to encode information for transmission to suitable receiver apparatus.

[0063] A computer program (also known as a program, software, software application, script, or code) can be written in any form of programming language, including compiled or interpreted languages, and it can be deployed in any form, including as a stand-alone program or as a module, component, subroutine, or other unit suitable for use in a computing environment. A computer program does not necessarily correspond to a file in a file system. A program can be stored in a portion of a file that holds other programs or data (e.g., one or more scripts stored in a markup language document) , in a single file dedicated to the program in question, or in multiple coordinated files (e.g., files that store one or more modules, sub programs, or portions of code) . A computer program can be deployed to be executed on one computer or on multiple computers that are located at one site or distributed across multiple sites and interconnected by a communication network.

[0064] The processes and logic flows described in this document can be performed by one or more programmable processors executing one or more computer programs to perform functions by operating on input data and generating output. The processes and logic flows can also be performed by, and apparatus can also be implemented as, special purpose logic circuitry, e.g., an FPGA (field programmable gate array) or an ASIC (application-specific integrated circuit) . Processors suitable for the execution of a computer program include, by way of example, both general and special purpose microprocessors and any one or more processors of any kind of digital computer. Generally, a processor will receive instructions and data from a read-only memory or a random-access memory or both. The essential elements of a computer are a processor for performing instructions and one or more memory devices for storing instructions and data. Generally, a computer will also include, or be operatively coupled to receive data from or transfer data to, or both, one or more mass storage devices for storing data, e.g., magnetic, magneto-optical disks, or optical disks. However, a computer need not have such devices. Computer-readable media suitable for storing computer program instructions and data include all forms of non-volatile memory, media, and memory devices, including, by way of example, semiconductor memory devices, e.g., EPROM, EEPROM, and flash memory devices; magnetic disks, e.g., internal hard disks or removable disks; magneto-optical disks; and CD-ROM and DVD-ROM disks. The processor and the memory can be supplemented by, or incorporated in, special purpose logic circuitry.

[0065] While this patent document contains many specifics, these should not be construed as  limitations on the scope of any invention or of what may be claimed but rather as descriptions of features that may be specific to particular embodiments of particular inventions. Certain features that are described in this patent document in the context of separate embodiments can also be implemented in combination in a single embodiment. Conversely, various features that are described in the context of a single embodiment can also be implemented in multiple embodiments separately or in any suitable subcombination. Moreover, although features may be described above as acting in certain combinations and even initially claimed as such, one or more features from a claimed combination can, in some cases, be excised from the combination, and the claimed combination may be directed to a subcombination or variation of a subcombination.

[0066] Similarly, while operations are depicted in the drawings in a particular order, this should not be understood as requiring that such operations be performed in the particular order shown or in sequential order, or that all illustrated operations be performed, to achieve desirable results. Moreover, the separation of various system components in the embodiments described in this patent document should not be understood as requiring such separation in all embodiments.

[0067] Only a few implementations and examples are described, and other implementations, enhancements, and variations can be made based on what is described and illustrated in this patent document.

Claims

1.A method for installing or updating at least one of a firmware or an operating system on an embedded system, comprising:accessing a package that comprises information for the at least one of the firmware or the operating system,wherein a structure of the package remains same across multiple partition types for installing or updating the at least one of the firmware or the operating system;receiving an indication of a partition type selected from the multiple partition types; andinstalling at least part of the information in the package to a non-transitory memory of the embedded system according to the selected partition type.2.The method of claim 1, wherein the package comprises partition information corresponding to the multiple partition types and one or more image files corresponding to the at least one of the firmware or the operating system.3.The method of claim 2, wherein the partition information comprises multiple partition tables, each corresponding to one of the multiple partition types.4.The method of any of claims 1 to 3, wherein the multiple partition types comprise at least one of: A / B partition type, non-A / B partition type, or virtual A / B partition type.5.The method of any of claims 1 to 4, wherein the indication of the partition type is received via a command line option.6.The method of any of claims 1 to 5, wherein the indication of the partition type is received via a user interface.7.The method of any of claims 1 to 6, wherein the package further comprises a bootloader program, the method comprising:installing the bootloader program to the non-transitory memory of the embedded system to enable the bootloader program to load the at least one of the firmware or the operating system according to the selected partition type.8.A non-transitory, computer-readable storage medium as a package for installing or updating at least one of a firmware or an operating system on an embedded system, comprising:partition information that corresponds to multiple partition types for installing or updating the at least one of the firmware or the operating system; andone or more image files that correspond to the at least one of the firmware or the operating system,wherein a structure of the package remains same across the multiple partition types.9.The non-transitory, computer-readable storage medium of claim 8, wherein the partition information comprises multiple partition tables, each corresponding to one of the multiple partition types.10.The non-transitory, computer-readable storage medium of claim 8 or 9, wherein the multiple partition types comprise at least one of: A / B partition type, non-A / B partition type, or virtual A / B partition type.11.The non-transitory, computer-readable storage medium of any of claims 8 to 10, further comprising:instructions recorded thereon that, when executed by at least one processor of the embedded system, cause the embedded system to load the firmware or the operating system based on a partition type.12.The non-transitory, computer-readable storage medium of claim 11, wherein the instructions, when executed by at least one processor of the embedded system, cause the embedded system to:determine a partition structure of the one or more image files based on a partition table stored in a non-transitory memory of the embedded system, anddetermine the partition type based on the partition structure.13.A device, comprising:one or more processors, anda non-transitory memory that comprises instructions recorded thereon that, when executed by the one or more processors, cause the one or more processors to:determine a partition structure of one or more images stored in the device based on a partition table stored in the non-transitory memory,wherein the one or more images correspond to a firmware or an operating system installed on the device;determine a partition type from multiple partition types based on the partition structure of the one or more images; andload the firmware or the operating system based on the partition type.14.The device of claim 13, wherein the partition table comprises a Globally Unique Identifier GUID Partition Table (GPT) .15.The device of claim 13 or 14, wherein the partition table is stored at logical block addressing (LBA) 1 of the non-transitory memory.16.The device of any of claims 13 to 15, wherein the instructions are part of a secondary program loader.17.The device of any of claims 13 to 16, wherein the multiple partition types comprise at least one of: A / B partition type, non-A / B partition type, or virtual A / B partition type.18.The device of claim 17, wherein the instructions recorded thereon, when executed by the one or more processors, cause the one or more processors to:determine that the partition type is the non-A / B partition type upon detecting a recovery image based on the partition structure of the one or more images.19.The device of claim 17, wherein the instructions recorded thereon, when executed by the one or more processors, cause the one or more processors to:determine that the partition type is the virtual A / B partition type upon detecting a super partition based on the partition structure of the one or more images.20.The device of claim 17, wherein the instructions recorded thereon, when executed by the one or more processors, cause the one or more processors to:determine that the partition type is the A / B partition type or the virtual A / B partition type upon detecting a mirror image for at least one of the one or more images.

Images