Patent Description:
Basic Input/Output System (BIOS) is firmware of a computing system that executes tasks to perform hardware initialization during a booting process (e.g., during startup, a firmware-update, etc.) and provides services to an operating system of the computing system during runtime. During a boot process, the BIOS initializes and test the hardware components of a computing system. Some computing systems utilize extensible firmware interface (EFI), unified extensible firmware interface (UEFI), or other firmware to perform initialization and/or provide runtime services.

<CIT>, titled "Electronic Device with Overlapped Boot Task Fetches and Boot Task Execution," describes a system that comprises two processors and a boot task storage medium. This storage medium can only be accessed by one processor at a time. The boot process of the system is divided into two stages. In the first stage, the first processor retrieves and executes boot tasks without any help from the second processor. In the second stage, the execution of boot tasks by the first processor overlaps with the fetching of at least one boot task by the second processor.

Patent publication <CIT> titled SELF-OPTIMIZING MULTI-CORE INTEGRATED CIRCUIT discusses a self-optimizing System-on-Chip (SOC) that includes multiple cores, multiple hardware accelerators, multiple memories and an interconnect framework. The SOC also includes a machine learning (ML) module that uses data flow information to build a ML network dynamically and configures all the various hardware blocks autonomously, to achieve predetermined application performance targets. The SOC is able to recover from hangs caused when testing various configuration settings. The SOC also avoids configuration settings that cause severe drops in performance.

The figures are not to scale. Instead, the thickness of the layers or regions may be enlarged in the drawings. As used herein, connection references (e.g., attached, coupled, connected, and joined) may include intermediate members between the elements referenced by the connection reference and/or relative movement between those elements unless otherwise indicated. As such, connection references do not necessarily infer that two elements are directly connected and/or in fixed relation to each other. As used herein, stating that any part is in "contact" with another part is defined to mean that there is no intermediate part between the two parts.

Unless specifically stated otherwise, descriptors such as "first," "second," "third," etc., are used herein without imputing or otherwise indicating any meaning of priority, physical order, arrangement in a list, and/or ordering in any way, but are merely used as labels and/or arbitrary names to distinguish elements for ease of understanding the disclosed examples. " In such instances, it should be understood that such descriptors are used merely for identifying those elements distinctly that might, for example, otherwise share a same name. As used herein, "approximately" and "about" refer to dimensions that may not be exact due to manufacturing tolerances and/or other real world imperfections. As used herein "substantially real time" refers to occurrence in a near instantaneous manner recognizing there may be real world delays for computing time, transmission, etc. Thus, unless otherwise specified, "substantially real time" refers to real time +/- <NUM> second. As used herein, the phrase "in communication," including variations thereof, encompasses direct communication and/or indirect communication through one or more intermediary components, and does not require direct physical (e.g., wired) communication and/or constant communication, but rather additionally includes selective communication at periodic intervals, scheduled intervals, aperiodic intervals, and/or one-time events. As used herein, "processor circuitry" is defined to include (i) one or more special purpose electrical circuits structured to perform specific operation(s) and including one or more semiconductor-based logic devices (e.g., electrical hardware implemented by one or more transistors), and/or (ii) one or more general purpose semiconductor-based electrical circuits programmed with instructions to perform specific operations and including one or more semiconductor-based logic devices (e.g., electrical hardware implemented by one or more transistors). Examples of processor circuitry include programmed microprocessors, Field Programmable Gate Arrays (FPGAs) that may instantiate instructions, Central Processor Units (CPUs), Graphics Processor Units (GPUs), Digital Signal Processors (DSPs), XPUs, or microcontrollers and integrated circuits such as Application Specific Integrated Circuits (ASICs). For example, an XPU may be implemented by a heterogeneous computing system including multiple types of processor circuitry (e.g., one or more FPGAs, one or more CPUs, one or more GPUs, one or more DSPs, etc., and/or a combination thereof) and application programming interface(s) (API(s)) that may assign computing task(s) to whichever one(s) of the multiple types of the processing circuitry is/are best suited to execute the computing task(s).

Some entities (e.g., cloud service providers) provide services (e.g., compute-as-a-service (CaaS)) to computing devices of users (e.g., computers, laptops, servers, virtual machines, etc.). Initially, the entity may provide (e.g., deploy) software, instructions, commands, etc., that may be implemented at the computing device of a user. However, as the entity generates updated software, instructions, patches, etc., the entity may deploy updates to the computing devices to update the computing system.

Traditionally, when an update from an entity includes or is based on a firmware update (e.g., updating the configuration of firmware at the computing device), a computing device performs a full reboot to install the firmware update. During a full reboot, the operating system of the computing device shuts down and restarts all the processes and/or components of the computing device (e.g., including hardware drivers, kernels etc.) by interacting with the Basic Input/Output System (BIOS). The BIOS is firmware that performs hardware initialization during power up and/or booting the computing device by performing tasks (e.g., boot tasks) on processing components of the computing device (e.g., cores, big cores, little cores, atoms, big device processor, little device processor, etc.). Boot protocols and/or firmware updates may be vital to the performance and/or security of the computing device.

Heterogeneous technology in computing systems are computing systems that include more than one type of core. For example, a computing system may have one or more big device processor (e.g., cores) and/or one or more small device processors (e.g., atoms) to perform operations. A big device processor may include one or more cores and/or processing units while a small device processor may have one or two cores. Additionally, the big processor device is more power and/or takes up more space than a small processor device. A big device processor can handle high performance applications while a small device processor offers lower power, smaller footprint, and more modest performance compared to bit device processors. Examples of small device processors include Intel® Atom®, Intel® Quark® SoC, LITTLE cores, etc. Heterogeneous systems provide compact, powerful, and efficient computing systems. Examples disclosed herein leverage heterogeneous computing systems to increase the speed and efficiency of a BIOS controlled boot (e.g., for startup, firmware updates, low power boot mode, S5 charging, etc.).

Some traditional BIOS boot protocols utilize a boot strap processor (BSP) and/or controller in a single threaded and/or multi-threaded environment without analyzing the speed, energy, performance efficiency, etc. of the processing component (e.g., core, small device processor, thread etc.), thereby resulting in more idle time for the boot protocol. Additionally such traditional BIOS boot protocols do not differentiate tasks with respect to the processing components running the tasks. For example, traditional BISO boot protocols obtain a task and assign the task to the next available processing component (e.g., core/thread/small device processor) without determining if the task is better suited to a particular processing component. For example, assigning a task to a small device processor is more efficient than assigning the task to the core. However, the amount of time it takes for an small device processor to perform a task is longer than for a core.

Examples disclosed herein categorize boot tasks into task types and/or processing component types based on performance metrics to balance the speed and efficiency of different processing components of a computing system. For example, more computationally intensive tasks may be linked to cores while less computationally intensive tasks are linked to small device processors. Examples disclosed herein categorize the boot tasks into one of four types: a compute bound task, a cache bound task, a memory bound task, and/or an I/O bound task. Additionally or alternatively, examples disclosed herein may categorize tasks into additional and/or alternative task types. As an example, a compute bound task may be a task that performs computations and/or calculations (e.g., multiplying small matrices), a cache count task may be a task that processes more data than fits in the cache, a memory bound task may be a task that processes large amounts of memory data (e.g., multiplying large matrices), and an I/O bound task may be a task that processes data from a disk (e.g., counting the number of lines in a file).

Examples disclosed herein categorize boot tasks using firmware agents that monitor the performance of the boot tasks during a boot protocol (e.g., during a learning phase) and identify the compute task category and/or an appropriate processor component based on the performance. The agents store the classifications (also referred to as categorizations) to a learning boot table. After the training phase, when control is passed to the BIOS (e.g., during startup, during a firmware update, etc.), a scheduler utilizes the learning boot schedule to instruct the tasks to be performed on the processing component identified in the learning boot table. For example, the scheduler may schedule compute bound tasks and/or memory bound tasks to be performed by a first processing component (e.g., a core, a BIG core, etc.) while the cache bound tasks and/or IO based tasks are scheduled to be performed on a small device processor (e.g., an atom, a LITTLE core, etc.). Using examples disclosed herein, the boot process is faster and more efficient.

<FIG> is a block diagram of an example computing device <NUM>. The example computing device <NUM> includes an example CPU <NUM>, which includes one or more example cores <NUM> and one or more example small device processors <NUM>. The example computing device <NUM> further includes an example operating system (OS) <NUM> and example firmware <NUM>. The example firmware <NUM> includes an example BIOS <NUM>, example hybrid firmware <NUM>, example agent <NUM>, and example scheduler <NUM>.

The example CPU <NUM> of <FIG> is electronic circuity that executes instructions making up a program or workload. The CPU <NUM> may be an embedded system, a field programmable gate array, a shared-memory controller, a network on-chip, a networked system, and/or any other circuitry that includes a hardware (e.g., semiconductor based) processor, memory, and/or cache. The example CPU <NUM> utilizes processor resources (e.g., memory, register(s) and/or logic circuitry of the example processor core(s) <NUM> and/or atom(s) <NUM>) to execute instructions to implement an application and/or access data from memory. In some examples, the CPU <NUM> includes circuitry to execute firmware instructions. For example, the CPU <NUM> may include agent circuitry to execute the example agent <NUM> and/or scheduler circuitry to execute the scheduler <NUM>.

The example processor core(s) <NUM> and/or the example small device processor(s) <NUM> of <FIG> execute(s) instructions (e.g., a workload) from an application (e.g., by reading and/or writing data). Tasks executed on one or more core(s) <NUM> may result in a different amount of time to complete and/or a different efficiency than the same tasks being executed on the one or more small device processors <NUM>. For example, the one or more cores <NUM> may be more efficient with respect to iterations per cycle (IPC) ratios when executing compute-bound tasks. Additionally, the one or more cores <NUM> may have a larger cache than the small device processors <NUM> for executing cache bound tasks. The one or more small device processors <NUM> may be more efficient for memory-bound tasks that correspond to more time in pipe stall waiting for memory and/or may be more efficient for I/O bound tasks, as IO bound tasks do not depend on processing operating speed. Although the example CPU <NUM> includes the core(s) <NUM> and the small device processor(s) <NUM>, the CPU <NUM> can include any number and/or type of processing components (e.g., little core, big core, threads, etc.). Examples of small device processors <NUM> include Intel® Atom®, Intel® Quark® SoC, LITTLE cores, etc..

The example OS <NUM> of <FIG> is a software system managing the example CPU <NUM> to manage hardware of the computing device <NUM>, software resources, and/or provides servers for computer programs and/or applications. During a boot process (e.g., at start-up, a firmware update, etc.), the OS <NUM> passes control of the computing device <NUM> to the firmware <NUM> (e.g., the BIOS <NUM>). After the boot process, control is passed back to the OS <NUM> for normal operation.

The example firmware <NUM> of <FIG> provides low-level control over the hardware of the computing device <NUM>. The example firmware <NUM> includes the BIOS <NUM> to use the example core(s) <NUM> and/or small device processor(s) <NUM> to execute instructions and/or perform operations during a boot protocol. The BIOS <NUM> can perform hardware initialization and/or provide runtime services for the OS <NUM> and/or other programs. Additionally, the BIOS <NUM> can perform tasks during a firmware update and/or any other boot protocol, where the BIOS <NUM> has control of the core(s) <NUM> and/or small device processor(s) <NUM>. Although the example computing device <NUM> of <FIG> includes the BIOS <NUM>, the BIOS <NUM> can be replaced with EFI, UEFI, and/or any other type of firmware that is capable of interfacing between hardware and the OS <NUM>.

The example hybrid firmware <NUM> of <FIG> deploys the agent <NUM> and/or the scheduler <NUM> into the firmware <NUM>. For example, during a training phase (e.g., during an initial boot, when a learning table is not authenticated, and/or during retraining), the hybrid firmware <NUM> deploys the agent <NUM> to initialize the categorization of boot tasks to generate a learning boot table based on the nature of the tasks. The example agent <NUM> analyzes boot tasks and/or obtains performance data of the boot tasks when executed by the core(s) <NUM> and/or the small device processor(s) <NUM> to be able to categorize the boot tasks (e.g., into the nature of the task, such as compute bound, memory bound, IO bound, and/or cache bound) in a learning boot table. The agent <NUM> is further described below in conjunction with <FIG>. The hybrid firmware <NUM> instruct the agent <NUM> on how to implement the training protocol to gather information for the categorization of the boot tasks. For example, the hybrid firmware <NUM> cause the agents circuitry <NUM> to run a boot task on one or more of the core(s) <NUM> and/or small device processor(s) <NUM> to obtain performance data for the categorization of the coot task. After training and/or during a subsequent boot process, the hybrid firmware <NUM> deploys the scheduler <NUM> to schedule the tasks based on the learning boot table. For example, during a boot, the scheduler identifies the boot tasks of the boot protocol, identifies the corresponding categorization, and schedules the task to be executed by one of the core(s) <NUM> or the small device processor(s) <NUM> based on the categorization. The example scheduler <NUM> is further described below in conjunction with <FIG>.

<FIG> illustrates an example heterogenous processor boot diagram <NUM> with a hybrid firmware model. The example heterogenous processor boot diagram <NUM> includes the example CPU <NUM>, the example core(s) <NUM>, the example hybrid firmware <NUM>, the example agent <NUM>, and the example scheduler <NUM> of <FIG>. The example heterogeneous processor boot diagram further includes an example hardware view <NUM>, an example firmware view <NUM>, an example CPU view <NUM>, an example system on chip (SOC) north (e.g., also referred to as uncore) <NUM>, an example SOC south (e.g., also referred to as a chipset) <NUM>, an example learning boot table <NUM>, example system memory <NUM>, an example display <NUM>, an example BIOS flash <NUM>, and example IO subsystems <NUM>.

The example core <NUM> running on the CPU <NUM> can be utilized to perform tasks that focus on operating speed (e.g., arithmetic operations). The SoC north <NUM> requires large amount of memory data and does not depend on processing operating speed. For example, the SOC <NUM> may copy master boot record from block devices into the memory <NUM> and use the same for booting to the OS <NUM> or split boot wherein portion of the BIOS <NUM> is expected to run from inactive boot partitions because higher memory is available to copy the data into memory and run from the memory <NUM>. In absence of memory and/or when memory availability is limited, the SOC north <NUM> may rely on cache. Prior to DRAM initialization in the computing device <NUM>, all BIOS tasks may be dependent on cache. The IO chipset/SOC south <NUM> can be used to focus on IO subsystem and deal with chipset registers (e.g., read from block device, updating firmware on IO sub-systems, etc.).

As described above, the example hybrid firmware <NUM> deploys the agent <NUM> to generate the learning boot table <NUM> and/or the scheduler <NUM> use the learning boot table <NUM> to schedule boot tasks on the core(s) <NUM> and/or small device processor(s) <NUM> during a boot protocol. In some examples, the example CPU <NUM> may implement the agent <NUM> by executing software and/or firmware using agent circuitry and may implement the scheduler <NUM> by executing software and/or firmware using scheduler circuitry. In some examples, the agent <NUM> and/or the scheduler <NUM> be hardware structured to perform specific functions. When the agent <NUM> is deployed, the example agent <NUM> gathers information related to boot tasks to be able to classify the boot tasks. For example, the agent <NUM> may gather task identifiers, performance information of the tasks executed on the core(s) <NUM> and/or the small device processor(s) <NUM>, time to execute, and/or information from hardware agents. Hardware agents facilitate the boot tasks using the hardware. Accordingly, hardware agents may be able to determine whether a task is a memory bound task, and IO bound task or a cache task and provide this information (e.g., operational data) to the agent <NUM>. The example agent <NUM> categorizes the task(s) based on the obtained information. For example, the agent <NUM> uses the performance data (e.g., IPC), timestamps, and/or information (e.g., operational data) from the hardware agents to classify the tasks. For example, a task (e.g., encryption operation based on a memory buffer), may include both computational and memory components. Accordingly, the agent <NUM> may use the timestamp and performance to categorize the task as compute bound or memory bound.

The agent <NUM> of <FIG> may gather information from a single boot (e.g., for static scheduling) and/or multiple boots (for dynamic scheduling) to generate the learning boot table <NUM>. If the agent <NUM> generates the learning boot table <NUM> based on static scheduling, the agent <NUM> categorizes each task to a corresponding task category (e.g., compute bound, memory bound, IO bound, cache bound) to generate the learning boot table <NUM>. If the agent <NUM> generates the learning boot table <NUM> based on dynamic scheduling, the agent <NUM> causes a task to be run on different processor components and compares the results to link the task to a processor component. For example, during a first boot, the agent <NUM> may obtain information related to the task being performed on one of the core(s) <NUM>. During a second boot, the agent <NUM> may cause the task to be performed on a different one of the core(s) <NUM> and/or one of the small device processor(s) <NUM>. In this manner, the agent <NUM> can compare the performance and/or timing of the task operating on the two different components to determine which processor component is better (e.g., with respect to performance, efficiency, and/or timing, depending on user and/or manufacturer preferences). Accordingly, the agent <NUM> may generate an entry in the learning boot table <NUM> that identifies a task identifier, a corresponding task classification and/or category (e.g., compute bound, memory bound, IO bound, cache bound, etc.) for static scheduling, and/or a corresponding processing component type (e.g., core, small device processor, etc.) for dynamic scheduling. Although examples disclosed herein describe the example learning boot table <NUM> being generated locally in the computing device <NUM> by the agent <NUM>, the learning boot table <NUM> may be generated externally (e.g., at a different computing device and/or server) and deployed to the example computing device <NUM> for the scheduler <NUM> to use.

After the learning boot table <NUM> of <FIG> is generated, the learning boot table is stored in non-volatile memory. During a subsequent boot, the scheduler <NUM> uses the information of the learning boot table <NUM> to schedules boot tasks on processing components based on the corresponding information of the boot table <NUM>. For example, if the scheduler <NUM> applies static scheduling (e.g., because dynamic scheduling information is not available or based on a setting), the scheduler <NUM> identifies a boot task that is to be performed. After identification, the scheduler <NUM> identifies the classification and/or category corresponding to the task in the learning boot table <NUM> based on a task identifier of the task. After the classification and/or category of the task is identified, the scheduler <NUM> schedules the task on one of the core(s) <NUM> and/or small device processor(s) <NUM> based on the categorization (e.g., compute bound and/or cache bound tasks on the core(s) <NUM> and memory and/or IO bound tasks on the small device processor(s) <NUM>). If the scheduler <NUM> applies dynamic scheduling, the scheduler <NUM> identifies a boot task that is to be performed. After identification, the scheduler <NUM> identifies the processor component corresponding to the task in the learning boot table <NUM> based on a task identifier of the task. After the component processor is identified, the scheduler <NUM> schedules the task on one of the core(s) <NUM> and/or small device processor(s) <NUM> corresponding to the identified processor component. Retraining and/or additional training (e.g., for dynamic scheduling) for additional and/or replacement entries for the learning boot table <NUM> may be performed at any time after the initial boot protocol.

<FIG> is a block diagram of an example implementation of the agent <NUM> and the scheduler <NUM> of <FIG> and/or <NUM>. The example agent <NUM> includes an example task identifier <NUM>, an example task controller <NUM>, an example performance determiner <NUM>, an example categorizer <NUM>, an example table entry controller <NUM>, and an example interface <NUM>. The example task identifier <NUM>, the example task controller <NUM>, the example performance determiner <NUM>, the example categorizer <NUM>, the example table entry controller <NUM>, and/or the example interface <NUM> may be implemented by the CPU <NUM> executing software and/or firmware. For example, the CPU may include task identification circuitry to implement the task identifier <NUM>, task control circuitry to implement the task controller <NUM>, performance determination circuitry to implement the example performance determiner <NUM>, categorization circuitry to implement the example categorizer <NUM>, table entry circuitry to implement the example table entry controller <NUM>, and/or interface circuitry to implement the example interface <NUM>. The example scheduler <NUM> includes an example interface <NUM>, an example table entry processor <NUM>, an example BIOS controller <NUM>, and an example table validator <NUM>. The example interface <NUM>, the example table entry processor <NUM>, the example BIOS controller <NUM>, and/or the example table validator <NUM> may be implemented by the CPU <NUM> executing software and/or firmware. For example, the CPU <NUM> may include interface circuitry to implement example interface <NUM>, table entry processing circuitry to implement the example table entry processor <NUM>, BIOS control circuitry to implement the example BIOS controller <NUM>, and/or table validation circuitry to implement the example table validator <NUM>.

The example task identifier <NUM> of <FIG> identifies and/or assigns a task identifier of a boot task. Each task can be associated with a different identifier. In this manner, the task identifier <NUM> can ensure that when the task is scheduled during a subsequent boot protocol, the correct categorization will correspond to the same task identified during training. If the task already corresponds to an identifier, the task identifier <NUM> can identify the task based on the predefined identifier. If the task does not have an identifier, the task identifier <NUM> can provide an identifier so that the task can be identified during subsequent boot protocols.

The example task controller <NUM> of <FIG> controls how the task is performed. For example, the task controller <NUM> can cause a task to be run on one of the core(s) <NUM> or one of the small device processor(s) <NUM>. The task controller <NUM> may perform the task on the different processing components to be able to confirm that the correct processing component is being used and/or for dynamic scheduling.

The example performance determiner <NUM> of <FIG> determines the performance of a task being executed on one of the core(s) <NUM> and/or the small device processor(s) <NUM>. For example, the performance determiner <NUM> can measure the IPC of a task being executed on one of the core(s) <NUM> and/or the small device processor(s) <NUM>. The performance determiner <NUM> may additionally or alternatively measure the amount of time a task took to complete on the core(s) <NUM> and/or the small device processor(s) <NUM>, the power usage and/or any other data related to the performance of the task.

The categorizer <NUM> of <FIG> categorizes the task into a task type and/or a processor component type. For example, during an initial boot processes, the categorizer <NUM> may use the performance information (e.g., IPC, timestamp, power usage, telemetric data, etc.) and/or information (e.g., operational data) from hardware agents to determine the task type. For example, the categorizer <NUM> may categorize a task as compute count when the task results in more than a threshold amount of time to compete and/or corresponds to more than a threshold IPC. The categorizer <NUM> may categorize a task as IO bound when hardware agents provide operational information that the task corresponding to IO operations. Additionally, hardware agents and/or the amount of time to perform that requires memory may be analyzed to determine whether a task is a memory bound task or a cache bound task. Additionally or alternatively, the categorizer <NUM> may categorize into a processor component time (e.g., core or small device processor), based on the performance information and/or operational information from the hardware agents (e.g., for dynamic scheduling). For example, the task controller <NUM> may execute a task on one of the cores <NUM> and one of the small device processors <NUM> (e.g., during the same boot or during different boots) and compare the performance results. In this manner, the categorizer <NUM> can determine which component is faster, more efficient, consumes less power resources, etc. based on the comparison of the performance on the core <NUM> vs. the small device processor <NUM>.

The example table entry controller <NUM> of <FIG> generates information to include in an entry in the learning boot table <NUM>. For example, the table entry controller <NUM> organizes the task identifier, the task categorization and/or the processor component categorization for the task. The table entry controller <NUM> adds the entry to the learning boot table <NUM>, which may be stored in volatile memory and/or cache during the boot process. In some examples, the table entry controller <NUM> and/or another component of the firmware <NUM> may store the learning boot table into non-volatile memory at the end of the boot process so that the scheduler <NUM> can utilize the learning boot table <NUM> during a subsequent boot.

The example interface <NUM> of <FIG> obtains operational information from hardware agents, the core(s) <NUM>, and/or the small device processor(s) <NUM>. For example, the interface <NUM> can obtain performance information and/or information related to how a task was executed via the hardware agents, core(s) <NUM>, and/or small device processor (s) <NUM>. Additionally, the example interface <NUM> may transmit the learning boot table <NUM> and/or an entry for the learning boot table <NUM> into volatile memory and/or cache to be stored during the boot process.

The example interface <NUM> of the example scheduler <NUM> of <FIG> obtains the learning boot table <NUM> from memory when a boot process starts. In this manner, the scheduler <NUM> can schedule the boot tasks statically and/or dynamically using the learning boot table <NUM>. Additionally, when a boot protocol is initiated, the interface <NUM> obtains the list of tasks to be executed during the boot protocol.

The example table entry processor <NUM> of <FIG> processes entries in the learning boot table <NUM> to be able to find information related to a boot task. For example, when a boot protocol is initiated, the table entry processor <NUM> identifies an identifier of the first obtained task for the boot protocol. After the identifier is obtained, the table entry processor <NUM> searches for an entry that matches the identifier. If a match is not found, the table entry processor <NUM> may default the task to one of the core(s) <NUM> and/or small device processor(s) <NUM> and/or may instruct the agent <NUM> to process the task to add to the learning boot table <NUM>. If a match is found, the table entry processor <NUM> may identify the corresponding task categorization (e.g., for static scheduling) and/or processor core categorization (e.g., for dynamic scheduling) for the task.

The example BIOS controller <NUM> of <FIG> schedules the task based on the task categorization and/or processor component categorization of the tasks to be executed during the boot process. For example, if dynamic scheduling is to be performed, the BIOS controller <NUM> schedules each task based on the processor component categorization of the tasks in the learning boot table <NUM> (e.g., the BIOS controller <NUM> schedules a task classified to a core to be execute by one or more of the core(s) <NUM> for the boot process). For static scheduling, the BIOS controller <NUM> schedules a task based on the corresponding task categorization. For example, the BIOS control circuitry can schedule the compute bound tasks and/or the cache bound tasks on the core(s) <NUM> and schedule the IO bound tasks and/or memory bound tasks on the small device processor(s) <NUM>. Additionally, the BIOS controller <NUM> may perform a hybrid scheduling, where some of the tasks are statically scheduled and/or some of the tasks are dynamically scheduled (e.g., when all the dynamical information is not yet known, when the core(s) <NUM> and/or the small device processor(s) <NUM> are under or over utilized, and/or based on preferences). Additionally, the BIOS controller <NUM> may schedule the tasks based on an indication that static/dynamic scheduling will be overridden (e.g., due to low available power resources, speed preference, etc.). For example, if the computing device has low battery, the static and/or dynamic scheduling may be overridden, so that the BIOS <NUM> can operate according to a predefined low power scheduling to conserve power.

The example table validator <NUM> of <FIG> validates the learning boot table <NUM>. In order to avoid an invalid table from being implemented during a boot process, the table validator <NUM> validates an accessed table prior to use to ensure that the table is safe and/or complete to use during the boot process. The table validator <NUM> can use any type of data validation technique.

While an example manner of implementing the agent <NUM> and/or the scheduler <NUM> of <FIG> is illustrated in <FIG>, one or more of the elements, processes, and/or devices illustrated in <FIG> may be combined, divided, re-arranged, omitted, eliminated, and/or implemented in any other way. Further, the example task identifier <NUM>, the example task controller <NUM>, the example performance determiner <NUM>, the example categorizer <NUM>, the example table entry controller <NUM>, the example interface <NUM>, the example interface <NUM>, the example table entry processor <NUM>, the example BIOS controller <NUM>, the example table validator <NUM>, and/or, more generally, the computing device <NUM>, the example firmware <NUM>, the example BIO <NUM>, the example hybrid firmware <NUM>, the agent <NUM>, and/or the scheduler <NUM> of <FIG>, may be implemented by hardware, software, firmware, and/or any combination of hardware, software, and/or firmware. Thus, for example, any of the example task identifier <NUM>, the example task controller <NUM>, the example performance determiner <NUM>, the example categorizer <NUM>, the example table entry controller <NUM>, the example interface <NUM>, the example interface <NUM>, the example table entry processor <NUM>, the example BIOS controller <NUM>, the example table validator <NUM>, and/or, more generally, the computing device <NUM>, the example firmware <NUM>, the example BIO <NUM>, the example hybrid firmware <NUM>, the agent <NUM>, and/or the scheduler <NUM> of <FIG>, could be implemented by processor circuitry, analog circuit(s), digital circuit(s), logic circuit(s), programmable processor(s), programmable microcontroller(s), graphics processing unit(s) (GPU(s)), digital signal processor(s) (DSP(s)), application specific integrated circuit(s) (ASIC(s)), programmable logic device(s) (PLD(s)), and/or field programmable logic device(s) (FPLD(s)) such as Field Programmable Gate Arrays (FPGAs). When reading any of the apparatus or system claims of this patent to cover a purely software and/or firmware implementation, at least one of the computing device <NUM>, the example firmware <NUM>, the example BIO <NUM>, the example hybrid firmware <NUM>, the agent <NUM>, and/or the scheduler <NUM> of <FIG> is/are hereby expressly defined to include a non-transitory computer readable storage device or storage disk such as a memory, a digital versatile disk (DVD), a compact disk (CD), a Blu-ray disk, etc., including the software and/or firmware. Further still, the computing device <NUM>, the example firmware <NUM>, the example BIO <NUM>, the example hybrid firmware <NUM>, the agent <NUM>, and/or the scheduler <NUM> of <FIG> may include one or more elements, processes, and/or devices in addition to, or instead of, those illustrated in <FIG>, and/or may include more than one of any or all of the illustrated elements, processes, and devices.

Flowcharts representative of example hardware logic circuitry, machine readable instructions, hardware implemented state machines, and/or any combination thereof for implementing the computing device <NUM>, the agent <NUM>, and/or the scheduler <NUM> of <FIG> are shown in <FIG>. The machine readable instructions may be one or more executable programs or portion(s) of an executable program for execution by processor circuitry, such as the processor circuitry <NUM> shown in the example processor platform <NUM> discussed below in connection with <FIG> and/or the example processor circuitry discussed below in connection with <FIG>. The program may be embodied in software stored on one or more non-transitory computer readable storage media such as a CD, a floppy disk, a hard disk drive (HDD), a DVD, a Blu-ray disk, a volatile memory (e.g., Random Access Memory (RAM) of any type, etc.), or a non-volatile memory (e.g., FLASH memory, an HDD, etc.) associated with processor circuitry located in one or more hardware devices, but the entire program and/or parts thereof could alternatively be executed by one or more hardware devices other than the processor circuitry and/or embodied in firmware or dedicated hardware. The machine readable instructions may be distributed across multiple hardware devices and/or executed by two or more hardware devices (e.g., a server and a client hardware device). For example, the client hardware device may be implemented by an endpoint client hardware device (e.g., a hardware device associated with a user) or an intermediate client hardware device (e.g., a radio access network (RAN) gateway that may facilitate communication between a server and an endpoint client hardware device). Similarly, the non-transitory computer readable storage media may include one or more mediums located in one or more hardware devices. Further, although the example program is described with reference to the flowchart illustrated in <FIG>, many other methods of implementing the computing device <NUM>, the agent <NUM>, and/or the scheduler <NUM> of <FIG> may alternatively be used. For example, the order of execution of the blocks may be changed, and/or some of the blocks described may be changed, eliminated, or combined. Additionally or alternatively, any or all of the blocks may be implemented by one or more hardware circuits (e.g., processor circuitry, discrete and/or integrated analog and/or digital circuitry, an FPGA, an ASIC, a comparator, an operational-amplifier (op-amp), a logic circuit, etc.) structured to perform the corresponding operation without executing software or firmware. The processor circuitry may be distributed in different network locations and/or local to one or more hardware devices (e.g., a single-core processor (e.g., a single core central processor unit (CPU)), a multi-core processor (e.g., a multi-core CPU), etc.) in a single machine, multiple processors distributed across multiple servers of a server rack, multiple processors distributed across one or more server racks, a CPU and/or a FPGA located in the same package (e.g., the same integrated circuit (IC) package or in two or more separate housings, etc.).

The machine readable instructions described herein may be stored in one or more of a compressed format, an encrypted format, a fragmented format, a compiled format, an executable format, a packaged format, etc. Machine readable instructions as described herein may be stored as data or a data structure (e.g., as portions of instructions, code, representations of code, etc.) that may be utilized to create, manufacture, and/or produce machine executable instructions. For example, the machine readable instructions may be fragmented and stored on one or more storage devices and/or computing devices (e.g., servers) located at the same or different locations of a network or collection of networks (e.g., in the cloud, in edge devices, etc.). The machine readable instructions may require one or more of installation, modification, adaptation, updating, combining, supplementing, configuring, decryption, decompression, unpacking, distribution, reassignment, compilation, etc., in order to make them directly readable, interpretable, and/or executable by a computing device and/or other machine. For example, the machine readable instructions may be stored in multiple parts, which are individually compressed, encrypted, and/or stored on separate computing devices, wherein the parts when decrypted, decompressed, and/or combined form a set of machine executable instructions that implement one or more operations that may together form a program such as that described herein.

In another example, the machine readable instructions may be stored in a state in which they may be read by processor circuitry, but require addition of a library (e.g., a dynamic link library (DLL)), a software development kit (SDK), an application programming interface (API), etc., in order to execute the machine readable instructions on a particular computing device or other device. In another example, the machine readable instructions may need to be configured (e.g., settings stored, data input, network addresses recorded, etc.) before the machine readable instructions and/or the corresponding program(s) can be executed in whole or in part. Thus, machine readable media, as used herein, may include machine readable instructions and/or program(s) regardless of the particular format or state of the machine readable instructions and/or program(s) when stored or otherwise at rest or in transit.

As mentioned above, the example operations of <FIG> and <FIG> may be implemented using executable instructions (e.g., computer and/or machine readable instructions) stored on one or more non-transitory computer and/or machine readable media such as optical storage devices, magnetic storage devices, an HDD, a flash memory, a read-only memory (ROM), a CD, a DVD, a cache, a RAM of any type, a register, and/or any other storage device or storage disk in which information is stored for any duration (e.g., for extended time periods, permanently, for brief instances, for temporarily buffering, and/or for caching of the information). As used herein, the terms non-transitory computer readable medium and non-transitory computer readable storage medium is expressly defined to include any type of computer readable storage device and/or storage disk and to exclude propagating signals and to exclude transmission media.

Thus, whenever a claim employs any form of "include" or "comprise" (e.g., comprises, includes, comprising, including, having, etc.) as a preamble or within a claim recitation of any kind, it is to be understood that additional elements, terms, etc., may be present without falling outside the scope of the corresponding claim or recitation. The term "and/or" when used, for example, in a form such as A, B, and/or C refers to any combination or subset of A, B, C such as (<NUM>) A alone, (<NUM>) B alone, (<NUM>) C alone, (<NUM>) A with B, (<NUM>) A with C, (<NUM>) B with C, or (<NUM>) A with B and with C. As used herein in the context of describing structures, components, items, objects and/or things, the phrase "at least one of A and B" is intended to refer to implementations including any of (<NUM>) at least one A, (<NUM>) at least one B, or (<NUM>) at least one A and at least one B. Similarly, as used herein in the context of describing structures, components, items, objects and/or things, the phrase "at least one of A or B" is intended to refer to implementations including any of (<NUM>) at least one A, (<NUM>) at least one B, or (<NUM>) at least one A and at least one B. As used herein in the context of describing the performance or execution of processes, instructions, actions, activities and/or steps, the phrase "at least one of A and B" is intended to refer to implementations including any of (<NUM>) at least one A, (<NUM>) at least one B, or (<NUM>) at least one A and at least one B. Similarly, as used herein in the context of describing the performance or execution of processes, instructions, actions, activities and/or steps, the phrase "at least one of A or B" is intended to refer to implementations including any of (<NUM>) at least one A, (<NUM>) at least one B, or (<NUM>) at least one A and at least one B.

The term "a" or "an" object, as used herein, refers to one or more of that object. The terms "a" (or "an"), "one or more", and "at least one" are used interchangeably herein. Furthermore, although individually listed, a plurality of means, elements or method actions may be implemented by, e.g., the same entity or object.

<FIG> is a flowchart representative of example machine readable instructions and/or example operations <NUM> that may be executed and/or instantiated by processor circuitry to generate the example learning boot table <NUM> during learning. The learning may occur during an initial boot and/or during retraining and/or to gather more information for dynamic scheduling.

The machine readable instructions and/or operations <NUM> of <FIG> begin at block <NUM>, at which the example OS <NUM> passes control to the example BIOS <NUM> to initiate the learning of the boot tasks during a boot protocol. At block <NUM>, the example hybrid firmware <NUM> deploys the agent <NUM> to control the boot process and obtain data for the categorization of the tasks. At block <NUM>, the example task controller <NUM> determines if a boot task is to be performed based on the boot protocol.

If the example control circuitry <NUM> determines that a boot task is not be performed (block <NUM>: NO), control continues to block <NUM>, as further described below. If the example control circuitry <NUM> determines that a boot task is to be performed (block <NUM>: YES), the example task identifier <NUM> identifies the task (block <NUM>). For example, if the task includes an identifier, the task identifier <NUM> processes the task to determine the task identifier. If the task does not include an identifier, the task identifier <NUM> may generate a task identifier for the task, so that the scheduler <NUM> and/or the agent <NUM> can identify the task during a subsequent boot.

At block <NUM>, the example task controller <NUM> and/or the BIOS <NUM> executes the task on a processor component. For example, during an initial boot, the BIOS <NUM> may execute all boot tasks on the core(s) <NUM>. For dynamic scheduling, the task controller <NUM> may cause the task to be performed on one or more of the core(s) <NUM> or the small device processor(s) <NUM> to be able to gather information about the task being executed on the processor components. At block <NUM>, the example performance determiner <NUM> and/or the categorizer <NUM> collects data corresponding to the task. For example, the performance determiner <NUM> can collect performance data (e.g., timing information, IPC, power usage information, etc.) for the task being executed on one or the core(s) <NUM> or the small device processor(s) <NUM>. The example categorizer <NUM> may obtain operational information (e.g., via the interface <NUM>) from the hardware agents that corresponds to whether a task included IO operations, memory operations (e.g., operations that access memory), and/or cache operations (e.g., operations the access cache).

At block <NUM>, the example task controller <NUM> determines if a different processor component can be selected to execute the boot task. As described above, for dynamic scheduling a boot task needs to be executed on different processor component types to be able to compare the performance, timing, etc. to generate a processor component categorization. In some examples, the task can be executed in the different processor components during a single boot process. In some examples, the task can be executed in the different processor components during different boot processes.

If the example task controller <NUM> determines that a different processor component should be selected to execute the boot task (block <NUM>: YES), the example task controller <NUM> selects the different processor component (e.g., if the task was first executed on the core <NUM>, now execute on the small device processor <NUM>) and control returns to block <NUM> to gather performance information based on the task being executed on the selected processor component. If the example task controller <NUM> determines that a different processor component should not be selected to execute the boot task (block <NUM>: NO), the categorizer <NUM> categorizes the task based on the collected data (block <NUM>). For example, for static schedule training, the categorizer <NUM> uses performance data of the task (e.g., timing data, IPCs, power usage data, etc.) to categorize the task as compute bound by comparing the performance data to one or more thresholds. If the categorizer <NUM> determines that the task should is not compute bound (e.g., the IPC is below a threshold, the power usage is below a threshold, etc.), the categorizer <NUM> can use the operational data from hardware agents to determine whether the task included memory operations, cache operations, and/or IO operations to be able to categorize the task as memory bound, cache bound, and/or IO bound. For dynamic schedule training, the categorizer <NUM> will have performance information for the task executed on the core <NUM> and the small device processor <NUM>. Accordingly, the categorizer <NUM> can categorize the task to be performed on the core <NUM> or the small device processor <NUM> based on a comparison of the performance (e.g., to improve speed, reduce power, etc.) of the task on the core <NUM> or the small device processor <NUM>.

At block <NUM>, the example table entry controller <NUM> adds the categorization to the learning boot table <NUM> and control returns to block <NUM> to categorize a subsequent task. If there are no more tasks to categorization (block <NUM>: NO), the example BIOS <NUM> stores the learning boot table <NUM> into non-volatile memory so that the learning boot table <NUM> can be utilized for subsequent boots.

<FIG> is a flowchart representative of example machine readable instructions and/or example operations <NUM> that may be executed and/or instantiated by processor circuitry to schedule boot tasks.

The machine readable instructions and/or operations <NUM> of <FIG> begin at block <NUM>, at which the table entry processor <NUM> determines if the OS <NUM> has indicated an override of the boot processing using the learning boot table <NUM>. For example, the OS <NUM> may wish to override use of the learning boot table when the computing device <NUM> is operating in a low power mode, has limited power capability, etc. If the table entry processor <NUM> determines that the OS <NUM> has overridden use of the learning boot table <NUM> (block <NUM>: YES), the example table entry processor <NUM> indicates the override in the learning boot table (block <NUM>) (e.g., so that the BIOS controller <NUM> and/or the BIOS <NUM> is aware of the override). At block <NUM>, the example BIOS controller <NUM> and/or the BIOS <NUM> performs an alternative boot path devices by the OS <NUM> (block <NUM>).

If the table entry processor <NUM> determines that the OS <NUM> has not overridden use of the learning boot table <NUM> (block <NUM>: NO), the example table validator <NUM> determines if the learning boot table is valid using any data validation technique (block <NUM>). If the example table validator <NUM> determines that the learning boot table is not valid (block <NUM>: NO), the example agent <NUM> can perform learning boot table training in conjunction with the instructions <NUM> of <FIG>. Additionally or alternatively, the example agent <NUM> can perform a default boot process in response to the learning boot table not being valid (e.g., perform all boot tasks on the core(s) <NUM>). If the example table validator <NUM> determines that the learning boot table is valid (block <NUM>: YES), the example table entry processor <NUM> identifies(s) identifiers of the tasks to be performed (block <NUM>).

At block <NUM>, the example BIOS controller <NUM> schedules the tasks to processor component(s) based on the corresponding entries of the example learning boot table <NUM>. For example, if dynamic scheduling is active (e.g., based on preferences and/or the availability of processor component categorizations for boot tasks in the learning boot table <NUM>), the BIOS controller <NUM> schedules the tasks according to the corresponding processor component categorization based on the corresponding task identifiers of the learning boot table <NUM>. If static scheduling is active (e.g., based on preferences and/or the unavailability of processor component categorizations for boot tasks in the learning boot table <NUM>), the BIOS controller <NUM> schedules the tasks according to the corresponding task categorization (e.g., compute bound/cache bound tasks on core(s) <NUM> and cache bound/IO bound tasks on small device processor(s) <NUM>). In some examples, the BIOS controller <NUM> may perform hybrid scheduling, where one or more tasks are scheduling dynamically and one or more tasks are scheduled statically. In some examples, the BIOS controller <NUM> may ignore and/or override categorizations when resources are over/under utilized. For example, if all or most of the tasks are scheduled for the core(s) <NUM> and none or a limited number of tasks are scheduled for small device processor(s) <NUM>, the BIOS controller <NUM> may schedule one or more of the tasks corresponding to the core(s) <NUM> (e.g., based on the learning boot table categorizations) to the small device processor(s) <NUM> to increase the efficiency of the utilization of the core(s) <NUM> and small device processor(s) <NUM>.

At block <NUM>, the example BIOS <NUM> performs the boot path (e.g., process) by executing the tasks on the corresponding processor component based on the schedule. At block <NUM>, the example BIOS <NUM> synchronizes the components in preparation for returning control back to the OS <NUM>. At block <NUM>, the example BIOS passes the payload over to the OS <NUM> to return control back to the OS <NUM>.

<FIG> is a block diagram of an example processor platform <NUM> structured to execute and/or instantiate the machine readable instructions and/or operations of <FIG> and/or <NUM> to implement the agent <NUM> and/or the scheduler <NUM> of <FIG>. The processor platform <NUM> can be, for example, a server, a personal computer, a workstation, a self-learning machine (e.g., a neural network), a mobile device (e.g., a cell phone, a smart phone, a tablet such as an iPad™), a personal digital assistant (PDA), an Internet appliance, a DVD player, a CD player, a digital video recorder, a Blu-ray player, a gaming console, a personal video recorder, a set top box, a headset (e.g., an augmented reality (AR) headset, a virtual reality (VR) headset, etc.) or other wearable device, or any other type of computing device.

The processor platform <NUM> of the illustrated example includes processor circuitry <NUM>. The processor circuitry <NUM> of the illustrated example is hardware. For example, the processor circuitry <NUM> can be implemented by one or more integrated circuits, logic circuits, FPGAs microprocessors, CPUs, GPUs, DSPs, and/or microcontrollers from any desired family or manufacturer. The processor circuitry <NUM> may be implemented by one or more semiconductor based (e.g., silicon based) devices. In this example, the processor circuitry <NUM> implements the example CPU <NUM>, the example BIOS <NUM>, the example hybrid firmware <NUM>, the example agent <NUM>, the example scheduler <NUM>, the example task identifier <NUM>, the example task controller <NUM>, the example performance determiner <NUM>, the example categorizer <NUM>, the example table entry controller <NUM>, the example interface <NUM>, the example interface <NUM>, the example table entry processor <NUM>, the example BIOS controller <NUM>, and the example table validator <NUM>.

The processor circuitry <NUM> of the illustrated example includes a local memory <NUM> (e.g., a cache, registers, etc.). The processor circuitry <NUM> of the illustrated example is in communication with a main memory including a volatile memory <NUM> and a non-volatile memory <NUM> by a bus <NUM>. The volatile memory <NUM> may be implemented by Synchronous Dynamic Random Access Memory (SDRAM), Dynamic Random Access Memory (DRAM), RAMBUS® Dynamic Random Access Memory (RDRAM®), and/or any other type of RAM device. Access to the main memory <NUM>, <NUM> of the illustrated example is controlled by a memory controller <NUM>.

The processor platform <NUM> of the illustrated example also includes interface circuitry <NUM>. The interface circuitry <NUM> may be implemented by hardware in accordance with any type of interface standard, such as an Ethernet interface, a universal serial bus (USB) interface, a Bluetooth® interface, a near field communication (NFC) interface, a PCI interface, and/or a PCIe interface.

In the illustrated example, one or more input devices <NUM> are connected to the interface circuitry <NUM>. The input device(s) <NUM> permit(s) a user to enter data and/or commands into the processor circuitry <NUM>. The input device(s) <NUM> can be implemented by, for example, an audio sensor, a microphone, a camera (still or video), a keyboard, a button, a mouse, a touchscreen, a track-pad, a trackball, an isopoint device, and/or a voice recognition system.

One or more output devices <NUM> are also connected to the interface circuitry <NUM> of the illustrated example. The output devices <NUM> can be implemented, for example, by display devices (e.g., a light emitting diode (LED), an organic light emitting diode (OLED), a liquid crystal display (LCD), a cathode ray tube (CRT) display, an in-place switching (IPS) display, a touchscreen, etc.), a tactile output device, a printer, and/or speaker. The interface circuitry <NUM> of the illustrated example, thus, typically includes a graphics driver card, a graphics driver chip, and/or graphics processor circuitry such as a GPU.

The interface circuitry <NUM> of the illustrated example also includes a communication device such as a transmitter, a receiver, a transceiver, a modem, a residential gateway, a wireless access point, and/or a network interface to facilitate exchange of data with external machines (e.g., computing devices of any kind) by a network <NUM>. The communication can be by, for example, an Ethernet connection, a digital subscriber line (DSL) connection, a telephone line connection, a coaxial cable system, a satellite system, a line-of-site wireless system, a cellular telephone system, an optical connection, etc..

The processor platform <NUM> of the illustrated example also includes one or more mass storage devices <NUM> to store software and/or data. Examples of such mass storage devices <NUM> include magnetic storage devices, optical storage devices, floppy disk drives, HDDs, CDs, Blu-ray disk drives, redundant array of independent disks (RAID) systems, solid state storage devices such as flash memory devices, and DVD drives.

The machine executable instructions <NUM>, which may be implemented by the machine readable instructions of <FIG> and/or <NUM>, may be stored in the mass storage device <NUM>, in the volatile memory <NUM>, in the non-volatile memory <NUM>, and/or on a removable non-transitory computer readable storage medium such as a CD or DVD.

<FIG> is a block diagram of an example implementation of the processor circuitry <NUM> of <FIG>. In this example, the processor circuitry <NUM> of <FIG> is implemented by a microprocessor <NUM>. For example, the microprocessor _00 may implement multi-core hardware circuitry such as a CPU, a DSP, a GPU, an XPU, etc. Although it may include any number of example cores <NUM> (e.g., <NUM> core), the microprocessor <NUM> of this example is a multi-core semiconductor device including N cores. The cores <NUM> of the microprocessor <NUM> may operate independently or may cooperate to execute machine readable instructions. For example, machine code corresponding to a firmware program, an embedded software program, or a software program may be executed by one of the cores <NUM> or may be executed by multiple ones of the cores <NUM> at the same or different times. In some examples, the machine code corresponding to the firmware program, the embedded software program, or the software program is split into threads and executed in parallel by two or more of the cores <NUM>. The software program may correspond to a portion or all of the machine readable instructions and/or operations represented by the flowchart of <FIG> and/or <NUM>.

The cores <NUM> may communicate by an example bus <NUM>. In some examples, the bus <NUM> may implement a communication bus to effectuate communication associated with one(s) of the cores <NUM>. For example, the bus <NUM> may implement at least one of an Inter-Integrated Circuit (I2C) bus, a Serial Peripheral Interface (SPI) bus, a PCI bus, or a PCIe bus. Additionally or alternatively, the bus <NUM> may implement any other type of computing or electrical bus. The cores <NUM> may obtain data, instructions, and/or signals from one or more external devices by example interface circuitry <NUM>. The cores <NUM> may output data, instructions, and/or signals to the one or more external devices by the interface circuitry <NUM>. Although the cores <NUM> of this example include example local memory <NUM> (e.g., Level <NUM> (L1) cache that may be split into an L1 data cache and an L1 instruction cache), the microprocessor <NUM> also includes example shared memory <NUM> that may be shared by the cores (e.g., Level <NUM> (L2_ cache)) for high-speed access to data and/or instructions. Data and/or instructions may be transferred (e.g., shared) by writing to and/or reading from the shared memory <NUM>. The local memory <NUM> of each of the cores <NUM> and the shared memory <NUM> may be part of a hierarchy of storage devices including multiple levels of cache memory and the main memory (e.g., the main memory <NUM>, <NUM> of <FIG>). Typically, higher levels of memory in the hierarchy exhibit lower access time and have smaller storage capacity than lower levels of memory. Changes in the various levels of the cache hierarchy are managed (e.g., coordinated) by a cache coherency policy.

Each core <NUM> may be referred to as a CPU, DSP, GPU, etc., or any other type of hardware circuitry. Each core <NUM> includes control unit circuitry <NUM>, arithmetic, and logic (AL) circuitry (sometimes referred to as an ALU) <NUM>, a plurality of registers <NUM>, the L1 cache <NUM>, and an example bus <NUM>. Other structures may be present. For example, each core <NUM> may include vector unit circuitry, single instruction multiple data (SIMD) unit circuitry, load/store unit (LSU) circuitry, branch/jump unit circuitry, floating-point unit (FPU) circuitry, etc. The control unit circuitry <NUM> includes semiconductor-based circuits structured to control (e.g., coordinate) data movement within the corresponding core <NUM>. The AL circuitry <NUM> includes semiconductor-based circuits structured to perform one or more mathematic and/or logic operations on the data within the corresponding core <NUM>. The AL circuitry <NUM> of some examples performs integer based operations. In other examples, the AL circuitry <NUM> also performs floating point operations. In yet other examples, the AL circuitry <NUM> may include first AL circuitry that performs integer based operations and second AL circuitry that performs floating point operations. In some examples, the AL circuitry <NUM> may be referred to as an Arithmetic Logic Unit (ALU). The registers <NUM> are semiconductor-based structures to store data and/or instructions such as results of one or more of the operations performed by the AL circuitry <NUM> of the corresponding core <NUM>. For example, the registers <NUM> may include vector register(s), SIMD register(s), general purpose register(s), flag register(s), segment register(s), machine specific register(s), instruction pointer register(s), control register(s), debug register(s), memory management register(s), machine check register(s), etc. The registers <NUM> may be arranged in a bank as shown in <FIG>. Alternatively, the registers <NUM> may be organized in any other arrangement, format, or structure including distributed throughout the core <NUM> to shorten access time. The bus <NUM> may implement at least one of an I2C bus, a SPI bus, a PCI bus, or a PCIe bus.

Each core <NUM> and/or, more generally, the microprocessor <NUM> may include additional and/or alternate structures to those shown and described above. For example, one or more clock circuits, one or more power supplies, one or more power gates, one or more cache home agents (CHAs), one or more converged/common mesh stops (CMSs), one or more shifters (e.g., barrel shifter(s)) and/or other circuitry may be present. The microprocessor <NUM> is a semiconductor device fabricated to include many transistors interconnected to implement the structures described above in one or more integrated circuits (ICs) contained in one or more packages. The processor circuitry may include and/or cooperate with one or more accelerators. In some examples, accelerators are implemented by logic circuitry to perform certain tasks more quickly and/or efficiently than can be done by a general purpose processor. Examples of accelerators include ASICs and FPGAs such as those discussed herein. A GPU or other programmable device can also be an accelerator. Accelerators may be on-board the processor circuitry, in the same chip package as the processor circuitry and/or in one or more separate packages from the processor circuitry.

<FIG> is a block diagram of another example implementation of the processor circuitry <NUM> of <FIG>. In this example, the processor circuitry <NUM> is implemented by FPGA circuitry <NUM>. The FPGA circuitry <NUM> can be used, for example, to perform operations that could otherwise be performed by the example microprocessor <NUM> of <FIG> executing corresponding machine readable instructions. However, once configured, the FPGA circuitry <NUM> instantiates the machine readable instructions in hardware and, thus, can often execute the operations faster than they could be performed by a general purpose microprocessor executing the corresponding software.

More specifically, in contrast to the microprocessor <NUM> of <FIG> described above (which is a general purpose device that may be programmed to execute some or all of the machine readable instructions represented by the flowchart of <FIG> but whose interconnections and logic circuitry are fixed once fabricated), the FPGA circuitry <NUM> of the example of <FIG> includes interconnections and logic circuitry that may be configured and/or interconnected in different ways after fabrication to instantiate, for example, some or all of the machine readable instructions represented by the flowchart of <FIG>. In particular, the FPGA <NUM> may be thought of as an array of logic gates, interconnections, and switches. The switches can be programmed to change how the logic gates are interconnected by the interconnections, effectively forming one or more dedicated logic circuits (unless and until the FPGA circuitry <NUM> is reprogrammed). The configured logic circuits enable the logic gates to cooperate in different ways to perform different operations on data received by input circuitry. Those operations may correspond to some or all of the software represented by the flowchart of <FIG>. As such, the FPGA circuitry <NUM> may be structured to effectively instantiate some or all of the machine readable instructions of the flowchart of <FIG> as dedicated logic circuits to perform the operations corresponding to those software instructions in a dedicated manner analogous to an ASIC. Therefore, the FPGA circuitry <NUM> may perform the operations corresponding to the some or all of the machine readable instructions of <FIG> faster than the general purpose microprocessor can execute the same.

In the example of <FIG>, the FPGA circuitry <NUM> is structured to be programmed (and/or reprogrammed one or more times) by an end user by a hardware description language (HDL) such as Verilog. The FPGA circuitry <NUM> of <FIG>, includes example input/output (I/O) circuitry <NUM> to obtain and/or output data to/from example configuration circuitry <NUM> and/or external hardware (e.g., external hardware circuitry) <NUM>. For example, the configuration circuitry <NUM> may implement interface circuitry that may obtain machine readable instructions to configure the FPGA circuitry <NUM>, or portion(s) thereof. In some such examples, the configuration circuitry <NUM> may obtain the machine readable instructions from a user, a machine (e.g., hardware circuitry (e.g., programmed or dedicated circuitry) that may implement an Artificial Intelligence/Machine Learning (AI/ML) model to generate the instructions), etc. In some examples, the external hardware <NUM> may implement the microprocessor <NUM> of <FIG>. The FPGA circuitry <NUM> also includes an array of example logic gate circuitry <NUM>, a plurality of example configurable interconnections <NUM>, and example storage circuitry <NUM>. The logic gate circuitry <NUM> and interconnections <NUM> are configurable to instantiate one or more operations that may correspond to at least some of the machine readable instructions of <FIG> and/or other desired operations. The logic gate circuitry <NUM> shown in <FIG> is fabricated in groups or blocks. Each block includes semiconductor-based electrical structures that may be configured into logic circuits. In some examples, the electrical structures include logic gates (e.g., And gates, Or gates, Nor gates, etc.) that provide basic building blocks for logic circuits. Electrically controllable switches (e.g., transistors) are present within each of the logic gate circuitry <NUM> to enable configuration of the electrical structures and/or the logic gates to form circuits to perform desired operations. The logic gate circuitry <NUM> may include other electrical structures such as look-up tables (LUTs), registers (e.g., flip-flops or latches), multiplexers, etc..

The interconnections <NUM> of the illustrated example are conductive pathways, traces, vias, or the like that may include electrically controllable switches (e.g., transistors) whose state can be changed by programming (e.g., using an HDL instruction language) to activate or deactivate one or more connections between one or more of the logic gate circuitry <NUM> to program desired logic circuits.

The storage circuitry <NUM> of the illustrated example is structured to store result(s) of the one or more of the operations performed by corresponding logic gates. The storage circuitry <NUM> may be implemented by registers or the like. In the illustrated example, the storage circuitry <NUM> is distributed amongst the logic gate circuitry <NUM> to facilitate access and increase execution speed.

The example FPGA circuitry <NUM> of <FIG> also includes example Dedicated Operations Circuitry <NUM>. In this example, the Dedicated Operations Circuitry <NUM> includes special purpose circuitry <NUM> that may be invoked to implement commonly used functions to avoid the need to program those functions in the field. Examples of such special purpose circuitry <NUM> include memory (e.g., DRAM) controller circuitry, PCIe controller circuitry, clock circuitry, transceiver circuitry, memory, and multiplier-accumulator circuitry. Other types of special purpose circuitry may be present. In some examples, the FPGA circuitry <NUM> may also include example general purpose programmable circuitry <NUM> such as an example CPU <NUM> and/or an example DSP <NUM>. Other general purpose programmable circuitry <NUM> may additionally or alternatively be present such as a GPU, an XPU, etc., that can be programmed to perform other operations.

Although <FIG> and <FIG> illustrate two example implementations of the processor circuitry <NUM> of <FIG>, many other approaches are contemplated. For example, as mentioned above, modern FPGA circuitry may include an on-board CPU, such as one or more of the example CPU <NUM> of <FIG>. Therefore, the processor circuitry <NUM> of <FIG> may additionally be implemented by combining the example microprocessor <NUM> of <FIG> and the example FPGA circuitry <NUM> of <FIG>. In some such hybrid examples, a first portion of the machine readable instructions represented by the flowchart of <FIG> may be executed by one or more of the cores <NUM> of <FIG> and a second portion of the machine readable instructions represented by the flowchart of <FIG> may be executed by the FPGA circuitry <NUM> of <FIG>.

In some examples, the processor circuitry <NUM> of <FIG> may be in one or more packages. For example, the processor circuitry <NUM> of <FIG> and/or the FPGA circuitry <NUM> of <FIG> may be in one or more packages. In some examples, an XPU may be implemented by the processor circuitry <NUM> of <FIG>, which may be in one or more packages. For example, the XPU may include a CPU in one package, a DSP in another package, a GPU in yet another package, and an FPGA in still yet another package.

A block diagram illustrating an example software distribution platform <NUM> to distribute software such as the example machine readable instructions <NUM> of <FIG> to hardware devices owned and/or operated by third parties is illustrated in <FIG>. The example software distribution platform <NUM> may be implemented by any computer server, data facility, cloud service, etc., capable of storing and transmitting software to other computing devices. The third parties may be customers of the entity owning and/or operating the software distribution platform <NUM>. For example, the entity that owns and/or operates the software distribution platform <NUM> may be a developer, a seller, and/or a licensor of software such as the example machine readable instructions <NUM> of <FIG>. The third parties may be consumers, users, retailers, OEMs, etc., who purchase and/or license the software for use and/or re-sale and/or sub-licensing. In the illustrated example, the software distribution platform <NUM> includes one or more servers and one or more storage devices. The storage devices store the machine readable instructions <NUM>, which may correspond to the example machine readable instructions <NUM>, <NUM> of <FIG> and <FIG>, as described above. The one or more servers of the example software distribution platform <NUM> are in communication with a network <NUM>, which may correspond to any one or more of the Internet and/or any example network. In some examples, the one or more servers are responsive to requests to transmit the software to a requesting party as part of a commercial transaction. Payment for the delivery, sale, and/or license of the software may be handled by the one or more servers of the software distribution platform and/or by a third party payment entity. The servers enable purchasers and/or licensors to download the machine readable instructions <NUM> from the software distribution platform <NUM>. For example, the software, which may correspond to the example machine readable instructions <NUM>, <NUM> of <FIG>, may be downloaded to the example processor platform <NUM>, which is to execute the machine readable instructions <NUM> to implement the agent <NUM> and/or the scheduler <NUM>. In some example, one or more servers of the software distribution platform <NUM> periodically offer, transmit, and/or force updates to the software (e.g., the example machine readable instructions <NUM> of <FIG>) to ensure improvements, patches, updates, etc., are distributed and applied to the software at the end user devices.

From the foregoing, it will be appreciated that example systems, methods, apparatus, and articles of manufacture have been disclosed that increases boot performance. The disclosed systems, methods, apparatus, and articles of manufacture improve the efficiency of using a computing device by executing boot tasks with processor components during a boot based on a learning boot table that result in increased speed, increased performance, and/or decreased power usage of a boot process. The learning boot table is developed during a training phase, where the performance of tasks are evaluated on one or more processor component types to determine which processor component type is best for each task. In this manner, during subsequent boots, the ideal processor component type can be used for each boot task to increase performance. The disclosed systems, methods, apparatus, and articles of manufacture are accordingly directed to one or more improvement(s) in the operation of a machine such as a computer or other electronic.

Although certain example systems, methods, apparatus, and articles of manufacture have been disclosed herein, the scope of coverage of this patent is not limited thereto. On the contrary, this patent covers all systems, methods, apparatus, and articles of manufacture fairly falling within the scope of the claims of this patent.

Claim 1:
A method comprising:
during a boot process:
identifying (<NUM>), by executing an instruction with one or more processors, a boot task that is to be performed during the boot process;
executing (<NUM>) the boot task using a first processor component;
collecting (<NUM>) data corresponding to the execution of the boot task on the first processor component, wherein the data corresponds to at least one of performance data of the boot task executed on the first processor component or operational data from a hardware agent;
categorizing (<NUM>), by executing an instruction with the one or more processors, the boot task into a task category and/or to a processor component type based on at least one of the performance data of the boot task executed on the first processor component or the operational data from the hardware agent; and
generating (<NUM>), by executing an instruction with the one or more processors, an entry for a boot table, the entry comprising a boot task identifier and the corresponding categorized task category and/or the corresponding categorized processing component type, the boot table used to schedule the boot task on at least one of the first processor component or a second processor component different than the first processor component based on the categorization,
during a subsequent boot process:
accessing the boot table; and
scheduling a second boot task of the subsequent boot process based on a categorization of from the boot table that corresponds to the second boot task.