Improved boot process for earlier display initialization and visualization

Abstract

To provide a hardware processor, a system, and a method for executing an improved boot process for early display initialization and visualization.SOLUTION: In a system-on-chip 100, a hardware processor 102 comprises: a plurality of processor cores 112; a cache coupled to the plurality of processor cores; and a boot controller 146 that initializes a portion of the cache as static memory for using a hardware initialization code before beginning execution of the hardware initialization code after power-on of the hardware processor and causes initialization of a display device to be performed using the portion of the cache. The initialization of the display device is performed independently of initialization of dynamic memory of the hardware processor.SELECTED DRAWING: Figure 1

Description

[Background technology]

[0001] A processing system may include hardware and software components. Software components may include one or more applications, an operating system (OS), and firmware. An application may include control logic for performing tasks that are valuable to a user of the processing system. In a processing system, applications run on an OS, which operates at a lower logical level (i.e., closer to the hardware) than the application and provides an underlying environment or abstraction layer that makes it easier to create and run applications. Firmware operates at an even lower logical level and provides an underlying environment or abstraction layer that makes it easier to create and run an OS. For example, firmware may establish a basic input / output system (BIOS), and the OS may use the BIOS to communicate with different hardware components within the processing system.

[0002] Typically, the OS and applications run in random access memory (RAM), which is volatile. Some or all firmware may also run in RAM. However, because RAM is volatile, the environment for performing useful work essentially disappears whenever the processing system is turned off. As a result, whenever the processing system is turned on, the processing system must recreate that environment before useful work can be performed. For purposes of this disclosure, the operation of preparing the processing system to run the OS may be referred to as a "boot process." Similarly, the time that elapses during the boot process may be referred to as "boot time." [Brief explanation of the drawings]

[0003] The embodiments described herein are illustrated by way of example, and not by way of limitation, in the figures of the accompanying drawings, in which like reference numerals refer to similar elements and in which:

[0004] [Figure 1]1 illustrates a system-on-chip (SoC) for improving the boot process for early display initialization and visualization according to an implementation of the present disclosure.

[0005] [Figure 2A] 1 illustrates an exemplary boot flow according to an implementation of the present disclosure.

[0006] [Figure 2B] 1 illustrates an example boot flow utilizing a boot controller that configures a cache for use as memory for hardware initialization code prior to executing the hardware initialization code, according to an implementation of the present disclosure.

[0007] [Figure 3] 1 illustrates a system-on-chip (SoC) including a shared cache used to improve the boot process for early display initialization and visualization, according to an implementation of the present disclosure.

[0008] [Figure 4] 1 illustrates a memory hierarchy showing exemplary response times for memory accesses, according to implementations of the present disclosure.

[0009] [Figure 5] 1 illustrates a modified firmware boot flow of a system to improve the boot process for early display initialization and visualization, according to an implementation of the present disclosure.

[0010] [Figure 6] 10 illustrates an example flow of hardware initialization in which a cache is configured as static memory before executing hardware initialization code, according to an implementation of the present disclosure.

[0011] [Figure 7] FIG. 1 is a flow diagram illustrating operations for improving the boot process for early display initialization and visualization according to implementations of the present disclosure.

[0012] [Figure 8] FIG. 1 is a schematic diagram of an exemplary electronic computing device for enabling an improved boot process for early display initialization and visualization, in accordance with implementations of the present disclosure. DETAILED DESCRIPTION OF THE INVENTION

[0013] The embodiments described herein are directed to improving the boot process for early display initialization and visualization.

[0014] When a processing system is turned on or reset, it may perform a boot process before it can be used for work. As described herein, the operations that prepare the processing system to run an OS may be referred to as a "boot process." Similarly, the time that elapses during the boot process may be referred to as "boot time." The control logic or firmware that performs or controls the boot process may be referred to as "system firmware," "system boot code," "platform boot code," or simply "boot code."

[0015] As part of an improved user experience, applications that use computer systems may require instantaneous (e.g., instantaneous to a human eye) system boot-up times. Shorter system response times are key performance indicators (KPIs) that may be used by original equipment manufacturers (OEMs) and original design manufacturers (ODMs) for their product requirements in various computing sectors, such as personal devices (e.g., smartphones / tablets / laptops), healthcare (e.g., ultrasound, defibrillators, and patient monitoring devices), industrial (e.g., robots that change arms), military, aerospace, and government (MAG) (e.g., missile firing, fail-safe redundancy for aircraft, or similar single-function devices), and / or office / home automation. In a particular use, the average system (e.g., platform) boot time is expected to be less than a threshold (e.g., 500 ms) (e.g., in the Advanced Configuration and Power Interface (ACPI) standard) from a system state (e.g., no power applied) (e.g., starting in ACPI "mechanical off" (e.g., "G3" state)) to operating system (OS) handoff.

[0016] In consumer electronics products, a product differentiator is user experience (UX). A common practice for product manufacturers is to enhance UX by providing shorter boot-up times along with rapid system response. Faster system response corresponds to the perceived boot-up time measured by the duration until the visualization of the display to the end user. The visualization of the display to the user is also referred to herein as "display bring-up." An exemplary duration of display bring-up may be measured from when a user presses the power button until the display appears on the associated display panel. Reducing the duration corresponding to display bring-up correlates with faster system response from a UX perspective.

[0017] For display initialization, a set amount of system memory is used for display initialization. In one example, for a 4K panel, approximately 68 MB of system memory is used for display initialization. In conventional systems, the boot process does not have pre-programmed memory available upon processor reset (e.g., central processing unit (CPU) reset), and there is limited cache memory. As a result, there is not enough memory available for display initialization to use for display bring-up until the boot process has completed memory such as dynamic random access memory (DRAM) to train and bring-up such DRAM. This limits the ability of conventional systems to enable early boot display, thereby improving response time for the UX.

[0018] Implementations of the present disclosure address the above technical problem by providing an improved boot process for early display initialization and visualization. In one implementation, hardware initialization code (such as a basic input / output system (BIOS) and / or a unified extensible firmware interface (UEFI)) improves the process by configuring a shared (e.g., L4) cache to be available upon processor reset (e.g., CPU reset). In implementations of the present disclosure, this shared cache available upon reset can be utilized to provide faster pre-reset display bring-up. Implementations of the present disclosure modify the pre-reset initialization flow of the boot process to initialize at least a portion of the shared cache as static memory (e.g., SRAM) available for platform initialization use (e.g., use by the BIOS and / or UEFI). Implementations of the present disclosure utilize the shared (e.g., L4) cache initialized as static memory for early display initialization, independent of DRAM training and initialization during the boot process. For example, a portion of the shared (e.g., L4) cache initialized as static memory may be used to store display device initialization code used for early display device initialization and display bring-up, independent of DRAM training and initialization in implementations of the present disclosure.

[0019] Thus, implementations of the present disclosure improve early boot display and reduce response time for the UX of a processing system. Specifically, implementations of the present disclosure may bring up the display much earlier, which provides better response time and enhances UX. For example, PCI enumeration and display device initialization may be performed much earlier in the boot process compared to conventional systems, where this does not occur until after DRAM training is complete. Furthermore, having static memory available at reset may further assist the boot process in other boot process tasks. Referring to FIG. 1, an exemplary system-on-chip (SoC) is shown.

[0020] FIG. 1 illustrates a system-on-chip (SoC) 100 for improving the boot process for early display initialization and visualization, according to an implementation of the present disclosure. The SoC 100 includes a boot controller 146. The boot controller 146 may be located within the processor 102. The illustrated SoC 100 illustrates a hardware processor 102 coupled to a memory 106 via a memory controller 108. In one embodiment, the memory 106 of the SoC 100 is system memory (e.g., dynamic random access memory (DRAM)). The memory controller 108 may be included between the processor 102 and the memory 106, for example, to manage memory requests. In one embodiment, the memory controller 108 provides (e.g., fills) data (e.g., cache lines) for cache misses (e.g., misses in L3 124, L4 126, or other last level caches (LLCs) of the processor 102.

[0021] Processor 102 may include one or more, e.g., 0 to N, processor cores 112, where N is a positive integer. In one embodiment, each of the multiple processor cores has an instance of the circuitry described herein. Core 0 112(0) is shown to include a first level (L1) data cache 118(0), a first level (L1) instruction cache 120(0), and a level two (L2) cache 122(0). Core 1 112(1) is shown to include a first level (L1) data cache 118(1), a first level (L1) instruction cache 120(1), and a level two (L2) cache 122(1).

[0022] In some embodiments, as shown in FIG. 1 , processor 102 includes one or more next-level (e.g., level 3 (L3) cache 124 and level 4 (L4) cache 126) caches coupled to and shared by one or more (e.g., all) cores, e.g., L4 being a last-level cache (LLC) (e.g., the last cache searched before a data item was fetched from memory 106). In particular embodiments, each of L1 data cache 118, L1 instruction cache 120, L2 cache 122, L3 cache 124, and L4 (e.g., LLC) cache 126 is managed by cache coherency controller 142 (e.g., circuitry), e.g., to cache data (e.g., and / or instructions) according to a specified cache coherency.

[0023] In particular embodiments, data (e.g., and / or instructions) stored in the various processor caches are managed at the granularity of cache lines, which may be a fixed size (e.g., 64, 128, 512 bytes long, etc.). Each core 112 may include, among other components, instruction fetch circuitry for fetching instructions (e.g., from (e.g., main) memory 106 via memory controller 106 and / or from a cache), decode circuitry (e.g., a decoder or decode unit) for decoding instructions (e.g., decoding program instructions into micro-operations or “uops”), and execution units (e.g., execution circuitry) for executing the decoded instructions. A core may include writeback / retirement circuitry for retiring instructions and writing back results. The illustrated core 0 112(0) further includes a set of one or more registers 114(0), e.g., with one or more model-specific registers 116(0), e.g., as control registers.

[0024] SoC 100 may include one or more other devices 144 (e.g., CSME, GSPI, ESPI, etc., any devices that should be initialized before DRAM initialization is added to a cache) that are also coupled to cache coherency controller 142. SoC 100 may include graphics circuitry 136 (e.g., a graphics core). In particular embodiments, graphics circuitry 136 includes one or more caches 138 that are coupled to one or more caches shared with the processor, such as L3 cache 124 and / or L4 cache 126. SoC 100 may include embedded dynamic random access memory 140 (eDRAM), embedded in SoC 100, for example, with processor 102. In particular embodiments, eDRAM 140 is used as L4 (e.g., LLC) cache 126 (e.g., instead of using embedded static RAM (eSRAM) for the L4 cache). In particular embodiments, eDRAM 140 is located between L3 cache 124 and memory 106 (e.g., DRAM (e.g., double data rate synchronous DRAM (DDR))), e.g., on a memory bus. SoC 100 may include a power management integrated circuit 154 (PMIC) that provides power (e.g., to components of SoC 100), e.g., in response to a power-on indication (e.g., pressing a mechanical on / off switch).

[0025] In some implementations, SoC 100 (e.g., internal or external to processor 102) includes hardware initialization code storage 148. The hardware initialization code may be hardware initialization firmware. In particular embodiments, the hardware initialization code from storage 148, when executed by processor 102, causes boot-up of SoC 100 (e.g., boot-up of at least its hardware processor 102).

[0026] In some implementations, the hardware initialization code is responsible for transferring control of a computer (eg, SoC 100) to a program (eg, an OS) stored in memory coupled to the computer.

[0027] In some implementations, hardware initialization code storage 148 includes BIOS and / or UEFI code from storage 150 and boot loader code from storage 152. In certain of these embodiments, the BIOS and / or UEFI (e.g., boot ROM) code is executed as a first stage, and then the boot loader code is executed as a second stage. As one example, the BIOS code conforms to the BIOS standard. As another example, the UEFI code conforms to the UEFI standard.

[0028] In some implementations, the BIOS and / or UEFI code effects a (e.g., cold) reset of SoC 100 (e.g., its processor 102), placing the processor in a known stable state, checking for second-stage boot loader code (e.g., from storage 152), and passing control to the next stage. In one embodiment, the BIOS and / or UEFI (e.g., boot ROM) code is aware of second-stage boot loader code 152 and is unaware of any potential subsequent software stages. In certain embodiments, during this period, the BIOS and / or UEFI (e.g., boot ROM) code handles any error conditions.

[0029] In some implementations, the boot loader code (e.g., passed control to the SoC (e.g., processor) when the BIOS and / or UEFI code stage is completed) then locates and loads (e.g., for execution by the processor) the next stage of software (e.g., OS), etc. In one embodiment, before control is passed to the boot loader code, it is decrypted and / or authenticated if secure boot is enabled.

[0030] In some implementations, the BIOS and / or UEFI (e.g., boot ROM) code, when executed, initializes certain hardware of the SoC, checks its integrity, and initializes (e.g., first-level) boot loader code. In some implementations, the boot loader code is invoked, for example, upon completion of execution of the BIOS and / or UEFI (e.g., boot ROM) code, and then executes to cause a handoff of control of the SoC (e.g., processor) to an operating system running on the SoC. In one implementation, for example, the boot loader code knows where in memory (e.g., memory location) an OS kernel image is stored and loads the OS kernel image for execution.

[0031] Although BIOS and / or UEFI (e.g., boot ROM) code storage 150 and boot loader code storage 152 are shown together, in another implementation, BIOS and / or UEFI (e.g., boot ROM) code storage 150 is within processor 102 and boot loader code storage 152 is separate from processor 102 (e.g., in storage 148 of SoC 100).

[0032] In some implementations, once boot is complete, certain control of the SoC is transferred to the executing OS code 160 (and / or application code 162). In certain implementations, the BIOS / UEFI code 150 includes authenticated code module (ACM) code. In one implementation, the ACM code supports the establishment of a measured environment that enables the capabilities of an authenticated code execution mode, for example, by the ACM code being loaded into the processor and executed using tamper-resistant mechanisms. Authentication can be achieved by a digital signature in the header of the ACM code, for example, where the processor calculates a hash of the ACM and uses the result to verify the signature. For example, the processor then initializes the processor state or executes the ACM if the ACM passes authentication.

[0033] In implementations of the present disclosure, the BIOS and / or UEFI provided by BIOS / UEFI code 150 is improved by configuring L4 cache 126 to be available at reset and using this L4 cache 126 available at reset to provide faster pre-reset display bring-up. Implementations of the present disclosure modify the pre-reset initialization flow of the boot process to initialize at least a portion of L4 cache 126 as static memory (e.g., SRAM) available for platform initialization use (e.g., use by BIOS and / or UEFI). Implementations of the present disclosure utilize L4 cache 126 initialized as static memory for early display initialization independent of DRAM training and initialization during the boot process. For example, portion 158 of L4 cache 126 initialized as static memory can be used to store display device initialization code 159 used for early display device initialization and display bring-up independent of DRAM training and initialization in implementations of the present disclosure. 2A and 2B, an exemplary boot flow of a boot process according to an implementation of the present disclosure is shown.

[0034] FIG. 2A illustrates an example boot flow 200 according to an implementation of the present disclosure. The illustrated flow 200 shows one implementation of an architecture (e.g., Intel® Architecture (IA)) platform boot path. For example, the boot time flow is from an initial “mechanical off” state (e.g., ACPI G3) to a working state (e.g., ACPI G0 sleep state S0 (e.g., an operational S0 state, not S0 low-power idle (e.g., “standby” or partial SoC sleep))). The boot flow 200 may include boot path components before power (e.g., all rails and clock stabilization, e.g., real-time clock (RTC)), before reset (e.g., power sequencing, reset / security, authenticated code module (ACM), microcode (ucode) / power management code (pcode), etc.), and after central processing unit (CPU) reset (e.g., boot loader).

[0035] The illustrated boot flow 200 includes accepting power on at 202 (e.g., exiting G3 state), an initial power sequence 204 (e.g., performed by the PMIC), SoC security and reset 206 (e.g., the SoC (e.g., its reset manager) generating a module reset signal based on reset requests from various sources in the hardware processor system (e.g., processor 102), any storage (e.g., storage 148), and a software write to a module reset control register where the reset manager terminates the reset of the SoC if, for example, secure fuses are loaded and verified). ) and authenticated code module 208 (e.g., according to known IA guidelines and boot guard (a combination of BIOS guard, TXT, and ACM) used to verify other firmware blocks) that is executed to cause completion of the secure boot, and then hardware initialization code 210 (e.g., such that BIOS and / or UEFI code 210A from storage 150 and boot loader code 210B from storage 152 are executed, e.g., sequentially); after an OS handoff, the OS may then execute 212, and one or more (e.g., user) applications may then execute 214 (e.g., under control of the OS). Note that blocks 202-214 are merely examples, and more or fewer blocks may be utilized in the boot flow.

[0036] In some implementations, the most time-consuming phase of the entire boot path is the execution of code (e.g., firmware) used to perform hardware initialization during the boot process (e.g., sometimes referred to as basic input / output system (BIOS) processing), making it the phase to optimize for providing a fast boot experience. In certain embodiments, the size of the hardware initialization code (e.g., BIOS / UEFI code and / or boot loader code) increases as more workloads are executed.

[0037] Implementations herein provide an improved boot flow by utilizing a boot controller (e.g., circuitry) that configures a cache to use as memory for hardware initialization code (e.g., memory 158 in FIG. 1 , where the size of the BIOS configuration memory can be pre-allocated between 64 MB and 256 MB) before executing hardware initialization code, e.g., before entering any hardware initialization code (e.g., BIOS code or UEFI code). The improved boot flow of implementations of the present disclosure utilizes pre-initialized memory to enable display initialization to be performed without relying on DRAM resources that are trained and initialized by the hardware initialization code.

[0038] FIG. 2B illustrates an example boot flow 220 utilizing a boot controller 216 that configures a cache for use as a memory for hardware initialization code prior to executing hardware initialization code 210, according to an implementation of the present disclosure. The illustrated flow 220 illustrates one embodiment of an architecture (e.g., Intel® Architecture (IA)) platform boot path. For example, the boot time flow is from an initial “mechanical off” state (e.g., ACPI G3) to a working state (e.g., ACPI G0 sleep state S0 (e.g., an operational S0 state, not S0 low-power idle (e.g., “standby” or partial SoC sleep))). Boot flow 220 may include boot path components before power (e.g., all rails and clock stabilization, e.g., real-time clock (RTC)), before reset (e.g., power sequencing, reset / security, authenticated code module (ACM), microcode (ucode) / power management code (pcode), etc.), and after central processing unit (CPU) reset (e.g., boot loader).

[0039] The illustrated boot flow 220 includes accepting power on at 202 (e.g., exiting G3 state), initial power sequencing 204 (e.g., performed by the PMIC), SoC security and reset 206 (e.g., with the SoC (e.g., its reset manager) generating a module reset signal based on reset requests from various sources in the hardware processor system (e.g., processor 102), any storage (e.g., storage 148), and software writes to module reset control registers that cause the reset manager to terminate the reset of the SoC if, for example, secure fuses are loaded and verified), and hardware initialization code 21. 2, includes a boot controller 216 for initializing a portion of a cache (e.g., an L4 cache) for use by the boot controller 216; an authenticated code module 208 that executes to ensure a secure boot is completed; and then hardware initialization code 210, such that, for example, BIOS and / or UEFI code 210A from storage 150 and boot loader code 210B from storage 152 execute, e.g., in parallel, through use of the portion of the cache (e.g., an L4 cache) initialized by the boot controller 216; after an OS handoff, the OS may then execute 212, and one or more (e.g., user) applications may then execute 214 (e.g., under control of the OS). Note that blocks 202-216 are merely examples, and that more or fewer blocks may be utilized in the boot flow.

[0040] Also, in some implementations, (e.g., BIOS / UEFI) hardware initialization (e.g., boot) may occur in a single-threaded (e.g., single core running multiple cores) environment, resulting in independent (e.g., input / output (I / O)) initialization waiting its execution time or turn. In some implementations, hardware initialization code (e.g., BIOS firmware) runs in a single-threaded environment because there is insufficient pre-initialized memory available at reset and / or there is (e.g., limited) memory at reset, which does not allow for a multi-threaded environment. Implementations herein provide a faster boot process without using cache-as-random-access-memory (RAM) (CAR) that is set up during execution of the hardware initialization code (e.g., using a complex and limited CAR setup). Some implementations herein provide a faster boot process without tying up (e.g., static) memory (e.g., static random access memory (SRAM)) provided for boot (e.g., firmware) space use. Some implementations herein provide a faster boot process without using a last level cache (LLC) in the processor (although, for example, an LLC in an SoC may be used).

[0041] As described above, in conventional systems, the platform boot process does not have pre-programmed memory at reset (e.g., in the CPU), and is provided with limited cache memory size, resulting in an ineffective boot method using a single-core processor at reset. This limits the system's ability to initialize display devices and bring up the display until DRAM is available. This results in hardware initialization code (e.g., BIOS / FW) execution running sequentially, resulting in slower boot times and ineffective use of processor power. Therefore, the lack of memory to effectively use existing processor power and system resources to provide faster boot response (and display bring-up time) results in wasted system resources and a subpar user experience.

[0042] Particular implementations herein provide a memory system for a computing architecture augmented with several levels of caches, for example, as shown in FIG. In one example, the memory system includes: A read-only memory path for images (e.g., in the Open Computing Language (OpenCL) standard) including Level 1 (L1) and Level 2 (L2) sampler caches. Level 3 (L3) data cache as a slice-shared (e.g., across multiple cores) asset. In one embodiment, all read and write operations to (e.g., OpenCL) buffers (e.g., caches) pass through the L3 data cache in cache-line units (e.g., 64-byte wide). In one embodiment, the L3 cache contains missed sampler read transactions in the L1 and L2 sampler caches and also supports sampler writes. The system-on-chip (SoC) memory hierarchy may include a (e.g., larger) last level cache (LLC) (e.g., an LLC shared between the CPU and a graphics processing unit (GPU) (e.g., graphics core 136)), system dynamic random access memory (DRAM) 106, and (optionally) embedded DRAM (eDRAM) 140. This LLC may include, for example, a level 4 (L4) cache that has a larger size and is used to improve performance in a hybrid CPU and GPU ecosystem.

[0043] In some implementations, the level 4 (L4) and / or LLC shared cache has a larger size than that of the processor (e.g., CPU) or GPU alone, improving performance, for example, in hybrid ecosystems that use a CPU and a GPU. However, the disconnect in some conventional systems can be inefficient in system resources due to the lack of visibility to the boot process of this large chunk of L4 and / or LLC cache memory. Implementations described herein address this disconnect in the memory hierarchy during the system boot phase (e.g., before executing hardware initialization code, e.g., BIOS / UEFI code).

[0044] In some implementations, UX performance metrics include faster system response, including faster boot times and faster display bring-up times. Certain implementations herein provide a faster ecosystem boot process that does not work on a single core due to, for example, a lack of visibility into cache memory during boot time, thus limiting the capabilities of multi-core processor systems. Implementations herein improve the boot process by enabling multi-core environments by extending (e.g., LLC / L4) cache memory at reset, enabling hardware initialization (e.g., boot) code (e.g., firmware), and utilizing LLC / L4 cache for display initialization and early display bring-up independent of DRAM training and initialization by the hardware initialization code.

[0045] In certain implementations, the SoC hardware is modified to configure the L4 cache as static memory, such as static RAM (SRAM), and / or to provide a larger pre-initialized memory at reset for boot firmware. Implementations herein utilize the L4 cache (e.g., persistent memory, such as, but not limited to, Intel® Optane® persistent memory) as memory for use by hardware initialization code, for example, prior to secure boot. In one embodiment, the access time of the (e.g., L4) cache is (e.g., significantly) shorter than the access time of system memory (e.g., DRAM). Embodiments herein expose portions of the (e.g., L4) cache (e.g., at boot time) to enable, for example, display initialization and early display bring-up independent of DRAM training and initialization by hardware initialization code.

[0046] Certain implementations herein include an on-package (e.g., L4) cache (e.g., 64 MB to 256 MB) (e.g., having access times much shorter than DRAM access times, e.g., with DRAM sizes of approximately 4 GB to 32 GB) that is used to improve hardware initialization code (e.g., firmware) and thus boot and display bring-up times. Certain implementations herein provide (e.g., more) pre-initialized memory upon (e.g., power-on) reset, e.g., as part of the processor (e.g., CPU) reset process (but not, e.g., as part of the hardware initialization process (e.g., BIOS or UEFI process)). Certain embodiments herein provide (e.g., more) pre-initialized memory at reset to invalidate legacy (e.g., x86) BIOS / UEFI assumptions and / or provide faster and more efficient BIOS / UEFI solutions for modern device use cases, such as, but not limited to, automotive in-vehicle infotainment (IVI) (e.g., turning on rearview camera in less time), domestic robots, industrial robots, etc.

[0047] The following describes two implementation categories: (1) making the (e.g., L4) cache available as part of the SRAM, and (2) using the shared (e.g., L4) cache as SRAM upon reset to enable early display initialization and display bring-up. In a specific implementation of category (1), the hardware initialization code (e.g., firmware) is aware of the SRAM base and limits its use (max). Here, for example, the hardware initialization code uses the (e.g., L4) cache for all normal operations, such as resource allocation, instead of DRAM-based resources. In some implementations, a portion of the L4 / LLC cache configured as pre-programmed SRAM is available for hardware initialization code consumption (e.g., for use by the code when it executes). Therefore, the access time of the (e.g., L4) cache is faster than the DRAM access time, which improves boot time (e.g., by reducing the total time to execute the hardware initialization code).

[0048] In certain implementations of category (2), the hardware initialization code is modified to utilize the L4 / LLC cache configured as SRAM and available at reset. Thus, some implementations allow the design / redesign of the hardware initialization code (e.g., firmware) to use pre-initialized memory to perform display initialization without relying on DRAM resources trained and initialized by the hardware initialization code following reset.

[0049] In a particular implementation, execution of a processor identification instruction (e.g., a CPUID instruction) or reading of a (e.g., dedicated) model-specific register (MSR) indicates whether the features described herein are available (e.g., for a particular system / processor).

[0050] The following description of the two implementation categories includes methods (e.g., in addition to hardware) that, in certain embodiments, enable all (e.g., BIOS or UEFI) hardware initialization (e.g., boot) to occur in a multi-threaded (e.g., multiple core) environment.

[0051] In some implementations, the platform boot time of a device refers to the total time it takes for something to appear on the device's screen after the device has been commanded to turn on (e.g., mostly consisting of BIOS or UEFI boot time (and boot loader time) + OS boot time).

[0052] 3 illustrates a system-on-chip (SoC) 300 including a cache 308, such as an L4 cache, used to improve the boot process for early display initialization and visualization, according to an implementation of the present disclosure. The illustrated SoC 300 includes one or more cores 302 (e.g., plus a boot controller 304 as described herein), a graphics circuit 306 (e.g., a GFX core), and a cache 308 shared by the one or more cores 302 and the graphics circuit 306. The illustrated cores 302 and cache 308 are coupled to memory 310 (e.g., DRAM). For example, a first die of the SoC 300 may include the one or more cores 302 and the graphics circuit 306, a base die may include the cache 308 initialized by the boot controller 304, and the package of the SoC 300 may include the memory 310 (e.g., DRAM).

[0053] Thus, in particular embodiments, the (e.g., L4) cache 308 is shared by the (e.g., data) processor and the graphics processor, e.g., such that the shared cache (e.g., in the base die of the SoC) has a larger size than the cache used by the (e.g., data) processor (e.g., approximately 400 MB to 700 MB in size). In particular embodiments, one or more coherent memory interfaces (CMIs) are utilized as coupling between the cache and another component (e.g., the CPU and / or GPU). In particular embodiments, the coupling between the CPU (e.g., cores 302) and GPU 306 follows the Computer Express Link (CXL) standard.

[0054] The following is an example of hardware and firmware design details for configuring a cache 308, such as an L4 / LLC cache, as static memory (e.g., SRAM) available as system memory for use during the hardware initialization (e.g., boot) (e.g., hardware initialization code) phase. One use case for system memory is to allocate resources to devices (e.g., devices coupled together according to the Peripheral Component Interconnect Express (PCI Express) standard) and read kernel blocks from the boot device before booting the OS. In one implementation, a fixed amount (e.g., approximately 256 MB to 384 MB) of system memory (e.g., initialized by the boot controller) is allocated to hardware initialization code to perform device initialization in the pre-boot environment. For example, the display engine is a PCI device that utilizes approximately 68 MB of memory for initialization in the pre-boot environment.

[0055] In a particular implementation, a system (e.g., an auxiliary processor core or controller) initializes a portion of a shared (e.g., L4) cache (as described herein) for use by platform hardware initialization code (e.g., as SRAM). Optionally, an indication (e.g., via a model specific register (MSR)) is provided of the physical start and limits of the SRAM for hardware initialization code design.

[0056] In some implementations, the flow of hardware initialization code is modified to reference static memory resources of the (e.g., PCI) device to avoid long waits for DRAM-based memory training. The hardware initialization code may allocate memory for the display device and call the display driver for display initialization. Because multi-core capabilities are available at reset due to the availability of the L4 / LLC cache as SRAM, display initialization may run in parallel with other hardware initialization code flows.

[0057] In some implementations, additional security lockdown can be provided on top of the SRAM range. For example, before booting into the OS, the "(e.g., L4) cache configured as SRAM" range can be disabled / locked down. For example, once disabled / locked, it cannot be overridden without a platform reset. In one implementation, the Firmware Support Package (FSP) handles this lockdown using the "firmware exit" boot event.

[0058] In implementations of the present disclosure, the above hardware and / or firmware design changes may use package (e.g., L4) cache as SRAM for hardware initialization code access, for example, providing a much larger pre-initialized memory at (e.g., SoC) reset for the hardware initialization code to utilize. Also, the firmware flow may be independent of DRAM memory training, which takes longer to initialize. For example, access to (e.g., L4) cache memory ranges may be faster than DRAM memory access.

[0059] 4 illustrates a memory hierarchy 400 showing example response times for accesses to a DRAM 402 and to multiple caches 404, 406, 408, 410 according to an implementation of the present disclosure. The caches may include an L1 cache 410, an L2 cache 408 (e.g., both within a core 412), an L3 cache 406, and an L4 cache 404.

[0060] As described above, implementations of the present disclosure may utilize a package cache, such as an L4 cache, instead of DRAM-based memory access because DRAM access takes longer compared to cache access. In some implementations, a shared (e.g., L4) cache is used as a larger, faster memory available at reset, and hardware initialization code is modified to utilize this pre-initialized memory (rather than defining a hardware initialization code (e.g., BIOS or UEFI) flow that relies on DRAM resources). Implementations of the present disclosure perform bring-up by using a shared (e.g., L4) cache as SRAM at reset, enabling early display initialization.

[0061] 5 illustrates a modified firmware boot flow 500 for a system in which (e.g., L4) cache is configured as SRAM before reset and all cores (e.g., BSP and AP) are enabled at reset, e.g., without memory constraints, to optimize hardware initialization code execution (e.g., boot phase) for faster boot processing. In an implementation of the present disclosure, the modified firmware boot flow 500 includes a pre-reset phase 510, which occurs between power on and CPU reset, an SRAM utilization phase 520, a memory initialization phase 530, a post-memory phase 540, a payload phase 550, and an OS runtime phase 560. The pre-reset phase 510 may include power sequencing, reset / security, ACM, ucode / pcode, etc.

[0062] Pre-reset phase 510 may also include a sub-stage 515 for configuring a shared cache (e.g., an L4 cache) as static memory (e.g., an SRAM). Configuring the L4 cache in sub-stage 515 may be performed as described above in connection with FIGS. 2A, 2B, 3, and / or 4. The configured shared (e.g., L4) cache as SRAM may then be utilized in utilization of SRAM stage 520. A sub-stage of display initialization module 525 may enable earlier display initialization and display bring-up by using the shared (e.g., L4) cache as SRAM at reset, independent of DRAM training and initialization in memory initialization phase 530. Accordingly, display utilization 590 (e.g., display bring-up time) is shown relative to modified firmware boot flow 500, illustrating that a display may be brought up for display by memory initialization phase 530 earlier and / or faster than display bring-up in conventional systems.

[0063] A post-reset core boot stage 570 and a UEFI stage 580 are illustrated relative to flow 500. Core boot stage 570 may include boot block 571, verstage 572, rom stage 573, postCAR 574, ram stage 575, and deep charge stage 577, which are described in further detail below in connection with FIG. 6. UEFI stage 580 may include security (SEC) stage 581, pre-EFI initialization (PEI) stage 582, driver execution environment (DXE) stage 583, and boot device selection (BDS) stage 584.

[0064] Exemplary hardware and firmware design details overcome the constraint of limited memory available at reset (e.g., using embodiments in category (1) above) by including a shared (e.g., L4) cache accessible by the processor (e.g., CPU) as part of the SRAM, allowing multiple (e.g., all) cores (e.g., bootstrap processor BSP and application processor AP) to be reset early and assigned resources (e.g., the same AP as the BSP) to execute parallel tasks. Certain embodiments herein invalidate / lock down a (e.g., L4) cache range (e.g., a cache used as boot SRAM) before booting into the OS.

[0065] Figure 6, described below, illustrates a modified firmware boot flow for a system in which the (e.g., L4) cache is configured as SRAM before reset and all cores (e.g., BSP and AP) are enabled at reset, e.g., without memory constraints, to optimize execution of hardware initialization code (e.g., boot phase) for faster boot processing.

[0066] 6 illustrates an example flow 600 of hardware initialization in which a cache (e.g., an L4 / LLC shared cache) is configured (e.g., by a boot controller) as static memory (e.g., SRAM) before executing hardware initialization code, according to an implementation of the present disclosure. In flow 600, BIOS / UEFI code 610 includes a boot block stage 612, a ROM stage 616, and a RAM stage 618.

[0067] For example, the boot block stage 612 includes tasks such as resetting vectors, switching processor modes, utilizing the L4 cache, and / or enabling the console. The boot block stage 612 also includes a display module sub-block 614 that includes a graphics device resource allocation stage, a display bring-up stage, making the logo visible, and determining if the frame buffer is ready for application use.

[0068] ROM stages 616 include (e.g., processor) chipset initialization, populating memory initialization phase (e.g., FSP-M) data structures, calling memory initialization phase, and / or creating a console (e.g., CBMEM). RAM stages 618 include calling silicon initialization phase (e.g., FSP-S), PCI enumeration and resource allocation, creating memory and in-memory OS power tables (e.g., e820 and ACPI tables), and locking down a portion of the (e.g., L4) cache (e.g., SRAM range) used as memory for hardware initialization code.

[0069] In a particular implementation, once BIOS / UEFI code 610 is executed, it causes the execution of boot loader code 620. For example, boot loader code 620 is used to read the block device for the kernel partition and boot into the OS.

[0070] In a particular implementation, the RAM stage 618 operates from (e.g., SPI) mapped memory, using (e.g., L4) cache as memory (e.g., SRAM), and all context is moved to DRAM mapped memory before jumping from the BIOS / UEFI code 610 to the boot loader code 620.

[0071] In the implementation shown, once the hardware initialization code 610 completes, an OS handoff is performed, transferring control of the system (e.g., processor) to the OS 630 (e.g., OS kernel). An exemplary security policy is to lock down the SRAM memory ranges used by the hardware initialization code before booting into the operating system.

[0072] As described above and shown in the preceding examples, implementations of the present disclosure use a shared (e.g., L4) cache as an SRAM reset to enable early display initialization and display bring-up. Accordingly, implementations utilize pre-initialized memory (e.g., larger than the L1, L2, or L3 cache) at reset for use by hardware initialization code. The hardware initialization code (e.g., firmware) flow may be independent of DRAM memory training, which takes longer than initialization, for example. Early hardware initialization code stages (e.g., before DRAM initialization) may be avoided to reduce the hardware initialization code footprint. Auxiliary processor cores and / or controllers (e.g., microcontrollers) within an SoC may, for example, initialize an (e.g., L4) cache as an SRAM without requiring the use of a (e.g., IA) processor (e.g., BSP) core. In certain implementations, memory (e.g., L4 cache) is available before any (e.g., processing) core is released from reset.

[0073] Certain implementations do not use Cache-as-RAM (CAR) ("tempRAM init") in the flow of hardware initialization code, for example, to reduce complex assembly programming in boot loader space. Implementations allow CPU, chipset, and PCI enumeration to be performed early without relying on DRAM initialization, and instead use SRAM to perform all CPU / chipset programming. Implementations of the present disclosure allow CAR teardown logic to be avoided.

[0074] Implementations of the present disclosure obtain a larger portion of memory from the L4 cache SRAM bucket for early display initialization use cases. Certain implementations initialize SRAM-based memory resources to the integrated graphics device for register access of memory-related devices. Some implementations map SRAM-based memory to UMA-based based on maximum resolution support. In implementations of the present disclosure, the GTT is built based on the UMA-based.

[0075] The implementation allocates graphics stolen memory depending on the state of the device. In integrated graphics devices, all base address register (BAR) access registers are implemented using pre-requisite SRAM-mapped memory.

[0076] In some implementations, control may be transferred to the GOP / Graphics PEIM module for further device-related programming, which may include, but is not limited to, setting up a frame buffer in linear mode directed to L4 cache SRAM memory, accessing the frame buffer through a PCI aperture programmed during SRAM initialization, accessing the base address register of the graphics core device, performing clock programming, initializing clock PLL programming, setting the display clock frequency, identifying endpoint ports for display panel initialization, setting supported modes depending on the UMA size, and / or performing recommended display panel training, in accordance with the UEFI specification.

[0077] In implementations of the present disclosure, following device-related programming, the boot loader may ensure that the display frame buffer address and size have been programmed along with the supported resolutions and display clocks. Any further applications may now directly access the frame buffer address for display purposes.

[0078] Certain implementations allow CAR teardown logic to be avoided. Certain implementations avoid switching between temporary memory (e.g., CAR) and persistent memory (e.g., DRAM-based) in the boot (e.g., boot loader) space, and all boot loader execution can be driven from SRAM-based fixed memory. Certain implementations perform DRAM initialization at the end of the hardware initialization code (e.g., boot loader) sequence to ensure, for example, that the payload or OS can use DRAM-based resources in cases of higher memory utilization.

[0079] Certain implementations allow all cores to be available at reset, allowing the BSP to make the AP operational early without any memory bottlenecks. Certain implementations allow hardware initialization code (e.g., BIOS / UEFI) to run in a multithreaded (e.g., multiple core) environment. Certain implementations allow firmware support packages (e.g., FSP-M for DRAM initialization and FSP-S for chipset initialization) to run on parallel threads to optimize boot time. Certain implementations allow the boot sequence of all hardware initialization code (e.g., firmware) to be spread across all cores and for execution to occur on parallel threads, where the parallel threads may perform, for example, (i) boot events for the bootstrap processor (BSP) for handling reset vectors, processor mode switching, console enablement, generating boot loader memory layout, and chipset initialization; (ii) entering configuration parameters, e.g., FSP-M, to initialize DRAM, executing memory reference code (MRC) to initialize DRAM, performing independent security boot operations (e.g., verified boot), and independent I / O programming. and (iii) a boot event of another AP core (e.g., AP0, AP1...APn) to enter configuration parameters, e.g., FSP-S, to initialize hardware blocks, execute FSP-S for detailed chipset initialization, read kernel partition from block device used to boot OS, and lock down part of cache (e.g., L4 SRAM range) used by execution of hardware initialization code for security compliance.

[0080] 7 is a flow diagram 700 illustrating operations for improving the boot process for early display initialization and visualization according to an implementation of the present disclosure. Some or all of the operations 700 (or other operations described herein, or variations and / or combinations thereof) are performed under the control of one or more computer components configured to execute and are implemented as code (e.g., executable instructions, one or more computer programs, or one or more applications). The code is stored on a computer-readable storage medium, for example, in the form of a computer program comprising instructions executable by one or more processors. The computer-readable storage medium is non-transitory. In some embodiments, one or more (or all) of the operations 700 are performed by a boot service.

[0081] The operation 700 includes powering on a system having a plurality of processor cores coupled to a cache at block 710. The operation 700 further includes initializing, by a controller of the system, a portion of the cache as static memory for use by the hardware initialization code before beginning execution of the hardware initialization code at block 720. The operation 700 further includes executing the hardware initialization code for one or more of the plurality of processor cores to initialize the system at block 730.

[0082] The operations 700 further include performing display initialization using memory from the portion of the cache initialized as static memory at block 740. In one implementation, the display initialization is performed independently from the initialization of the system's DRAM. The operations 700 further include transferring execution control of the system from the hardware initialization code to operating system code executing on the system at block 750.

[0083] 8 is a schematic diagram of an exemplary electronic computing device for facilitating an improved boot process for early display initialization and visualization, according to some embodiments. In some embodiments, the computing device 800 includes one or more processors 810, including one or more processor dies (e.g., cores) 818, each including a hardware initialization component 864, such as a component for executing hardware initialization code, and including the BIOS / UEFI coder 150 and / or boot loader code 152, as described in connection with FIG. 1. In some embodiments, the computing device provides an improved boot process for early display initialization and visualization using an L4 cache 865 associated with cache 862, as provided in FIGS. 1-7.

[0084] Computing device 800 may additionally include one or more of the following: cache 862, a graphical processing unit (GPU) 812 (which may be a hardware accelerator in some implementations), a wireless input / output (I / O) interface 820, a wired I / O interface 830, a system memory 840 (e.g., memory circuitry), power management circuitry 850, a non-transitory storage device 860, and a network interface 870 for connection to a network 872. The following discussion provides a brief, general description of the components that form exemplary computing device 800. Exemplary, non-limiting computing device 800 may include a desktop computing device, a blade server device, a workstation, or a similar device or system.

[0085] In an embodiment, processor core(s) 818 are capable of executing machine-readable instruction set(s) 814, reading data and / or instruction set(s) 814 from, and writing data to, one or more storage devices 860. Those skilled in the art will appreciate that the illustrated embodiment, as well as other embodiments, may be implemented with other processor-based device configurations, including, for example, portable or handheld electronic devices such as smartphones, portable computers, wearable computers, consumer electronics, personal computers (PCs), network PCs, minicomputers, server blades, mainframe computers, and the like.

[0086] Processor core 818 may include any number of hardwired or configurable circuits, some or all of which may include a programmable and / or configurable combination of electronic components, semiconductor devices, and / or logic elements located partially or completely in a PC, server, or other computing system capable of executing processor-readable instructions.

[0087] Computing device 800 includes a bus or similar communication link 816 that communicatively couples and facilitates the exchange of information and / or data between various system components, including a processor core 818, a cache 862, a graphics processor circuit 812, one or more wireless I / O interfaces 820, one or more wired I / O interfaces 830, one or more storage devices 860, and / or one or more network interfaces 870. Although computing device 800 may be referred to herein in the singular, this is not intended to limit embodiments to a single computing device 800, as in particular embodiments there may be more than one computing device 800 that incorporates, includes, or encompasses any number of communicatively coupled, co-located, or remotely networked circuits or devices.

[0088] Processor core 818 may include any number, type, or combination of currently available or future developed devices capable of executing a set of machine-readable instructions.

[0089] Processor core 818 may include (or be coupled to) any presently or future-developed single or multi-core processor or microprocessor, such as, but not limited to, one or more systems-on-chip (SoCs), central processing units (CPUs), digital signal processors (DSPs), graphics processing units (GPUs), application-specific integrated circuits (ASICs), programmable logic units, field-programmable gate arrays (FPGAs), etc. Unless otherwise described, the structure and operation of the various blocks illustrated in FIG. 8 are of conventional design. As a result, such blocks will be understood by those skilled in the art and will not be described in further detail herein. Bus 816, which interconnects at least some components of computing device 800, may employ any presently available or future-developed serial or parallel bus structure or architecture.

[0090] System memory 840 may include read-only memory (“ROM”) 842 and random access memory (“RAM”) 846. A portion of ROM 842 may be used to store or otherwise maintain a basic input / output system (“BIOS”) 844. BIOS 844 provides basic functionality for computing device 800, for example, by causing processor core 818 to load and / or execute one or more machine-readable instruction sets 814. In an embodiment, at least some of one or more machine-readable instruction sets 814 cause at least a portion of processor core 818 to provide, create, manufacture, transition, and / or function as a dedicated, unique, and specific machine, such as, for example, a word processor, a digital image acquisition machine, a media playback machine, a gaming system, a communications device, a smartphone, or the like.

[0091] The computing device 800 may include at least one wireless input / output (I / O) interface 820. The at least one wireless I / O interface 820 may be communicatively coupled to one or more physical output devices 822 (such as a tactile device, a video display, an audio output device, a hardcopy output device, etc.). The at least one wireless I / O interface 820 may be communicatively coupled to one or more physical input devices 824 (such as a pointing device, a touchscreen, a keyboard, a tactile device, etc.). The at least one wireless I / O interface 820 may include any currently available or future-developed wireless I / O interface. Exemplary wireless I / O interfaces include, but are not limited to, Bluetooth, Near Field Communication (NFC), and the like.

[0092] Computing device 800 may include one or more wired input / output (I / O) interfaces 830. At least one wired I / O interface 830 may be communicatively coupled to one or more physical output devices 822 (such as tactile devices, video displays, audio output devices, hardcopy output devices, etc.). At least one wired I / O interface 830 may be communicatively coupled to one or more physical input devices 824 (such as pointing devices, touch screens, keyboards, tactile devices, etc.). Wired I / O interface 830 may include any currently available or future-developed I / O interface. Exemplary wired I / O interfaces include, but are not limited to, Universal Serial Bus (USB), IEEE 1394 ("FireWire"), and the like.

[0093] Computing device 800 may include one or more communicatively coupled non-transitory data storage devices 860. Data storage device 860 may include one or more hard disk drives (HDDs) and / or one or more solid-state storage devices (SSDs). One or more data storage devices 860 may include any present or future developed storage appliance, network storage device, and / or system. Non-limiting examples of such data storage device(s) 860 may include any present or future developed non-transitory storage appliance or device, such as, but not limited to, one or more magnetic storage devices, one or more optical storage devices, one or more electro-resistive storage devices, one or more molecular storage devices, one or more quantum storage devices, or various combinations thereof. In some implementations, one or more data storage devices 860 may include one or more removable storage devices, such as one or more flash drives, flash memories, flash storage units, or similar appliances or devices, communicatively coupled to and decoupled from computing device 800.

[0094] The one or more data storage devices 860 may include an interface or controller (not shown) that communicatively couples a respective storage device or system to bus 816. The one or more data storage devices 860 may store, retain, or otherwise contain machine-readable instruction sets, data structures, program modules, data stores, databases, logical structures, and / or other data useful to processor core 818 and / or graphics processor circuitry 812 and / or one or more applications executed on or by processor core 818 and / or graphics processor circuitry 812. In some examples, one or more data storage devices 860 may be communicatively coupled to the processor core(s) 818, for example, via bus 816, or via one or more wired communication interfaces 830 (e.g., Universal Serial Bus, or USB), one or more wireless communication interfaces 820 (e.g., Bluetooth, Near Field Communication, or NFC), and / or one or more network interfaces 870 (IEEE 802.3 or Ethernet, IEEE 802.11 or Wi-Fi, etc.).

[0095] Processor-readable instruction set 814 and other programs, applications, logic sets, and / or modules may be stored, in whole or in part, in system memory 840. Such instruction set 814 may be transferred, in whole or in part, from one or more data storage devices 860. Instruction set 814 may be loaded, stored, or otherwise retained, in whole or in part, in system memory 840 during execution by processor core 818 and / or graphics processor circuitry 812.

[0096] Computing device 800 may include a power management circuit 850 that controls one or more operational aspects of energy storage device 852. In embodiments, energy storage device 852 may include one or more primary (i.e., non-rechargeable) or secondary (i.e., rechargeable) batteries or similar energy storage devices. In embodiments, energy storage device 852 may include one or more supercapacitors or ultracapacitors. In embodiments, power management circuit 850 may modify, regulate, or control the flow of energy from an external power source 854 to energy storage device 852 and / or to computing device 800. Power source 854 may include, but is not limited to, a solar power system, a utility grid, a portable generator, an external energy storage device, or any combination thereof.

[0097] For convenience, processor core 818, graphics processor circuitry 812, wireless I / O interface 820, wired I / O interface 830, storage device 860, and network interface 870 are illustrated as communicatively coupled to each other via bus 816, thereby providing connectivity between the above components. In alternative embodiments, the above components may be communicatively coupled in a manner different from that illustrated in FIG. 8. For example, one or more of the above components may be directly coupled to other components or may be coupled to each other through one or more intermediary components (not shown). In another example, one or more of the above components may be integrated into processor core 818 and / or graphics processor circuitry 812. In some embodiments, all or a portion of bus 816 may be omitted, and the components may be directly coupled to each other using appropriate wired or wireless connections.

[0098] The following examples relate to further embodiments. Example 1 is an apparatus that facilitates an improved boot process for early display initialization and visualization. The apparatus of Example 1 includes a hardware processor including a plurality of processor cores, a cache coupled to the plurality of processor cores, and a controller circuit that initializes a portion of the cache as static memory for use by hardware initialization code after powering on the hardware processor and before starting execution of the hardware initialization code, and causes initialization of a display device using the portion of the cache, wherein the initialization of the display device is performed independently of initialization of the dynamic memory of the hardware processor.

[0099] In Example 2, the subject matter of Example 1 may optionally include the hardware initialization code conforming to the Basic Input / Output System standard. In Example 3, the subject matter of any one of Examples 1-2 may optionally include the hardware initialization code conforming to the Unified Extensible Firmware Interface standard. In Example 4, the subject matter of any one of Examples 1-3 may optionally include the hardware initialization code running in parallel on multiple processor cores using a portion of a cache as static memory.

[0100] In Example 5, the subject matter of any one of Examples 1-4 may optionally include the cache being shared by multiple processor cores and graphics cores. In Example 6, the subject matter of any one of Examples 1-5 may optionally include the cache being an L4 cache. In Example 7, the subject matter of any one of Examples 1-6 may optionally include the dynamic memory comprising dynamic random access memory (DRAM). In Example 8, the subject matter of any one of Examples 1-7 may optionally include a portion of the cache as static memory being locked down after execution of hardware initialization code to prevent access to the portion.

[0101] Example 9 is a non-transitory computer-readable storage medium that facilitates an improved boot process for early display initialization and visualization. The non-transitory computer-readable storage medium of Example 9 comprises executable computer program instructions that, when executed by one or more processors, cause one or more processors to perform operations comprising: powering on a system including a plurality of processor cores coupled to a cache; initializing, by a controller of the system, a portion of the cache as static memory for use by the hardware initialization code before beginning execution of the hardware initialization code; executing the hardware initialization code for one or more of the plurality of processor cores to initialize the system; performing display initialization using memory from the portion of the cache initialized as static memory, wherein the display initialization is performed independently from initialization of dynamic memory of the system; and transferring execution control of the system from the hardware initialization code to operating system code running on the system.

[0102] In Example 10, the subject matter of Example 9 may optionally include the hardware initialization code conforming to the Basic Input / Output System standard. In Example 11, the subject matter of any one of Examples 9-10 may optionally include the hardware initialization code conforming to the Unified Extensible Firmware Interface standard. In Example 12, the subject matter of any one of Examples 9-11 may optionally include the executing step including executing the hardware initialization code in parallel on multiple processor cores using a portion of a cache as static memory to initialize the system.

[0103] In Example 13, the subject matter of any one of Examples 9-12 may optionally include the cache being shared by multiple processor cores and graphics cores. In Example 14, the subject matter of any one of Examples 9-13 may optionally include the dynamic memory comprising dynamic random access memory (DRAM). In Example 15, the subject matter of any one of Examples 9-14 may optionally include a portion of the cache as static memory being locked down after execution of hardware initialization code to prevent access to the portion.

[0104] Example 16 is a system for improving the boot process for early display initialization and visualization. The system of Example 16 includes a hardware processor having a plurality of processor cores, a cache coupled to the hardware processor, storage for hardware initialization code, and a controller circuit that initializes a portion of the cache as static memory for use by the hardware initialization code after powering on the hardware processor and before starting execution of the hardware initialization code, and causes initialization of a display device using the portion of the cache, where the initialization of the display device is performed independently of initialization of the dynamic memory of the hardware processor.

[0105] In Example 17, the subject matter of Example 16 may optionally include the hardware initialization code conforming to the Basic Input / Output System standard. In Example 18, the subject matter of any one of Examples 16 to 17 may optionally include the hardware initialization code conforming to the Unified Extensible Firmware Interface standard. In Example 19, the subject matter of any one of Examples 16 to 18 may optionally include the hardware initialization code running in parallel on multiple processor cores using a portion of a cache as memory. In Example 20, the subject matter of any one of Examples 16 to 19 may optionally include a graphics core, wherein the cache is shared by the multiple processor cores and the graphics core.

[0106] Example 21 is a method that facilitates improving the boot process for early display initialization and visualization. The method of Example 21 may optionally include powering on a system having a plurality of processor cores coupled to a cache; initializing, by a controller of the system, a portion of the cache as static memory for use by the hardware initialization code before starting execution of the hardware initialization code; executing the hardware initialization code for one or more of the plurality of processor cores to initialize the system; performing display initialization using memory from the portion of the cache initialized as static memory, wherein the display initialization is performed independently from initialization of dynamic memory of the system; and transferring execution control of the system from the hardware initialization code to operating system code running on the system.

[0107] In Example 22, the subject matter of Example 21 can optionally include the hardware initialization code conforming to the Basic Input / Output System standard. In Example 23, the subject matter of any one of Examples 21-22 can optionally include the hardware initialization code conforming to the Unified Extensible Firmware Interface standard. In Example 24, the subject matter of any one of Examples 21-23 can optionally include the executing step including executing the hardware initialization code in parallel on multiple processor cores using a portion of a cache as static memory to initialize the system.

[0108] In Example 25, the subject matter of any one of Examples 21-24 may optionally include the cache being shared by multiple processor cores and graphics cores. In Example 26, the subject matter of any one of Examples 21-25 may optionally include the dynamic memory comprising dynamic random access memory (DRAM). In Example 27, the subject matter of any one of Examples 21-26 may optionally include a portion of the cache as static memory being locked down after execution of hardware initialization code to prevent access to the portion.

[0109] Example 28 is an apparatus that facilitates improving early display initialization and visualization boot processes in accordance with implementations of the present disclosure. The apparatus of Example 28 may include means for powering on a system including a plurality of processor cores coupled to a cache; means for initializing, by a controller of the system, a portion of the cache as static memory for use by the hardware initialization code before starting execution of the hardware initialization code; means for executing the hardware initialization code for one or more of the plurality of processor cores to initialize the system; means for performing display initialization using memory from the portion of the cache initialized as static memory, wherein the display initialization is performed independently from initialization of dynamic memory of the system; and means for transferring execution control of the system from the hardware initialization code to operating system code running on the system.

[0110] In Example 29, the subject matter of Example 28 may optionally include an apparatus further configured to perform the method of any one of Examples 22 to 27.

[0111] Example 30 is at least one machine-readable medium comprising a plurality of instructions that, when executed on a computing device, cause the computing device to perform the method of any one of Examples 21 to 27. Example 31 is an apparatus for facilitating an improved boot process for early display initialization and visualization, configured to perform the method of any one of Examples 21 to 27. Example 32 is an apparatus for facilitating an improved boot process for early display initialization and visualization, comprising means for performing the method of any one of Examples 21 to 27. Specific details in the examples may be used anywhere in one or more embodiments.

[0112] In the above description, for purposes of explanation, numerous specific details are set forth to provide a thorough understanding of the described embodiments. However, it will be apparent to one skilled in the art that embodiments may be practiced without some of these specific details. In other instances, well-known structures and devices are shown in block diagram form. Intermediate structures may exist between the illustrated components. Components described or illustrated herein may have additional inputs or outputs not shown or described.

[0113] Various embodiments may include various processes. These processes may be performed by hardware components or may be embodied in computer programs or machine-executable instructions that may be used to cause a general-purpose or special-purpose processor or logic circuitry that is programmed with the instructions to perform the processes. Alternatively, the processes may be performed by a combination of hardware and software.

[0114] Some of the various embodiments may be provided as a computer program product, which may include a computer-readable medium (e.g., a non-transitory computer-readable storage medium) having computer program instructions stored thereon, which may be used to program a computer (or other electronic device) to be executed by one or more processors to perform processes according to particular embodiments. The computer-readable medium may include, but is not limited to, a magnetic disk, an optical disk, a read-only memory (ROM), a random access memory (RAM), an erasable programmable read-only memory (EPROM), an electrically erasable programmable read-only memory (EEPROM), a magnetic or optical card, a flash memory, or any other type of computer-readable medium suitable for storing electronic instructions. Furthermore, embodiments may also be downloaded as a computer program product, where the program may be transferred from a remote computer to a requesting computer.

[0115] While many of the methods have been described in their basic form, operations may be added or deleted from any of the methods, and information may be added or removed from any of the described messages, without departing from the basic scope of the embodiments. It will be apparent to those skilled in the art that many further modifications and adaptations may be made. The specific embodiments are provided to illustrate, not to limit, the concepts. The scope of the embodiments is determined not by the specific examples provided above, but only by the claims that follow.

[0116] When element "A" is referred to as being coupled to or coupled with element "B," element A may be directly coupled to element B or indirectly coupled, for example, through element C. When the specification or claims specify that component, feature, structure, process, or property A "causes" component, feature, structure, process, or property B, it means that "A" is at least partially responsible for "B," but that there may also be at least one other component, feature, structure, process, or property that assists in the generation of "B." When the specification indicates that a component, feature, structure, process, or property "may," "might," or "could" be included, that particular component, feature, structure, process, or property is not required to be included. When the specification or claims refer to "a" or "an" element, this does not imply that only one of the described element is present.

[0117] An embodiment is an implementation or example. Reference in the specification to “an embodiment,” “one embodiment,” “some embodiments,” or “other embodiments” means that a particular feature, structure, or characteristic described in connection with an embodiment is included in at least some of the embodiments. The various appearances of “an embodiment,” “one embodiment,” or “some embodiments” do not all refer to the same embodiments. In the foregoing description of exemplary embodiments, it should be understood that various features are sometimes grouped together in a single embodiment, drawing, or description thereof for the purpose of streamlining the disclosure and facilitating understanding of one or more various novel aspects. However, this method of disclosure should not be interpreted as reflecting an intention that the claimed embodiments utilize more features than are expressly recited in each claim. Rather, as the following claims reflect, novel aspects lie in comprising fewer than all features of a single foregoing disclosed embodiment. Accordingly, the following claims are hereby expressly incorporated into this specification, with each claim standing on its own as a separate embodiment.

Claims

1. 1. A hardware processor, comprising: Multiple processor cores; a cache coupled to the plurality of processor cores; in response to powering on the hardware processor, and prior to execution of the hardware initialization code, initializing a portion of the cache as static memory for use by the hardware initialization code, wherein the portion of the cache is initialized as the static memory without using cache-as-random-access memory (CAR); a controller circuit that uses the static memory of the portion of the cache to execute the hardware initialization code, the hardware initialization code causing display device initialization to be performed for display device initialization and display device bring-up, and initialization and training of the dynamic memory of the hardware processor occurring before booting into an operating system (OS) and occurring independently and in parallel with initialization of the display device that utilizes the static memory; 1. A hardware processor comprising:

2. 2. The hardware processor of claim 1, wherein the hardware initialization code complies with the Basic Input / Output System standard.

3. 2. The hardware processor of claim 1, wherein the hardware initialization code complies with the Unified Extensible Firmware Interface standard.

4. 2. The hardware processor of claim 1, wherein the hardware initialization code executes in parallel on the multiple processor cores using the static memory of the portion of the cache.

5. The hardware processor of claim 1 , wherein the cache is shared by the multiple processor cores and graphics core.

6. The controller circuit transfers control of execution from the hardware initialization code to operation system code. The hardware processor of claim 5 .

7. 2. The hardware processor of claim 1, wherein the cache is an L4 cache.

8. 2. The hardware processor of claim 1, wherein the dynamic memory comprises dynamic random access memory (DRAM).

9. 2. The hardware processor of claim 1, wherein the portion of the cache as the static memory is locked down after execution of the hardware initialization code to prevent access to the portion.

10. A system comprising: Graphic score and Memory and a hardware processor having a plurality of processor cores; a cache coupled to the plurality of processor cores, the cache being shared by the plurality of processor cores and the graphics core; initializing a portion of the cache as static memory for use by the hardware initialization code after powering on the hardware processor and before starting execution of the hardware initialization code; using the portion of the cache to perform initialization of a display device, the initialization of the display device being performed independently of initialization of a dynamic memory of the hardware processor; transferring control of execution of the system from the hardware initialization code to operating system code executing on the system; and 1. A system comprising a hardware processor having:

11. The method of claim 10, wherein the portion of the cache is initialized as the static memory without using cache-as-random-access memory (CAR); the controller circuit executes the hardware initialization code using the static memory of the portion of the cache, wherein the hardware initialization code causes display device initialization to be performed for display device initialization and display device bring-up; initialization and training of the hardware processor's dynamic memory occurs prior to booting into an operating system (OS) and occurs independently and in parallel with initialization of the display device that utilizes the static memory; The system of claim 10.

12. a hardware processor having a plurality of processor cores; a cache coupled to the hardware processor; storage for hardware initialization code; in response to powering on the hardware processor and prior to execution of the hardware initialization code, initializing a portion of the cache as static memory for use by the hardware initialization code, wherein the portion of the cache is initialized as the static memory without using cache-as-random-access memory (CAR); a controller circuit that uses the static memory of the portion of the cache to execute the hardware initialization code, wherein the hardware initialization code causes display device initialization to be performed for display device initialization and display device bring-up, and the initialization and training of the dynamic memory of the hardware processor occurs before booting to an operating system (OS) and occurs independently and in parallel with the initialization of the display device that utilizes the static memory; 1. A system comprising a hardware processor having:

13. 13. The system of claim 10, wherein the hardware initialization code complies with the Basic Input / Output System standard.

14. 13. The system of claim 10, wherein the hardware initialization code complies with the Unified Extensible Firmware Interface standard.

15. 13. The system of claim 10, wherein the hardware initialization code is executed in parallel on the multiple processor cores using the static memory of the portion of the cache.

16. The system of claim 12 , further comprising a graphics core, wherein the cache is shared by the multiple processor cores and the graphics core.

17. 1. A method for facilitating an improved boot process for early display initialization and visualization, the method comprising: powering on a system comprising a plurality of processor cores coupled to a memory and a cache; initializing, by a controller circuit of a hardware processor of the system, a portion of the cache of the hardware processor as static memory for use by the hardware initialization code prior to commencing execution of the hardware initialization code, wherein the cache is shared by multiple processor cores of the hardware processor and a graphics core of the system; executing hardware initialization code for one or more of the plurality of processor cores to initialize the hardware processor; causing, by the controller circuit, initialization of a display device that is executed using the portion of the cache, the initialization of the display device being performed independently from initialization of a dynamic memory of the hardware processor; transferring execution control of the system from the hardware initialization code to operating system code running on the system.

18. The method of claim 17, wherein a portion of the cache is initialized as the static memory without using cache-as-random-access memory (CAR); the method comprising: performing a display device initialization using the static memory of the portion of the cache, wherein the hardware initialization code causes display device initialization to be performed for display device initialization and display device bring-up; initialization and training of the hardware processor's dynamic memory occurs prior to booting into an operating system (OS) and occurs independently and in parallel with initialization of the display device that utilizes the static memory; 18. The method of claim 17.

19. 1. A method for facilitating an improved boot process for early display initialization and visualization, the method comprising: powering on a system comprising a plurality of processor cores coupled to a cache; initializing, by a controller of a hardware processor of the system, a portion of the cache as static memory for use by the hardware initialization code prior to execution of the hardware initialization code, the portion of the cache being initialized as static memory without using cache-as-random-access memory (CAR); executing the hardware initialization code for one or more of the plurality of processor cores to initialize the hardware processor; performing a display device initialization using the static memory of the portion of the cache, wherein the hardware initialization code causes display device initialization to be performed for display device initialization and display device bring-up, and initialization and training of the hardware processor's dynamic memory occurs prior to booting into an operating system (OS) and occurs independently and in parallel with initialization of the display device utilizing the static memory; transferring execution control of the system from the hardware initialization code to operating system code running on the system.

20. 20. The method of any one of claims 17 to 19, wherein the hardware initialization code complies with the Basic Input / Output System standard.

21. 20. The method of any one of claims 17 to 19, wherein the hardware initialization code complies with the Unified Extensible Firmware Interface standard.

22. 20. The method of claim 17, wherein the executing step comprises executing the hardware initialization code in parallel on the multiple processor cores using the static memory of the portion of the cache to initialize the system.

23. 20. The method of claim 19, wherein the cache is shared by the multiple processor cores and graphics cores.

24. 23. The method of any one of claims 17 to 22, wherein the dynamic memory comprises a dynamic random access memory (DRAM).

25. 23. The method of any one of claims 17 to 22, wherein the portion of the cache as the static memory is locked down after execution of the hardware initialization code to prevent access to the portion.

26. 1. An apparatus that facilitates improving early display initialization and visualization boot processes, the apparatus comprising: means for powering on a system including a memory and a plurality of processor cores coupled to a cache; means for initializing, by a controller circuit of a hardware processor of the system, a portion of the cache of the hardware processor as static memory for use by the hardware initialization code before starting execution of the hardware initialization code, the cache being shared by multiple processor cores of the hardware processor and a graphics core of the system; means for executing hardware initialization code on one or more of the plurality of processor cores to initialize the hardware processor; means for causing the controller circuit to initialize a display device that is executed using the portion of the cache, the initialization of the display device being performed independently from initialization of a dynamic memory of the hardware processor; and means for transferring execution control of said system from said hardware initialization code to operating system code running on said system; An apparatus comprising:

27. The method of claim 27, wherein a portion of the cache is initialized as the static memory without using cache-as-random-access memory (CAR); the apparatus comprising: means for performing display device initialization using the static memory of the portion of the cache, wherein the hardware initialization code causes display device initialization to be performed for display device initialization and display device bring-up; initialization and training of the hardware processor's dynamic memory occurs prior to booting into an operating system (OS) and occurs independently and in parallel with initialization of the display device that utilizes the static memory; 27. The apparatus of claim 26.

28. 1. An apparatus that facilitates improving early display initialization and visualization boot processes, the apparatus comprising: means for powering on a system including a plurality of processor cores coupled to a cache; means for initializing, by a controller of a hardware processor of the system, a portion of the cache as static memory for use by the hardware initialization code prior to execution of the hardware initialization code, the portion of the cache being initialized as static memory without using cache-as-random-access memory (CAR); means for executing the hardware initialization code on one or more of the plurality of processor cores to initialize the hardware processor; means for performing display device initialization using the static memory of the portion of the cache, wherein the hardware initialization code causes display device initialization to be performed for display device initialization and display device bring-up, and initialization and training of the dynamic memory of the hardware processor occurs prior to booting of an operating system (OS) and occurs independently and in parallel with initialization of the display device utilizing the static memory; means for transferring execution control of said system from said hardware initialization code to operating system code running on said system; An apparatus comprising:

29. 29. Apparatus according to any one of claims 26 to 28, further configured to carry out a method according to any one of claims 17 to 25.

30. A program causing a computing device to carry out the method of any one of claims 17 to 25.

31. 31. At least one machine-readable medium storing the program of claim 30.

Images