A multi-device information dynamic display method, an electronic device, and a storage medium
By generating globally unique dynamic GUIDs and dynamically patching HII form data, the problem of displaying multiple device information in NVMe Option ROM was solved, enabling independent display and high compatibility of NVMe hard drives, and improving the accuracy and stability of the firmware configuration interface.
Patent Information
- Application Number
- CN202611469753.6
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2026-09-21
- Publication Date
- 2026-11-06
AI Technical Summary
Existing NVMe Option ROMs suffer from issues such as GUID conflicts leading to information overwriting or failure to display when running a graphical configuration interface on multiple hard drives of the same model, rigid device paths that cannot be dynamically generated, and poor compatibility under different manufacturers' UEFI environments.
By generating a globally unique dynamic GUID, dynamically patching HII form data, constructing a standard HII device path, and registering it to the UEFI global HII database, the read-only attribute information of each NVMe drive is ensured to be displayed independently.
It enables independent and complete display of information from multiple devices, with precise path binding, improving the accuracy and compatibility of the firmware configuration interface, avoiding garbled characters and registration failures, and reducing firmware adaptation costs.
Smart Images

Figure CN123048338A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of computer firmware technology, and in particular to a method for dynamically displaying information across multiple devices, an electronic device, and a storage medium. Background Technology
[0002] NVMe (Non-Volatile Memory Express) solid-state drives, as high-speed storage devices, typically require early initialization via Option ROM (Option Read-Only Memory). Traditional NVMe Option ROMs primarily focus on hardware initialization and boot services, lacking the ability to provide users with detailed device status information. While the Unified Extensible Firmware Interface (UEFI) specification provides a Human Interface Infrastructure (HII) protocol for implementing graphical configuration interfaces for firmware, existing NVMe Option ROMs suffer from the following significant shortcomings in implementing HII support:
[0003] Lacking dynamic adaptation capabilities, existing solutions typically use fixed GUIDs (Globally Unique Identifiers) to register HII forms during compilation. When multiple NVMe drives exist in the system, GUID conflicts can cause forms in the HII database to be overwritten, resulting in incorrect display of information for multiple hard drives. Furthermore, rigid device paths are common; traditional Option ROMs often bind to fixed device paths and cannot dynamically generate corresponding HII device paths at runtime based on the actually detected NVMe controller. This leads to the firmware's graphical configuration interface failing to accurately locate and display information for specific physical devices during boot. Finally, poor compatibility is another issue. UEFI implementations for different CPU manufacturers (such as AMD, Intel platforms, or Hygon) have varying levels of support for the HII protocol. Existing Option ROMs lack compatibility adaptation strategies for different UEFI custom versions, easily leading to garbled interfaces or registration failures. Summary of the Invention
[0004] The purpose of this invention is to solve the problems existing in the prior art, such as information overwriting or failure to display when multiple NVMe hard drives of the same model are running in a graphical configuration interface due to GUID conflicts, inability to dynamically construct device paths according to the actual hardware status at runtime, resulting in inaccurate binding between the interface and physical devices, poor compatibility under different manufacturers' customized UEFI environments, and easy display abnormalities. This invention proposes a method for dynamically displaying information of multiple devices, an electronic device, and a storage medium.
[0005] To achieve the above objectives, the present invention adopts the following technical solution:
[0006] On one hand, the present invention provides a method for dynamically displaying information from multiple devices, the method comprising:
[0007] During the system startup phase, the hardware serial number of the NVMe driver is read to generate a globally unique dynamic GUID;
[0008] Construct standard HII device paths based on dynamic GUIDs;
[0009] During Option ROM initialization, the original hard-coded GUID field is replaced with a dynamic GUID to dynamically repair the HII form data;
[0010] The repaired HII form data and standard HII device paths are registered to the UEFI global HII database, triggering the firmware's graphical configuration interface to parse and independently display the read-only attribute information of each NVMe drive.
[0011] As a further preferred embodiment of the present invention, the environment is set up and the data structure is defined before the system starts, as follows:
[0012] The core data structure is defined in the header file XXXXXOptionROMHii.h. The OPTIONROM_DEV structure is defined to store the private data of each NVMe device, including the hardware serial number of the NVMe driver, the hardware model of the NVMe driver, the NVMe driver-specific GUID, and the NVMe driver path.
[0013] As a further preferred embodiment of the present invention, the method for generating a globally unique dynamic GUID is as follows:
[0014] Read the hardware serial number of the NVMe driver, calculate the hash value using the CRC32 algorithm, and obtain the nanosecond value of the current system time as a random factor;
[0015] The hash value is mixed with a random factor and filled into the Data1 and Data4 fields of the GUID template to generate a globally unique dynamic GUID.
[0016] As a further preferred embodiment of the present invention, the process of calculating the hash value using the CRC32 algorithm includes:
[0017] Initialize by setting the CRC register to its initial value of 0xFFFFFFFF;
[0018] Process the input data byte by byte. For each byte of the input data, perform the following operations:
[0019] After shifting the current byte left, perform an XOR operation with the CRC register, and process the bits of the byte sequentially from the most significant bit to the least significant bit.
[0020] Perform one iteration for each bit. If the highest bit of the CRC is 1, shift the CRC left by 1 bit and then XOR it with the polynomial 0x04C11DB7; if the highest bit of the CRC is 0, simply shift the CRC left by 1 bit.
[0021] The CRC register value is XORed with 0xFFFFFFFF to obtain the final CRC32 check value.
[0022] As a further preferred embodiment of the present invention, the process of constructing the standard HII device path is as follows:
[0023] Based on the dynamic GUID, the global template mHiiVendorDevicePath is copied, and VendorDevicePath.Guid in the template is replaced with the input dynamic GUID. The mHiiVendorDevicePath is registered to the system through the installation protocol interface via API, and a standard HII device path starting with HARDWARE_DEVICE_PATH and ending with END_DEVICE_PATH is constructed.
[0024] As a further preferred embodiment of the present invention, the dynamic repair of HII form data includes:
[0025] Iterate through the HII form data in the OptionROMBin file and search for data of type EFI_HII_PACKAGE_FORMS.
[0026] Locate the FormSet operation code in the HII form data;
[0027] Replace the dynamic GUID with a hard-coded raw GUID field using a memory copy;
[0028] Call HiiAddPackages or HiiNewPackageList to register the patched HII form data into the HII database.
[0029] As a further preferred embodiment of the present invention, before the repaired HII form data is registered into the HII database, the repaired HII form is loaded through the Unified Extensible Firmware Interface (UEMI) to detect the firmware vendor characteristics of the current UEMI firmware. If a memory-constrained environment is detected, the HII string encoding method is adjusted or the HII form data structure is simplified.
[0030] On the other hand, the present invention provides an electronic device, comprising: at least one processor; at least one memory for storing at least one program; and implementing the multi-device information dynamic display method as described above when at least one of the programs is executed by at least one of the processors.
[0031] On the other hand, the present invention also provides a computer-readable storage medium storing computer-executable instructions for performing the multi-device information dynamic display method as described above.
[0032] Compared with existing technologies, the beneficial effects of this invention are as follows: This invention, through a dynamic GUID generation mechanism, ensures that even if multiple NVMe hard drives of the same model are inserted, their dynamic GUIDs are absolutely unique, achieving independent and complete display of information for multiple devices and completely resolving the problem of multi-device conflicts; at runtime, the HII device path is dynamically constructed, and the path is precisely bound, enabling the configuration interface to accurately locate the specific NVMe hard drive, improving the accuracy of the firmware configuration interface, effectively compatibility with standard UEFI, achieving high compatibility and stability, avoiding compatibility issues such as interface garbled characters and registration failures, and reducing firmware adaptation costs. Attached Figure Description
[0033] Figure 1 This is a flowchart of the method for dynamically displaying information from multiple devices in an embodiment of the present invention; Figure 2 This is a schematic diagram of the logic flow for dynamic GUID generation in an embodiment of the present invention; Figure 3 This is a schematic diagram of the standard HII device path construction process in an embodiment of the present invention; Figure 4 This is a schematic diagram of the structure of the electronic device in an embodiment of the present invention. Detailed Implementation
[0034] To make the objectives, technical solutions, and beneficial effects of this invention clearer, the specific embodiments of this invention will be described in detail below with reference to the accompanying drawings. These embodiments are merely preferred examples of this invention, used to aid in understanding the inventive concept, and do not constitute a limitation on the scope of protection.
[0035] This embodiment proposes a method for dynamically displaying multi-device information. Specifically, this method is based on the NVMe Option ROM of UEFI HII for dynamically displaying multi-device information. Figure 1 As shown, the method for dynamically displaying information across multiple devices includes the following steps:
[0036] Step 1: Before system startup, set up the environment and define the data structure as follows:
[0037] The core data structure is defined in the header file XXXXXOptionROMHii.h. The OPTIONROM_DEV structure is defined to store the private data of each NVMe device, including the hardware serial number (SN) of the NVMe driver, the hardware model (Mn) of the NVMe driver, and the NVMe driver-specific GUID and NVMe driver path.
[0038] During system startup, the hardware serial number of the NVMe driver is read, and a globally unique dynamic GUID is generated. The `GenerateDynamicGuid` function is implemented in the file `XXXXXOptionROMHii.c`. This function does not rely on fixed constants but generates a unique identifier through the following logic: Figure 2 This is a logical diagram illustrating the generation of a dynamic GUID. It shows the process starting from the input hardware serial number (SN), through CRC32 hash calculation, using the system timestamp as a random factor, and finally generating and outputting a dynamically globally unique identifier (GUID). The specific method for generating a globally unique dynamic GUID is as follows:
[0039] Input the hardware serial number (SN) of the NVMe driver, read the hardware serial number of the NVMe driver, calculate the CRC32 hash value using the CRC32 algorithm, and call gRT->GetTime (obtain the current system time through the runtime service) to get the nanosecond value of the current system time as a random factor;
[0040] The hash value is mixed with a random factor and filled into the Data1 and Data4 fields of the GUID template ( / / GUID struct) to generate and output a dynamically globally unique identifier, i.e., a globally unique dynamic GUID.
[0041] Because each NVMe drive has a unique serial number (SN), the SN is used as a seed to calculate a CRC32 hash value, and then mixed with the current nanosecond time as a random factor. This allows for the generation of a different GUID for each NVMe drive of the same model, ensuring that multiple NVMe drives of the same model can be displayed correctly. This generation strategy, based on hardware serial numbers and timestamps, ensures that even if multiple NVMe drives of the same model are inserted, their dynamic GUIDs will never be duplicated.
[0042] As one method for calculating hash values, this embodiment uses the CRC32 algorithm to calculate hash values, and the process is as follows:
[0043] Step 11, Initialization: Set the CRC register to its initial value 0xFFFFFFFF;
[0044] Step 12: Process the input data byte by byte. For each byte of the input data, perform the following operations:
[0045] Step 13: Shift the current byte left by 24 bits and then perform an XOR operation with the CRC register. Process the 8 bits of the byte sequentially from the most significant bit to the least significant bit.
[0046] Step 14: Perform one iteration for each bit using bit-by-bit modulo-2 division.
[0047] If the most significant bit (bit 31) of the CRC is 1, shift the CRC left by 1 bit and then perform an XOR operation with the polynomial 0x04C11DB7; if the most significant bit of the CRC is 0, simply shift the CRC left by 1 bit.
[0048] Step 15: Finally, invert the result. After all data processing is complete, perform an XOR operation between the value of the CRC register and 0xFFFFFFFF to obtain the final CRC32 check value.
[0049] Step 2: Based on the dynamic GUID, the CreateHiiDevicePath function constructs the dynamic path, building a standard HII device path. The process is as follows:
[0050] The input parameter includes DeviceGuid (i.e., the dynamic GUID generated in the previous step). Internally, the function copies the global template mHiiVendorDevicePath, replaces VendorDevicePath.Guid in the global template mHiiVendorDevicePath with the input dynamic GUID, and registers mHiiVendorDevicePath with the system via the InstallProtocolInterface API, constructing a standard HII device path. The construction process is as follows: Figure 3 As shown.
[0051] By constructing a standard HII device path, the generated device path can be accurately recognized by the UEFI standard Form Browser, and the HII interface can be bound to a specific physical device (such as a PetaIO SSD).
[0052] Step 3: In the PatchFormSetGuid function, the FormSet opcode of the HII form data is dynamically replaced with a GUID to dynamically repair the IFR binary data generated during compilation. During Option ROM initialization, the original hard-coded GUID field is replaced with a dynamic GUID to dynamically repair the HII form data.
[0053] Dynamically repairing HII form data includes:
[0054] Iterate through the HII form data in the OptionROMBin file and search for data of type EFI_HII_PACKAGE_FORMS.
[0055] Locate the FormSet operation code in the HII form data;
[0056] Use a memory copy (CopyMem) to replace the dynamic GUID with the hard-coded original GUID field;
[0057] Call HiiAddPackages (add HII resource packages to the HII database) or HiiNewPackageList (create a list of resource packages to the HII database) to register the patched HII form data into the HII database.
[0058] Step 4: Register the repaired HII form data and standard HII device path to the UEFI global HII database. When entering the UEFI Advanced page, the firmware's graphical configuration interface will be triggered to parse and independently display the read-only attribute information of each NVMe drive.
[0059] Before the patched HII form data is registered into the HII database, the patched HII form is loaded through the Unified Extensible Firmware Interface (UEFI) to detect the firmware vendor characteristics of the current UEFI. If a specific vendor environment or memory-constrained environment is detected, the HII string encoding method is adjusted or the HII form data structure is simplified to adapt to different CPU vendors (such as AMD, Intel platforms or Hygon) and ensure stability in various standardized UEFI environments.
[0060] Although the steps in the above embodiments are described in the above order, those skilled in the art will understand that in order to achieve the effect of this embodiment, different steps do not need to be executed in such an order. They can be executed simultaneously (in parallel) or in a reverse order. These simple variations are all within the protection scope of this invention.
[0061] In addition to the embodiments described above, one embodiment of the present invention also provides an electronic device. See also Figure 4 , Figure 4 This is a schematic diagram of the structure of an electronic device according to an embodiment of the present invention. The electronic device includes a memory and a processor. The number of memories and processors can be one or more. Figure 4 Taking a memory and a processor as an example; the memory and processor can be connected via a bus or other means. Figure 4 Taking the example of a connection between China and Israel via a bus.
[0062] As a computer-readable storage medium, a memory can be used to store one or more software programs, computer-executable programs, and modules, such as the program, instructions, or modules corresponding to the solid-state drive boot method provided in any embodiment of the present invention. The processor implements the multi-device information dynamic display method provided in any embodiment of the present invention by executing one or more computer programs, instructions, and modules stored in the memory.
[0063] The memory may primarily comprise a program storage area and a data storage area, wherein the program storage area may store the operating system and computer programs required for at least one function. Furthermore, the memory may include high-speed random access memory and non-volatile memory, such as at least one disk storage device, flash memory device, or other non-volatile solid-state storage device. In some instances, the memory may further include memory remotely located relative to the processor, which can be connected to the device via a network. Examples of such networks include, but are not limited to, the Internet, intranets, local area networks, mobile communication networks, and combinations thereof.
[0064] In addition to the embodiments described above, one embodiment of this application also provides a computer-readable storage medium storing computer-executable instructions for performing the multi-device information dynamic display method as described in any of the preceding embodiments.
[0065] Furthermore, one embodiment of this application also provides a computer program product, including a computer program or computer instructions, which are stored in a computer-readable storage medium. The processor of an electronic device reads the computer program or computer instructions from the computer-readable storage medium and executes the computer program or computer instructions, causing the electronic device to perform the multi-device information dynamic display method as described in any of the preceding embodiments.
[0066] It will be understood by those skilled in the art that all or some of the steps and systems in the methods disclosed above can be implemented as software, firmware, hardware, and suitable combinations thereof. Some or all of the physical components can be implemented as software executed by a processor, such as a central processing unit, digital signal processor, or microprocessor, or as hardware, or as an integrated circuit, such as an application-specific integrated circuit. Such software can be distributed on a computer-readable medium, which can include computer storage media (or non-transitory media) and communication media (or transient media). As is known to those skilled in the art, the term computer storage media includes volatile and non-volatile, removable and non-removable media implemented in any method or technology for storing information (such as computer-readable instructions, data structures, program modules, or other data). Computer storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technologies, CD-ROM, digital versatile disc (DVD) or other optical disc storage, magnetic cartridges, magnetic tape, disk storage or other magnetic storage devices, or any other medium that can be used to store desired information and is accessible to a computer. Furthermore, as is known to those skilled in the art, communication media typically contain computer-readable instructions, data structures, program modules, or other data in modulated data signals such as carrier waves or other transmission mechanisms, and may include any information delivery medium.
[0067] Those skilled in the art will understand that although some embodiments described herein include certain features but not others included in other embodiments, combinations of features from different embodiments are intended to be within the scope of the invention and form different embodiments. For example, in the claims of this invention, any of the claimed embodiments can be used in any combination.
[0068] It should be noted that the above embodiments are illustrative of the invention and not restrictive, and that those skilled in the art can devise alternative embodiments without departing from the scope of the appended claims. In the claims, the word "comprising" does not exclude the presence of elements or steps not listed in the claims. The word "a" or "an" preceding an element does not exclude the presence of a plurality of such elements. The invention can be implemented by means of hardware comprising several different elements and by means of a suitably programmed PC.
[0069] The technical solution of the present invention has been described above with reference to the preferred embodiments shown in the accompanying drawings. However, it should be noted that the parts not covered in this invention are the same as or can be implemented using existing technology. It will be readily understood by those skilled in the art that the scope of protection of this invention is obviously not limited to these specific embodiments. Without departing from the principles of this invention, those skilled in the art can make equivalent changes or substitutions to the relevant technical features, and the technical solutions resulting from these changes or substitutions will all fall within the scope of protection of this invention.
Claims
1. A multi-device information dynamic display method, characterized by, include: During the system startup phase, the hardware serial number of the NVMe driver is read to generate a globally unique dynamic GUID; Construct standard HII device paths based on dynamic GUIDs; During Option ROM initialization, the original hard-coded GUID field is replaced with a dynamic GUID to dynamically repair the HII form data; The repaired HII form data and standard HII device paths are registered to the UEFI global HII database, triggering the firmware's graphical configuration interface to parse and independently display the read-only attribute information of each NVMe drive.
2. The multi-device information dynamic display method of claim 1, wherein, Before system startup, environment setup and data structure definition should be performed as follows: The core data structure is defined in the header file XXXXXOptionROMHii.h. The OPTIONROM_DEV structure is defined to store the private data of each NVMe device, including the hardware serial number of the NVMe driver, the hardware model of the NVMe driver, the NVMe driver-specific GUID, and the NVMe driver path.
3. The method of claim 1, wherein, The method for generating a globally unique dynamic GUID is as follows: Read the hardware serial number of the NVMe driver, calculate the hash value using the CRC32 algorithm, and obtain the nanosecond value of the current system time as a random factor; The hash value is mixed with a random factor and filled into the Data1 and Data4 fields of the GUID template to generate a globally unique dynamic GUID.
4. The multi-device information dynamic display method of claim 3, wherein, The process of calculating the hash value using the CRC32 algorithm includes: Initialize by setting the CRC register to its initial value of 0xFFFFFFFF; Process the input data byte by byte. For each byte of the input data, perform the following operations: After shifting the current byte left, perform an XOR operation with the CRC register, and process the bits of the byte sequentially from the most significant bit to the least significant bit. Perform one iteration for each bit. If the highest bit of the CRC is 1, shift the CRC left by 1 bit and then XOR it with the polynomial 0x04C11DB7; if the highest bit of the CRC is 0, simply shift the CRC left by 1 bit. The CRC register value is XORed with 0xFFFFFFFF to obtain the final CRC32 check value.
5. The method of claim 1, wherein, The process of constructing the standard HII device path is as follows: Based on the dynamic GUID, the global template mHiiVendorDevicePath is copied, and VendorDevicePath.Guid in the template is replaced with the input dynamic GUID. The mHiiVendorDevicePath is registered to the system through the installation protocol interface via API, and a standard HII device path starting with HARDWARE_DEVICE_PATH and ending with END_DEVICE_PATH is constructed.
6. The method for dynamically displaying information across multiple devices according to claim 1, characterized in that, The dynamically repaired HII form data includes: Iterate through the HII form data in the OptionROMBin file and search for data of type EFI_HII_PACKAGE_FORMS. Locate the FormSet operation code in the HII form data; Replace the dynamic GUID with a hard-coded original GUID field using a memory copy; Call HiiAddPackages or HiiNewPackageList to register the patched HII form data into the HII database.
7. The multi-device information dynamic display method of claim 6, wherein, Before the patched HII form data is registered into the HII database, the patched HII form is loaded through the Unified Extensible Firmware Interface (UEMI) to detect the firmware vendor characteristics of the current UEMI firmware. If a memory-constrained environment is detected, the HII string encoding method is adjusted or the HII form data structure is simplified.
8. An electronic device, characterized in that, include: At least one processor; At least one memory for storing at least one program; The multi-device information dynamic display method as described in any one of claims 1 to 7 is implemented when at least one of the programs is executed by at least one of the processors.
9. A computer-readable storage medium storing computer-executable instructions, characterized in that, The computer-executable instructions are used to execute the multi-device information dynamic display method as described in any one of claims 1 to 7.
