Method and apparatus for executing an option rom of an accessory in a computing device

Abstract

A method of executing an option ROM of an accessory in a computing device includes the steps of: loading a firmware interface by a first processing unit of the computing device; activating a second processing unit of the computing device to monitor execution of the option ROM; executing the option ROM by the first processing unit; if the option ROM fails to execute, the second processing unit restores the first processing unit to a state prior to the executing step; and if the option ROM is successfully executed, the second processing unit stops monitoring execution of the option ROM. Even if there is a bad option ROM, the system BIOS, such as UEFI, does not hang, but instead automatically maps the bad peripheral and skips the option ROM execution and automatically continues system boot.

Description

Technical Field

[0001] This invention relates to a method for starting a computing device, and more specifically to the initialization of peripheral devices of the computing device during startup. Background Technology

[0002] Modern servers in computer networks support the connection of various peripheral devices, enabling these devices to enhance the server's functionality. Examples of peripheral devices include virtual adapters, host bus adapters, and network adapters, which can be connected to the server's processor and other components via the server's bus (e.g., PCTe). Peripheral devices are often manufactured by a different manufacturer than the server and can be removably plugged into the server's motherboard or connected to I / O ports provided on the server.

[0003] However, if the peripheral devices are manufactured by a third-party vendor, there is a potential risk that the option ROM carried on the peripheral devices may cause the server's system firmware to hang during the boot process. The option ROM typically consists of firmware called by the server's system firmware, but because the option ROM is manufactured by a third-party vendor, any incompatibility issues between the option ROM and the system firmware may cause the system firmware to hang during the execution of the option ROM.

[0004] Traditionally, when a system hangs during startup, one method for diagnosing the problem is to manually remove all peripherals at once and then add them back one by one to identify which specific peripheral caused the firmware hang. Obviously, this method is time-consuming and interrupts server uptime. Alternatively, logs can be saved during system startup, and when the firmware hangs, these logs can be checked later to identify the specific peripheral causing the hang. However, this method does not eliminate the possibility of system hangs, and even if the problematic peripheral is identified, the user still needs to physically remove it from the server, requiring manual intervention. If the problematic peripheral is an onboard device, it becomes even more difficult to remove it from the server. Summary of the Invention

[0005] In view of the above background, the object of the present invention is to provide alternative methods and apparatus for eliminating or at least mitigating the above-mentioned technical problems.

[0006] The above objectives are achieved by a combination of features of the main claims; the dependent claims disclose other advantageous embodiments of the invention.

[0007] Other objects of the invention will become apparent to those skilled in the art from the following description. Therefore, the foregoing statements are not exhaustive and are merely illustrative of some of the many objects of the invention.

[0008] Therefore, in one aspect, the present invention is a method for executing an optional ROM of an attachment in a computing device, comprising the following steps: loading a firmware interface by a first processing unit of the computing device; activating a second processing unit of the computing device to monitor the execution of the optional ROM; executing the optional ROM by the first processing unit; if the optional ROM fails to execute, the second processing unit restores the first processing unit to the state before the execution step; and if the optional ROM is successfully executed, the second processing unit stops monitoring the execution of the optional ROM.

[0009] Preferably, the method further includes a step of saving the execution environment of the first processing unit to a first memory of the computing device before performing the execution step.

[0010] More preferably, the first memory is the system memory of the computing device.

[0011] According to a variant of the preferred embodiment, the recovery step further includes storing the information of the attachment in a second memory of the computing device; and restoring the first processing unit to the execution environment stored in the first memory.

[0012] In one implementation, the second memory is the non-volatile random access memory (NVRAM) of the computing device.

[0013] According to another variation of the preferred embodiment, the method further includes the step of continuing to calculate the startup of the device by skipping the option ROM based on information stored in the second memory.

[0014] According to another variation of the preferred embodiment, the recovery step further includes storing the information of the attachment into a second memory of the computing device; and restarting the computing device.

[0015] Preferably, the second memory is part of a module of the computing device. This module is separate from the motherboard of the computing device and replaces one or more functions of the motherboard.

[0016] In one implementation, the second memory is part of the Integrated Management Module (IMM).

[0017] According to another variation of the preferred embodiment, the method further includes a step of disabling the accessory based on information stored in a second memory prior to the activation step.

[0018] According to another variation of the preferred embodiment, the computing device includes a multi-core microprocessor. The first processing unit and the second processing unit are two cores of the microprocessor's plurality of cores.

[0019] Alternatively, the computing device includes multiple microprocessors. The first processing unit and the second processing unit are two of the multiple microprocessors.

[0020] In one specific implementation, the first and second processing units support Intel Architecture (IA). The first processing unit is a Bootstrap Processor (BSP), and the second processing unit is an Application Processor (AP).

[0021] In another specific implementation, the firmware interface is the Unified Extensible Firmware Interface (UEFI).

[0022] According to another aspect of the present invention, a computing device is disclosed including an accessory containing an option ROM. The computing device further includes a first processing unit adapted to load a firmware interface and a second processing unit adapted to be activated by the first processing unit to monitor the execution of the option ROM. The first processing unit is adapted to execute the option ROM. If the option ROM fails to be executed, the second processing unit is adapted to restore the first processing unit to a state prior to the execution of the option ROM. If the option ROM is successfully executed, the second processing unit is adapted to stop monitoring the execution of the option ROM.

[0023] Preferably, the first processing unit is further adapted to save the execution environment of the first processing unit to the first memory of the computing device before executing the option ROM.

[0024] More preferably, the first memory is the system memory of the computing device.

[0025] According to a variant of a preferred embodiment, the second processing unit is further adapted to store the information of the attachment in a second memory of the computing device; and to restore the first processing unit to the execution environment stored in the first memory.

[0026] In one implementation, the second memory is the non-volatile random access memory (NVRAM) of the computing device.

[0027] According to another variation of the preferred embodiment, the first processing unit is adapted to continue calculating the startup of the device after the first processing unit is restored by skipping the option ROM based on information stored in the second memory.

[0028] According to another variation of the preferred embodiment, the second processing unit is further adapted to store the information of the attachment into a second memory of the computing device; and to restart the computing device.

[0029] According to another variation of the preferred embodiment, the computing device further includes a motherboard and a module detachable from the motherboard and replacing one or more functions of the motherboard. A second memory is part of this module.

[0030] In one implementation, the second memory is part of the Integrated Management Module (IMM).

[0031] According to another variation of the preferred embodiment, the first processing unit is further adapted to disable the attachment based on information stored in the second memory before activating the second processing unit.

[0032] In one implementation, the computing device includes a multi-core microprocessor. The first processing unit and the second processing unit are two cores among the multiple cores of the microprocessor.

[0033] Alternatively, the computing device includes multiple microprocessors. The first processing unit and the second processing unit are two of the multiple microprocessors.

[0034] In another implementation, the first and second processing units support Intel architecture (IA). The first processing unit is a boot processor (BSP), and the second processing unit is an application processor (AP). Attached Figure Description

[0035] The foregoing and other features of the invention will become apparent from the following description of preferred embodiments provided by way of example only, in conjunction with the accompanying drawings, in which:

[0036] Figure 1 A block diagram illustrating the internal structure of a computing device according to an embodiment of the present invention is shown;

[0037] Figure 2 The structure of a processor module of a computing device according to another embodiment of the present invention is shown; and

[0038] Figure 3 This is a flowchart illustrating a method for executing an option ROM of a third-party attachment according to another embodiment of the present invention.

[0039] In the accompanying drawings, the same reference numerals denote the same parts throughout the several embodiments described herein. Detailed Implementation

[0040] In the appended claims and the foregoing description of the invention, the word “comprise” or variations thereof, such as “comprises” or “comprising,” are used in an inclusive sense, that is, to specify the presence of the stated feature, but not to exclude the presence or addition of additional features in various embodiments of the invention, except where such requirements are otherwise made in the context due to the language of expression or necessary implication.

[0041] As used herein and in the claims, unless otherwise stated, “coupled” or “connected” means a direct or indirect electrical coupling or connection via one or more electrical devices.

[0042] Figure 1 An embodiment of a computing device implementing the principles of the present invention is illustrated. The computing device may include a processor 20. The processor 20 may include any type of processor capable of executing software and / or processing data signals. The processor 20 may be coupled to system memory 24 via a memory path (not shown) for storing instructions and data and / or for storing, for example, graphics commands, data, and textures. The processor 20 may be coupled to one or more peripheral devices 38 via a PCIe port (not shown) coupled to a PCIe interconnect 30. The memory 24 may be a hard disk, floppy disk, random access memory (RAM), read-only memory (ROM), flash memory, or any other type of media readable by the processor 20. The RAM may also include non-volatile random access memory (NVRAM) and / or dynamic random access memory (DRAM) and static random access memory (SRAM).

[0043] Processor 20 can refer to more than one processor in a computing device, or may include one or more processors such as multiple threads and multiple cores. This enhancement is not limited to computer systems or data processing device systems. Alternative embodiments of the invention can be used in any form factor device using a Unified Extensible Firmware Interface (UEFI) Basic Input / Output System (BIOS), such as handheld devices and embedded applications. Some examples of handheld devices include cellular phones, tablet computers, Internet Protocol devices, digital cameras, personal digital assistants (PDAs), or handheld PCs such as netbooks or laptops. Embedded applications may include microcontrollers, digital signal processors (DSPs), system-on-a-chip (SoCs), network computers (NetPCs), set-top boxes, network hubs, wide area network (WAN) switches, or any other system.

[0044] Processor 20 may be coupled to system logic chip 26. For example, system logic chip 26 in the illustrated embodiment may be a platform controller center (PCH). In one embodiment, PCH 26 may provide connectivity to one or more I / O devices, for example, via a local I / O interconnect. In one embodiment, the local I / O interconnect may be a high-speed I / O bus, such as a peripheral component interconnect (PCI) fast bus. PCH 26 may direct data signals or other information between processor 20 and one or more other components in the computing device, and bridge data signals or information between processor 20 and system I / O.

[0045] Examples of one or more components may include a data storage device 28, one or more PCIe ports (not shown), a networking controller 34, and a USB port 36. In one embodiment, the data storage device 28 may include a hard disk drive, a floppy disk drive, a CD-ROM device, a flash memory device, or other mass storage device. Although Figure 1 Some examples of the components are shown, but the PCH 26 can provide connectivity to other components such as audio I / O, keyboard / mouse I / O and other integrated I / O components, such as integrated driver electronics (IDE), local area network (LAN) and other serial expansion ports, wireless transceivers, traditional I / O controllers, etc.

[0046] refer to Figure 1 Non-volatile memory, such as flash memory 34, can be coupled to PCH 26 via, for example, a low pin count (LPC) bus. BIOS firmware 32 can reside in flash memory 34 and can execute instructions from flash memory or firmware upon startup. Although Figure 1 The illustration shows BIOS firmware 32 in flash memory 34, but in some embodiments, BIOS firmware 32 may be stored in other non-volatile memory such as firmware hub. In one embodiment, BIOS firmware 32 may be implemented by Unified Extensible Firmware Interface (UEFI) firmware or any other firmware interface between the operating system and the hardware of the computing device.

[0047] One or more peripheral devices 38 may be connected to the PCIe interconnect 30, and these devices 38 may be connected to the computing device internally or externally. In the case of an internal peripheral device 38, it is embedded on the motherboard of the computing device or removably mounted in an available PCIe slot on the motherboard. In the case of an external peripheral device 38, it is a standalone device located outside the casing of the computing device and connected to the PCIe interconnect 30 via a port provided by the motherboard. Each peripheral device 38 includes an option ROM 40, which is firmware executed by the system BIOS of the computing device during platform initialization. The option ROM 40 is provided by a third-party manufacturer of the peripheral device 38.

[0048] like Figure 1The computing device shown also includes a Baseboard Management Controller (BMC) 29, a dedicated microcontroller embedded on the motherboard of the computing device that manages the interface between the system management software and the platform hardware. The BMC 29 is a component typically included in server-class computers to implement the Intelligent Platform Management Interface (IPMI) specification protocol. In one embodiment, the BMC 29 can be replaced by an Integrated Management Module (IMM, not shown), which combines the service processor functions provided by a combination of the BMC and the Remote Management Adapter (RSA) on the motherboard of the computing device. The IMM module is separate from the motherboard of the computing device and replaces one or more functions of the motherboard.

[0049] although Figure 1 The computing device is shown, but embodiments of the invention can be used in any other hardware and software architecture, such as a platform using multiple processor cores or a platform using a processor or coprocessor, a platform using an I / O center or memory control embedded in the processor, etc.

[0050] Figure 2 This is a block diagram illustrating a hardware and firmware layered view of an embodiment of the present invention. (Reference) Figure 2 System 200 may include one or more logical processors 202 and a bootable processor (BSP) 204. In one embodiment, the logical processor 202 may be an application processor (AP) 202. The BSP 204 and AP 202 are controlled by... Architecture (IA) support is provided. AP 202 and BSP 204 can execute firmware 220. In another embodiment, the processor can be randomly assigned as either AP or BSP in response to power-on. In one embodiment, firmware 220 can be implemented in a BIOS environment (e.g., a UEFI environment or an application environment where no other operating system (OS) exists). Although Figure 2 Four processor cores are shown, but in some embodiments, system 200 may include a different number of processor cores. Although Figure 2 AP 202 and BSP 204 are shown, but the embodiments can be used in systems with any other processor core.

[0051] Now go to Figure 3 , Figure 3 A method is shown for implementing option ROMs for third-party add-ons in a computing device that includes at least a BSP, an AP, and an IMM, all of which are similar to those described in the above reference. Figure 1-2The BSP is responsible for executing the UEFI boot code to configure the APIC environment, set up system-wide data structures, and start and initialize the AP. When the BSP and AP are initialized, the BSP begins executing the operating system initialization code. In this embodiment, the BSP is also referred to as the first processing unit of the computing device.

[0052] Figure 3 The methods shown and described herein are part of the device startup process and whether they are executed at any specific point in time during the entire startup process. Figure 3 The method shown is irrelevant. The only requirement is that the method is executed after the BSP and at least one AP have been initialized and UEFI has been loaded. Then, before executing the option ROM of a third-party peripheral device or an accessory such as a PCIe device, in step 60, the BSP first checks whether there is any list of bad option ROMs for one or more third-party peripheral devices pre-stored in the IMM module. Bad option ROMs are option ROMs that cannot be successfully executed by the system BIOS and cause the system to hang. In step 60, the BSP will retrieve any such list from the IMM and then disable one or more bad peripheral devices and skip the execution of their option ROMs.

[0053] Next, in step 62, the BSP calls the Application Programming Interface (API) 74, which is executed by the AP instead of the BSP. As described above, the AP is an independent physical process or processor core from the BSP, and its operation is unaffected by the BSP's state. The AP is also referred to as the second processing unit of the computing device. The workflow of API 74 will be described in more detail later. However, it should be noted that unless the BSP's process is interrupted by the AP in a manner that enables BSP recovery or system reset, the BSP's process will continue independently of the API 74 process performed by the AP, as will be described in more detail later.

[0054] In step 64, the BSP continues from step 62 to save the current execution environment of the computing device (e.g., stack, heap, and main memory...) as a recovery point in system memory. The recovery point, saved in system memory, can be accessed by both the BSP and one or more APs. The BSP saves the recovery point in step 64 before jumping to the run option ROM. In step 64, the BSP also passes the recovery point (with the memory address containing the recovery data) to the AP.

[0055] Next, before executing the option ROM, the BSP checks in step 66 whether there is any information in the NVRAM of the system memory regarding peripheral devices whose option ROM cannot be successfully executed by the system BIOS. If the check finds no such information, in step 68, the BSP continues with the normal execution of the peripheral device's option ROM. If the option ROM can be successfully executed, the method proceeds to step 70, where the BSP sets a flag with a true value (e.g., = 1) in the system memory, indicating that the execution of the option ROM for the peripheral device has been completed, and in other words, the peripheral device has been successfully initialized. This flag can be accessed by both the BSP and the AP. However, if the check in step 66 finds that information about the peripheral device does exist in the NVRAM, the BSP bypasses step 68 and jumps directly to step 70, where the BSP still sets the true flag. After step 70, the BSP continues with the device boot process, such as initializing other components and then loading the operating system.

[0056] Note that steps 66, 68, and 70 may be executed multiple times for each peripheral device in the computing device that includes the option ROM. For each peripheral device, the BSP will determine whether to execute its option ROM based on the value of the corresponding flag for that specific peripheral device in memory. The BSP will only continue with system startup in step 72 after all peripheral devices with option ROMs have been successfully initialized.

[0057] Now we turn to API 74. As mentioned above, this is an independent process executed by the AP, so API 74 can still proceed unaffected even if the BSP is suspended in step 68 during the execution of the option ROM. When the BSP calls API 74 in step 62, the AP initially checks in step 76 whether the aforementioned flag has been set to true by the BSP, indicating that the peripheral device's option ROM has been successfully executed. If the flag has been set to true, the AP uses the AP rendezvous function 88 to enter an idle state, where the AP stops monitoring the execution of the option ROM because it has been successfully executed. However, if the AP finds in step 76 that the flag has not yet been set to true, the AP will check in step 78 whether a predetermined time has elapsed using the AP watchdog timer before taking any recovery measures. If the predetermined time has not elapsed, the AP returns to step 76, and steps 76 and 78 can be repeated multiple times while the AP waits for the BSP's execution result of the option ROM. In other words, during the parallel operation of both the BSP and the AP, the AP polls for the true value of the flag within a predetermined time period.

[0058] In step 78, if the flag is not set to true after a predetermined time has elapsed, the AP will intervene in the execution of the option ROM. First, in step 80, the AP stores information about peripherals for which the option ROM could not be successfully executed within a given time in NVRAM. As mentioned above, such information can be used later by the BSP in other separate processes in step 66. Then, in step 82, the AP restores the BSP to the execution environment using a restore point stored in system memory. The AP knows the restore point and its location in memory because the BSP passed this information to the AP when it saved the execution environment to memory in step 64. The purpose of restoring the BSP is to ensure that the BSP is in good condition and can attempt to execute the option ROM again. Otherwise, without restoring the BSP, a BSP hang may occur when the BSP first attempts to execute the option ROM.

[0059] After the BSP recovers and attempts to execute the option ROM again, in step 84, the AP will check again whether the flag is set to true. If so, similar to the success determination in step 76, the AP uses the AP rendezvous function 88 to enter an idle state, where the AP stops monitoring the execution of the option ROM since it has been successfully executed. However, if the AP finds in step 84 that the option ROM still cannot be executed successfully after the BSP is recovered, the AP will report the peripheral device information to the IMM module in step 86. After the computing device restarts, the information about the peripheral devices stored in the memory of the IMM module can be used by the BSP in step 60, as described above. After step 86, the AP causes the system to restart, retaining the peripheral device information stored in the memory of the IMM module during the restart process. The restart of the computing device can be considered as another way of receiving the BSP, since the state of the BSP will be reset during the restart. For ease of description, the system memory of the computing device is referred to as the first memory, and the memory in the IMM module is referred to as the second memory.

[0060] Therefore, the above embodiments provide an improved, tolerant option ROM dispatch method. If any bad option ROM (i.e., an option ROM incompatible with the system BIOS and causing the BSP to hang) or a bad peripheral device (i.e., a peripheral device with hardware failure and attempting to execute its option ROM also causes the BSP to hang), it is blocked in option ROM dispatch. Even if a bad option ROM exists, a system BIOS such as UEFI will not hang, but will automatically map the bad peripheral device and skip option ROM execution, and automatically continue system boot. This method improves the fault tolerance of the computing device when executing option ROMs of one or more peripheral devices in the computing device, enhances the availability time of the computing device, and reduces the service support / cost of the computing device.

[0061] Therefore, exemplary embodiments of the invention have been fully described. Although the description relates to specific embodiments, those skilled in the art will recognize that the invention can be practiced with variations in these specific details. Therefore, the invention should not be construed as limited to the embodiments set forth herein.

Claims

1. A method for executing an option ROM of an accessory in a computing device, comprising the steps of: At the first processing unit, the firmware interface of the computing device is loaded; The application programming interface (API) executed by the second processing unit is invoked to report information about peripheral devices with faulty option ROMs to the integrated management module (IMM). Check if the Integrated Management Module (IMM) contains a list of faulty option ROMs for peripheral devices; In response to the determination that the list exists, execution of the bad option ROM is skipped; Monitor the execution of the option ROM; Execute the aforementioned option ROM; If the option ROM fails to be executed, the computing device is restored to the state prior to the execution step based on the recovery information from the API executed by the second processing unit.

2. The method according to claim 1, further comprising: The step of saving the execution environment of the first processing unit to the first memory of the computing device before the execution step.

3. The method according to claim 2, wherein the first memory is the system memory of the computing device.

4. The method of claim 2, wherein the recovery step further comprises: The information of the attachment is stored in the second memory of the computing device; as well as The first processing unit is restored to the execution environment stored in the first memory.

5. The method of claim 4, wherein the second memory is the non-volatile random access memory (NVRAM) of the computing device.

6. The method of claim 4, further comprising the following steps after the recovery step: The startup of the computing device continues by skipping the option ROM based on the information stored in the second memory.

7. The method of claim 2, wherein the recovery step further comprises: The information of the attachment is stored in the second memory of the computing device; as well as Restart the computing device.

8. The method of claim 7, wherein the second memory is part of a module of the computing device; the module is detached from the motherboard of the computing device and replaces one or more functions of the motherboard.

9. The method of claim 8, wherein the second memory is part of an integrated management module (IMM).

10. The method of claim 7, further comprising activating the second processing unit, and the following steps prior to activating the second processing unit: The attachment is disabled based on the information stored in the second memory.

11. The method of claim 1, wherein the computing device comprises a multi-core microprocessor; the first processing unit and the second processing unit are two cores of a plurality of cores of the microprocessor.

12. The method of claim 1, wherein the computing device comprises a plurality of microprocessors; the first processing unit and the second processing unit are two of the plurality of microprocessors.

13. The method of claim 1, wherein the first processing unit and the second processing unit support Intel architecture (IA); the first processing unit is a bootable processor (BSP), and the second processing unit is an application processor (AP).

14. The method of claim 1, wherein the firmware interface is a Unified Extensible Firmware Interface (UEFI).

15. A computing device including an accessory comprising an option ROM, the computing device further comprising: The first processing unit, adapted to load the firmware interface, calls the application programming interface (API) executed by the second processing unit to report information about peripheral devices with bad option ROMs to the integrated management module (IMM); checks whether a list of bad option ROMs for peripheral devices exists in the IMM; and, in response to determining that the list exists, skips the execution of the bad option ROM. A second processing unit is adapted to be activated by the first processing unit to monitor the execution of the option ROM; The first processing unit is adapted to execute the option ROM, and in response to the option ROM failing to execute, the second processing unit is adapted to restore the first processing unit to the state before the execution of the option ROM based on recovery information from the API.

16. The computing device of claim 15, wherein the first processing unit is further adapted to save the execution environment of the first processing unit to a first memory of the computing device before executing the option ROM.

17. The computing device of claim 16, wherein the first memory is the system memory of the computing device.

18. The computing device of claim 16, wherein the second processing unit is further adapted to store information of the attachment in a second memory of the computing device; and to restore the first processing unit to the execution environment stored in the first memory.

19. The computing device of claim 18, wherein the second memory is the non-volatile random access memory (NVRAM) of the computing device.

20. The computing device of claim 18, wherein the first processing unit is adapted to continue the startup of the computing device after the first processing unit is restored by skipping the option ROM based on the information stored in the second memory.

21. The computing device of claim 16, wherein the second processing unit is further adapted to store the information of the accessory into a second memory of the computing device; and to restart the computing device.

22. The computing device of claim 21, further comprising a motherboard and a module detachable from the motherboard of the computing device and replacing one or more functions of the motherboard; the second memory being part of the module.

23. The computing device of claim 22, wherein the second memory is part of an integrated management module (IMM).

24. The computing device of claim 21, wherein the first processing unit is further adapted to disable the accessory based on the information stored in the second memory before activating the second processing unit.

25. The computing device of claim 15, wherein the computing device comprises a multi-core microprocessor; the first processing unit and the second processing unit are two cores of a plurality of cores of the microprocessor.

26. The computing device of claim 15, wherein the computing device comprises a plurality of microprocessors; the first processing unit and the second processing unit are two of the plurality of microprocessors.

27. The computing device of claim 15, wherein the first processing unit and the second processing unit support Intel architecture (IA); the first processing unit is a bootable processor (BSP), and the second processing unit is an application processor (AP).

Images