Distributing firmware boot tasks to enable low-latency boot performance

Abstract

To provide a performance-enhanced computing system configured to reduce inefficient boot process and boot latency even after multicores become available, a semiconductor device, a method, and a program.SOLUTION: A boot processing method includes: identifying, during a first boot process, whether at least one task associated with at least one software program is set to occur in a single-threaded process or a multithreaded process; in response to the at least one task being set to occur in the multithreaded process, executing the at least one task in the multithreaded process during the first boot process; and in response to the at least one task being set to occur in the single-threaded process, executing the at least one task in the single-threaded process during the first boot process.SELECTED DRAWING: Figure 2

Description

[Technical Field]

[0001] [CROSS-REFERENCE TO RELATED APPLICATIONS] This application claims priority to Indian Patent Application No. 202041042915 filed on October 2, 2020.

[0002] Embodiments relate generally to enhanced firmware updates and, more particularly, to firmware boot processes, where, among other things, singleton processes, such as firmware updates, can be identified and executed concurrently with other boot process tasks to reduce boot flow latency and also reduce computing resources. [Background technology]

[0003] Some applications and computing architectures may strive to achieve reduced or near-instantaneous system boot times. The boot process may include updating firmware, such as the basic input / output system (BIOS), unified extensible firmware interface (UEFI), system-on-chip (SoC) firmware (e.g., silicon hardware), and platform firmware. Firmware updates may impede system performance, particularly during boot time due to high-latency and serial operations. For example, firmware updates may occur during a boot path in which the entire boot process is sequential. Therefore, it may be difficult, if not impossible, to meet latency expectations that would allow system firmware to complete all device (e.g., SoC and platform) firmware processes and / or updates (e.g., measuring firmware components, verifying firmware components, loading firmware onto devices, and retrieving firmware versions to ensure successful firmware updates) within a desired time window (e.g., 500 ms to less than 1 sec). [Brief explanation of the drawings]

[0004] Various advantages of the embodiments will become apparent to those skilled in the art upon reading the following specification and appended claims, and upon reviewing the following drawings.

[0005] [Figure 1] 1 is an example process for an informed boot process, according to one embodiment.

[0006] [Figure 2] 1 is a flowchart of an example method of boot processing that may be performed in a multi-threaded environment and / or a single-threaded environment, according to one embodiment.

[0007] [Figure 3] 1 is a flowchart of an example of a beneficial method of boot processing that may be performed based at least on previous boot data, according to one embodiment.

[0008] [Figure 4] 1 is a flowchart of an example of a method for performing a normal boot process, according to one embodiment.

[0009] [Figure 5] 1 is a flowchart of an example of a method for performing a boot process associated with a firmware update mode, according to one embodiment.

[0010] [Figure 6] 1 is a flowchart of an example of a method for performing a self-tuning related boot process, according to one embodiment.

[0011] [Figure 7] FIG. 2 is a schematic diagram of an example of a separated communication flow, according to one embodiment.

[0012] [Figure 8] 1 is an example process of a communication process according to one embodiment.

[0013] [Figure 9] FIG. 2 is a schematic diagram of an example monitor, according to one embodiment.

[0014] [Figure 10] FIG. 2 is a schematic diagram of an example memory architecture, according to one embodiment.

[0015] [Figure 11] FIG. 1 is a block diagram of an example computing system, according to one embodiment.

[0016] [Figure 12] 1 is an illustration of an example semiconductor device, according to one embodiment.

[0017] [Figure 13] FIG. 2 is a block diagram of an example processor, according to one embodiment.

[0018] [Figure 14] FIG. 1 is a block diagram of an example of a multiprocessor-based computing system, according to one embodiment. DETAILED DESCRIPTION OF THE INVENTION

[0019] To efficiently use existing processor power and system resources through boot loaders or firmware software (e.g., firmware support packages [FSPs]) that initiate SoC elements and / or platform devices, some architectures may lack the intelligence required for firmware boot processing. For example, even with the availability of multiple cores, the entire boot process update and / or initialization process may occur in a single-threaded environment on a single bootstrap processor (BSP). Such an inefficient boot process has increased boot latency due to waiting for sequential firmware updates, hardware initialization, and / or code execution to complete. Therefore, such a boot process results in long wait times for the firmware and / or boot loader to complete execution on the BSP. Furthermore, performing the entire boot process in a multithreaded environment may unnecessarily consume resources in portions of the boot process that would be more efficient in a single-threaded environment due to increased complexity, adaptation to a multithreaded environment, and / or increased difficulty in intercommunication.

[0020] 1, some embodiments include a flexible boot management process 100 in which some boot phases may operate in a single-threaded environment and other boot phases may operate in a multi-threaded environment. By alternating between a single-threaded environment and a multi-threaded environment, process 100 may streamline operation and reduce power consumption while also reducing latency, as opposed to a boot process that runs only in a single-threaded environment or a boot process that runs only in a multi-threaded environment. Furthermore, various tasks and stages may be divided and executed across an array of processor cores, such as first processor core 114, second processor core 124, third processor core 126, and fourth processor core 128.

[0021] That is, some embodiments implement an informed boot process by identifying scenarios that initiate parallel processing in the boot process by executing singleton tasks (e.g., firmware updates for silicon components on an SoC) that may be executed concurrently with boot loader tasks (e.g., boot stage tasks associated with a platform device). Boot loader 120 may act as a context master in the computing system and allocate resources (e.g., processor cores) between firmware tasks and the boot loader. For example, boot loader 120 (e.g., BIOS, UEFI, etc.) may access a data structure that identifies when to begin operating in a multithreaded environment. The data structure may be referred to as an information enhancement table (IET) and may be set during a previous execution of a previous boot process and / or during execution of the system's operating system (OS). Flexible boot management process 100 may be referred to as a first boot process, and the previous boot process may be referred to as a second boot process. A previous boot process (e.g., hard boot, soft boot, warm boot, cold boot, etc.) may have completed loading an OS prior to flexible boot management process 100 (e.g., the first boot process and / or the current boot process), and enhancements may be identified based on latencies identified during the previous boot process to enhance flexible boot management process 100 (e.g., performing longer latency firmware processes in multithreading). For example, the previous boot process may complete booting the system and loading an OS. Thereafter (e.g., after the OS is loaded by the previous boot process), the system may be classified into different states (e.g., mode switch, sleep state, hibernation state, soft-off state, mechanical-off state, etc.). Flexible boot management process 100 may then initiate booting from a different state to a fully operational state (e.g., booting into an OS fully operational for user use) to selectively apply certain processes in a multithreaded environment based on the IET.For example, one or more of the firmware or the OS may configure the IET based on an analysis of a previous boot operation to indicate that one or more of a firmware update or firmware execution to start a hardware device may be performed in a multithreaded environment in a boot operation after the previous boot operation. For example, if firmware is identified as having an execution latency during a previous boot operation that exceeds a threshold, the IET may be configured to indicate that the firmware will be initialized and executed in a multithreaded environment during the next boot operation. The IET may also include an indication that the firmware will be updated in a multithreaded environment. The boot loader 120 may further address memory allocation (e.g., utilizing various levels and types of cache and / or memory) to avoid memory shortages in the pre-memory phase for performing operations in parallel. Thus, the boot operation 100 may include multithreaded firmware execution to reduce hardware initialization time and / or perform SoC firmware updates and hardware initialization in parallel with platform device firmware updates and hardware initialization, reducing firmware update and initialization time and overall latency of the boot operation. Notably, not all operations may be configured in a multithreaded environment. Rather, only those processes identified as having longer latencies during the previous boot process may be executed in a multi-threaded environment during process 100, while other lower latency processes may be executed in a single-threaded environment.

[0022] 1 , a single-threaded environment operates from time T0 to T1 (e.g., a first time period), while a multi-threaded environment operates from time T1 to T2 (e.g., a second time period). Between time T0 and T1, the computing system may execute a first boot stage 102 on a first processor core 114. For example, the first boot stage 102 may load a boot loader from system storage (e.g., a boot block, boot selector, or partition) and boot the system. Such operations may be performed before other firmware updates and initializations may occur in parallel, thus avoiding unnecessary multi-threaded operations by executing in a single-threaded environment.

[0023] Then, at time T1, to enhance performance and reduce overall boot time, process 100 may identify from the IET that firmware-related processes can be executed in parallel in a multithreaded environment. Accordingly, the system may switch to a multithreaded environment in which first processor core 114, second processor core 124, third processor core 126, and fourth processor core 128 may be divided between firmware-related tasks for components of the SoC and other boot-stage tasks. For example, a boot loader may assign, and if necessary, reallocate, first processor core 114, second processor core 124, third processor core 126, and fourth processor core 128 to perform either SoC-related firmware updates or other boot-stage tasks.

[0024] In some embodiments, the first processor core 114 may correspond to a BSP and may execute the first firmware task 104 to initiate the multithreaded environment. The first processor core 114 may then execute boot stage tasks, including firmware tasks for platform components external to the SoC and / or communicatively coupled to the SoC. The second processor core 124, the third processor core 126, and the fourth processor core 128 may execute boot stage tasks or firmware tasks (e.g., hardware initialization and / or firmware updates) in the multithreaded environment. In this example, the first processor core 114 and the second processor core 124 may be associated with (e.g., and / or dedicated to) boot loader tasks and execute boot stage tasks (including firmware platform initialization), while the third processor core 126 and the fourth processor core 128 may be assigned and / or dedicated to execute firmware tasks for the SoC.

[0025] In a multi-threaded environment, processes may run in parallel. For example, a first firmware task 104 may execute on a first processor core 114. The first firmware task 104 may initialize temporary random access memory (RAM) along with any other initial initialization.

[0026] The second boot stage (e.g., initializing memory such as dynamic random access memory and preparing the platform device for startup) may be divided into a first subset of tasks and a second subset of tasks. The first subset of tasks may be referred to as second boot stage tasks 106a, and the second subset of tasks may be referred to as second boot stage tasks 106b. The first subset of tasks may be different from the second subset of tasks. Concurrently with executing the first firmware task 104 on the first processor core 114, the second boot stage tasks 106a may execute on the second processor core 124. After the first firmware task 104 is completed on the first processor core 114, the first processor core 114 may execute the second boot stage tasks 106b. The second boot stage tasks 106a and the second boot stage tasks 106b may execute simultaneously for a period of time.

[0027] The update and / or execution of the second firmware (e.g., initializing persistent memory along with any other initial silicon initialization may be a firmware support package) may be divided into a first subset of tasks referred to as second firmware tasks 108a and a second firmware of tasks referred to as second update tasks 108b. The second firmware tasks 108a may execute on the third processor core 126, and the second update tasks 108b may execute on the fourth processor core 128. As shown, the second boot stage tasks 106a, 106b, second firmware tasks 108a, and second firmware tasks 108b may execute simultaneously on the first processor core 114, the second processor core 124, the third processor core 126, and the fourth processor core 128.

[0028] After second boot stage task 106a is completed, second processor core 124 may execute third boot stage 110 (e.g., discarding caches as RAM architecture utilized during the earlier boot stages and loading RAM stages). Third firmware updates and / or tasks (e.g., completing silicon initialization, including initialization of the central processing unit (CPU) and input / output (I / O) controllers) may be divided into a first subset of tasks that may be referred to as third firmware tasks 112a and a second subset of tasks that may be referred to as third firmware tasks 112b. Third processor core 126 may execute third firmware tasks 112a, while fourth processor core 128 may concurrently execute third firmware tasks 112b. As shown, third boot stage 110, second boot stage task 106b, third firmware tasks 112a, and third firmware tasks 112b may execute concurrently.

[0029] A fourth boot stage (e.g., starting peripheral component interconnect (PCI) devices, starting trusted platform modules, starting graphics, and / or starting major devices, such as others) may be divided into a first subset of tasks that may be referred to as fourth boot stage tasks 130a and a second subset of tasks that may be referred to as fourth boot stage tasks 130b. Fourth boot stage tasks 130a may execute on first processor core 114, and fourth boot stage tasks 130b may execute on second processor core 124. As shown, fourth boot stage tasks 130a, fourth boot stage tasks 130b, third firmware task 112a, and third firmware task 112b may execute concurrently.

[0030] At time T2, boot loader 120 may continue to execute. For example, boot loader 120 may pass a kernel boot partition buffer created during the boot process to boot operating system 116. Operating system 116 may then be loaded at time T3.

[0031] Thus, as shown above, process 100 can seamlessly shift between single-threaded and multi-threaded environments to efficiently load operating system 116 with reduced latency, thereby significantly reducing the time to load as opposed to a fully single-threaded boot process and reducing inefficiencies (e.g., software complexity and communication difficulties) that result from a fully multi-threaded boot process.

[0032] For example, in a completely single-threaded boot process environment, firmware initialization (e.g., SoC firmware) may be idle while a boot loader executes on the BSP, which in turn may be idle while the SoC firmware executes on the BSP. Such serialized processing results in separate, serial platform initialization, with each independent device (e.g., processor core) initialization and / or update waiting its own execution time or turn (e.g., serially). Furthermore, running each firmware update serially may be an inefficient use of processor power because not all computing resources are utilized. This results in longer platform boot times, inefficient use of resources, and a poor user experience. Users may then avoid approving firmware updates, which may result in avoided updates that could result in adverse performance, such as platform security issues.

[0033] Furthermore, in a fully multithreaded boot processing environment, some static tasks may execute in parallel threads, but the default static nature of multithreaded booting can increase complexity and complicate other aspects (e.g., debugging, development, communication, concurrency management, porting of existing code, context switch overhead, etc.). Thus, some embodiments include beneficial boot processes that avoid forcing the platform into fully multithreaded or single-threaded execution unless an advantage is identified from the IET data structures described above. Some aspects described herein may be implemented in a single application programming interface system.

[0034] 2 illustrates a method 300 for performing a boot process that may run in a multithreaded environment, a single-threaded environment, or may cycle between multithreaded and single-threaded environments. Method 300 may be implemented in a computing system generally and / or in conjunction with process 100 (FIG. 1). More specifically, method 300 may be implemented as one or more modules: a set of logic instructions stored in a machine- or computer-readable storage medium, such as random access memory (RAM), read-only memory (ROM), programmable ROM (PROM), firmware, flash memory, etc.; configurable logic, such as a programmable logic array (PLA), FPGA, or complex programmable logic device (CPLD); fixed-function hardware logic using circuit technology, such as an application-specific integrated circuit (ASIC), complementary metal-oxide semiconductor (CMOS), or transistor-transistor logic (TTL) technology, or any combination thereof.

[0035] Illustrated processing block 302 identifies whether at least one task associated with at least one software program is configured to occur in single-threaded processing or multi-threaded processing during the first boot process. Processing block 310 determines (e.g., with reference to an IET) whether at least one task is configured to occur in a multi-threaded environment. If so (e.g., in response to at least one task being configured to occur in multi-threaded processing), illustrated processing block 304 executes at least one task in multi-threaded processing during the first boot process. Illustrated processing block 306 executes at least one task in single-threaded processing during the first boot process when processing block 310 determines that at least one task does not execute in a multi-threaded environment (e.g., in response to at least one task being configured to occur in single-threaded processing). In some embodiments, the at least one software program is firmware associated with the system-on-chip.

[0036] Some embodiments of method 300 include performing at least one boot step in a single-threaded manner during a first portion of a first boot process, and performing at least one task in a multi-threaded manner during a second portion of the first boot process. Some embodiments of method 300 include identifying that the at least one task occurs in a multi-threaded manner during the first boot process, dedicating a first group of processor cores of a host processor of the SoC to the at least one task, and dedicating a second group of processor cores of the host processor to executing firmware associated with a hardware device communicatively coupled to the SoC.

[0037] Some embodiments of method 300 include determining a time to execute at least one task during the second boot process, determining that the at least one task is updated in a multithreaded process based on the time, storing identification information in a data structure that the at least one task occurs in a multithreaded process, accessing the data structure during the first boot process to identify that the at least one task occurs in a multithreaded process, and executing the at least one task in a multithreaded process during the first boot process. In some embodiments of method 300, the at least one task includes one or more of updating or executing at least one software program.

[0038] 3 illustrates a method 350 for performing a beneficial boot process based at least on previous boot data. As previously described, method 350 may generally be implemented in a computing system and / or in conjunction with process 100 (FIG. 1) and / or method 300 (FIG. 2).

[0039] More specifically, method 350 may be implemented as one or more modules: a set of logical instructions stored in a machine or computer-readable storage medium such as RAM, ROM, PROM, firmware, flash memory, etc.; configurable logic such as a PLA, FPGA, CPLD, etc.; fixed-function hardware logic using circuit technologies such as ASIC, CMOS, or TTL technology, etc.; or any combination thereof.

[0040] Method 350 can inform booting by analyzing and understanding various scenarios that initiate parallelism in the booting process by executing singleton tasks that can run concurrently with the booting process. The boot loader can act as a context master that allocates processor cores. For example, in a first portion of method 350, the platform basic input / output system (BIOS) can be equipped with information to identify when to begin operating in a multithreaded environment.

[0041] Some embodiments may therefore use all available processing cores (e.g., microprocessors) to perform platform-wide firmware initialization and updates in parallel. Doing so may significantly reduce firmware update latency and increase the likelihood that a system will not experience outages due to errors in firmware updates or avoidance of such updates. Some embodiments may further define new communication flows between the boot loader and SoC firmware (e.g., FSP) using a beneficial multi-core environment to ensure parallel execution for faster boot processing when efficiency is most desired. Some embodiments may therefore include opportunistic platform booting by predicting when to initiate multi-threaded booting to optimize boot time.

[0042] Illustrated processing block 352 may include performing a power cycle (e.g., a system reset) that may cause the boot loader to load. In illustrated processing block 354, control may be passed to the boot loader, which may read the IET. For example, the boot loader may use a real-time clock (RTC) and / or an upper CMOS block (e.g., 128 bits) of memory to generate the IET during a previous boot, and then an informative decision may be made by runtime services during the previous execution of the OS. The previous boot may be referred to as a second boot process. The previous boot may complete booting the system into the OS. Illustrated processing block 352 may power cycle the system, at which point the OS (booted by the second boot process) may execute to restart the system and execute method 350. Method 350 may be referred to as a first boot process. Some embodiments may not initiate multi-threaded booting unless the process detects a specific pattern or opportunity for reduced boot performance latency and performance enhancement.

[0043] For example, in order for a boot loader (e.g., firmware such as a BIOS or UEFI) to make decisions usefully and efficiently, the boot loader may have a learning feed from the operating system (OS) layer to the runtime services layer (e.g., firmware such as a BIOS or UEFI) to receive identification information for efficient multi-threaded operations. For example, the boot loader may perform platform initialization and boot the OS. If such operations were performed in only a single-threaded environment, the decision and analysis flow may result in longer latency.

[0044] Thus, some embodiments may rely on an OS environment in which a runtime service (e.g., BIOS or UEFI) may be used to perform some, but not all, analysis and decisions and store them in an IET (e.g., a data structure) that is accessed during the next boot (e.g., first boot process). A boot loader may access the IET and information contained in the IET to determine when to run a multi-threaded environment.

[0045] To facilitate such determination and storage between the OS layer and lower layers (e.g., BIOS or UEFI) and between lower layers and the OS layer, some embodiments may access hardware-based memory (e.g., CMOS memory and / or RTC memory) to store an IET that remains available across boot cycles and may survive platform power cycles. During boot, the boot loader may allocate the IET structure in persistent memory. After boot when the OS is loaded, the IET structure may be accessed and modified to include an indication of whether multi-threaded boot processing is preferred during the next boot cycle. Pseudocode for implementing the IET is provided below, where "FEEDCODE" is the table signature. [Table 1] [Pseudocode 1]

[0046] The illustrated processing block 356 may verify whether the IET is valid. For example, processing block 356 may read the signature of the IET to identify whether the signature is valid. If the signature can be verified, the IET may be valid. If the signature is invalid, the IET may not be valid.

[0047] Thus, if the IET is disabled, then illustrated process block 366 may perform a normal boot process without further modification to avoid switching between single-threaded mode and multi-threaded mode (e.g., perform only single-threaded mode or only multi-threaded mode without switching between them). If the IET is enabled, illustrated process block 358 determines whether sufficient storage is available to perform a modified boot process to perform a multi-threaded boot.

[0048] For example, a multithreaded boot may be performed before all memory and storage resources are available (e.g., DRAM resources are not available). Some components that may be included in the initial boot (e.g., to update microcode, security firmware, power management controller firmware, or Trusted Platform Manager) may be executed in a multithreaded environment for parallel execution. If dedicated memory is not available to allow all cores to be available to execute parallel operations for the useful boot process, some embodiments may provide an alternative to pre-initialized memory. As described in some embodiments, some embodiments may include hardware modifications that provide sufficient memory for useful boot utilization. For example, some embodiments may access a lower-level cache (e.g., L4 cache) to reduce memory access latency compared to DRAM access. Some embodiments may further use any of the package caches available on modern SoC dies as static RAM (SRAM) for firmware access without any further initialization. Some embodiments may include a package cache available as part of a lower-level cache (LLC) that firmware uses when physical memory is not present by executing a memory initialization flow. Therefore, some embodiments may be independent of DRAM memory initialization, so that the processing core is installed before the DRAM is initialized.

[0049] If sufficient storage is unavailable, then process block 366 executes. In some embodiments, if process block 358 determines that storage is unavailable (e.g., a previous request to start a multithreaded environment is unavailable), method 350 may again execute process block 354 (e.g., return to this analysis and re-execute processing until memory is available).

[0050] Otherwise, illustrated processing block 360 may again refer to the IET to detect whether the firmware update mode is selected in the IET. Specifically, the IET may include identifying information (e.g., from a previous boot of the OS) indicating whether a prediction corresponding to the firmware update mode is set. For example, during a previous execution of the OS, the OS may determine that firmware for a peripheral, SoC component, or other device has been updated. Runtime firmware (e.g., BIOS runtime or UEFI runtime) may set a firmware update request bit in the IET to indicate that the firmware for the peripheral or other device will be updated during the next boot cycle. If the firmware update request bit is set in the IET, then processing block 362 executes the firmware update mode in a multithreaded environment.

[0051] If not, illustrated process block 368 determines whether self-tuning mode is selected. Process block 368 may do so by reference to the IET (e.g., execute self-tuning mode if the IET includes an indication that self-tuning mode is to be used). If so, illustrated process block 364 executes self-tuning mode in a multithreaded environment, selectively executing some firmware tasks in parallel. If the boot process (e.g., firmware execution and initialization of hardware associated with the firmware) has a latency that exceeds a threshold identified during a previous boot process, self-tuning mode may be set and executed by the IET.

[0052] For example, after a platform boots an OS, a runtime service may analyze boot performance data and make beneficial calls to enhance the platform's boot time. During the boot process, various firmware timings may be recorded as firmware entries. After boot, if any boot performance of a firmware entry has a recorded execution time that exceeds a threshold (e.g., 100 ms), then the firmware of the firmware entry may be subject to beneficial boot enhancement (e.g., a self-tuning mode may be set to execute the firmware in parallel during the next boot cycle). Firmware identified as having timings that exceed the threshold may be recoded (post-boot) into the IET. Processing block 368 may access the IET to retrieve and identify firmware that will execute in parallel during the boot process based on previous latencies that exceed the threshold.

[0053] If self-tuning mode is not selected, processing block 366 performs normal boot processing. It is worth noting that processing block 366 may perform a firmware update. Such an update by processing block 366 may be omitted when processing block 362 executes because processing block 362 has already updated the firmware.

[0054] If self-tuning mode is selected, process block 364 executes the self-tuning mode in a multi-threaded environment. Process 346 shown boots the OS with runtime services and updates the IET. Such aspects are described above. Some embodiments may provide enhanced and better CPU resource (core) utilization in the boot block. To reduce boot time and support a faster boot process, some embodiments may execute parallel device initialization and / or FW update blocks.

[0055] Additionally, some embodiments of method 350 may be executed during a mode switch, such as when a user switches from "normal" mode to "developer" or "recovery" mode, performing a "power-wash" to restore factory settings in which the underlying BIOS must initialize additional debug controllers (XHCI, XDCI, DAM) or retrain memory controllers within a fixed boot budget. Thus, processing block 352 may be replaced by a switch mode, power-wash, etc. In another example, the entire boot (e.g., even after multiple cores become available ~650ms after the CPU) may occur in a single-threaded environment running only on the bootstrap processor (BSP).

[0056] 4 illustrates a method 370 for performing a normal boot process, according to some embodiments. Method 370 may generally replace process block 366 (FIG. 3). More specifically, method 370 may be implemented as one or more modules: a set of logical instructions stored in a machine- or computer-readable storage medium, such as RAM, ROM, PROM, firmware, flash memory, etc.; configurable logic, such as a PLA, FPGA, CPLD, etc.; fixed-function hardware logic using circuit technologies, such as ASIC, CMOS, or TTL technology, etc.; or any combination thereof.

[0057] As shown, firmware initialization and update firmware program 372 (e.g., firmware support package program and / or update program) and boot program 374 may be responsible for booting a computing device, with operations listed under the actor that performs the operation. For example, firmware program 372 may be responsible for updating SoC firmware and initializing SoC hardware components, such as silicon components including the processor, memory controller, chipset, and specific bus interfaces. Boot program 374 may initialize and update platform firmware (e.g., non-SoC devices), set clocks in the clock tree, start and calibrate memory, such as SDRAM, RAM, and ROM, initialize flash memory, load an OS from memory (e.g., flash memory), and set pin muxing and pin settings (e.g., slew rate, voltage, and pull-up / pull-down) that pass control to the OS.

[0058] Illustrated processing block 376 includes a boot program 374 that makes cache-on-RAM available. Optionally, firmware program 372 may execute processing block 378 to make cache-on-RAM available. It will be understood that in some embodiments, processing block 378 may be executed and processing block 376 may be bypassed. Illustrated processing block 380 includes a boot loader that invokes memory initialization (e.g., DRAM). Illustrated processing block 382 initializes memory. Illustrated processing block 384 invokes hardware component initialization. In response, illustrated processing block 386 initializes the hardware components. Illustrated processing block 388 invokes signaling phases and may further enumerate peripheral component interconnects (PCIs). In response, illustrated processing block 390 signals phases (e.g., firmware exit, prepare for boot, post PCI enumeration). Illustrated processing block 392 loads the operating system. Illustrated processing block 394 updates runtime services to the IET as described herein based on the latency identified during method 370 and / or the firmware update.

[0059] It is worth noting that in some embodiments, firmware program 372 may also update firmware as needed. For example, if processing block 362 (FIG. 3) is bypassed, firmware program 372 may update firmware as needed. If processing block 362 (FIG. 3) is executed, firmware updates may be bypassed.

[0060] 5 illustrates a method 400 for performing a boot process associated with a firmware update mode, according to some embodiments. Method 400 may generally replace process block 360 (FIG. 3). More specifically, method 400 may be implemented as one or more modules: a set of logical instructions stored in a machine- or computer-readable storage medium, such as RAM, ROM, PROM, firmware, flash memory, etc.; configurable logic, such as a PLA, FPGA, CPLD, etc.; fixed-function hardware logic using circuit technologies, such as ASIC, CMOS, or TTL technology, etc.; or any combination thereof.

[0061] As shown, the SoC firmware update program 402 (e.g., a firmware support package program and / or an SoC device update program) and the boot program 404 may be responsible for booting a computing device, with operations listed under the actor that performs the operation. For example, the SoC firmware update program 402 may be responsible for updating the SoC firmware of silicon components including the processor, memory controller, chipset, and specific bus interfaces. The boot program 404 may configure other platform devices (e.g., non-SoC devices), such as setting clocks in the clock tree, powering up and calibrating memory such as SDRAM, RAM, and ROM, initializing flash memory, loading an OS from memory (e.g., flash memory), and passing control to the OS, such as pin multiplexing and pin settings (e.g., slew rate, voltage, and pull-up / pull-down).

[0062] As described below, method 400 may relate to advantageous task scheduling and resource allocation (e.g., CPU resources, etc.) to reduce boot time. For example, method 400 may be an advantageous multi-threaded BIOS implementation.

[0063] Initially, the boot program 404 (e.g., a boot loader) executes the illustrated process block 406 to allocate processor cores. For example, the boot program 404 may allocate each processor core of the host processor to the boot program 404 or the SoC firmware update program 402. In some embodiments, the boot program 404 may identify the number of cores to efficiently execute the operations of the boot program 404 and the SoC firmware update program 402 in parallel. The boot program 404 may further set certain fields (e.g., updatable product data) to enable the boot program 404 to execute a platform firmware update on at least one processor (e.g., a bootstrap processor) while a silicon firmware update is executing on another processor (e.g., an application processor).

[0064] Illustrated process block 408 updates platform memory firmware in a multithreaded environment. Illustrated process block 410 updates SoC memory firmware in a multithreaded environment. Illustrated process block 412 updates platform hardware component firmware in a multithreaded environment. Illustrated process block 414 updates SoC hardware component firmware in a multithreaded environment. Illustrated process block 416 updates platform peripheral component firmware in a multithreaded environment. Illustrated process block 418 updates firmware and signals a phase (e.g., firmware finalization, boot preparation, post PCI enumeration). Process block 420 may initialize the updated firmware and associated hardware. It will be understood that one or more of the above process blocks 406, 408, 410, 412, 414, 416, and 418 may be omitted if the corresponding firmware does not need to be updated.

[0065] In some embodiments, method 400 may boot an OS. After a period of time (e.g., ∼20 seconds after logging into the OS's user interface and / or console), a runtime service may automatically trigger and reset the PET table's indication that a firmware update is desired (e.g., resetting the "FW_Update" variable). The PET table may then be set if a firmware update is desired during the next boot cycle.

[0066] 6 illustrates a method 448 for performing a self-tuning-related boot process, according to some embodiments. As previously described, method 448 may generally replace process block 368 (FIG. 3). More specifically, method 448 may be implemented as one or more modules: a set of logical instructions stored in a machine- or computer-readable storage medium, such as RAM, ROM, PROM, firmware, flash memory, etc.; configurable logic, such as a PLA, FPGA, CPLD, etc.; fixed-function hardware logic using circuit technologies, such as ASIC, CMOS, or TTL technology, etc.; or any combination thereof.

[0067] As shown, two different actors may boot a computing device. For example, SoC firmware initialization 446 (e.g., firmware support package programs and / or updates) and boot program 444 may be responsible for booting a computing device. Actions are listed under the actor that performs the action.

[0068] Some embodiments relate to self-tuning firmware boot enhancement. For example, after a first platform boot into an OS, a runtime service (e.g., BIOS) may perform a boot performance analysis to identify whether certain boot entries can execute in parallel and reduce the platform's boot time. Such boot performance analysis may be self-tuning or self-learning and may include predefined training parameters (e.g., "reduce boot time for entries with execution times greater than 100 ms"). Such training data may be obtained as part of an updatable script for the OS, allowing for modifications if boot time enhancement goals are more aggressive for a particular platform (e.g., Internet of Things compared to client devices).

[0069] For example, the runtime service may generate a boot entry list for the firmware program to be enhanced (e.g., write it to a specific entry as part of an IET table, such as a "Buffer[]" data variable) and set a bit (e.g., a "Self_Tuning_Boot" bit) indicating that the firmware program will be executed in parallel. The bit may inform the boot phase that a boot entry list is available so that the boot process can enter self-tuning mode and read the boot entry list. For example, processing block 368 (FIG. 3) and / or method 448 may read the "Self_Tuning_Boot" bit in the IET to determine whether self-tuning mode is selected.

[0070] Thus, during the next successive boot, the boot phase may extract the IET table after verifying that the IET table is valid, may read the "Self_Tuning_Boot" bit to determine that firmware is to be hardened by running in parallel, and may read the boot entry list to identify the list of firmware, such processing being described below, in response to the IET table including an indication that the firmware is to be run in parallel.

[0071] 5 , the boot program 444 may execute the illustrated processing block 426 to allocate all possible cores or a subset of cores between the SoC firmware initialization 446 and the boot program 444. Some embodiments may read through the IET's boot enhancement entry list (Buffer[0..n]) and determine whether each firmware is associated with the boot program 444 or the SoC executed by the SoC firmware initialization 446. Based on the above determination, the boot program 444 may allocate a multi-core division between the boot program 444 and the SoC firmware initialization 446 so that each of the boot program 444 and the SoC firmware initialization 446 can efficiently execute the firmware. For example, if the enhancement boot entry corresponds only to the SoC firmware initialization 446, then the boot program 444 (e.g., a boot loader) may allocate all cores (including the BSP) to the SoC firmware initialization 446 for parallel execution. Conversely, if the enhancement's boot entry corresponds only to boot program 444, then all cores may be assigned to boot program 444. Thus, boot program 444 may assign cores relatively to SoC firmware initialization 446 and boot program 444 based on workload. Boot program 444 and SoC firmware initialization 446 may continue to run in parallel.

[0072] Illustrated process block 428 includes invoking SoC memory initialization and performing platform memory operations in a multithreaded environment. Although not shown, platform memory initialization not identified in the IET for multithreaded execution may be performed in a single-threaded environment. Illustrated process block 430 selectively initializes SoC memory in a multithreaded environment based on the IET. Although not shown, SoC memory not identified in the IET for multithreaded execution may be performed in a single-threaded environment.

[0073] Illustrated processing block 432 invokes initialization of hardware components and performs platform hardware operations (e.g., initialization, etc.). Although not shown, initialization of platform hardware not identified in the IET for multithreaded execution may be performed in a single-threaded environment. Illustrated processing block 434 selectively initializes SoC hardware components in a multithreaded environment based on the IET. Although not shown, initialization of SoC hardware components not identified in the IET for multithreaded execution may be performed in a single-threaded environment. Illustrated processing block 436 initializes platform peripheral components. Although not shown, initialization of platform peripheral components not identified in the IET for multithreaded execution may be performed in a single-threaded environment. Illustrated processing block 438 selectively initializes firmware in a multithreaded environment and notifies it of a phase. Although not shown, firmware for a phase not identified in the IET for multithreaded execution may be performed in a single-threaded environment.

[0074] Some embodiments may also load the OS. Some embodiments may also store runtime services to update the IET. For example, after the end of firmware initialization and booting of the OS, the runtime services may again proceed to analyze boot performance data using an informative boot, and may store firmware to be updated in parallel in the IET so that some devices (e.g., "hybrid storage," "initializing eMMC," etc.) operate in parallel to improve platform response time.

[0075] It is worth noting that firmware operations and / or initializations not identified in the IET as being capable of executing in a multi-threaded environment may be executed in a single-threaded environment before or after method 448. Additionally, in some embodiments, method 400 (FIG. 5) may complete execution and method 448 may execute immediately thereafter.

[0076] 7, a separate communication flow 480 may separate the unidirectional communication flow between the boot loader and the firmware. Separate communication flow 480 may generally be implemented in conjunction with a computing system and / or previously described process 100 (FIG. 1), method 300 (FIG. 2), method 350 (FIG. 3), method 370 (FIG. 4), method 400 (FIG. 5), and / or method 448 (FIG. 6).

[0077] For example, a single-threaded environment may be implemented on a first core 462. The first core 462 may execute a boot thread 464. The first core 462 may then execute a firmware thread 466. The firmware thread 466 (e.g., FSP) and the boot thread 464 may rely on synchronization 468 to pass control between the boot thread 464 and the firmware thread 466.

[0078] In contrast, a multithreaded environment may not require such synchronization to pass control between first core 482, second core 488, third core 490, and fourth core 496. First core 482 may execute first boot thread 484, and second core 488 may execute second boot thread 486. First boot thread 484 and second boot thread 486 may be associated with boot processes, such as starting the device's platform. Third core 490 and fourth core 496 may execute first FSP thread 492 and second FSP thread 494, respectively, to update and initiate SoC-related firmware.

[0079] For example, some embodiments may provide a choice between a boot loader and firmware and execute tasks in parallel with a thread-saving mechanism using dedicated data structures such as the UPD (e.g., without extra resources for core synchronization between the boot loader and firmware). For example, some embodiments as described herein implement a high-level synchronization construct as a "monitor" type in the firmware and allocate tasks within the firmware with multiple cores remaining synchronized to avoid any overlapping accesses. The monitor construct ensures that only one processor at a time can be given access to a task. Some embodiments as described herein use special instructions (e.g., MONITOR / MWAIT instructions) to reduce the latency between core operation time and wake-up from idle time. Some embodiments of the firmware as described herein use semaphores to access potentially shared resources within the FSP and / or boot loader.

[0080] Some embodiments relate to underlying mechanisms for core synchronization. Firmware (e.g., BIOS) may divide a single task, such as device initialization or update, into multiple subtasks and assign the subtasks to multiple cores to operate in parallel. Thus, some embodiments may use semaphores to provide a low-latency, efficient, and effective mechanism for core synchronization. Some embodiments may "monitor" synchronization constructs for core synchronization within firmware 504 (e.g., FSP) to ensure that a task is only attempted and executed by one core at a time.

[0081] Some embodiments may further ensure that other cores are not starved and may provide a deadlock-free solution by imposing the restriction that a core may pick up a task if both the task and the core are available. For example, some embodiments may implement possible states to identify task states in a shared data variable; in the same way, a core may identify whether a task is available for execution.

[0082] Some embodiments may include a data structure to implement the above, which is "enum{waiting, signal, complete}state[n][where 'n' is task count]". Some embodiments may also include an arbiter that can assign a task to an available core only if the core's associated state corresponds to the "wait" state. When the monitor hardware is triggered, for example, whether mwait acts as a nop and execution continues with the next instruction, it will mark the task state with an indication (e.g., "signal"). As soon as the task completes, the core will update the task state with an indication of completion (e.g., "completed").

[0083] A write to a particular core's address range (e.g., MONITOR address) may cause that core to access the monitor region to identify and execute a task, which results in a state transition of the assigned task. As soon as the task is completed, the core will update the task state to "completed" before executing a wait (e.g., MWAIT) instruction. The following pseudocode may show a typical example of a MONITOR / MWAIT pair: [Table 2] [Pseudocode 2] A task can only be considered complete when all subtask states have moved to the "completed" state.

[0084] Shared data is described in more detail below. Some embodiments may include a data area where inter-processor communication (IPC) variables may be stored to avoid synchronization issues and that is accessible by first core 482, second core 488, third core 490, and fourth core 496. An example of shared data for this monitor prior to commencing multi-core operation is provided. [Table 3] [Table 1]

[0085] In some embodiments, available cores (e.g., CPU cores) associated with the execution of the SoC firmware, such as the third core 490 and the fourth core 496, may be identified by identification information in a data structure, such as the UPD. The third core 490 and the fourth core 496 may acquire tasks, progress toward task completion, and update task state. For example, assume that the third core 490 is executing task 0 as the first FSP thread 492, and the fourth core 496 has nearly completed execution of the second FSP thread 494 to complete task 1. Thus, the fourth core 496 may approach toward a new task. The following may be a snapshot of the shared data variables at that time: [Table 4] [Table 2] Initialization code may be provided. For example, all task states may be programmed to a default value as "wait" before beginning execution of an operation. Tables 1 and 2 above may be stored in memory for access.

[0086] 8, some embodiments may relate to a communication method 500 for passing core information between a boot program 502 (e.g., a boot loader) and firmware 504 (e.g., an FSP), as shown in FIG 8. Method 500 may be implemented generally in conjunction with a computing system and / or previously described process 100 (FIG. 1), method 300 (FIG. 2), method 350 (FIG. 3), method 370 (FIG. 4), method 400 (FIG. 5), method 448 (FIG. 6), and / or method 400 (FIG. 7).

[0087] 8 may illustrate processing beneficial firmware updates between boot program 502 and firmware 504. For example, boot program 502 may identify the number of available cores, assign the available cores, and initiate firmware 514. Core zero 506 may correspond to a BSP, and core zero 506 and core one 508 may be assigned to boot program 502, and core two 510 and core three 512 may be assigned to firmware 504.

[0088] Boot program 502 may process and update firmware for the platform on core one 508 516 and may also process and update firmware on core zero 506. Firmware 504 may compare core numbers and monitor address ranges 518, determine and assign tasks, and perform SoC updates 520. In some embodiments, firmware 504 may also compare core numbers to identify that a multi-threaded core environment is being used, monitor address ranges to monitor processor write-back stores, and initiate execution based on the processor's identification.

[0089] For example, boot program 502 may calculate the number of available active cores before initiating parallel execution between boot program 502 and firmware 504. Boot program 502 divides the active cores between boot program 502 and associated operations of firmware 504. To implement a thread-saving mechanism between boot program 502 and firmware 504 during parallel execution, some embodiments may use a policy whereby boot program 502 and firmware 504 inform each other about the number of cores being utilized. Boot program 502 may reassign core zero 506, core one 508, core two 510, and core three 512 accordingly. For example, a "multithreaded firmware blob" may include a newly added firmware header UPD to uniquely identify the cores responsible for parallel execution within the firmware.

[0090] Some embodiments may include a parameter (e.g., a UPD parameter such as MTCpuCoreCount) filled by the boot program 502 to inform the firmware 504 about the number of cores available for firmware 504 utilization in a thread-saving manner. The default value may be 1, corresponding to single-threaded operation. Some embodiments may include an array (e.g., a UPD parameter such as MTCpuAPICIds[n]) to uniquely identify the specified cores for firmware 504 utilization. In the above example, “n” may be a CPU index, and the value at index “n” may be an advanced programmable interrupt controller (APIC) ID that identifies a particular core among core zero 506, core one 508, core two 510, and core three 512. The boot program 502 may fill this array with the corresponding CPU cores (e.g., APIC IDs) assigned to the firmware 504 to utilize, with a default value of 0. The definition of the default UPD variable in the FSP may be shown below: [Table 5] [Pseudocode 3]

[0091] For example, consider a platform design with quad cores. Therefore, the number of active CPU cores on the boot loader side is four. Boot program 502 may allocate two cores among core zero 506, core one 508, core two 510, and core three 512 for its own execution, and may allocate the remaining two cores among core zero 506, core one 508, core two 510, and core three 512 for firmware 504 consumption. Allocating the FSP-M UPD required to start parallel FSP executions may be provided by the following pseudocode: "MTCpuCoreCount=2, MTCpuAPICIds[2]=2 and MTCpuAPICIds[3]=3".

[0092] Below is a pseudo-code example of an overridden UPD variable definition: [Table 6] [Pseudocode 4] Allocating these UPDs once during that initial phase is sufficient to provide multi-threaded firmware execution in parallel with the boot loader for the entire lifespan of firmware 504 (e.g., as with FSP-M, FSP-S, and corresponding NotifyPhase).

[0093] Some embodiments may use sequential execution in a multi-core environment to track control transfers between the boot program 502 and firmware 504, using a shared data variable (e.g., named "Boot Loader Core Number") to identify whether the firmware 504 and the boot program 502 are executing in parallel. When the number of active platform cores is equal to the shared data variable "Boot Loader Core Number," then the SoC's firmware execution is not operating in parallel. Otherwise, the boot program 502 and firmware 504 are executing in parallel.

[0094] Boot program 502 may own the BSP core that is core zero 506, and therefore core zero 506 may constantly monitor the shared data variables to control the core when firmware 504 execution is not running. The reallocated core may update the "boot loader core number" with an entry and terminate the core.

[0095] The boot program 502 may continue to perform normal operations, such as locating firmware 504 (e.g., FSP-M / S) and updating the UPD based on the configuration of the SoC and mainboard on one core, while other cores may handle updating the platform device's firmware or optimizing boot loader-specific boot entries. Upon invoking an entry point in firmware (e.g., FSP-M / S) by the boot loader processor, the firmware 504 (e.g., FSP-M) now has all the required information from the boot program 502, along with dedicated CPU resources and memory, creating a parallel execution environment within the firmware 504.

[0096] Firmware 504 may check that the MTCpuCoreCount UPD has more than one core and establish parallel communication. If so, firmware 504 may then generate a MONITOR address range for each core (by comparing an identifier, such as an APIC ID, of an available CPU core with the APIC ID assigned in the MTCpuAPICIds[n] UPD) so that there is minimal latency while the running core wakes up from idle by issuing an execute command. After completing the assigned task, the core may wait using MWAIT for the next write to the MONITOR address range for the next set of operations.

[0097] The cores executing the operations of firmware 504 may read the default UPD for core two 510 and core three 512 assigned to firmware 504 and may generate policy configuration blocks with additional boot loader policy overrides. Core two 510 and core three 512 in firmware 504 may handle the execution of specific components of the SoC, such as input / output modules, M-PHY related components, integrated sensor hubs, etc., in a multi-threaded environment.

[0098] Some embodiments may create these subtasks and shared data with the status of these tasks as "wait" by default to efficiently divide tasks. Furthermore, some embodiments may write to the MONITOR address of a dedicated core in the subtask function(), which then triggers the monitor HW in the core. A wait instruction (e.g., mwait) may be implemented, and execution continues from the next instruction to execute that task. Core Two 510 and Core Three 512 in firmware 504 may each execute these tasks and update the shared data variable. This may continue until all tasks are transitioned to the "completed" state. Core Zero 506 and Core One 508 may run under the control of the boot loader and continue to run in parallel with Core Two 510 and Core Three 512.

[0099] Some embodiments include a verified boot flow, initialization of the trusted platform module, and verification of and jump to the embedded controller read / write (EC RW) area. Device firmware updates (e.g., SoC firmware) can be handled using the application processor. The boot program 502 can check the shared variable data "boot loader core count" to know if firmware 504 is complete and has released all cores for the boot program's 502 usage.

[0100] Some embodiments may check whether the platform has a reset request. If so, control transfers to the reset vector. Additionally, in some embodiments, boot program 502 may perform operations in parallel on all possible active cores to ensure the execution of the remaining operations to boot the OS.

[0101] 9 illustrates a monitor 550. The monitor 550 may generally be implemented in conjunction with a computing system and / or previously described process 100 (FIG. 1), method 300 (FIG. 2), method 350 (FIG. 3), method 370 (FIG. 4), method 400 (FIG. 5), method 448 (FIG. 6), method 400 (FIG. 7), and / or method 500 (FIG. 8).

[0102] A set of tasks 552 and subtasks may initially be set to standby (a core may not be executing a task). Monitor 550 may include cores one through M, but cores one through M may be separate from monitor 550. Tasks 552 may be assigned to cores one through M. Initialization code may initialize monitor 550.

[0103] 10 illustrates a memory architecture that may implement aspects of the disclosure. The memory architecture may generally be implemented in conjunction with a computing system and / or previously described process 100 (FIG. 1), method 300 (FIG. 2), method 350 (FIG. 3), method 370 (FIG. 4), method 400 (FIG. 5), method 448 (FIG. 6), method 400 (FIG. 7), method 500 (FIG. 8), and / or monitor (FIG. 9).

[0104] For example, some embodiments may use memory 548 (e.g., DRAM) available on modern SoC dies as static RAM (SRAM) for firmware access. The SoC 542 may also access cache 546 for firmware access, as may the CPU 540 and GPU 544 as part of a firmware update. In some embodiments, memory 548 may be excluded if it occurs that it cannot be initialized during the early boot stages.

[0105] 11 , an efficiency-enhanced computing system 150 is shown. System 150 may generally be part of an electronic device / platform having computing capabilities (e.g., personal digital assistant / PDA, notebook computer, tablet computer, convertible tablet, server), communications capabilities (e.g., smartphone), imaging capabilities (e.g., camera, camcorder), media playback capabilities (e.g., smart television / TV), wearable capabilities (e.g., watch, eyeglasses, hat, footwear, jewelry), vehicle capabilities (e.g., car, truck, motorcycle), robotic capabilities (e.g., autonomous robot), etc., or any combination thereof. In the illustrated example, system 150 includes a host processor 152 (e.g., CPU) having an integrated memory controller (IMC) 154 coupled to system memory 156.

[0106] The illustrated system 150 also includes an input / output (IO) module 158 and a graphics processor 160 (e.g., GPU) implemented together with the host processor 152 on a semiconductor die 162 as an SoC. The illustrated IO module 158 communicates with, for example, a display 164 (e.g., a touchscreen, a liquid crystal display / LCD, a light-emitting diode / LED display), a network controller 166 (e.g., wired and / or wireless), and mass storage 168 (e.g., a hard disk drive / HDD, an optical disk, a solid-state drive / SSD, flash memory). The SoC 162 includes core zero to core N 140, which may perform multithreaded booting in accordance with embodiments described herein. Data associated with the multithreaded system may be stored in an on-board SoC cache 142. The SoC may further include a bus interface 144. Multi-threaded operation may perform firmware update and boot processes on a first subset of cores zero through N140, and other platform firmware related processes may be performed on a second subset of the first subset of cores zero through N140.

[0107] Host processor 152, graphics processor 160, and / or IO module 158 may execute instructions 170 retrieved from system memory 156 and / or mass storage 168. In embodiments, computing system 150 implements previously described process 100 (FIG. 1), method 300 (FIG. 2), method 350 (FIG. 3), method 370 (FIG. 4), method 400 (FIG. 5), method 448 (FIG. 6), method 400 (FIG. 7), method 500 (FIG. 8), monitor 550 (FIG. 9), and / or memory architecture (FIG. 10). The illustrated computing system 150 is therefore considered to have enhanced efficiency, at least to the extent that it enables faster boot times with higher execution throughput.

[0108] Core Zero to Core N 140, IMC 154, SoC cache 142 and bus interface 144, graphics processor, IO 158 may be examples of SoC devices that are initiated, controlled, and updated by the FSP, SoC firmware, etc. Network controller 166, mass storage 168, system memory 156, and display 164 may be examples of platform devices that are external to SoC 162 and may be updated, initiated, and controlled by platform firmware that is separate from the SoC firmware. As previously described, SoC firmware may operate in parallel with platform firmware during the boot process to enhance efficiency.

[0109] 12 illustrates a semiconductor device 172 (e.g., a chip, die, package). The illustrated device 172 includes one or more substrates 174 (e.g., silicon, sapphire, gallium arsenide) and logic 176 (e.g., transistor arrays and other integrated circuit / IC components) coupled to the substrate 174. In an embodiment, the device 172 implements aspects of the previously described process 100 ( FIG. 1 ), method 300 ( FIG. 2 ), method 350 ( FIG. 3 ), method 370 ( FIG. 4 ), method 400 ( FIG. 5 ), method 448 ( FIG. 6 ), method 400 ( FIG. 7 ), method 500 ( FIG. 8 ), monitor 550 ( FIG. 9 ), and / or memory architecture ( FIG. 10 ).

[0110] Logic 176 may be implemented at least in part with configurable logic or fixed-function hardware logic. In one example, logic 176 includes transistor channel regions disposed (e.g., buried) within substrate 174. Thus, the interface between logic 176 and substrate 174 need not be an abrupt junction. Logic 176 may also be considered to include an epitaxial layer grown on an initial wafer of substrate 174.

[0111] Figure 13 shows a processor core 200, according to one embodiment. Processor core 200 may be the core of any type of processor, such as a microprocessor, embedded processor, digital signal processor (DSP), network processor, or other device that executes code. Although only one processor core 200 is shown in Figure 13, a processing element may alternatively include more than one of the processor cores 200 shown in Figure 13. Processor core 200 may be a single-threaded core, or, for at least one embodiment, processor core 200 may be multi-threaded in that it may include more than one hardware thread context (or "logical processor") per core.

[0112] FIG. 13 also illustrates memory 270 coupled to processor core 200. Memory 270 may be any of a wide variety of memories (including various layers of a memory hierarchy) known or otherwise available to those skilled in the art. Memory 270 may include one or more code 213 instructions executed by processor core 200. Code 213 may implement aspects of embodiments described herein. Processor core 200 follows the program sequence of instructions represented by code 213. Each instruction may enter front-end section 210 and be processed by one or more decoders 220. Decoder 220 may generate as output micro-operations, such as fixed-width micro-operations in a predefined format, or other instructions, micro-instructions, or control signals that reflect the original code instructions. The illustrated front-end section 210 also includes register renaming logic 225 and scheduling logic 230, which generally allocate resources and queue operations corresponding to the conversion instructions for execution.

[0113] Processor core 200 is shown to include execution logic 250 having a set of execution units 255-1 through 255-N. Some embodiments may include multiple execution units dedicated to a particular function or set of functions. Other embodiments may include only one execution unit, or one execution unit capable of performing a particular function. The execution logic 250 is shown to perform operations specified by code instructions.

[0114] After completing execution of the operations specified by the code instructions, back-end logic 260 retires the instructions of code 213. In one embodiment, processor core 200 allows out-of-order execution but requires in-order retirement of instructions. Retirement logic 265 can take various types of forms known by those skilled in the art (e.g., a reorder buffer or the like). In this manner, processor core 200 is transformed during execution of code 213 with respect to at least the outputs generated by the decoder, the hardware registers and tables utilized by register renaming logic 225, and any registers (not shown) modified by execution logic 250.

[0115] Although not shown in FIG. 13 , a processing element may include other elements on chip with processor core 200. For example, a processing element may include memory control logic along with processor core 200. A processing element may include I / O control logic and / or I / O control logic integrated with memory control logic. A processing element may also include one or more caches. Processor core 200 may implement one or more aspects of previously described process 100 ( FIG. 1 ), method 300 ( FIG. 2 ), method 350 ( FIG. 3 ), method 370 ( FIG. 4 ), method 400 ( FIG. 5 ), method 448 ( FIG. 6 ), method 400 ( FIG. 7 ), method 500 ( FIG. 8 ), monitor 550 ( FIG. 9 ), and / or memory architecture ( FIG. 10 ).

[0116] 14, a block diagram of an embodiment of a computing system 1000 according to an embodiment is shown. Shown in FIG. 14 is a multiprocessor system 1000 including a first processing element 1070 and a second processing element 1080. Although two processing elements 1070 and 1080 are shown, it will be understood that an embodiment of system 1000 may also include only one such processing element.

[0117] System 1000 is shown as a point-to-point interconnect system. A first processing element 1070 and a second processing element 1080 are coupled via a point-to-point interconnect 1050. It should be understood that any or all of the interconnects shown in Figure 14 may be implemented as multi-drop buses rather than point-to-point interconnects.

[0118] 14, each of the processing elements 1070 and 1080 may be a multi-core processor including a first processor core and a second processor core (i.e., processor cores 1074a and 1074b, and processor cores 1084a and 1084b). Such cores 1074a, 1074b, 1084a, 1084b may be configured to execute instruction codes in a manner similar to that described above in connection with FIG.

[0119] Each processing element 1070, 1080 may include at least one shared cache 1896a, 1896b. The shared cache 1896a, 1896b may store data (e.g., instructions) used by one or more components of the processor, such as core 1074a, core 1074b and core 1084a, core 1084b, respectively. For example, the shared cache 1896a, 1896b may locally cache data stored in memory 1032, 1034 for faster access by the components of the processor. In one or more embodiments, the shared cache 1896a, 1896b may include one or more mid-level caches, such as level 2 (L2), level 3 (L3), level 4 (L4), or other level caches, a last level cache (LLC), and / or a combination thereof.

[0120] While only two processing elements 1070, 1080 are shown, it will be understood that the scope of the embodiments is not so limited. In other embodiments, one or more additional processing elements may be present in a given processor. Alternatively, one or more processing elements 1070, 1080 may be elements other than processors, such as accelerators or field programmable gate arrays. For example, the additional processing elements may include an additional processor identical to the first processor 1070, an additional processor that is heterogeneous or asymmetric with the first processor 1070, an accelerator (e.g., a graphics accelerator or digital signal processing (DSP) unit), a field programmable gate array, or any other processing element. Various differences may exist between the processing elements 1070, 1080 with respect to a wide variety of value criteria, including architectural characteristics, microarchitectural characteristics, thermal characteristics, power consumption characteristics, and the like. These differences may effectively manifest themselves as asymmetries and heterogeneities between the processing elements 1070, 1080. For at least one embodiment, the various processing elements 1070, 1080 may reside in the same die package.

[0121] The first processing element 1070 may further include memory controller logic (MC) 1072 and point-to-point (PP) interfaces 1076 and 1078. Similarly, the second processing element 1080 may include MC 1082 and PP interfaces 1086 and 1088. As shown in FIG. 14 , the MCs 1072 and 1082 couple the processors to respective memories, i.e., memory 1032 and memory 1034, which may be part of main memory locally attached to the respective processors. While the MCs 1072 and 1082 are shown as being integrated into the processing elements 1070, 1080, for alternative embodiments, the MC logic may be separate logic external to the processing elements 1070, 1080 rather than being integrated therewith.

[0122] First processing element 1070 and second processing element 1080 may be coupled to I / O subsystem 1090 via PP interconnects 1076, 1086, respectively. As shown in FIG. 14 , I / O subsystem 1090 includes PP interfaces 1094 and 1098. Additionally, I / O subsystem 1090 includes interface 1092 that couples I / O subsystem 1090 to high-performance graphics engine 1038. In one embodiment, bus 1049 may be used to couple graphics engine 1038 to I / O subsystem 1090. Alternatively, a point-to-point interconnect may couple these components.

[0123] I / O subsystem 1090 may in turn be coupled to a first bus 1016 via an interface 1096. In one embodiment, first bus 1016 may be a bus such as a Peripheral Component Interconnect (PCI) bus, or a PCI Express bus or other third generation I / O interconnect bus, although the scope of the embodiment is not so limited.

[0124] 14, various I / O devices 1014 (e.g., biometric scanner, speaker, camera, sensors) may be coupled to a first bus 1016, along with a bus bridge 1018 that may couple the first bus 1016 to a second bus 1020. In one embodiment, the second bus 1020 may be a low pin count (LPC) bus. In one embodiment, various devices may be coupled to the second bus 1020, including, for example, a keyboard / mouse 1012, a communication device 1026, and a data storage unit 1019, such as a disk drive or other mass storage device, which may include code 1030. The illustrated code 1030 may implement previously described process 100 (FIG. 1), method 300 (FIG. 2), method 350 (FIG. 3), method 370 (FIG. 4), method 400 (FIG. 5), method 448 (FIG. 6), method 400 (FIG. 7), method 500 (FIG. 8), monitor (FIG. 9), and / or memory architecture (FIG. 10). Additionally, audio I / O 1024 may be coupled to second bus 1020, and battery 1010 may provide power to computing system 1000.

[0125] It should be noted that other embodiments are possible. For example, rather than the point-to-point architecture of Figure 14, the system could implement a multi-drop bus or other such communication topology. Also, the elements of Figure 14 could alternatively be split using more or fewer integrated chips than those shown in Figure 14.

[0126] [Additional notes and examples]

[0127] (Example 1) A performance-enhanced computing system includes a system-on-chip including a host processor; and a memory including a set of executable program instructions that, when executed by the host processor, cause the computing system to: identify, during a first boot process, whether at least one task associated with at least one software program is set to occur in single-threaded processing or multi-threaded processing; execute the at least one task in multi-threaded processing during the first boot process in response to the at least one task being set to occur in multi-threaded processing; and execute the at least one task in single-threaded processing during the first boot process in response to the at least one task being set to occur in single-threaded processing.

[0128] Example 2: The computing system of Example 1, wherein the at least one software program is firmware associated with a system-on-chip.

[0129] (Example 3) The computing system of Example 2 includes the instructions, which, when executed, further cause the computing system to perform at least one boot step with single-threaded processing during a first portion of the first boot process, and to perform at least one task with multi-threaded processing during a second portion of the first boot process.

[0130] (Example 4) The computing system of Example 2 includes the instructions, which, when executed, further cause the computing system to identify that at least one task occurs in multithreaded processing during the first boot process, dedicate a first group of processor cores of the host processor to the at least one task, and dedicate a second group of processor cores of the host processor to executing firmware associated with a hardware device communicatively connected to the system-on-chip.

[0131] (Example 5) The instructions, when executed, include the computing system of Example 1, further causing the computing system to: determine a time to execute at least one task during a second boot process; determine that the at least one task is updated in multithreaded processing based on the time; store identification information in a data structure that the at least one task occurs in multithreaded processing; access the data structure during a first boot process to identify that the at least one task occurs in multithreaded processing; and execute the at least one task in multithreaded processing during the first boot process.

[0132] Example 6 includes the computing system of any one of Examples 1 to 5, wherein the at least one task includes one or more of updating or executing at least one software program.

[0133] (Example 7) A semiconductor device includes one or more substrates and logic coupled to the one or more substrates, the logic being implemented using one or more of configurable logic or fixed-function logic hardware, wherein the logic coupled to the one or more substrates identifies, during a first boot process, whether at least one task associated with at least one software program is set to occur in single-threaded processing or multi-threaded processing, and executes the at least one task in multi-threaded processing during the first boot process in response to at least one task set to occur in multi-threaded processing, and executes the at least one task in single-threaded processing during the first boot process in response to at least one task set to occur in single-threaded processing.

[0134] (Example 8) The semiconductor device of Example 7, wherein the at least one software program is firmware associated with a system-on-chip.

[0135] (Example 9) The logic includes the semiconductor device of Example 8, which performs at least one boot step in a single-threaded process during a first portion of a first boot process, and performs at least one task in a multi-threaded process during a second portion of the first boot process.

[0136] (Example 10) The semiconductor device of Example 8 includes logic that identifies at least one task occurring in multithreaded processing during the first boot process, dedicates a first group of processor cores of a host processor of the system-on-chip to the at least one task, and dedicates a second group of processor cores of the host processor to executing firmware associated with a hardware device communicatively coupled to the system-on-chip.

[0137] (Example 11) The semiconductor device of Example 7 includes logic that determines a time to execute at least one task during the second boot process, determines that the at least one task is updated in multithreaded processing based on the time, stores identification information in a data structure that the at least one task occurs in multithreaded processing, accesses the data structure during the first boot process to identify that the at least one task occurs in multithreaded processing, and executes the at least one task in multithreaded processing during the first boot process.

[0138] Example 12 includes the semiconductor device of any one of Examples 7 to 11, wherein the at least one task includes one or more of updating or executing at least one software program.

[0139] (Example 13) The logic coupled to the one or more substrates includes the semiconductor device of any one of Examples 7 to 11, including a transistor channel region disposed in the one or more substrates.

[0140] (Example 14) includes at least one computer-readable storage medium comprising a set of instructions that, when executed by a computing system, cause the computing system to: identify, during a first boot process, whether at least one task associated with at least one software program is set to occur in single-threaded processing or multi-threaded processing; execute the at least one task in multi-threaded processing during the first boot process in response to the at least one task being set to occur in multi-threaded processing; and execute the at least one task in single-threaded processing during the first boot process in response to the at least one task being set to occur in single-threaded processing.

[0141] Example 15. The at least one computer-readable storage medium of Example 14, wherein the at least one software program is firmware associated with the system-on-chip.

[0142] (Example 16) The at least one computer-readable storage medium of Example 15 includes instructions that, when executed, further cause the computing system to perform at least one boot step with single-threaded processing during a first portion of the first boot process and to perform at least one task with multi-threaded processing during a second portion of the first boot process.

[0143] (Example 17) The at least one computer-readable storage medium of Example 15 includes instructions that, when executed, further cause the computing system to identify that at least one task occurs in multithreaded processing during a first boot process, dedicate a first group of processor cores of a host processor of the system-on-chip to the at least one task, and dedicate a second group of processor cores of the host processor to executing firmware associated with a hardware device communicatively connected to the system-on-chip.

[0144] (Example 18) The at least one computer-readable storage medium of Example 14 includes instructions that, when executed, further cause the computing system to: determine a time to execute at least one task during a second boot process; determine that the at least one task is updated in multithreaded processing based on the time; store identification information in a data structure that the at least one task occurs in multithreaded processing; access the data structure during a first boot process to identify that the at least one task occurs in multithreaded processing; and execute the at least one task in multithreaded processing during the first boot process.

[0145] (Example 19) The at least one computer-readable storage medium of any one of Examples 14 to 18 includes at least one task including one or more of updating or executing at least one software program.

[0146] (Example 20) A method includes: identifying, during a first boot process, whether at least one task associated with at least one software program is configured to occur in single-threaded processing or multi-threaded processing; and, in response to the at least one task being configured to occur in multi-threaded processing, executing the at least one task in multi-threaded processing during the first boot process; and, in response to the at least one task being configured to occur in single-threaded processing, executing the at least one task in single-threaded processing during the first boot process.

[0147] Example 21. The at least one software program includes the method of Example 20, wherein the at least one software program is firmware associated with a system-on-chip.

[0148] (Example 22) The method of Example 21 further includes, during a first portion of the first boot process, performing at least one boot step in a single-threaded process, and during a second portion of the first boot process, performing at least one task in a multi-threaded process.

[0149] (Example 23) The method of Example 21 further includes identifying that at least one task occurs in multithreaded processing during the first boot process, dedicating a first group of processor cores of a host processor of the system-on-chip to the at least one task, and dedicating a second group of processor cores of the host processor to executing firmware associated with a hardware device communicatively coupled to the system-on-chip.

[0150] (Example 24) The method of Example 20 further includes determining a time to execute at least one task during the second boot process, determining that the at least one task is updated in a multithreaded process based on the time, storing identification information in a data structure that the at least one task occurs in a multithreaded process, accessing the data structure during the first boot process to identify that the at least one task occurs in a multithreaded process, and executing the at least one task in a multithreaded process during the first boot process.

[0151] Example 25. The method of any one of Examples 20 to 24, wherein the at least one task includes one or more of updating or running at least one software program.

[0152] (Example 26) one or more substrates; Logic coupled to one or more substrates; Equipped with The logic is implemented in one or more of configurable logic or fixed-function logic hardware, and the logic coupled to one or more substrates includes a semiconductor device including: means for identifying, during a first boot process, whether at least one task is associated with at least one software program configured to occur in a single-threaded manner or at least one software program configured to occur in a multi-threaded manner; means for executing, during the first boot process, the at least one task in a multi-threaded manner in response to the at least one task being configured to occur in a multi-threaded manner; and means for executing, during the first boot process, the at least one task in a single-threaded manner in response to the at least one task being configured to occur in a single-threaded manner.

[0153] (Example 27) The semiconductor device of Example 26, wherein the at least one software program is firmware associated with the system-on-chip.

[0154] (Example 28) The semiconductor device of Example 27 further includes means for executing at least one boot step in single-threaded processing during a first portion of the first boot process, and means for executing at least one task in multi-threaded processing during a second portion of the first boot process.

[0155] (Example 29) The semiconductor device of Example 27 further includes means for identifying that at least one task occurs in multithreaded processing during the first boot process, means for dedicating a first group of processor cores of a host processor of the system-on-chip to the at least one task, and means for dedicating a second group of processor cores of the host processor to executing firmware associated with a hardware device communicatively connected to the system-on-chip.

[0156] (Example 30) The semiconductor device of Example 26 further includes means for determining a time to execute at least one task during the second boot process, means for determining that the at least one task is updated in multithreaded processing based on the time, means for storing identification information in a data structure that the at least one task occurs in multithreaded processing, means for accessing the data structure during the first boot process and identifying that the at least one task occurs in multithreaded processing, and means for executing the at least one task in multithreaded processing during the first boot process.

[0157] (Example 31) The semiconductor device of any one of Examples 26 to 30, wherein the at least one task includes one or more of updating or executing at least one software program.

[0158] Thus, the techniques described herein may support updated firmware during the graceful update and boot process.

[0159] Embodiments are applicable for use with all types of semiconductor integrated circuit (IC) chips. Examples of these IC chips include, but are not limited to, processors, controllers, chipset components, programmable logic arrays (PLAs), memory chips, network chips, systems-on-chips (SoCs), SSD / NAND controller ASICs, and the like. Additionally, in some figures, signal lines are represented as lines, some of which may vary to indicate more component signal paths, may have numbered labels to indicate multiple component signal paths, and / or may have arrows at one or more end points to indicate the direction of primary information flow. However, this should not be construed as limiting. Rather, such additional detail may be used in connection with one or more exemplary embodiments to facilitate easier understanding of the circuit. Any represented signal line, whether or not it has additional information, may actually comprise one or more signals that may travel in multiple directions and may be implemented with any suitable type of signaling scheme, e.g., digital or analog lines implemented in differential pairs, fiber optic lines, and / or single-ended lines.

[0160] Although example sizes / models / values / ranges may be given, embodiments are not limited to the same. It is expected that smaller devices can be produced as manufacturing technologies (e.g., photolithography) mature over time. Furthermore, for simplicity of illustration and description, and so as not to obscure certain aspects of the embodiments, well-known power / ground connections to IC chips and other components may or may not be shown in the drawings. Furthermore, configurations may be shown in block diagram form to avoid obscuring the embodiments, and in light of the fact that details regarding the implementation of such block diagram configurations will vary greatly depending on the computing system on which the embodiments are implemented, i.e., such details should be well within the knowledge of those skilled in the art. Where specific details (e.g., circuits) are described to illustrate example embodiments, it should be apparent to one skilled in the art that the embodiments can be practiced without these specific details or with variations on these specific details. Therefore, the description is to be regarded as illustrative and not limiting.

[0161] The term "coupled" may be used herein to refer to any type of direct or indirect relationship between the components under consideration and may apply to electrical, mechanical, fluid, optical, electromagnetic, or other connections. Additionally, terms such as "first," "second," etc. may be used herein for ease of description only and do not imply any particular temporal or chronological connotation unless otherwise indicated.

[0162] As used in this application and the claims, a list of items joined by the term "one or more of" may mean any combination of the listed terms. For example, the term "one or more of A, B, or C" may mean A, B, C, A and B, A and C, B and C, or A, B, and C.

[0163] Those skilled in the art will appreciate from the foregoing description that the broad technology of the embodiments can be implemented in a variety of forms. Accordingly, while the embodiments have been described with reference to specific examples thereof, the true scope of the embodiments should not be so limited, as other modifications will become apparent to those skilled in the art upon review of the drawings, the specification, and the following claims.

Claims

1. 1. A performance-enhanced computing system, comprising: a system-on-chip including a host processor; When executed by the host processor, the enhanced performance computing system includes: determining, during a previous boot process, an amount of time required to execute at least one task associated with at least one software program; configuring the at least one task to occur in a single-threaded process or a multi-threaded process based on the time required to execute the at least one task; responsive to the at least one task being configured to occur in the multithreaded process, executing the at least one task in the multithreaded process during a next boot process; responsive to the at least one task being configured to occur in the single-threaded process, executing the at least one task in the single-threaded process during the next boot process; a memory containing a set of executable program instructions that cause 1. A performance-enhanced computing system comprising:

2. The setting such that the at least one task occurs in single-threaded processing or multi-threaded processing includes: configuring the at least one task to occur in the single-threaded process if the time does not exceed a threshold; configuring the at least one task to occur in the multithreaded process if the time exceeds the threshold; The enhanced performance computing system of claim 1 , wherein the at least one software program is firmware associated with the system-on-chip.

3. The executable program instructions, when executed, cause the enhanced performance computing system to: performing at least one boot step in the single-threaded process during a first portion of the subsequent boot process; executing the at least one task in the multithreaded process during a second portion of the subsequent boot process; Let them do this further, The enhanced performance computing system of claim 2 , wherein the at least one task is the execution of the at least one software program.

4. The executable program instructions, when executed, cause the enhanced performance computing system to: identifying the at least one task to occur in the multithreaded process during the next boot process; dedicating a first group of processor cores of the host processor to the at least one task; allocating a second group of processor cores of the host processor specifically to execute firmware associated with hardware devices communicatively coupled to the system-on-chip; The enhanced performance computing system of claim 2 , further comprising:

5. The executable program instructions, when executed, cause the enhanced performance computing system to: storing in a data structure an identification of said at least one task that is to occur in said multithreaded process; During the next boot process, accessing the data structure and identifying that the at least one task should occur in the multithreaded process; executing the at least one task in the multithreaded process during the next boot process; The enhanced performance computing system of claim 1 , further comprising:

6. A performance-enhanced computing system, comprising: a system-on-chip including a host processor; When executed by the host processor, the enhanced performance computing system includes: identifying whether at least one task associated with the at least one software program is configured to occur in single-threaded or multi-threaded processing during the next boot process; responsive to the at least one task being configured to occur in the multithreaded process, executing the at least one task in the multithreaded process during the next boot process; responsive to the at least one task being configured to occur in the single-threaded process, executing the at least one task in the single-threaded process during the next boot process; determining the time required to perform the at least one task during a previous boot process; determining, based on the time, that the at least one task should be updated in the multithreaded process; storing in a data structure an identification of said at least one task that is to occur in said multithreaded process; During the next boot process, accessing the data structure and identifying that the at least one task should occur in the multithreaded process; executing the at least one task in the multithreaded process during the next boot process; a memory containing a set of executable program instructions that cause 1. A performance-enhanced computing system comprising:

7. The enhanced performance computing system of claim 1 , wherein the at least one task includes one or more of updating or executing the at least one software program.

8. one or more substrates; logic coupled to the one or more substrates; Equipped with The logic is implemented in one or more of configurable logic or fixed logic hardware, and the logic coupled to the one or more substrates includes: determining, during a previous boot process, the time required to execute at least one task associated with at least one software program; configuring the at least one task to occur in a single-threaded process or a multi-threaded process based on the time required to execute the at least one task; executing the at least one task in the multithreaded process during a next boot process in response to the at least one task being configured to occur in the multithreaded process; executing the at least one task in a single-threaded process during the next boot process in response to the at least one task being configured to occur in the single-threaded process; Semiconductor device.

9. The setting of the at least one task to occur in single-threaded processing or multi-threaded processing comprises: configuring the at least one task to occur in the single-threaded process if the time does not exceed a threshold; configuring the at least one task to occur in the multithreaded process if the time exceeds the threshold; 9. The semiconductor device of claim 8, wherein the at least one software program is firmware associated with a system-on-chip.

10. The logic is: performing at least one boot step in the single-threaded process during a first portion of the subsequent boot process; executing the at least one task in the multithreaded process during a second portion of the subsequent boot process; the at least one task is execution of the at least one software program; The semiconductor device according to claim 9 .

11. The logic is: identifying that the at least one task should occur in the multithreaded process during the next boot process; dedicating a first group of processor cores of a host processor of the system-on-chip to the at least one task; dedicating a second group of processor cores of the host processor to executing firmware associated with hardware devices communicatively coupled to the system-on-chip; The semiconductor device according to claim 9 .

12. The logic is: storing in a data structure an identification of said at least one task that is to occur in said multithreaded process; accessing the data structure during the next boot process to identify that the at least one task is to occur in the multithreaded process; executing the at least one task in the multithreaded process during the next boot process; The semiconductor device according to claim 8 .

13. One or more substrates; logic coupled to the one or more substrates; Equipped with The logic is implemented in one or more of configurable logic or fixed logic hardware, and the logic coupled to the one or more substrates includes: during the next boot process, identifying whether at least one task associated with the at least one software program is configured to occur in single-threaded or multi-threaded processing; responsive to the at least one task being configured to occur in the multithreaded process, executing the at least one task in the multithreaded process during the next boot process; responsive to the at least one task being configured to occur in the single-threaded process, executing the at least one task in the single-threaded process during the next boot process; determining the time required to perform the at least one task during a previous boot process; determining, based on the time, that the at least one task should be updated in the multithreaded process; storing in a data structure an identification of said at least one task that is to occur in said multithreaded process; accessing the data structure during the next boot process to identify that the at least one task is to occur in the multithreaded process; executing the at least one task in the multithreaded process during the next boot process; Semiconductor device.

14. The semiconductor device according to claim 8 , wherein the at least one task includes one or more of updating or executing the at least one software program.

15. 14. The semiconductor device of claim 8, wherein the logic coupled to the one or more substrates includes a transistor channel region disposed within the one or more substrates.

16. In a computing system, determining the time required to execute at least one task associated with at least one software program during a previous boot process; configuring the at least one task to occur in a single-threaded or multi-threaded manner based on the time required to execute the at least one task; responsive to the at least one task being configured to occur in the multithreaded process, executing the at least one task in the multithreaded process during a next boot process; responsive to the at least one task being configured to occur in the single-threaded process, executing the at least one task in the single-threaded process during the next boot process; A program that executes.

17. The procedure for configuring the at least one task to occur in single-threaded processing or multi-threaded processing comprises: If the time does not exceed a threshold, configuring the at least one task to occur in single-threaded processing; configuring the at least one task to occur in the multithreaded process if the time exceeds the threshold; 17. The program of claim 16, wherein the at least one software program is firmware associated with a system-on-chip.

18. The computing system includes: performing at least one boot step in the single-threaded process during a first portion of the subsequent boot process; executing the at least one task in the multithreaded process during a second portion of the subsequent boot process; Then run 20. The program of claim 17, wherein the at least one task is the execution of the at least one software program.

19. The computing system includes: identifying that the at least one task should occur in the multithreaded process during the next boot process; dedicating a first group of processor cores of a host processor of the system-on-chip to the at least one task; allocating a second group of processor cores of the host processor specifically to execute firmware associated with hardware devices communicatively coupled to the system-on-chip; The program according to claim 17, further comprising:

20. The computing system includes: storing in a data structure an identification of said at least one task that should occur in said multithreaded process; during the next boot process, accessing the data structure and identifying that the at least one task should occur in the multithreaded process; executing the at least one task in a multi-threaded manner during the next boot process; The program according to claim 16, further comprising:

21. A computing system comprising: during the next boot process, identifying whether at least one task associated with the at least one software program is configured to occur in single-threaded or multi-threaded processing; responsive to the at least one task being configured to occur in the multithreaded process, executing the at least one task in the multithreaded process during the next boot process; responsive to the at least one task being configured to occur in the single-threaded process, executing the at least one task in the single-threaded process during the next boot process; determining the time required to perform said at least one task during a previous boot process; determining, based on the time, that the at least one task should be updated in the multithreaded process; storing in a data structure an identification of said at least one task that should occur in said multithreaded process; during the next boot process, accessing the data structure and identifying that the at least one task should occur in the multithreaded process; executing the at least one task in a multi-threaded manner during the next boot process; A program that executes.

22. 22. The program of claim 16, wherein the at least one task comprises one or more of updating or running the at least one software program.

23. At least one computer readable storage medium storing a program according to any one of claims 16 to 22.

24. A method performed by a computing system, comprising: determining, during a previous boot process, an amount of time required to execute at least one task associated with at least one software program; configuring the at least one task to occur in a single-threaded process or a multi-threaded process based on the time required to execute the at least one task; responsive to the at least one task being configured to occur in the multithreaded process, executing the at least one task in the multithreaded process during a next boot process; responsive to the at least one task being configured to occur in the single-threaded process, executing the at least one task in the single-threaded process during the next boot process; A method comprising:

25. The step of configuring the at least one task to occur in a single-threaded process or a multi-threaded process, If the time does not exceed a threshold, configuring the at least one task to occur in the single-threaded processing; configuring the at least one task to occur in the multithreaded process if the time exceeds the threshold; 25. The method of claim 24, wherein the at least one software program is firmware associated with a system-on-chip.

26. performing at least one boot step in the single-threaded process during a first portion of the subsequent boot process; executing the at least one task in the multithreaded process during a second portion of the subsequent boot process; further comprising 26. The method of claim 25, wherein the at least one task is the execution of the at least one software program.

27. identifying the at least one task to occur in the multithreaded process during the next boot process; dedicating a first group of processor cores of a host processor of the system-on-chip to the at least one task; allocating a second group of processor cores of the host processor specifically to executing firmware associated with hardware devices communicatively coupled to the system-on-chip; 26. The method of claim 25, further comprising:

28. The method of claim 27, further comprising: storing in a data structure an identification of the at least one task that should occur in the multithreaded processing; during the next boot process, accessing the data structure and identifying that the at least one task should occur in the multithreaded process; executing the at least one task in the multithreaded process during the next boot process; 25. The method of claim 24, further comprising:

29. A method performed by a computing system, comprising: identifying whether at least one task associated with the at least one software program is configured to occur in single-threaded or multi-threaded processing during the next boot process; responsive to the at least one task being configured to occur in the multithreaded process, executing the at least one task in the multithreaded process during the next boot process; responsive to the at least one task being configured to occur in the single-threaded process, executing the at least one task in the single-threaded process during the next boot process; determining the time required to perform said at least one task during a previous boot process; determining, based on the time, that the at least one task should be updated in the multithreaded process; storing in a data structure an identification of said at least one task that is to occur in said multithreaded process; during the next boot process, accessing the data structure and identifying that the at least one task should occur in the multithreaded process; executing the at least one task in the multithreaded process during the next boot process; A method comprising:

30. 30. The method of any one of claims 24 to 29, wherein the at least one task includes one or more of updating or running the at least one software program.

Images