Firmware boot methods, firmware boot systems, storage media and computing devices

Abstract

This application provides a firmware boot method applicable to the field of computer firmware technology. It includes: in response to a firmware boot command, executing a first coroutine task in a coroutine task queue; upon detecting that the execution of the first coroutine task has been paused by calling a blocking interface, saving context data determined during the execution of the first coroutine task to a first stack space corresponding to the first coroutine task; determining a second coroutine task in a paused execution state from the coroutine task queue; resuming the execution of the second coroutine task based on the context data stored in a second stack space corresponding to the second coroutine task; and determining the firmware state as booted based on the execution results of multiple completed coroutine tasks. This method utilizes cooperative coroutines to concurrently execute multiple hardware initialization tasks within a single thread, and achieves non-intrusive yielding by intercepting blocking interfaces, significantly shortening firmware boot time.

Description

Technical Field

[0001] This application relates to the field of computer firmware technology, specifically to the field of firmware boot technology, and more specifically to a firmware boot method, a firmware boot system, a storage medium, and a computing device. Background Technology

[0002] During firmware boot, multiple hardware initialization tasks typically need to be executed. In related technologies, these tasks are often executed sequentially, resulting in long firmware boot times. While multi-threading solutions exist for parallel execution, resources are limited and hardware is unstable in the early stages of firmware boot, leading to resource contention risks and requiring significant modifications to existing code to accommodate parallel execution. Therefore, achieving safe and efficient task concurrency during firmware boot has become a pressing issue in this field. Summary of the Invention

[0003] In view of the above problems, this application provides a firmware boot method, a firmware boot system, a storage medium, and a computing device to achieve parallel boot of all stages while ensuring security, thereby shortening the firmware boot time.

[0004] According to a first aspect of this application, a firmware boot method is provided, comprising: in response to a firmware boot instruction, executing a first coroutine task in a coroutine task queue, the first coroutine task being used to boot firmware; upon detecting that the execution of the first coroutine task is paused by calling a blocking interface, saving context data determined during the execution of the first coroutine task to a first stack space corresponding to the first coroutine task; determining a second coroutine task in a paused execution state from the coroutine task queue; resuming the execution of the second coroutine task based on the context data stored in a second stack space corresponding to the second coroutine task; and determining the state of the firmware as booted based on the execution results of multiple completed coroutine tasks.

[0005] The firmware boot method provided in this application encapsulates multiple hardware initialization tasks into coroutines and utilizes cooperative scheduling within a single thread, thus avoiding the risk of multi-threaded resource contention. When a coroutine calls a blocking interface, it automatically saves the context and switches, allowing the central processing unit to execute other coroutines during the waiting period. This transforms the serial waiting time into concurrent execution time, significantly shortening the total firmware boot time.

[0006] According to an embodiment of this application, the coroutine task queue includes a first queue for storing coroutine tasks that are in an executable state among a plurality of suspended coroutine tasks. The method further includes: when it is detected that the execution of a second coroutine task is suspended by calling an active yield interface, saving the context data of the second coroutine task to the second stack space corresponding to the second coroutine task; and moving the second coroutine task into the first queue.

[0007] The proactive yielding interface provides a way for tasks without blocking points to explicitly relinquish CPU execution rights, preventing long tasks from monopolizing the CPU; the proactively yielded coroutines are directly put back into the executable queue (first queue), so that they can compete fairly with other ready coroutines during scheduling, ensuring scheduling flexibility and fairness.

[0008] According to an embodiment of this application, the coroutine task queue includes a second queue for storing coroutine tasks that are paused in execution by calling a blocking interface. The method further includes: moving a paused first coroutine task into the second queue; and moving the target coroutine task in the second queue from the second queue into the first queue in response to the target coroutine task in the second queue meeting the execution conditions.

[0009] By separating the management of passively yielded coroutines from those actively yielded, waiting conditions (such as delay or resource readiness) only need to be checked against the second queue, avoiding the need to traverse all coroutines for each scheduling and improving scheduling efficiency. Once the condition is met, the coroutines are moved back to the first queue, ensuring that waiting tasks can be rescheduled in a timely manner, forming a complete wait-wake-up mechanism.

[0010] According to an embodiment of this application, the execution conditions include at least one of the following: the preceding coroutine task that has a dependency relationship with the target coroutine task has been completed; the computing resources on which the target coroutine task depends are ready; and the waiting time passed when calling the blocking interface meets the preset time.

[0011] By combining various execution conditions, the timing of coroutine wake-up is precisely controlled to avoid waking up too early or too late, which would waste computing resources and affect startup speed. In particular, the dependency relationship ensures the correctness of the hardware initialization order and prevents system instability caused by incorrect order.

[0012] According to an embodiment of this application, resuming execution of a second coroutine task based on context data stored in the second stack space corresponding to the second coroutine task includes: loading the context data of the second coroutine task from the second stack space of the second coroutine task, wherein the context data of the second coroutine task includes execution status data when the second coroutine task was suspended; determining the suspended subtasks in the second coroutine task based on the execution status data; and executing the suspended subtasks and other subtasks related to the suspended subtasks based on the dependencies between multiple subtasks in the second coroutine task.

[0013] The context data is loaded from the stack space, the paused subtasks corresponding to the execution status data are determined, and the relevant subtasks are executed based on their dependencies. By incorporating the subtask dependencies that may exist within the coroutine into the recovery logic, execution can not only continue the main flow upon resumption but also automatically execute unfinished subtasks based on dependencies, enhancing the coroutine's adaptability to complex initialization processes.

[0014] According to an embodiment of this application, a coroutine task is determined based on the following operations: determining multiple startup tasks to be executed and creating corresponding coroutine tasks for the startup tasks; allocating corresponding stack space for the coroutine tasks based on the memory resources required by the startup tasks.

[0015] By mapping "one task, one coroutine", hardware initialization tasks are directly mapped to concurrent execution units, simplifying task splitting; different sizes of stack space are allocated according to the memory requirements of tasks, so that lightweight tasks occupy very little memory and complex tasks obtain sufficient stack depth, which not only adapts to the memory-constrained environment in the early stage of firmware startup, but also avoids the risk of stack overflow.

[0016] According to an embodiment of this application, the method further includes: detecting the execution status of a plurality of coroutine tasks; in response to detecting that a coroutine task has failed to execute, identifying the failed coroutine task as a faulty coroutine task; and when identifying a second coroutine task, skipping the faulty coroutine task and other coroutine tasks that depend on the faulty coroutine task.

[0017] Through fault marking and propagation isolation mechanisms, the failure of a single hardware initialization task will not block the entire boot process, and the system can continue to execute other unrelated tasks; at the same time, it skips subsequent coroutines that depend on the failed task, avoiding invalid execution or system crashes caused by the absence of preceding tasks, and significantly improving the fault tolerance of firmware boot.

[0018] According to an embodiment of this application, multiple coroutine tasks are pre-configured with execution priorities. Determining a second coroutine task that is in a suspended execution state from the coroutine task queue includes: determining the second coroutine task from the first queue based on the execution priority; or determining the second coroutine task based on the order of the coroutine tasks in the first queue.

[0019] It offers two optional scheduling strategies: priority and first-in-first-out queue, which allows the system to be flexibly configured according to the importance of tasks: critical tasks can be assigned high priority for execution, while ordinary tasks can be scheduled in order fairly, thus optimizing the overall startup efficiency while ensuring startup security.

[0020] A second aspect of this application provides a firmware booting system, comprising: an execution module, configured to execute a first coroutine task in a coroutine task queue in response to a firmware boot command, the first coroutine task being used to boot firmware; a blocking module, configured to save context data determined during the execution of the first coroutine task to a first stack space corresponding to the first coroutine task when it is detected that the execution of the first coroutine task is paused by calling a blocking interface; a coroutine determination module, configured to determine a second coroutine task in a paused execution state from the coroutine task queue; a coroutine switching module, configured to resume the execution of the second coroutine task based on the context data stored in a second stack space corresponding to the second coroutine task; and a state determination module, configured to determine the state of the firmware as booted based on the execution results of multiple completed coroutine tasks.

[0021] A third aspect of this application also provides a computer-readable storage medium having firmware or instructions stored thereon, which, when executed by a processor, implement the steps of the above-described method.

[0022] A fourth aspect of this application provides a computing device, comprising: one or more processors; and a memory for storing firmware or instructions, wherein the firmware, when executed by the processor, implements the steps according to the method described above. Attached Figure Description

[0023] The above-mentioned contents, other objects, features and advantages of this application will become clearer from the following description of embodiments with reference to the accompanying drawings, in which:

[0024] Figure 1 This illustration schematically shows a system architecture diagram of a firmware boot system provided according to an embodiment of this application;

[0025] Figure 2 A flowchart illustrating a firmware boot method according to an embodiment of this application is shown schematically.

[0026] Figure 3 This illustration schematically shows the interaction process between multiple coroutine tasks during the firmware startup phase according to an embodiment of this application;

[0027] Figure 4 A schematic diagram illustrating the structure of a firmware boot system according to an embodiment of this application is shown; and

[0028] Figure 5A block diagram schematically illustrates an electronic device suitable for implementing a firmware boot system according to an embodiment of this application. Detailed Implementation

[0029] The embodiments of this application will now be described with reference to the accompanying drawings. However, it should be understood that these descriptions are exemplary only and are not intended to limit the scope of this application. In the following detailed description, numerous specific details are set forth to provide a thorough understanding of the embodiments of this application for ease of explanation. However, it will be apparent that one or more embodiments may be implemented without these specific details. Furthermore, descriptions of well-known structures and technologies are omitted in the following description to avoid unnecessarily obscuring the concepts of this application.

[0030] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit the scope of this application. The terms “comprising,” “including,” etc., as used herein indicate the presence of features, steps, operations, and / or components, but do not exclude the presence or addition of one or more other features, steps, operations, or components.

[0031] All terms used herein (including technical and scientific terms) have the meanings commonly understood by those skilled in the art, unless otherwise defined. It should be noted that the terms used herein are to be interpreted in a manner consistent with the context of this specification, and not in an idealized or overly rigid way.

[0032] When using expressions such as "at least one of A, B and C", they should generally be interpreted in accordance with the meaning that is commonly understood by those skilled in the art (e.g., "a system having at least one of A, B and C" should include, but is not limited to, a system having A alone, a system having B alone, a system having C alone, a system having A and B, a system having A and C, a system having B and C, and / or a system having A, B and C, etc.).

[0033] During firmware boot, multiple hardware initialization tasks are typically executed, such as memory training, PCIe device enumeration, and USB controller initialization. These tasks often involve multiple delays or status polling. If a traditional serial execution method is used, the total boot time will increase linearly with the number of tasks. Although multi-threaded parallel execution can shorten the time, resources are extremely limited in the early stages of firmware boot, and the hardware state is not yet stable. Multi-threaded concurrency can easily lead to resource contention and unpredictable behavior. Furthermore, existing coroutine libraries are mostly designed for the operating system environment, relying on system calls and dynamic memory management, making them difficult to deploy directly at the firmware level. Therefore, how to safely and efficiently implement task concurrency during firmware boot without significantly modifying existing initialization code has become a pressing technical problem in this field.

[0034] To address the aforementioned technical issues, embodiments of this application provide a firmware booting method, comprising: responding to a firmware boot command, executing a first coroutine task in a coroutine task queue, the first coroutine task being used to boot the firmware; upon detecting that the execution of the first coroutine task is paused by calling a blocking interface, saving context data determined during the execution of the first coroutine task to a first stack space corresponding to the first coroutine task; determining a second coroutine task in a paused execution state from the coroutine task queue; resuming the execution of the second coroutine task based on the context data stored in a second stack space corresponding to the second coroutine task; and determining the firmware state as booted based on the execution results of multiple completed coroutine tasks.

[0035] Figure 1 A schematic diagram illustrating the system architecture of a firmware boot system provided according to an embodiment of this application is shown. Figure 1 As shown, the coroutine framework of this application adopts a layered architecture design in the firmware boot environment, consisting of the following layers from bottom to top: the underlying hardware / firmware layer, the HOOK layer, the core layer, and the application layer. The underlying hardware / firmware layer includes hardware resources such as the Central Processing Unit (CPU), memory controller, and PCIe root port, as well as standard service interfaces provided by the firmware, such as the Stall delay service and WaitForEvent event waiting service in the Unified Extensible Firmware Interface (UEFI). These services are fundamental to hardware initialization and typically exist in the firmware service table in the form of function pointers. The HOOK layer is one of the key innovations of this application, used to intercept blocking interfaces provided by the underlying firmware. During the framework initialization phase, the HOOK layer obtains the function pointer of the original blocking interface (such as gBS->Stall) and replaces it with a custom enhanced blocking interface. Subsequently, when any coroutine calls this interface, the enhanced version is actually executed. This enhanced interface retains the original blocking functionality (such as hardware delay) while additionally inserting coroutine yielding logic, causing the coroutine calling the blocking interface to automatically yield the CPU. This layer allows existing firmware code to gain concurrency capabilities without any modification, achieving non-intrusive integration.

[0036] The core layer is responsible for the full lifecycle management of coroutines, and mainly includes the following modules:

[0037] The coroutine management module creates a coroutine control block for each hardware initialization task during firmware startup and allocates independent stack space for it. The stack space size can be dynamically configured according to task requirements; for example, 8KB of stack space can be allocated for memory training tasks, while 1KB can be allocated for simple register configuration tasks. Furthermore, the coroutine management module supports establishing dependencies between coroutines, laying the foundation for subsequent fault propagation control.

[0038] The cooperative scheduler module runs within a single execution thread and maintains a ready queue and a waiting queue. When a coroutine voluntarily yields or is triggered to yield by the hook layer, the scheduler saves the current coroutine's context and decides whether to place the coroutine into the ready queue (voluntary yield) or the waiting queue (passive yield) based on the yield type. Then, it selects the next coroutine from the ready queue, restores its context, and continues execution. The scheduler supports both first-in-first-out (FIFO) and priority-based scheduling strategies, which can be flexibly configured according to task importance.

[0039] The context management module is responsible for saving and restoring the coroutine context. During a switch, the current coroutine's CPU register state (including the program counter, stack pointer, general-purpose registers, etc.) is saved to its private stack space. When the coroutine is rescheduled, the previously saved context is loaded from its stack space, allowing the coroutine to continue execution from the yield point. This embodiment uses the standard C library's `setjmp` / `longjmp` functions to implement context management, thus eliminating the need to write assembly code for different CPU architectures and ensuring cross-architecture portability.

[0040] The fault handling module monitors the execution status of each coroutine. If a coroutine fails (e.g., returns an error code or experiences a stack overflow), it marks the coroutine as faulty. The scheduler automatically skips the faulty coroutine and its dependent successor coroutines in subsequent scheduling to prevent the fault from propagating. This module also manages the order of coroutines through a dependency graph to ensure the correctness of the hardware initialization process.

[0041] The application layer contains various hardware initialization tasks encapsulated as coroutines, such as the Peripheral Component Interconnect Express (PCIe) root port training coroutine, memory training coroutine, and Universal Serial Bus (USB) initialization coroutine. These coroutine tasks are created and scheduled by the kernel layer, and their code is no different from ordinary initialization functions, only calling standard blocking interfaces (such as Stall) when waiting is required. Due to the existence of the hook layer, these calls automatically trigger coroutine switching, enabling concurrent execution.

[0042] Through the aforementioned layered architecture, this application constructs a lightweight, non-intrusive, coroutine-based concurrent system in the firmware boot environment. Each layer has clearly defined responsibilities and collaborates with each other, effectively shortening the firmware boot time while enhancing the system's fault tolerance.

[0043] The following will be based on Figure 1 The described architecture, through Figures 2-5 The firmware boot method of the disclosed embodiments will be described in detail.

[0044] Figure 2 A flowchart illustrating a firmware boot method according to an embodiment of this application is shown schematically.

[0045] like Figure 2 As shown, the firmware boot method of this embodiment includes operations S210 to S250, which can be executed by a central processing unit.

[0046] In operation S210, in response to the firmware boot command, the first coroutine task in the coroutine task queue is executed. The first coroutine task is used to boot the firmware.

[0047] In one example, the firmware boot instruction is triggered by system power-on or hardware reset, causing the CPU to execute firmware code starting from the reset vector address. During firmware initialization, the system creates corresponding coroutine tasks for multiple hardware initialization tasks to be executed and places these coroutine tasks into a coroutine task queue. This queue stores all coroutine tasks in a ready state, i.e., coroutines that are ready to execute but have not yet obtained CPU execution rights. It should be understood that in the embodiments of this application, coroutine task and coroutine are synonymous terms, both referring to a lightweight concurrent execution unit with independent stack space that can be suspended and resumed by the scheduler, and both referring to coroutine instances created by the coroutine management module for executing specific boot tasks.

[0048] In one example, when the scheduler selects the first coroutine task from the head of the queue, it restores its context to begin execution. The first coroutine task corresponds to a specific hardware initialization task, such as link training on the PCIe root port or parameter configuration of the memory controller. Because coroutine tasks have their own independent stack space, their local variables and function call chains are completely isolated from other coroutines, ensuring the independence of task execution.

[0049] In operation S220, if it is detected that the execution of the first coroutine task is paused by calling the blocking interface, the context data determined during the execution of the first coroutine task is saved to the first stack space corresponding to the first coroutine task.

[0050] In one example, during firmware startup, hardware initialization tasks often need to wait for the hardware state to stabilize or for external events to occur, such as waiting 100 microseconds for the hardware to complete negotiation after triggering PCIe link training. To this end, coroutine tasks call standard blocking interfaces provided by the firmware (such as the Stall delay service in UEFI) to implement this waiting. This application replaces the function pointer of this blocking interface with a custom enhanced implementation during the framework initialization phase, ensuring that the coroutine actually executes the enhanced version when calling the interface. During the execution of this enhanced interface, if the system detects that the coroutine needs to pause, it saves the current coroutine's context data, i.e., the CPU register state, including the program counter, stack pointer, and general-purpose registers, to the private stack space corresponding to the coroutine. This operation ensures that the coroutine's execution state is fully preserved, providing a basis for subsequent resumption of execution.

[0051] In operation S230, the second coroutine task that is in a suspended execution state is determined from the coroutine task queue.

[0052] In one example, when the first coroutine task is paused due to a blocking interface call, the scheduler selects the next coroutine task to be executed from the coroutine task queue, i.e., the second coroutine task. The coroutine task queue may contain multiple coroutines in a ready state, and the scheduler determines the second coroutine task according to a preset scheduling strategy (such as the order in which they were added to the queue or by task priority). Since the coroutine tasks are independent of each other and each executes within a single thread, there is no need to consider the resource contention issues of multi-threading, and the scheduler can safely perform this selection operation.

[0053] In operation S240, the execution of the second coroutine task is resumed based on the context data stored in the second stack space corresponding to the second coroutine task.

[0054] In one example, after the second coroutine task is determined, the scheduler loads previously saved context data, including the program counter, stack pointer, registers, etc., from its private stack space. By restoring this state, the CPU's execution flow jumps to the point where the second coroutine task was last suspended, allowing it to resume execution from that point. Because the second coroutine task may have been voluntarily yielded or suspended due to a blocking interface call, its context data reflects the complete state of the task during execution, thus enabling seamless continuation of execution after restoration.

[0055] When operating the S250, the firmware status is determined to be in the started state based on the execution results of multiple completed coroutine tasks.

[0056] In one example, once all the coroutine tasks corresponding to the hardware initialization tasks have completed, each coroutine task returns its execution result (e.g., success or failure). After collecting these results, if all necessary initialization tasks have completed successfully, the system marks the firmware status as "started," indicating that the firmware is ready to hand over control to the operating system loader. This status confirmation mechanism ensures that the system only proceeds to the next stage after all critical tasks have been successfully executed.

[0057] Through the above steps, multiple hardware initialization tasks are encapsulated into coroutines and executed alternately within a single thread. When a coroutine waits due to a blocking interface call, its CPU usage is automatically relinquished, and the scheduler switches to executing other ready coroutines, thus reusing the originally sequential waiting time as concurrent execution time. Since all coroutines share a single thread, hardware access conflicts that may be caused by multi-threaded concurrency are avoided. Furthermore, by saving and restoring the context, a coroutine can accurately return to the interrupted position and continue execution after the blocking ends, without modifying the original initialization code. Therefore, the firmware booting method provided in this application reduces the total firmware booting time from the sum of the times of all tasks to the time of the slowest single task without increasing the risk of hardware resource contention, significantly improving booting efficiency while maintaining the non-intrusiveness of the code.

[0058] According to an embodiment of this application, a coroutine task is determined based on the following operations: determining multiple startup tasks to be executed and creating corresponding coroutine tasks for the startup tasks; allocating corresponding stack space for the coroutine tasks based on the memory resources required by the startup tasks.

[0059] In one example, during the firmware initialization phase, the system first identifies all hardware initialization tasks that need to be executed concurrently, such as memory training, PCIe root port enumeration, and USB4 controller initialization. For each task, the coroutine management module creates a corresponding coroutine control block and stores the task's entry function address, parameters, and other information in the control block. When allocating stack space, the system determines the required stack size based on the characteristics of the task: for tasks with shallow function call depth and few local variables (such as single register configuration), a smaller stack (e.g., 1KB) is allocated; for tasks with long call chains, involving recursion, or a large number of local variables (such as PCIe device tree traversal), a larger stack (e.g., 8KB) is allocated. Stack space is allocated from memory regions available in the firmware (such as CAR memory in the PEI phase or regular memory in the DXE phase).

[0060] By using a "one task, one coroutine" mapping approach, hardware initialization tasks are directly transformed into concurrent execution units, simplifying the task splitting logic. Stack space of different sizes is allocated according to the actual needs of the task, ensuring that memory usage matches task complexity: simple tasks consume very little memory, suitable for resource-constrained early stages of firmware development; complex tasks receive sufficient stack space to avoid stack overflow. This on-demand allocation strategy guarantees both the system's lightweight nature and the reliable execution of complex tasks.

[0061] According to an embodiment of this application, the coroutine task queue includes a first queue for storing coroutine tasks that are in an executable state among a plurality of suspended coroutine tasks. The method further includes: upon detecting that a second coroutine task has been suspended by calling an active yield interface, saving the context data of the second coroutine task to a second stack space corresponding to the second coroutine task; and moving the second coroutine task into the first queue.

[0062] In one example, during the execution of a coroutine task, in addition to passively yielding through a blocking interface, developers can also explicitly call an active yielding interface (such as the `yield` function) in the task code to actively release the CPU. When the scheduler detects that the current coroutine is calling this interface, it performs the following operations: First, it saves the CPU register state of the current coroutine to its private stack space; second, it moves the coroutine directly to the tail of the first queue (i.e., the ready queue), instead of the waiting queue. The first queue is used to store all coroutine tasks that can be executed immediately, so the coroutine that is actively yielded will wait for the next scheduling along with other ready coroutines.

[0063] The voluntary yielding mechanism provides a way for tasks without natural blocking points to explicitly relinquish the CPU. This allows long-running tasks to periodically call the voluntary yielding interface within a loop, preventing prolonged CPU monopolization that could starve other coroutines. Because voluntary yielding coroutines return directly to the ready queue rather than the waiting queue, their resumption of execution does not depend on any external events; the scheduler simply needs to reselect the coroutine in the round-robin. This mechanism ensures scheduling fairness while providing developers with fine-grained execution control.

[0064] According to an embodiment of this application, multiple coroutine tasks are pre-configured with execution priorities. Determining a second coroutine task that is in a suspended execution state from the coroutine task queue includes: determining the second coroutine task from the first queue based on the execution priority; or determining the second coroutine task based on the order of the coroutine tasks in the first queue.

[0065] In one example, the first queue contains all immediately executable coroutine tasks. The scheduler supports two strategies when selecting the next coroutine: priority scheduling, where each coroutine task can be configured with an execution priority (e.g., high, medium, low) upon creation, and the scheduler always selects the highest-priority coroutine from the first queue. If multiple coroutines have the same priority, they are selected according to their order in the queue. First-In-First-Out (FIFO) queue scheduling, disregarding priority, strictly selects coroutines according to the order they were added to the first queue (FIFO). This strategy is simple to implement and suitable for scenarios with similar task importance. The system can select which strategy to use through configuration parameters or dynamically switch between strategies at different stages.

[0066] Priority scheduling ensures that critical tasks (such as memory training) receive priority access to CPU resources, guaranteeing that core system functions are ready as quickly as possible; first-in-first-out (FIFO) queue scheduling provides a fair execution opportunity for tasks without special priority. The coexistence of these two strategies allows the system to flexibly adjust its scheduling behavior according to the specific needs of the firmware startup phase, achieving a balance between startup speed and task importance.

[0067] According to an embodiment of this application, the coroutine task queue includes a second queue for storing coroutine tasks that are paused in execution by calling a blocking interface. The method further includes: moving a paused first coroutine task into the second queue; and moving the target coroutine task in the second queue from the second queue into the first queue in response to the target coroutine task in the second queue meeting the execution conditions.

[0068] In one example, when the first coroutine task relinquishes execution due to a blocking interface call, the scheduler removes it from the first queue (ready queue) and moves it to the second queue (waiting queue). The second queue stores coroutine tasks that are temporarily unable to execute due to waiting for external conditions. Each coroutine records its waiting conditions when entering the second queue, such as a preset delay time, its dependent predecessor coroutines, or hardware resources. The scheduler or a timer interrupt periodically checks whether the waiting conditions of the coroutines in the second queue have been met. When a coroutine's waiting conditions are met, it is moved from the second queue back to the first queue, allowing it to regain its eligibility for scheduling.

[0069] By separating the management of passively yielded coroutines from those actively yielded, the system only needs to perform wait condition checks on coroutines in the second queue, avoiding traversing all coroutines during each scheduling, thus improving scheduling efficiency. Simultaneously, coroutines whose wait conditions are met are moved back to the first queue, ensuring that waiting tasks can be scheduled and executed promptly after the conditions are met, forming a complete wait-wake-up closed loop.

[0070] According to an embodiment of this application, the execution conditions include at least one of the following: the preceding coroutine task that has a dependency relationship with the target coroutine task has been completed; the computing resources on which the target coroutine task depends are ready; and the waiting time passed when calling the blocking interface meets the preset time.

[0071] In one example, the execution condition is the basis for determining whether a coroutine in the waiting queue can be moved back to the ready queue. This embodiment defines three typical conditions:

[0072] Dependency condition: If the target coroutine task depends on a preceding coroutine task (e.g., the PCIe enumeration coroutine depends on the memory training coroutine), then the target coroutine will always be in a waiting state until the preceding coroutine task is completed; once the preceding coroutine is completed, the condition is satisfied.

[0073] Resource readiness condition: If the target coroutine task is waiting for a specific hardware resource (such as power stability or clock lock), the system will check the resource status by polling or interrupting, and the condition will be met when the resource is ready.

[0074] Timeout condition: If a coroutine waits due to calling a blocking interface (such as calling Stall(100)), its waiting condition is that the passed duration has expired. The system records the expiration time through a timer, and the condition is met after the time expires.

[0075] According to an embodiment of this application, resuming execution of a second coroutine task based on context data stored in the second stack space corresponding to the second coroutine task includes: loading the context data of the second coroutine task from the second stack space of the second coroutine task, wherein the context data of the second coroutine task includes execution status data when the second coroutine task was suspended; determining the suspended subtasks in the second coroutine task based on the execution status data; and executing the suspended subtasks and other subtasks related to the suspended subtasks based on the dependencies between multiple subtasks in the second coroutine task.

[0076] In one example, after the scheduler determines the second coroutine task, it loads previously saved context data from its private stack space. This data not only contains the values ​​of CPU registers but also implicitly indicates the coroutine's execution position when it was paused—that is, the identifier of the subtask being executed. Based on this position information, the system determines the specific subtask that the coroutine needs to resume. In firmware initialization scenarios, a coroutine task may contain multiple sequentially executed subtasks (e.g., PCIe link training includes multiple stages such as "triggering training → waiting for stabilization → reading status → configuring device"), and there may be dependencies between these subtasks. When resuming execution, the system, based on the subtask dependency graph, not only executes the paused subtasks but also automatically executes other subtasks that depend on them, ensuring the integrity of the entire initialization process.

[0077] By incorporating the subtask structure within a coroutine into the recovery logic, the coroutine can accurately pinpoint the interrupted step during recovery, rather than simply re-executing from the function entry point, thus avoiding the redundant initialization of completed subtasks. Simultaneously, automatically executing dependent subtasks ensures the correctness of the hardware initialization process, reduces the burden on developers to manually manage subtask dependencies, and improves code maintainability.

[0078] Figure 3 This illustration schematically shows the interaction process between multiple coroutine tasks during the firmware startup phase according to an embodiment of this application.

[0079] During firmware boot, the hardware tasks to be initialized typically include: PCIe root port training, memory training, USB4 controller initialization, and Compute Express Link (CXL) device link training. Each of these tasks involves multiple delays and status polling. This application encapsulates these tasks as coroutines and employs different organization methods based on the logical relationships between the tasks:

[0080] One-to-one mapping: For independent tasks (such as training multiple PCIe root ports), each task corresponds to an independent coroutine. These coroutines are independent of each other and can all be executed in parallel. For example, Figure 3 In the list, coroutine 0 corresponds to "PCIe Port 0 (RP0) Training", coroutine 1 corresponds to "PCIe Port 1 (RP1) Training", and coroutine 2 corresponds to "USB4 Initialization". They are all placed into the ready queue at the same time and executed in a round-robin fashion by the scheduler.

[0081] Parent-child coroutines: For tasks with a hierarchical structure, a parent-child coroutine organization method is used. For example, "Memory subsystem initialization" acts as the parent coroutine, responsible for overall process control; the parent coroutine creates three child coroutines to execute "Memory channel 0 training," "Memory channel 1 training," and "Memory channel 2 training," respectively. The parent coroutine waits for all child coroutines to complete before executing subsequent configuration operations. This organization encapsulates the complex subsystem initialization into a single parent coroutine, simplifying the calling interface.

[0082] Multiple Frames Coexisting: In large firmware, different modules (such as multiple PEIMs in the PEI stage) may use coroutine frames independently. Each module creates its own coroutine frame instance, maintaining independent ready queues and waiting queues, with frames isolated from each other. For example, the memory initialization module runs in frame A, and the PCIe enumeration module runs in frame B. The coroutines in the two frames do not interfere with each other, and even if a coroutine in one frame fails, it will not affect the normal scheduling of the other frame.

[0083] The following combination Figure 3 Let's take a specific task as an example to describe a typical scheduling cycle.

[0084] Initial state: The scheduling center's ready queue contains three coroutines: coroutine 0 (PCIe RP0 training), coroutine 1 (PCIe RP1 training), and coroutine 2 (USB4 initialization). The queue order is [coroutine 0, coroutine 1, coroutine 2].

[0085] Step 1: Execute coroutine 0 (PCIe RP0 training)

[0086] The scheduling center retrieves coroutine 0 from the head of the ready queue, restores its context, and begins link training on PCIe root port 0. During training, coroutine 0 needs to wait for hardware stabilization (e.g., 100 microseconds after triggering training), therefore it calls the Stall(100) blocking interface provided by the firmware. Since this interface has been replaced by the hook layer, an enhanced version is actually executed. This version records the wake-up time and moves coroutine 0 into the waiting queue, while saving coroutine 0's context to its private stack space. Subsequently, the scheduling center triggers a coroutine switch.

[0087] Step 2: Switch to coroutine 1 (PCIe RP1 training)

[0088] The scheduling center retrieves coroutine 1 from the ready queue, restores its context, and executes link training on PCIe root port 1. Coroutine 1 also calls Stall(100) after triggering training and is moved to the waiting queue. At this point, only coroutine 2 (USB4 initialization) remains in the ready queue.

[0089] Step 3: Switch to Coroutine 2 (USB4 Initialization)

[0090] The scheduling center executes coroutine 2 to begin the initialization of the USB4 controller. USB4 initialization involves multiple stages: cable direction detection, power negotiation, link training, etc., which include multiple delays and polling. During the first delay (e.g., waiting for power to stabilize), coroutine 2 calls Stall(5000) and is moved to the waiting queue. At this point, the ready queue is empty.

[0091] Step 4: Waiting for the queue to wake up

[0092] When there are no ready coroutines, the scheduling center enters an idle waiting state and continuously checks the wake-up conditions of coroutines in the waiting queue. The first coroutine to meet the conditions is coroutine 0 (after 100 microseconds), and the scheduling center moves it from the waiting queue back to the ready queue; then coroutine 1's 100 microseconds expires, and it is also moved back to the ready queue; finally, coroutine 2's 5 milliseconds expires, and it is moved back to the ready queue. At this time, the ready queue is [coroutine 0, coroutine 1, coroutine 2] (in wake-up order).

[0093] Step 5: Continue execution

[0094] The scheduling center then sequentially schedules coroutines 0, 1, and 2 to continue their respective tasks (such as reading link status and configuring devices). If a coroutine still has multiple waiting periods, the suspension and wake-up process is repeated until all coroutines have completed their execution. Training tasks on multiple independent ports (such as PCIe RP0 and RP1) are executed concurrently, reducing the total execution time from the sum of the individual task times to the longest single task time, significantly improving firmware startup speed.

[0095] In one example, when the parent coroutine initializing the memory subsystem is scheduled, it first creates three child coroutines and places them in the ready queue. The parent coroutine then calls the `yield` interface to relinquish the CPU, allowing the child coroutines to execute. After each child coroutine completes its channel training, when the parent coroutine is rescheduled, it checks that all child coroutines are complete before continuing with subsequent operations. Throughout this process, the switching of child coroutines is entirely managed by the scheduling center; the parent coroutine does not need to concern itself with the specific scheduling details. Encapsulating a complex subsystem into a single parent coroutine through parent-child coroutines reduces coupling between modules and facilitates firmware code maintenance and reuse.

[0096] In one example, suppose the memory initialization module uses frame A, and the PCIe enumeration module uses frame B. Each frame maintains its own independent ready queue and waiting queue. The scheduling center is actually two independent scheduler instances running at different times within the same thread. When frame A schedules its internal coroutines, the coroutines in frame B are in a suspended state, and vice versa. This isolation ensures that faults do not propagate: if a coroutine in frame A experiences a stack overflow, the coroutines in frame B are unaffected and can still be scheduled and executed normally. The coexistence of multiple frames allows coroutines of different functional modules to run in independent environments; an anomaly in a single module will not affect the entire system's startup process, enhancing firmware reliability.

[0097] All coroutine tasks are executed alternately within a single thread, eliminating the need for multi-core synchronization overhead, and stack space is allocated on demand, adapting to the memory-constrained environment in the early stages of firmware startup.

[0098] According to an embodiment of this application, the method further includes: detecting the execution status of a plurality of coroutine tasks; in response to detecting that a coroutine task has failed to execute, identifying the failed coroutine task as a faulty coroutine task; and when identifying a second coroutine task, skipping the faulty coroutine task and other coroutine tasks that depend on the faulty coroutine task.

[0099] In one example, the system continuously monitors the running status of a coroutine task during execution. When a coroutine fails due to abnormal exit, returning an error code, or stack overflow, the fault handling module captures the event and marks the coroutine as faulty. During subsequent scheduling, when the scheduler selects the next coroutine from the ready queue, it checks the status flags of each coroutine: if a faulty coroutine is found, it is skipped and not included in the scheduling selection. Furthermore, for coroutines with pre-established dependencies (e.g., a PCIe enumeration coroutine depends on a memory training coroutine), when the dependent predecessor coroutine is marked as faulty, all subsequent coroutines that depend on it are also marked as faulty or canceled, and the scheduler skips these coroutines as well.

[0100] The fault marking mechanism ensures that the failure of a single hardware initialization task will not block the entire boot process—after the scheduler skips the failed coroutine, the system can continue to execute other unrelated tasks. The dependency propagation mechanism further prevents subsequent tasks from executing incorrectly or the system from crashing due to the failure of preceding tasks. For example, when memory training fails, the PCIe enumeration task that depends on memory is automatically canceled, avoiding exceptions caused by accessing uninitialized memory. The combination of these two mechanisms significantly improves the fault tolerance of firmware boot, enabling the system to complete the initialization of usable hardware as much as possible even when some hardware fails.

[0101] Based on the above firmware boot method, this application also provides a firmware boot system. The following will combine... Figure 4 The system is described in detail.

[0102] Figure 4 A schematic block diagram of a firmware boot system according to an embodiment of this application is shown.

[0103] like Figure 4 As shown, the firmware boot system 400 of this embodiment includes an execution module 410, a blocking module 420, a coroutine determination module 430, a coroutine switching module 440, and a status determination module 450.

[0104] The execution module 410 is used to execute the first coroutine task in the coroutine task queue in response to the firmware boot command. The first coroutine task is used to boot the firmware. In one embodiment, the execution module 410 can be used to perform the operation S210 described above, which will not be repeated here.

[0105] The blocking module 420 is used to save the context data determined during the execution of the first coroutine task to the first stack space corresponding to the first coroutine task when it detects that the execution of the first coroutine task has been paused by calling the blocking interface. In one embodiment, the blocking module 420 can be used to perform the operation S220 described above, which will not be repeated here.

[0106] The coroutine determination module 430 is used to determine the second coroutine task that is in a suspended execution state from the coroutine task queue. In one embodiment, the coroutine determination module 430 can be used to perform the operation S230 described above, which will not be repeated here.

[0107] The coroutine switching module 440 is used to resume execution of the second coroutine task based on the context data stored in the second stack space corresponding to the second coroutine task. In one embodiment, the coroutine switching module 440 can be used to perform the operation S240 described above, which will not be repeated here.

[0108] The state determination module 450 is used to determine the firmware's state as "started" based on the execution results of multiple completed coroutine tasks. In one embodiment, the state determination module 450 can be used to perform the operation S250 described above, which will not be repeated here.

[0109] According to embodiments of this application, any plurality of modules among execution module 410, blocking module 420, coroutine determination module 430, coroutine switching module 440, and state determination module 450 can be combined into one module, or any one of these modules can be split into multiple modules. Alternatively, at least part of the functionality of one or more of these modules can be combined with at least part of the functionality of other modules and implemented in one module. According to embodiments of this application, at least one of execution module 410, blocking module 420, coroutine determination module 430, coroutine switching module 440, and state determination module 450 can be at least partially implemented as hardware circuitry, such as field-programmable gate array (FPGA), programmable logic array (PLA), system-on-a-chip, system-on-a-substrate, system-on-package, application-specific integrated circuit (ASIC), or implemented in hardware or firmware by any other reasonable means of integrating or packaging circuitry, or implemented in software, hardware, and firmware, or in any suitable combination of any of these three implementation methods. Alternatively, at least one of the execution module 410, blocking module 420, coroutine determination module 430, coroutine switching module 440, and state determination module 450 may be implemented at least partially as a computer program module, which can perform corresponding functions when the computer program module is executed.

[0110] Figure 5 A block diagram schematically illustrates an electronic device suitable for implementing a firmware boot method according to an embodiment of this application.

[0111] like Figure 5As shown, an electronic device 500 according to an embodiment of this application includes a processor 501, which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 502 or a program loaded from a storage portion 508 into a random access memory (RAM) 503. The processor 501 may include, for example, a general-purpose microprocessor (e.g., a CPU), an instruction set processor and / or an associated chipset and / or a special-purpose microprocessor (e.g., an application-specific integrated circuit (ASIC)), etc. The processor 501 may also include onboard memory for caching purposes. The processor 501 may include a single processing unit or multiple processing units for performing different actions of the method flow according to an embodiment of this application.

[0112] RAM 503 stores various programs and data required for the operation of electronic device 500. Processor 501, ROM 502, and RAM 503 are interconnected via bus 504. Processor 501 executes various operations of the method flow according to embodiments of this application by executing programs in ROM 502 and / or RAM 503. It should be noted that programs may also be stored in one or more memories other than ROM 502 and RAM 503. Processor 501 may also execute various operations of the method flow according to embodiments of this application by executing programs stored in one or more memories.

[0113] According to embodiments of this application, the electronic device 500 may further include an input / output (I / O) interface 505, which is also connected to a bus 504. The electronic device 500 may also include one or more of the following components connected to the input / output (I / O) interface 505: an input section 506 including a keyboard, mouse, etc.; an output section 507 including a cathode ray tube (CRT), liquid crystal display (LCD), etc., and a speaker, etc.; a storage section 508 including a hard disk, etc.; and a communication section 509 including a network interface card such as a LAN card, modem, etc. The communication section 509 performs communication processing via a network such as the Internet. A drive 510 is also connected to the input / output (I / O) interface 505 as needed. A removable medium 511, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., is installed on the drive 510 as needed so that computer programs read from it can be installed into the storage section 508 as needed.

[0114] This application also provides a computer-readable storage medium, which may be included in the device / apparatus / system described in the above embodiments; or it may exist independently and not assembled into the device / apparatus / system. The computer-readable storage medium carries one or more programs, which, when executed, implement the method according to the embodiments of this application.

[0115] According to embodiments of this application, the computer-readable storage medium can be a non-volatile computer-readable storage medium, such as including but not limited to: portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this application, the computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. For example, according to embodiments of this application, the computer-readable storage medium may include ROM 502 and / or RAM 503 and / or one or more memories other than ROM 502 and RAM 503 described above.

[0116] Embodiments of this application also include a computing device comprising a processor and memory, and running the aforementioned firmware program. The computing device may be, for example, a server, a personal computer, an embedded system, or any electronic device that relies on firmware for startup. The memory in the device stores firmware programs implementing the above methods, and the processor loads and executes the program from the memory when the device is powered on or reset. During program execution, the processor creates coroutines, responds to blocking interfaces, performs context switching according to the aforementioned methods, and ultimately completes all hardware initialization tasks and starts the device.

[0117] Embodiments of this application also include a computer program product comprising a computer program containing program code for performing the methods shown in the flowchart. When the computer program product is executed in a computer system, the program code is used to enable the computer system to implement the firmware boot method provided in the embodiments of this application.

[0118] When the computer program is executed by the processor 501, it performs the functions defined in the system / apparatus of this application embodiment. According to the embodiments of this application, the systems, apparatuses, modules, units, etc., described above can be implemented by computer program modules.

[0119] In one embodiment, the computer program may rely on a tangible storage medium such as an optical storage device or a magnetic storage device. In another embodiment, the computer program may also be transmitted and distributed in the form of signals over a network medium, and may be downloaded and installed via the communication section 509, and / or installed from a removable medium 511. The program code contained in the computer program can be transmitted using any suitable network medium, including but not limited to: wireless, wired, etc., or any suitable combination thereof.

[0120] In such an embodiment, the computer program can be downloaded and installed from a network via communication section 509, and / or installed from removable medium 511. When the computer program is executed by processor 501, it performs the functions defined in the system of this application embodiment. According to embodiments of this application, the systems, devices, apparatuses, modules, units, etc., described above can be implemented by computer program modules.

[0121] According to embodiments of this application, program code for executing the computer programs provided in the embodiments of this application can be written in any combination of one or more programming languages. Specifically, these computational programs can be implemented using high-level procedural and / or object-oriented programming languages, and / or assembly / machine languages. Programming languages ​​include, but are not limited to, languages ​​such as Java, C++, Python, "C", or similar programming languages. The program code can be executed entirely on the user's computing device, partially on the user's device, partially on a remote computing device, or entirely on a remote computing device or server. In cases involving remote computing devices, the remote computing device can be connected to the user's computing device via any type of network, including a local area network (LAN) or a wide area network (WAN), or it can be connected to an external computing device (e.g., via the Internet using an Internet service provider).

[0122] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram or flowchart, and combinations of blocks in a block diagram or flowchart, may be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0123] Those skilled in the art will understand that the features described in the various embodiments of this application can be combined and / or combined in various ways, even if such combinations or combinations are not explicitly described in this application. In particular, the features described in the various embodiments of this application can be combined and / or combined in various ways without departing from the spirit and teachings of this application. All such combinations and / or combinations fall within the scope of this application.

[0124] The embodiments of this application have been described above. However, these embodiments are merely illustrative and not intended to limit the scope of this application. Although various embodiments have been described above, this does not mean that the measures in the various embodiments cannot be used advantageously in combination. Without departing from the scope of this application, those skilled in the art can make various substitutions and modifications, all of which should fall within the scope of this application.

Claims

1. A firmware boot method, characterized in that, include: In response to the firmware boot command, the first coroutine task in the coroutine task queue is executed, and the first coroutine task is used to boot the firmware; If it is detected that the execution of the first coroutine task is paused by calling the blocking interface, the context data determined during the execution of the first coroutine task is saved to the first stack space corresponding to the first coroutine task. Determine the second coroutine task that is in a suspended execution state from the coroutine task queue; The second coroutine task is resumed based on the context data stored in the second stack space corresponding to the second coroutine task; Based on the execution results of multiple completed coroutine tasks, the firmware is determined to be in an "activated" state.

2. The method according to claim 1, characterized in that, The coroutine task queue includes a first queue, which stores coroutine tasks that are in an executable state among multiple suspended coroutine tasks. The method further includes: If it is detected that the execution of the second coroutine task is paused by calling the active yield interface, the context data of the second coroutine task is saved to the second stack space corresponding to the second coroutine task; Move the second coroutine task into the first queue.

3. The method according to claim 2, characterized in that, The coroutine task queue includes a second queue for storing coroutine tasks whose execution is paused by calling a blocking interface. The method further includes: Move the suspended first coroutine task into the second queue; In response to the target coroutine task in the second queue meeting the execution conditions, the target coroutine task in the second queue is moved from the second queue to the first queue.

4. The method according to claim 3, characterized in that, The execution conditions include at least one of the following: The preceding coroutine tasks that depend on the target coroutine task have been completed; The computing resources required for the target coroutine task are ready; The waiting time passed when calling the blocking interface meets the preset time.

5. The method according to claim 1, characterized in that, Resuming execution of the second coroutine task based on the context data stored in the second stack space corresponding to the second coroutine task includes: Load the context data of the second coroutine task from the second stack space of the second coroutine task. The context data of the second coroutine task includes the execution status data when the second coroutine task is suspended. Based on the execution status data, determine the subtasks that are suspended in the second coroutine task; Based on the dependencies between multiple subtasks in the second coroutine task, the suspended subtask and other subtasks related to the suspended subtask are executed.

6. The method according to any one of claims 1 to 5, characterized in that, The coroutine task is determined based on the following operations: Identify multiple startup tasks to be executed, and create corresponding coroutine tasks for the startup tasks; The corresponding stack space is allocated to the coroutine task based on the memory resources required by the startup task.

7. The method according to claim 1, characterized in that, The method further includes: Detect the execution status of multiple coroutine tasks; In response to the detection of a coroutine task execution failure, the failed coroutine task is identified as a faulty coroutine task; When determining the second coroutine task, the faulty coroutine task and other coroutine tasks that depend on the faulty coroutine task are skipped.

8. The method according to claim 2, characterized in that, The plurality of coroutine tasks are pre-configured with execution priorities, and the step of determining the second coroutine task in a suspended execution state from the coroutine task queue includes: The second coroutine task is determined from the first queue based on the execution priority; or The second coroutine task is determined based on the order of the coroutine tasks in the first queue.

9. A firmware boot system, characterized in that, include: An execution module is used to execute the first coroutine task in the coroutine task queue in response to a firmware boot command. The first coroutine task is used to boot the firmware. The blocking module is used to save the context data determined during the execution of the first coroutine task to the first stack space corresponding to the first coroutine task when it is detected that the execution of the first coroutine task is paused by calling the blocking interface. The coroutine determination module is used to determine the second coroutine task that is in a suspended execution state from the coroutine task queue; The coroutine switching module is used to resume the execution of the second coroutine task based on the context data stored in the second stack space corresponding to the second coroutine task; The status determination module is used to determine the status of the firmware as "started" based on the execution results of multiple completed coroutine tasks.

10. A computer-readable storage medium having firmware or instructions stored thereon, characterized in that, When the firmware program or instructions are executed by the processor, they implement the steps of the method according to any one of claims 1 to 8.

11. A computing device, comprising: One or more processors; Memory, used to store firmware programs or instructions. The firmware program, when executed by the processor, implements the steps of the method according to any one of claims 1 to 8.

Images