Intelligent visual modular BIOS firmware development method and system

Abstract

The invention discloses an intelligent visual modular BIOS (Basic Input / Output System) firmware development method and system, BIOS firmware is designed into a plurality of modular modules according to levels and functions, then the modular modules are coded according to rules and recorded into an intelligent visual development system, a developer inputs project requirements, the system intelligently selects the modular modules and generates the BIOS firmware, and the BIOS firmware is stored in the intelligent visual development system. And the modular modules can be selected, checked and modified, and new BIOS firmware can be generated after codes are modified. According to the method, complex firmware development work is converted into simple building block building work, and the difficulty of learning and developing BIOS firmware by developers is reduced; modularized modules are automatically selected by using an AI intelligent matching algorithm, so that the BIOS project firmware development efficiency is improved; most of the modular modules can be reused in different hardware platforms, adaptation of a new hardware platform can be completed only by modifying part of the modular modules in the hardware adaptation layer, and the adaptation speed of the domestic hardware platform is greatly increased.

Description

Technical Field

[0001] This invention belongs to the field of BIOS technology, specifically relating to an intelligent visual modular BIOS firmware development method and system. Background Technology

[0002] With the rapid development of domestically produced computer CPUs and peripheral hardware, the BIOS firmware, which is at the core of the computer, also needs to be adapted to these new CPU architectures and peripheral hardware in a timely manner. However, current BIOS firmware development relies on developers manually modifying code, resulting in low code reusability across different hardware architectures. Code modified to solve the same problem in one project must be modified again in a new project.

[0003] Modular development has become the mainstream practice in modern software development. Current mainstream languages ​​such as Java and JDK 9+ have built-in modular systems. In fields like game development and application development, modularity can significantly reduce repetitive development costs and improve development efficiency. However, because the BIOS is a program tightly integrated with underlying hardware technology, its development primarily uses assembly and C languages. Although modular development thinking has been applied, problems remain, including inconsistent interfaces for different hardware drivers, low modularity, and high difficulty in code migration. These factors lead to low efficiency in BIOS firmware development in projects, and the quality of BIOS firmware heavily relies on the individual skills of developers. Consequently, BIOS firmware development struggles to keep pace with the rapid development of domestically produced computer technology. Summary of the Invention

[0004] The technical problem solved by this invention is to provide an intelligent visual modular BIOS firmware development method and system that transforms complex firmware development work into a simple building block process, can automatically select modular modules, and allows the modular modules to be reused.

[0005] Technical Solution: To solve the above-mentioned technical problems, the present invention adopts the following technical solution:

[0006] A smart, visual, modular BIOS firmware development method involves designing the BIOS firmware into multiple modular modules based on hierarchy and function. These modules are then numbered according to rules and entered into an intelligent visual development system. During BIOS project development, developers input project requirements into the system, which intelligently selects the modular modules and generates the BIOS firmware based on the input requirements. Developers can select, view, and modify the modular modules within the intelligent development system, and after modifying the code, a new BIOS firmware is generated. The specific steps are as follows:

[0007] Step 1: Divide the BIOS firmware into three layers: hardware adaptation layer, BIOS function layer, and system adaptation layer, and define the functional scope of each layer and the interface between each two layers;

[0008] Step 2: In the three layers of hardware adaptation layer, BIOS function layer and system adaptation layer, the firmware is designed into different modular modules according to function;

[0009] Step 3: The intelligent visualization development system integrates an AI intelligent matching algorithm to intelligently match the required modular modules according to the needs;

[0010] Step 4: In the intelligent visual development system, you can view all the modular modules of the BIOS firmware, and you can also modify any modular module;

[0011] Step 5: Each modular module has a numbered system and a standard interface. Any modifications will result in a new modular module, which will be accumulated in the development system.

[0012] Furthermore, in step 1, the hardware adaptation layer includes all modular modules that adapt to computer CPU, memory, PCIE, SATA, and USB hardware devices.

[0013] Furthermore, in step 1, the BIOS functional layer includes support for standard protocol specifications such as PCIE / USB / Network / I2C / SPI, support for UEFI specifications, support for file systems, support for keyboard, mouse and display devices, allocation of system resources and booting of the operating system;

[0014] Furthermore, in step 1, the system adaptation layer includes providing the information and interfaces required by the OS system, such as the memory allocation table, SMBIOS, and ACPI.

[0015] Furthermore, in step 3, the AI ​​intelligent matching algorithm searches for all matching block module numbers based on the input requirements, and then intelligently selects suitable modular modules based on the input and output interfaces of the block modules.

[0016] Furthermore, each modular module has a unique number and functional description; the numbering rules are based on the logical level Ln of the modular module, the corresponding function Fn, and the modular number Xn; each modular module has a corresponding input interface, output interface, and functional description.

[0017] Furthermore, in step 4, the development system provides a visual operation interface and buttons. Developers input their development requirements into the system input box. After the developer clicks the start button, the system performs intelligent matching and displays the final modular modules to the user in graphical form. Developers can view all modular modules of the BIOS firmware and modify any modular module.

[0018] A smart visual modular BIOS firmware development system includes a hardware adaptation layer, a BIOS function layer and a system adaptation layer, and a smart visual development system.

[0019] The hardware adaptation layer includes all modular modules that adapt to computer CPU, memory, PCIe, SATA, and USB hardware devices;

[0020] The BIOS functional layer includes support for PCIE / USB / Network / I2C / SPI standard protocol specifications, support for UEFI specifications, support for file systems, support for keyboard, mouse and display devices, allocation of system resources and booting of the operating system;

[0021] The system adaptation layer includes the information and interfaces required by the OS system, such as memory allocation tables, SMBIOS, and ACPI.

[0022] Beneficial effects: Compared with the prior art, the present invention has the following advantages:

[0023] 1. This invention standardizes the functional scope and interface standards of different BIOS levels by dividing the BIOS firmware into logical layers and modular modules. It breaks down the complex BIOS system into relatively simple modular modules, transforming BIOS development into a simple building block process, thus reducing the difficulty for developers to learn and develop BIOS firmware.

[0024] 2. The AI ​​intelligent selection algorithm integrated in the intelligent visual development system of this invention can intelligently analyze the characteristics of modular modules in the system and select only matching modular modules. It can continuously modify and add to enrich the database and automatically select suitable modular modules according to needs. Modifications can be made to modular modules that cannot be completely matched, and the modified modules can be stored. Developers only need to modify a small number of modular modules according to the system prompts, which improves the efficiency and quality of BIOS project firmware development.

[0025] 3. Most of the modular modules in the development system can be reused on different hardware platforms. New hardware platforms only need to modify some modular modules in the hardware adaptation layer to complete the adaptation, which can reduce the difficulty of migrating BIOS code on new platforms and thus meet the requirements of rapid adaptation of domestic hardware platforms. Attached Figure Description

[0026] Figure 1 This is a schematic diagram of the BIOS firmware logic layering and modular segmentation disclosed in this invention;

[0027] Figure 2 This is a schematic diagram of the intelligent matching modular module process disclosed in this invention;

[0028] Figure 3This is a flowchart of the visual modular BIOS firmware development process disclosed in this invention;

[0029] Figure 4 This is a flowchart of the AI ​​intelligent matching algorithm disclosed in this invention. Detailed Implementation

[0030] The present invention will be further illustrated below with reference to specific embodiments. These embodiments are implemented based on the technical solutions of the present invention, and it should be understood that these embodiments are only used to illustrate the present invention and are not intended to limit the scope of the present invention.

[0031] Example 1

[0032] The intelligent visual modular BIOS firmware development method of this embodiment includes the following steps:

[0033] Step 1: Divide the BIOS firmware into three layers: hardware adaptation layer, BIOS function layer, and system adaptation layer;

[0034] Step 2: In the three layers of hardware adaptation layer, BIOS function layer and system adaptation layer, the firmware function is designed as multiple modular building blocks;

[0035] Step 3: The intelligent visual development system integrates an AI intelligent matching algorithm, which can intelligently match the required modular modules based on the developer's input requirements;

[0036] Step 4: The intelligent visual development system's user interface is WYSIWYG, allowing developers to view all modular modules of the BIOS firmware and modify any single modular module.

[0037] Step 5: Any modifications will create new modular modules, and the number of modular modules in the development system will accumulate over time.

[0038] Example 2

[0039] The specific implementation process of the present invention will be described below through specific embodiments.

[0040] Step 1: Divide the BIOS firmware into three layers: hardware adaptation layer, BIOS function layer, and system adaptation layer;

[0041] The hardware adaptation layer comprises modular modules that adapt to various hardware devices such as computer CPUs, memory, PCIe, SATA, and USB. Although the hardware adaptation layer supports significant differences in hardware, it abstracts unified interaction interfaces for the BIOS functional layer. For example, the CPU abstracts a unified input interface (CpuIO), memory abstracts Allocate and Free interfaces, PCIe devices abstract a PciIO interface, SATA devices abstract a SATAIO interface, and USB devices abstract a UsbIO interface. These abstracted interfaces are consistent in their input and output parameters, allowing the BIOS functional layer to remain unconcerned about the underlying hardware differences, thus achieving hardware independence.

[0042] The BIOS functional layer includes support for standard protocol specifications such as PCIe / USB / Network / I2C / SPI, and supports...

[0043] The UEFI specification supports file systems, keyboards, mice, and display devices, allocates system resources, and boots the operating system. Building upon the standard interfaces provided by the hardware adaptation layer, the BIOS functional layer focuses on implementing standard protocols and resource allocation. The results of resource allocation are recorded in specification tables such as SMBIOS and ACPI, and provided to the system adaptation layer for use.

[0044] The system adaptation layer includes providing information and interfaces required by the OS system, such as the memory allocation table, SMBIOS, and ACPI. This information and interface data is collected from various modular modules within the BIOS functional layer. The system adaptation layer standardizes this data and reports it to the OS system, freeing the OS from concern itself with the specific functional implementations within the BIOS.

[0045] Step 2: In the three layers of hardware adaptation layer, BIOS function layer and system adaptation layer, the firmware function is designed as multiple modular building blocks;

[0046] Each modular module has a unique number and attribute label; the numbering rule is composed of the logical level Ln where the modular module is located, the corresponding function Fn, and the modular number Xn; the attribute label of each modular module includes the corresponding input interface, output interface, and function description, etc.

[0047] For example: the hardware adaptation layer is L1, the BIOS function layer is L2, and the system adaptation layer is L3;

[0048] The different functions in each logical level are named F1, F2...Fn respectively;

[0049] There are also modular modules with different interfaces for the same function, numbered X1, X2...Xn respectively;

[0050] Therefore, the number of a modular assembly according to the above rules is LnFnXn.

[0051] Step 3: The intelligent visual development system integrates an AI intelligent matching algorithm, which can intelligently match the required modular modules based on the developer's input requirements;

[0052] like Figure 2 The diagram illustrates the intelligent matching process for modular modules within the development system. Developers input BIOS firmware requirements into the system's visual interface. Upon receiving the input, the system uses an AI-powered intelligent matching algorithm to automatically match the necessary modular modules from its database. If multiple similar modules exist, the developer is prompted to manually select one. Developers can also view or modify the code of any modular module. Modifications result in renumbered modules and the formation of new modular modules, thus enriching and perfecting the modular system's database.

[0053] The AI ​​intelligent matching algorithm in this invention utilizes artificial intelligence technology to calculate the correlation between user needs and optimal modules based on the multi-dimensional data characteristics of modular components. The specific implementation steps of the AI ​​intelligent matching algorithm in this invention are as follows:

[0054] Step 31: Using a predefined rule base, precisely match the key constraints in the requirements with the attribute tags of the modules, filtering out modules that do not meet the basic conditions. The rule definition and matching process is as follows:

[0055] 1) Build a rule base: Each modular module has a unique code and attribute tag. Tag and code each module.

[0056] For example, the attribute label of the CPU module in the hardware adaptation layer is {Manufacturer: Intel, Generation: 12, Interface: CpuIO}; and the number is L1F1X1.

[0057] For example, the attribute label of the UEFI module in the BIOS functional layer is {Specification:UEFI, Version:2.9}; the encoding is L2F2X2.

[0058] 2) Analyze the requirements: Break down the input requirements into key constraints (such as {Hardware: CPU, Manufacturer: Intel, Generation: 12}, {Function: UEFI, Version ≥ 2.9}).

[0059] 3) Matching rules: Use the logic of "IF - requirement constraint THEN - module attribute tag", for example:

[0060] If the requirement includes "Intel 12th generation CPU", then match the CPU module with the attribute tag {Manufacturer:Intel, Generation:12th generation} in the hardware adapter layer; its code is L1F1X1.

[0061] If the requirement includes "UEFI 2.9", then match the module in the BIOS functional layer that is {Specification:UEFI, Version ≥ 2.9}, whose code is L2F2X2.

[0062] Let the set of requirement constraints be R = {r1, r2, ..., r...} n For example, r1 = CPU manufacturer = Intel, and the module description tag set is M = {m1, m2, ..., m}. k}, then the module matching degree S 规则 for:

[0063]

[0064] When S 规则 When the value is 1, the module passes the initial screening.

[0065] The above process filters out modules that do not meet the hard constraints. For example, it excludes hardware adaptation modules that do not support a specified CPU; and it handles hard requirements such as explicit hardware specifications and protocol specifications, such as "must support Intel 12th generation CPUs" and "must be compatible with UEFI 2.9 specifications".

[0066] Step 32: Process user requirement data; then convert user requirements and module data into feature vectors, evaluate similarity by calculating the cosine of the angle between the vectors, and match requirements with modular modules; the higher the value, the higher the matching degree. Specifically, this includes steps 321 and 322:

[0067] Step 321: Process user request data

[0068] Users have diverse needs, and different users express their needs in different ways. If the system cannot accurately understand user needs, it will be detrimental to the next step of judgment and matching.

[0069] The first step is to break down user requirements into minimal atomic functions to match the modular design of the development system. An atomic function is a self-contained unit of user requirements, broken down layer by layer into indivisible, single-responsibility, and independently executable functional units. These atomic functions must meet the following criteria: clear inputs and outputs, no redundant logic, and indivisible into smaller, meaningful functions.

[0070] Taking PXE boot support as an example, the requirements are first broken down into atomic requirements such as network functions, file system functions, and PXE functions. These atomic requirements have corresponding numerical labels and tags in the system. Then, the corresponding modular modules such as network functions, file system functions, and PXE functions are selected from the system database according to the numerical labels and tags.

[0071] For descriptive requirements that cannot be split, algorithms are used to map them into numerical vectors (Natural Language Vectorization Data Processing), making semantically similar data closer together in the vector space. Natural Language Vectorization Data Processing mainly utilizes the Word2Vec text embedding model to generate multidimensional semantic vectors. The core idea is that semantically similar words have similar contexts. By optimizing the prediction task, the distributed representation of words (multidimensional semantic vectors) is indirectly learned, supporting accurate semantic retrieval.

[0072] Let the vocabulary size be V, and each word correspond to two vectors: an input vector and an output vector.

[0073] Input Vector: (d is the vector dimension, i.e. the embedding dimension), used to represent the vector when word w is used as input;

[0074] Output Vector: A vector used to represent word w as output (prediction target).

[0075] Context window: For the central word w, its context is 2c words in the window (c words on the left and right, such as when c=2, the context of "restore" in "support remote system status recovery" is "support, remote, system, status".

[0076] CBOW (Continuous Bag-of-Words) is an architecture of the Word2Vec model.

[0077] The input to CBOW is the context word vector of the center word w, and the output is the center word.

[0078] The probability distribution of w aims to maximize the probability of the head word appearing given the context.

[0079] From input layer to hidden layer: The set of context words is Context(w) = {w1, w2, ..., w...} 2c The hidden layer vector h is the average of the context input vectors.

[0080]

[0081] Wherein, Context(w) is the set of context words of the head word w; vwi It is the context word w i Word vectors, w i It is a context word.

[0082] Hidden layer to output layer: The output layer calculates the probability of the center word w (i.e., the probability of predicting it as word w) using the softmax function:

[0083]

[0084] Where P(w|Context(w)) is the probability of the center word w. It is the output vector u w The inner product with the hidden layer vector h is used to measure the relevance of the context to the center word w; V is the vocabulary, and w′ is any word in the vocabulary; u w′ It is the output layer vector of word w′ in the vocabulary.

[0085] Objective function (loss function): The training objective is to maximize the log-likelihood of all training samples (equivalent to minimizing the negative log-likelihood).

[0086]

[0087] in, This represents the loss function, and Corpus is the corpus.

[0088] Word2Vec optimizes the above objective function through stochastic gradient descent (SGD). The core of this process is calculating the loss function with respect to the input vector v. w and output vector u w The gradient is calculated, and the vector is updated.

[0089] First, all input vectors vw and output vectors uw are randomly initialized. Then, forward propagation, backward propagation, and vector updates are performed. Next, forward propagation, backward propagation, and vector updates are repeated for each central word and its context in the corpus until the loss function converges.

[0090] The original softmax algorithm requires calculating the probabilities of all V words (V often reaches millions), resulting in extremely high computational costs. Word2Vec addresses this softmax computational bottleneck by optimizing Hierarchical Softmax and Negative Sampling, thereby reducing computational complexity and improving computing power.

[0091] After training, the input vector v is usually taken. w The final semantic vector of a word (or the average of the input and output vectors, but the input vector is more commonly used) is used. The characteristic of these vectors is that words with similar meanings have higher cosine similarity in their vectors.

[0092] This embodiment employs the Word2Vec model to handle user input to the system. Through a context-headword prediction task, words are mapped to a low-dimensional vector space. Computational efficiency is addressed through Hierarchical Softmax or Negative Sampling, focusing on probability calculation and gradient updates. A simple neural network learns distributed representations of words, capturing semantic relationships and providing an efficient solution for natural language vectorization.

[0093] For example, if a user enters "has a beautiful interface" or "has a graphical interface", the system will match it to a system that supports graphical interfaces, and then select GuiSetup and related modular modules.

[0094] For example, if a user enters "remote wake-up system" or "remote recovery system", the system will associate it with the Wake onlan function, and then select WOL and related modular modules.

[0095] Step 322: Convert user requirements and module data into feature vectors, evaluate similarity by calculating the cosine of the angle between the vectors, match requirements with modular modules, the higher the value, the higher the matching degree, and filter out modules with high matching degree.

[0096] The method for constructing and calculating feature vectors of user requirements and module data is as follows:

[0097] 1) Feature dimension definition: covering hardware type (CPU / PCIe / SATA, etc.), protocol support (USB3.0 / PCIe 4.0, etc.), specification version (UEFI / ACPI, etc.), etc., with a total dimension of d.

[0098] 2) Vector transformation:

[0099] Demand Vector r i The weight of the i-th feature in the requirement (0 to 1, where a higher weight indicates that the requirement pays more attention to the feature);

[0100] Module vectors m i The support of the module for the i-th feature is 0 to 1, where 1 indicates full support and 0 indicates no support.

[0101] 3) Similarity calculation:

[0102]

[0103] Suppose we set a threshold θmin (e.g., 0.7), and a module is considered to meet the functional requirements when cosθ ≥ θmin; for example, in the requirement vector, "USB3.0" has a weight of 0.8, and "PCIe4.0" has a weight of 0.6; if a module's support for both is 1.0 and 0.5 respectively, then the similarity is:

[0104] (0.8×1.0+0.6×0.5) / (√(0.8 2 +0.6 2 )×√(1.0 2 +0.5 2 ))≈0.86.

[0105] If the similarity is higher than the threshold θmin, then the user's needs and the modular module are matched; if it is lower than the threshold θmin, then they are not matched. In this case, 0.86 > θmin = 0.7, so the calculation result is a match.

[0106] Step 33: For the user's vague input requirements, convert the vague semantics into quantifiable matching degree.

[0107] Before matching, the system breaks down user requirements and performs semantically similar word matching for requirements that cannot be broken down, enabling accurate matching of user input and solving the problem of semantic precision matching. However, when users are developing BIOS firmware, although they accurately input their requirements, these requirements are often vague and cannot be quantified. For example, requirements like "supporting multiple PCIe devices" and "compatible with most USB interfaces" are vague and cannot be quantified. With a large amount of system data, the system cannot accurately output the user's requirements. To address these vague user requirements, the system can use a fuzzy logic matching algorithm to handle them, transforming vague semantics into quantifiable matching degrees.

[0108] This embodiment provides the following method: defining the fuzzy relationship between requirements and module features through a membership function, calculating the membership degree of the module to the requirements, and evaluating the degree of matching.

[0109] Define fuzzy sets: Define the requirement features as fuzzy sets (e.g., "PCIe device compatibility" is divided into three levels: "low / medium / high").

[0110] The membership function is given: a triangular function is used to describe the membership degree of a module to a fuzzy set. For example, the membership function for "high PCIe compatibility" is:

[0111]

[0112] Where x is the number of PCIe device types supported by the module (0 to 5), μ高 (x) represents the membership degree (0 to 1).

[0113] Overall matching degree: a weighted sum of the membership degrees of multi-dimensional fuzzy features.

[0114]

[0115] Where, k i μ is the weight of the i-th feature. i This corresponds to the membership degree.

[0116] If the requirements are "high PCIe compatibility" (weight 0.6) and "medium USB compatibility" (weight 0.4), a certain module supports 4 types of PCIe devices (μ). 高 =0.5) and 3 types of USB devices (μ 中 If the score is 0.8, then the overall matching degree is 0.6×0.5+0.4×0.8=0.62.

[0117] Step 34: Optimize and combine the user's multiple needs into modules.

[0118] When developing BIOS firmware, users often need to combine multiple modules, including modules for the hardware adaptation layer and functional modules for the BIOS function layer. After matching each individual user requirement, the problem of combining multiple modules remains: can multiple modules be effectively connected, are the interfaces compatible, can the functions be organically combined, and can the protocols be standardized and integrated?

[0119] Therefore, when the requirements necessitate the collaborative work of multiple modules (such as the CPU + memory module in the hardware adaptation layer needing to be compatible with the resource allocation module in the functional layer), the overall adaptability of the module combination needs to be optimized.

[0120] To address this issue, the method presented in this embodiment treats module combinations as "chromosomes" and maximizes the compatibility and functional coverage of the combinations through selection, crossover, and mutation iterative optimization.

[0121] Step 4, Algorithm Selection Process:

[0122] Based on the functional requirement atoms or semantic vector data extracted in step 2 above, the multidimensional feature data described in step 3 is selected and matched in the modular database.

[0123] By using a predefined rule base, key constraints in the requirements are precisely matched with the attribute tags of the modules, filtering out modules that do not meet the basic conditions.

[0124] Algorithm steps and fitness function:

[0125] Encoding: Each chromosome is an index sequence of module combinations (e.g., [L1,L2,L3], directly using encoding, where the adaptation layer module is L1, the BIOS function layer module is L2, and the system adaptation layer module is L3).

[0126] The fitness function is used to evaluate the effectiveness of the portfolio, and the formula is as follows:

[0127] Fitness = α·C + β·F + γ·Q

[0128] Where C represents inter-module compatibility, with a value of 0 to 1, such as the matching degree between hardware layer module interfaces and functional layer module interfaces; F represents functional coverage, with a value of 0 to 1, representing the percentage of functional requirements that are met; Q represents hierarchical consistency, with a value of 0 to 1, ensuring the correctness of the dependency relationship between the hardware layer, functional layer, and system layer; α, β, and γ are weights (summing to 1).

[0129] The selected module is iteratively optimized, including the following steps:

[0130] 1) Selection: Retain chromosomes with high fitness;

[0131] 2) Crossover: Exchanging parts of two chromosomes (e.g., exchanging functional layer modules);

[0132] 3) Mutation: Randomly replace a module with another module at the same level;

[0133] 4) Termination condition: The maximum number of iterations is reached or the fitness converges.

[0134] After optimizing the compatibility and overall performance of the above combinations, the final module set is output.

[0135] Step 5: Optimize and save the results

[0136] The system will display the results of the algorithm selection in steps 3 and 4 to the developers, who can then manually adjust them. These manually adjusted data will also be recorded as feature values ​​and saved in the feature data database.

[0137] like Figure 3 The diagram shows the complete process of the development method of this invention, which mainly includes 7 steps:

[0138] 1. Developers input BIOS firmware project requirements, such as support for a certain network card function, support for a certain graphics card function, support for PXE boot, support for TCM function, etc.

[0139] 2. The development system intelligently matches modular modules according to requirements. Taking PXE boot support as an example, the requirements are first broken down into atomic requirements such as network function, file system function and PXE function. Based on the results of automatic matching and pushing by the system, modular modules for network function, file system function and PXE function are selected from the system database respectively.

[0140] 3. Developers manually select modular modules with similar functions;

[0141] 4. Modified modules whose functions or interfaces no longer match;

[0142] 5. The development system generates BIOS firmware that can be tested;

[0143] 6. Test and modify the corresponding modular modules based on the issues encountered;

[0144] 7. Output the BIOS firmware required for the project.

[0145] Example 3

[0146] This embodiment discloses an intelligent visual modular BIOS firmware development system, including a hardware adaptation layer, a BIOS function layer and a system adaptation layer, and an intelligent visual development system.

[0147] Figure 1 The diagram shows that the BIOS firmware is divided into three logical layers: the hardware adaptation layer, the BIOS function layer, and the system adaptation layer. Each layer consists of multiple modular modules with different functions. Modular modules with the same function are designed with a unified standard input / output interface. Different modular modules can call each other according to the interface and function. These selected modular modules work together to complete the full functions and requirements of the BIOS firmware.

[0148] The visual development system provides a visual operation interface and buttons. Developers can input development requirements into the system input box. After the developer clicks the start button, the system will intelligently match and display the final modular modules to the user in graphical form. Developers can view all modular modules of the BIOS firmware and modify any modular module.

[0149] The hardware adaptation layer comprises modular modules that adapt to various hardware devices such as computer CPUs, memory, PCIe, SATA, and USB. Although the hardware adaptation layer supports significant differences in hardware, it abstracts unified interaction interfaces for the BIOS functional layer. For example, the CPU abstracts a unified input interface (CpuIO), memory abstracts Allocate and Free interfaces, PCIe devices abstract a PciIO interface, SATA devices abstract a SATAIO interface, and USB devices abstract a UsbIO interface. These abstracted interfaces are consistent in their input and output parameters, allowing the BIOS functional layer to remain unconcerned about the underlying hardware differences, thus achieving hardware independence.

[0150] The BIOS functional layer includes support for standard protocol specifications such as PCIe / USB / Network / I2C / SPI, and supports...

[0151] The UEFI specification supports file systems, keyboards, mice, and display devices, allocates system resources, and boots the operating system. Building upon the standard interfaces provided by the hardware adaptation layer, the BIOS functional layer focuses on implementing standard protocols and resource allocation. The results of resource allocation are recorded in specification tables such as SMBIOS and ACPI, and provided to the system adaptation layer for use.

[0152] The system adaptation layer includes providing information and interfaces required by the OS system, such as the memory allocation table, SMBIOS, and ACPI. This information and interface data is collected from various modular modules within the BIOS functional layer. The system adaptation layer standardizes this data and reports it to the OS system, freeing the OS from concern itself with the specific functional implementations within the BIOS.

[0153] The above description is only a preferred embodiment of the present invention. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principle of the present invention, and these improvements and modifications should also be considered within the scope of protection of the present invention.

Claims

1. A smart, visual, modular BIOS firmware development method and system, characterized in that: The BIOS firmware is designed into multiple modular blocks according to layers and functions, and then the modular blocks are coded and recorded into an intelligent visual development system. When developing the BIOS project, the developer inputs the project requirements into the development system, and the system intelligently selects the modular blocks according to the input requirements and generates the BIOS firmware. The developer selects, views and modifies the modular blocks in the intelligent development system, and outputs new BIOS firmware after modifying the code.

2. The intelligent visual building block BIOS firmware development method and system of claim 1, wherein, The specific steps are as follows: Step 1: The BIOS firmware is divided into three layers of hardware adaptation layer, BIOS function layer and system adaptation layer, and the function range contained in each layer and the interface between each two layers are defined; Step 2: In the three layers of hardware adaptation layer, BIOS function layer and system adaptation layer, the firmware is designed into different modular blocks according to functions; Step 3: The AI intelligent matching algorithm is integrated in the intelligent visual development system, and the required modular blocks are intelligently matched according to the requirements; Step 4: In the intelligent visual development system, all the modular blocks of the BIOS firmware can be viewed, and any modular block can be modified; Step 5: Each modular block has a regular code and a property tag, and after any modification, a new modular block is formed and accumulated in the development system.

3. The intelligent visual building block BIOS firmware development method of claim 2, wherein: In step 2, the hardware adaptation layer includes all the modular blocks for adapting computer CPU, memory, PCIE, SATA, USB hardware devices.

4. The intelligent visual building block BIOS firmware development method of claim 2, wherein: In step 2, the BIOS function layer includes supporting PCIE / USB / Network / I2C / SPI standard protocol specifications, supporting UEFI specifications, supporting file systems, supporting keyboard, mouse and display devices, allocating system resources and booting operating systems.

5. The intelligent visual brick-based BIOS firmware development method of claim 2, wherein: In step 2, the system adaptation layer includes information and interfaces required by the OS system for providing memory allocation table, SMBIOS and ACPI.

6. The intelligent visual brick-based BIOS firmware development method of claim 2, wherein: In step 3, the AI intelligent matching algorithm analyzes and matches the modular blocks that meet the requirements according to the input requirements, and intelligently selects the appropriate modular blocks.

7. The intelligent visual brick-based BIOS firmware development method of claim 2, wherein: Each modular block has a unique number and function description; the number rule is composed of the logical layer Ln where the modular block is located, the corresponding function Fn and the modular number Xn; each modular block has corresponding input and output interfaces and function description.

8. The intelligent visual brick-based BIOS firmware development method of claim 1, wherein: In step 4, the development system provides a visual operation interface and buttons, and the developer inputs the development requirements into the system input box; after the developer clicks the start button, the system intelligently matches and displays the final modular blocks in graphical form to the user; The developer can view all the modular blocks of the BIOS firmware, and can modify any modular block.

9. An intelligent visual building block BIOS firmware development system, characterized by: It includes hardware adaptation layer, BIOS function layer and system adaptation layer, and intelligent visual development system; The hardware adaptation layer includes all the modular blocks for adapting computer CPU, memory, PCIE, SATA, USB hardware devices; The BIOS function layer includes supporting PCIE / USB / Network / I2C / SPI standard protocol specification, supporting UEFI specification, supporting file system, supporting keyboard, mouse and display device, allocating system resource and booting operating system; The system adaptation layer includes providing information and interface required by OS system of memory allocation table, SMBIOS and ACPI.

Images