Hybrid configuration management using bootloader translation

A hybrid co-processing system including both complex instruction set computer (CISC) architecture-based processing clusters and reduced instruction set computer (RISC) architecture-based processing clusters includes a parser to derive from a hardware configuration specific to the CISC architecture, such as an ACPI table, a device tree specific to the RISC architecture for booting. The hardware configuration information indicated by the device tree is specific to the RISC architecture, and in different cases includes more, less, or revised information than a corresponding ACPI table for the same hybrid co-processing system.

BACKGROUND

High performance processing systems use processor cores to execute software programs to perform designated services, such as file management, database management, document printing management, web page storage, computer game services, graphics processing, computer vision, and the like, or a combination thereof. Conventional processing systems include clusters of processor cores that follow either a complex instruction set computer (CISC) architecture or a reduced instruction set computer (RISC) architecture. During a bootstrap process (referred to as a “boot”) each cluster of processor cores executes local firmware to configure the processor cores for operation based on a set of configuration parameters. This allows each cluster of processor cores to be individually configured by adjusting the configuration parameters for each cluster. However, because the CISC architecture and the RISC architecture employ different configuration parameters, booting processing systems incorporating clusters of processor cores with both CISC architecture and RISC architecture can be an inefficient process.

DETAILED DESCRIPTION

FIGS. 1-3illustrate example techniques for booting a hybrid co-processing system including both CISC architecture-based processing clusters and RISC architecture-based processing clusters by parsing a hardware configuration specific to the CISC architecture to a device tree specific to the RISC architecture. In the context of the hybrid co-processing system, both the CISC architecture-based processing clusters and RISC architecture-based processing clusters run high-level operating systems (OSs) such as Linux or Windows. A CISC architecture-based processing cluster derives hardware configuration information for booting from an advanced configuration and power interface (ACPI) table, whereas a RISC architecture-based processing cluster derives hardware configuration information for booting from a device tree. The hardware configuration information indicated by the device tree is specific to the RISC architecture, and in different cases includes more, less, or revised information than a corresponding ACPI table for the same processing system. If the ACPI table were used for booting both the CISC architecture-based processing clusters and the RISC architecture-based processing clusters, the ACPI table would introduce unnecessary constraints on the OS running on the RISC architecture-based processing clusters.

During the boot process, a bootloader creates or updates an ACPI table to provide a hardware configuration specific to the CISC architecture-based processing clusters (referred to as x86-based processing clusters) to an operating system (OS) executing at the x86-based processing clusters. The bootloader includes a parser to translate the ACPI table into a device tree that provides a hardware configuration specific to the RISC architecture-based processing clusters (referred to as ARM-based processing clusters) to an OS executing at the ARM-based processing clusters. In some embodiments, the ACPI table includes a trusted memory region (TMR) that is only applicable to the OS executing at the ARM-based processing clusters. The parser accesses the TMR of the ACPI to generate a device node in the device tree, and the TMR is not exposed to the OS executing at the x86-based processing clusters. By leveraging the hardware configuration information already created or stored at the ACPI table and adapting the hardware configuration into a device tree that includes hardware configuration information specific to an ARM-based processing cluster, the bootloader efficiently boots both the x86-based processing clusters and the ARM-based processing clusters.

FIG. 1is a block diagram of a hybrid co-processing system100including a bootloader130configured to boot a first processing cluster A110including processor cores having a first architecture type and a second processing cluster B120including processor cores having a second architecture type in accordance with some embodiments. In some embodiments, the first processing cluster A110includes a cluster of processors implementing a CISC instruction set architecture, such as an x86 instruction set architecture, and the second processing cluster B120includes a cluster of processors implementing a RISC instruction set architecture, such as an Advanced RISC Machine (ARM) architecture.

As illustrated inFIG. 1, each of the first processing cluster A110and the second processing cluster B120also includes a system memory112,122, respectively, an operating system114,124, respectively, and a cache119,129, respectively. The processing system100further includes a communications infrastructure102, and one or more applications150. Access to system memories112,122is managed by one or more memory controllers (not shown), which are coupled to memories112,122. For example, requests from the processing cluster A110or the processing cluster B120or other devices for reading from or for writing to system memories112,122are managed by the memory controller. In some embodiments, the one or more applications150include various programs or commands to perform computations that are also executed at one or both of the processing cluster A110and the processing cluster B120. The processing system100further includes a motherboard104that provides power and support to at least the processing cluster A110and the processing cluster B120, a memory management unit, such as an input/output memory management unit (IOMMU)140and a power management unit160. Components of processing system100may be implemented as hardware, firmware, software, or any combination thereof. In some embodiments the processing system100includes one or more software, hardware, and firmware components in addition to or different from those shown inFIG. 1.

Within each of the processing cluster A110and the processing cluster B120, the system memories114,124include non-persistent memory, such as dynamic random-access memory (DRAM) (not shown). In various embodiments, the system memories112,122store processing logic instructions, constant values, variable values during execution of portions of applications or other processing logic, or other desired information. For example, in various embodiments, parts of control logic to perform one or more operations at processing cluster A110and processing cluster B120reside within system memories112,122during execution of the respective portions of the operation by processing cluster A110and processing cluster B120. During execution, respective applications, operating system functions, processing logic commands, and system software reside in system memories112,122, respectively. Control logic commands that are fundamental to operating systems114,124generally reside in system memories112,122, respectively, during execution. In some embodiments, other software commands (e.g., a device driver) also reside in system memories112,122during execution of processing system100.

The IOMMU140includes logic to perform virtual to physical address translation for memory page access for devices, such as the processing cluster A110and the processing cluster B120. In some embodiments, the IOMMU140also includes, or has access to, a translation lookaside buffer (TLB)142. The TLB142, as an example, is implemented in a content addressable memory (CAM) to accelerate translation of logical (i.e., virtual) memory addresses to physical memory addresses for requests made by the processing cluster A110and the processing cluster B120for data in system memories112,122.

In various embodiments, the communications infrastructure102interconnects the components of processing system100. Communications infrastructure102includes (not shown) one or more of a peripheral component interconnect (PCI) bus, extended PCI (PCI-E) bus, advanced microcontroller bus architecture (AMBA) bus, advanced graphics port (AGP), or other such communication infrastructure and interconnects. In some embodiments, communications infrastructure102also includes an Ethernet network or any other suitable physical communications infrastructure that satisfies an application's data transfer rate requirements. Communications infrastructure102also includes the functionality to interconnect components, including components of processing system100.

The processing cluster A110includes processing cores A-1115, A-2116, A-3117, and A-4118and the processing cluster B120includes processing cores B-1125, B-2126, B-3127, and B-4128. One or more of the processing cores115-118and125-128includes (not shown) one or more of a control processor, field programmable gate array (FPGA), application specific integrated circuit (ASIC), or digital signal processor (DSP). One or more of the processing cores115-118and125-128executes at least a portion of the control logic that controls the operation of the processing system100. For example, in various embodiments, one or more of the processing cores115-118and125-128execute the operating systems114,124and the one or more applications150. In some embodiments, one or more of the processing cores115-118and125-128executes commands and programs for selected functions, such as graphics operations and other operations that are particularly suited for parallel processing.

In general, the processing cluster B120is frequently used for executing graphics pipeline operations, such as pixel operations, geometric computations, and rendering an image to a display, such as for computer vision. Computer vision allows computers to extract high-level information from digital images by automating tasks that correspond to similar tasks performed by a human visual system. Examples of computer vision tasks include object recognition, motion analysis, scene reconstruction, and image restoration. Computer vision techniques include two complementary tasks: (1) acquiring one or more digital images and (2) processing the acquired images to generate high dimensional data that represents an “understanding” of the information in the digital images. Image acquisition is performed by one or more image sensors or cameras, as well as range sensors, depth sensors, tomography devices, radar, ultrasonic cameras, and the like. The digital image can be an ordinary two-dimensional (2D) image, a three-dimensional (3D) volume, or a combination of one or more of the 2D images and 3D volumes. Processing the acquired images involves one or more of pre-processing (for example, to reduce noise), feature extraction, and detection and segmentation. Computer vision tasks are generally more efficiently handled by processors implementing a RISC instruction set architecture, such as an Advanced RISC Machine (ARM) architecture. In some embodiments, the processing cluster B120also executes compute processing operations (e.g., those operations unrelated to graphics such as video operations, physics simulations, computational fluid dynamics, etc.).

The number of processing cores115-118and125-128that are implemented in each of the processing cluster A110and the processing cluster B120is a matter of design choice. Each of the processing cores115-118and125-128includes one or more processing elements such as scalar and/or vector floating-point units, arithmetic and logic units (ALUs), and the like. In various embodiments, the processing cores115-118and125-128also include special purpose processing units (not shown), such as inverse-square root units and sine/cosine units.

The power management unit160is configured to implement power states for certain components of the processing system100in accordance with one or more power state specifications, such as in accordance with the Advanced Configuration and Power Interface (ACPI) specification. For example, to implement a power state asserted by an OS114,124or other component, the power management unit160is able to change clock frequencies for one or more components, connect or disconnect one or more components from a power rail (not shown), change a voltage supplied to one or more components, or combinations thereof.

The bootloader130performs core initialization of the hardware of the processing system100and loads the operating systems114,124of the processing cluster A110and the processing cluster B120, respectively. The bootloader130then hands control to the operating systems114,124, which initialize themselves and configure the system hardware by, for example, setting up memory management, setting timers and interrupts, and loading device drivers.

The bootloader130includes a boot memory135configured to store a Basic Input/Output System (BIOS)133and a hardware-A configuration132indicating the hardware configuration of the processing system100for the processing cluster A110. In some embodiments, the boot memory135is implemented as a read only memory (ROM) that stores boot code for execution during a boot process that is initiated upon a power-on reset. Booting refers to any of a variety of initialization specifications or processes, BIOS, extensible firmware interface (EFI), unified EFI (UEFI), and the like. In some embodiments, the hardware-A configuration132includes a start-up service such as an ACPI framework. The hardware-A configuration132provides hardware registers to the components powered by the motherboard104to enable power management and device operation without directing calling each component natively such as by a hardware address. The hardware-A configuration132serves as an interface layer between the BIOS133and the OS114for the processing cluster A110.

During a bootstrap process, such as at a power-on reset or other boot initialization event, power is supplied to the motherboard104. When the motherboard104first receives power, the boot memory135is activated and completes its setup, initialization, and self-tests including a power-on self-test (POST). The BIOS133then uses information obtained during firmware initialization to create or update tables of the hardware-A configuration132with various platform and device configurations including power interface data.

During the boot process, the BIOS133identifies all available storage devices of the processing cluster A110for potential boot devices that may have an OS for the processing cluster A110. The BIOS133uses a boot order specified in a persistent storage available to the motherboard104. On some motherboards, the persistent storage is in a separate chip. In many instances, the BIOS persistent storage is integrated with a real-time clock (RTC) or with an integrated circuit (IC) on the motherboard104that is responsible for a hard drive controller, an I/O controller, and integrated components. In some embodiments, the BIOS persistent storage is provided with its own power source in the form of a battery which allows the BIOS persistent storage to maintain the boot order even if the motherboard104of the hybrid co-processing system100loses primary power.

The bootloader130includes executable code that loads the OS114into the system memory112and starts the OS114. At this point, the BIOS133activates the boot loader130and stops controlling the motherboard104and the hybrid co-processing system100. The bootloader130loads and executes the various components of the OS114into the system memory112and communicates the hardware-A configuration132to the OS114. During its initialization, the OS114starts and initializes a kernel (not shown) to allow the kernel to provide tasks in the form of processor instructions to the processing cores115-118. The kernel manages execution of processes on the processing cores115-118.

To facilitate efficient booting of the processing cluster B120, the bootloader130further includes a parser135configured to derive a hardware-B configuration134indicating the hardware configuration of the processing system100for the processing cluster120based on the hardware-A configuration132. The hardware-A configuration132is a description of the hardware configuration of the hybrid co-processing system100, such as memory configuration, I/O devices, device locations, device capabilities, and custom bootstrings, that is relevant to the OS114running at the processing cluster A110. The hardware-B configuration134is a description of the hardware configuration of the hybrid co-processing system100that is relevant to the OS124running at the processing cluster B120. Because the processing cluster A110has a different architecture type than the processing cluster B120, the hardware-A configuration132differs from the hardware-B configuration134.

Generating both the hardware-A configuration132and the hardware-B configuration134independently of one another is inefficient, and using the hardware-A configuration132for the OS124running at the processing cluster B120(or using the hardware-B configuration134for the OS114running at the processing cluster A110) introduces unnecessary constraints on the OS124(or insufficient information for the OS114). Accordingly, the parser136derives the hardware-B configuration134from the hardware-A configuration132. In some embodiments, the parser136derives the hardware-B configuration134by logically pruning, restricting, or adding information specific to the architecture of the processing cluster B120to the information contained in the hardware-A configuration132. By deriving the hardware-B configuration134from the hardware-A configuration132, the parser136leverages the information contained in the hardware-A configuration132and customizes the information to the needs of the OS114in the architectural context of the processing cluster B120, facilitating a more efficient bootstrap process.

In some embodiments, the hardware-A configuration132includes a trusted memory region (TMR) that is only applicable to the OS114in the architectural context of the processing cluster B120. The TMR region of the hardware-A configuration132is not exposed to the OS112running at the processing cluster A110.

Based on the hardware-B configuration134, the bootloader130loads the OS124into the system memory122and starts the OS124. In some embodiments, the bootloader130loads the OS124into the system memory122and starts the OS124in parallel with loading the OS114into the system memory112and starting the OS114. The bootloader130communicates the hardware-B configuration134to the OS124. During its initialization, the OS124starts and initializes a kernel (not shown) to allow the kernel to provide tasks in the form of processor instructions to the processing cores125-128. The kernel manages execution of processes on the processing cores125-128.

FIG. 2is a block diagram of the bootloader130ofFIG. 1including a parser136for parsing an advanced configuration and power interface (ACPI) table232indicating a hardware configuration of the hybrid co-processing system100that is used to boot a CISC architecture-based processing cluster (not shown) into a device tree234indicating a hardware configuration of the hybrid co-processing system100that is used to boot a RISC architecture-based processing cluster (not shown) in accordance with some embodiments. The ACPI table232includes a trusted memory region233, which includes a listing of hardware210and corresponding parameters212. The trusted memory region233is not exposed to the CISC architecture-based processing cluster. For example, in some embodiments the hardware210includes storage such as system memory, caches, frame buffers, and local shared memories, I/O devices, and peripheral devices. In some embodiments, the corresponding parameters212include memory configuration, device locations, device capacities, device capabilities, and custom bootstrings. The information contained in the ACPI table232is specific to the needs of an OS executing at the CISC architecture-based processing cluster, for example, for a Linux or Windows OS executing at an x86-based processing cluster.

The parser136is configured to translate the hardware configuration information of the ACPI table232into device nodes in the device tree234, which includes information specific to the needs of an OS executing at the RISC architecture-based processing cluster, for example, for a Linux OS executing at an ARM-based processing cluster. Based on the differences between the information specific to the needs of the OS executing at the RISC architecture-based processing cluster and the information specific to the needs of the OS executing at the CISC architecture-based processing cluster, the parser136derives the device tree234by logically pruning or restricting information from the ACPI table232, or adding information specific to the RISC architecture to the information contained in the ACPI table232. For example, in some embodiments, the parser136extracts from the trusted memory region233an extended peripheral component interconnect (PCI-E) root complex and information relating to peripherals, such as USB, universal asynchronous receiver/transmitter (UART), and general purpose input/output (GPIO) devices, that is only applicable to the RISC architecture-based processing cluster. Each node of the device tree234is also referred to as a device node. A device node includes device objects for each device's drivers (not shown), as well as internal information maintained by the RISC architecture-based processing cluster. The device tree234is hierarchical, with devices on a bus or interconnect device represented as “children” of the bus or interconnect. The hierarchy of the device tree234reflects the structure in which the devices are connected within the hybrid co-processing system100. In some embodiments, the parser136derives a device tree source file (not shown) from the ACPI table232, which is compiled into a device tree blob (not shown). The device tree blob is loaded by the bootloader130and parsed by a kernel (not shown) at boot time.

In the illustrated example, the device tree234includes a tree root250, which is depicted as a parent node to a CPU255node, a GPU260node, and a memory265node. The CPU255node is depicted as a parent node to a core1257and a core2259. The GPU node260is depicted as a parent node to a compute unit1262and a compute unit2264. The memory265node is depicted as a parent node to a double data rate (DDR) synchronous dynamic random access memory device267node. Thus, the device tree234describes the hardware layout and capabilities of, for example, the processing cluster B120.

FIG. 3is a flow diagram illustrating a method300for booting a hybrid co-processing system100ofFIGS. 1 and 2including clusters of CISC architecture-based processors and RISC architecture-based processors by parsing a hardware configuration such as an ACPI table for an operating system running at the cluster of CISC architecture-based processors into a hardware configuration such as a device tree for an operating system running at the cluster of RISC architecture-based processors in accordance with some embodiments. At block302, the hybrid co-processing system100supplies power to the motherboard104. At block304, when the motherboard104receives power, the motherboard104activates the boot memory135and the boot memory135conducts setup, firmware initialization, and self-tests such as a power-on self-test (POST). At block306, the BIOS133uses information obtained during firmware initialization to create or update tables of the hardware-A configuration132with various platform and device configurations including power interface data specific to the OS114at the processing cluster A110.

At block308, the parser136derives from the ACPI table232a device tree234for the OS124at the processing cluster B120. In some embodiments, the parser136derives the device tree234by logically pruning or restricting information from the ACPI table232, or by adding information specific to the RISC architecture to the information contained in the ACPI table232. At block310, the bootloader130identifies a boot device storing the OS114for the processing cluster A110and a boot device storing the OS124for the processing cluster B120. In some embodiments, the booting of the processing cluster A110and booting of the processing cluster B120proceed independently of each other after the parser136derives the device tree234from the ACPI table232. The BIOS133uses a boot order specified in a persistent storage available to the motherboard104. At block312, the bootloader130executes code that loads the OS114into the system memory112and starts the OS114, at which point the BIOS133stops controlling the motherboard104. At block314, the bootloader130loads the OS124into system memory114for the processing cluster B120. In some embodiments, the bootloader130performs the actions of blocks312and314in parallel. At block316, the bootloader130communicates the ACPI table232to the OS114. In some embodiments, the bootloader130employs a pointer to communicate the ACPI table232to the OS114. At block318, the bootloader130communicates the device tree234to the OS124. In some embodiments, the bootloader130employs a pointer to communicate the device tree234to the OS124. In some embodiments, the bootloader130performs the actions of blocks316and318in parallel.