Model loading method and electronic equipment

Abstract

The invention provides a model loading method and electronic device.The method comprises the steps that in response to a first target operation detected in the operating system boot loading stage, target data and first model data are read from a firmware storage area, and the first target operation represents that a user instructs to start a model; and running the first model in the stage based on target data and the first model data, wherein the target data comprises the equipment parameter data.

Description

Technical Field

[0001] The present application relates to the fields of data processing and deep learning, and in particular to a model loading method and electronic device. Background Art

[0002] Artificial intelligence (AI) capabilities are becoming increasingly sophisticated, approaching human capabilities in understanding and analyzing intent. However, current AI applications on PCs require the operating system to function. Embedding AI into the PC boot process, and even customizing the boot process based on user needs, could maximize the PC's performance potential. This represents a future development direction for BIOS (firmware for electronic devices). Summary of the Invention

[0003] The present application provides a model loading method and electronic device.

[0004] An embodiment of the present application provides a model loading method, the method comprising:

[0005] In response to detecting a first target operation during the booting and loading of the operating system, reading target data and first model data from the firmware storage area, wherein the first target operation represents a user instruction to start the model;

[0006] A first model is run at this stage based on the target data and the first model data, the target data including device parameter data.

[0007] The method further comprises:

[0008] Based on user input, obtaining input data of the first model;

[0009] determining a response strategy based on the input data using the first model;

[0010] The response strategy is executed, where the response strategy at least includes generating an output result and outputting the output result, where the output result is used to respond to the input data.

[0011] Wherein, executing the response strategy includes:

[0012] generating parameter adjustment data based on the input data and the output result using the first model;

[0013] The parameter adjustment data is stored in the firmware storage area, and the parameter adjustment data is used to adjust the first parameter of the device when it is started next time.

[0014] The method further comprises:

[0015] In response to detecting that parameter adjustment data belonging to the target phase exists in the firmware storage area during the target phase, a first parameter of the device is adjusted based on the parameter adjustment data. The target phase includes at least a hardware initialization phase and a driver startup phase.

[0016] Wherein, executing the response strategy includes:

[0017] determining a fault result based on the target data using the first model, the target data also including module operation data;

[0018] Executing a corresponding repair strategy based on the type of the fault result includes:

[0019] If the fault result is of the first type, generating parameter adjustment data based on the fault result and storing the data in the firmware storage area, so that the first parameter of the device is adjusted to fix the fault when the device is started next time;

[0020] If the fault result is of the second type, a repair suggestion is generated based on the fault result, and the repair suggestion is output to the user.

[0021] Wherein, executing the response strategy includes:

[0022] Get current device parameter data;

[0023] Determining a judgment result based on the target data and the current device parameter data using the first model, wherein the target data also includes log data;

[0024] The judgment result is output to the user, where the judgment result indicates whether the device parameters have been tampered with.

[0025] The method further comprises:

[0026] In response to completion of a target phase, obtaining module operation information of the target phase, the target phase including at least a hardware initialization phase and a driver startup phase;

[0027] The module operation information is determined as target data and stored in the firmware storage area, or the target data in the firmware storage area is updated based on the module operation information.

[0028] The method further comprises:

[0029] In response to detecting a third target operation during the booting and loading of the operating system, shutting down the first model and running the operating system, wherein the third target operation represents a user instruction to shut down the first model;

[0030] In response to detecting a first target operation during the operating system running phase, calling a request interface to read target data from the firmware storage area;

[0031] reading second model data from a storage device;

[0032] The second model is run during the operating system running phase based on the target data and the second model data.

[0033] The method further comprises:

[0034] Based on the user's input, obtaining input data of the second model;

[0035] determining a response strategy based on the input data using the second model;

[0036] executing the response strategy, wherein the response strategy at least includes generating an output result and outputting the output result, wherein the output result is used to respond to the input data;

[0037] A storage interface is called to update target data in the firmware storage area based on the output result.

[0038] In another aspect, the present application provides an electronic device, comprising: a processor and a firmware storage area; the processor and the firmware storage area are electrically connected;

[0039] The processor is used to boot and load the operating system, and after detecting the first target operation, read the target data and the first model data from the firmware storage area, and run the first model in this stage;

[0040] The firmware storage area is used to store the target data and the first model data, where the target data includes device parameter data.

[0041] It should be understood that the content described in this section is not intended to identify the key or important features of the embodiments of the present application, nor is it intended to limit the scope of the present application. Other features of the present application will become easily understood through the following description. BRIEF DESCRIPTION OF THE DRAWINGS

[0042] The above and other objects, features and advantages of the exemplary embodiments of the present application will become readily understood by reading the detailed description below with reference to the accompanying drawings. In the accompanying drawings, several embodiments of the present application are shown in an exemplary and non-limiting manner, in which:

[0043] In the drawings, the same or corresponding reference numerals denote the same or corresponding parts.

[0044] Figure 1 A flow chart of a model loading method according to an embodiment of the present application is shown;

[0045] Figure 2 A schematic diagram showing multiple main stages after the electronic device is started up according to an embodiment of the present application;

[0046] Figure 3 A flow chart of a model loading method according to another embodiment of the present application is shown;

[0047] Figure 4 A flow chart of a model loading method according to another embodiment of the present application is shown;

[0048] Figure 5 A flow chart of a model loading method according to another embodiment of the present application is shown;

[0049] Figure 6 A flow chart of a model loading method according to another embodiment of the present application is shown;

[0050] Figure 7 A schematic diagram of a model interaction interface according to an embodiment of the present application is shown;

[0051] Figure 8 A flow chart of a model loading method according to another embodiment of the present application is shown;

[0052] Figure 9 A flow chart of a model loading method according to another embodiment of the present application is shown;

[0053] Figure 10 A flow chart of a model loading method according to another embodiment of the present application is shown;

[0054] Figure 11 A schematic diagram of the structure of an electronic device according to an embodiment of the present application is shown;

[0055] Figure 12 A schematic structural diagram of a model loading device according to an embodiment of the present application is shown. DETAILED DESCRIPTION

[0056] In order to make the purpose, features, and advantages of this application more obvious and easy to understand, the technical solutions in the embodiments of this application will be clearly and completely described below in conjunction with the drawings in the embodiments of this application. Obviously, the described embodiments are only part of the embodiments of this application, not all of the embodiments. Based on the embodiments in this application, all other embodiments obtained by those skilled in the art without making creative efforts shall fall within the scope of protection of this application.

[0057] In order to run the model in the BIOS environment based only on local data, an embodiment of the present application provides a model loading method, such as Figure 1As shown, the method includes:

[0058] Step 101 : In response to detecting a first target operation during the booting and loading of an operating system, target data and first model data are read from a firmware storage area, where the first target operation represents a user instruction to start a model.

[0059] There are several main stages between the electronic device starting up and entering the operating system, such as Figure 2 As shown, it includes the SEC stage (security verification stage), the PEI stage (hardware initialization stage), the DXE stage (driver startup stage), the BDS stage (boot management stage), the TLS stage (boot loading operating system stage) and the RT stage (operating system running stage). In this embodiment, the startup, operation and application of the first model are all carried out in the boot loading operating system stage.

[0060] When a first target operation is detected during the booting and loading operating system stage, target data and first model data are read from the firmware storage area.

[0061] In this embodiment, the first target operation is an operation in which the user indicates that the first model needs to be started. This can be the user clicking a button to start the first model, the user selecting an option to start the first model, or any other operation that can indicate that the first model needs to be started. The firmware storage area includes at least SPI ROM (serial external solid-state memory of an onboard chip such as BIOS, EC, or TPM), EEPROM memory (electrically erasable programmable read-only memory), or Flash memory (a type of non-volatile memory). The target data includes device parameter data, which includes hardware parameters, driver configuration parameters, etc. The first model data includes model architecture data and model parameters of the first model.

[0062] Step 102: Run a first model at this stage based on the target data and the first model data, wherein the target data includes device parameter data.

[0063] During the operating system booting phase, the first model is run based on the target data and the first model data. Based on the target data, the first model addresses user needs raised through interaction with the first model, such as problem consultation, parameter adjustment, fault diagnosis, fault repair, data erasure, and determining whether parameters have been tampered with.

[0064] In the above solution, the ability to run a model independent of the network and the cloud is achieved by reading the locally stored data during the booting and loading of the operating system stage. When the user's first target operation is detected during the booting and loading of the operating system stage, the system reads the target data and the first model data from the local firmware storage area of the device (both are stored locally on the device in a non-volatile form to ensure the independence of data access). Based on the above data, the system directly calls the hardware computing power to run the first model during the booting and loading of the operating system stage. Since the operation of the first model is completely dependent on the locally stored data and the device's own computing resources, no network communication or cloud interaction is required. This not only avoids network delays, service interruptions, and data leakage risks, but also ensures the anti-tampering capabilities of data and models through the security isolation mechanism of the firmware storage area (such as the protected partition in the SPI ROM).

[0065] In an example of this application, a model loading method is also provided, such as Figure 3 As shown, the method further includes:

[0066] Step 201: Based on user input, obtain input data of the first model.

[0067] After the first model is started and executed during the booting and loading of the operating system, the user can interact with the electronic device through input devices such as a keyboard and a mouse. Based on the interaction between the user and the electronic device, input data of the first model is obtained.

[0068] Step 202: Determine a response strategy based on the input data using the first model.

[0069] The first model determines a response strategy based on the user's input data. For example, if the input data is a question inquiry, the response strategy is to answer the user's question. For another example, if the input data is a parameter adjustment, the response strategy is to adjust the user's parameter. For another example, if the input data is a fault diagnosis, the response strategy is to perform a fault diagnosis on the current device status based on the target data and output the diagnosis results to the user.

[0070] Step 203: executing the response strategy, wherein the response strategy at least includes generating an output result and outputting the output result, wherein the output result is used to respond to the input data.

[0071] After determining the response strategy, execute it. This response strategy at least involves generating and delivering output to the user in response to the user's input. Outputs can include answers to user questions, feedback on user requests and resolutions, and so on.

[0072] In this solution, the first model is run on locally stored data during the operating system boot phase. This model then uses user input to perform tasks such as problem consultation, fault diagnosis, security verification, or configuration optimization. This allows risk interception and decision-making before the operating system boots. This approach eliminates the need for network or cloud involvement, further minimizing the risks of network latency, service interruptions, and data leakage.

[0073] In an example of this application, a model loading method is also provided, such as Figure 4 As shown, executing the reply strategy includes:

[0074] Step 301: Generate parameter adjustment data based on the input data and the output result using the first model.

[0075] For example, when the user starts and runs the first model during the boot loading operating system stage, and inputs the input data of "overclocking the CPU to 2.8GHz" into the first model, the first model obtains the device parameters in the target data to determine that the current CPU frequency is 2.5GHz, and then generates parameter adjustment data to adjust the CPU frequency from 2.5GHz to 2.8GHz.

[0076] Step 302: Store the parameter adjustment data into the firmware storage area, where the parameter adjustment data is used to adjust the first parameter of the device when the device is started next time.

[0077] Continuing with the above example, the generated parameter adjustment data is stored in the firmware storage area. When the electronic device is cold-started to the hardware initialization stage next time, the parameter adjustment data in the firmware storage area is detected, and the CPU configuration parameters are set to 2.8 GHz when the CPU is initialized.

[0078] It should be noted that the parameter adjustment data can also be stored as target data in the firmware storage area, and can serve as the data basis for responses when inquiries or other needs are related to the parameter adjustment data.

[0079] Because the first model runs during the operating system booting and loading phase, some parameters that users need to modify cannot be hot-modified during this phase (i.e., they cannot be modified and take effect during this phase). Therefore, in the above solution, the parameter adjustment logic for non-hot-modifiable parameters (such as CPU frequency, memory timing, etc.) is stored in the firmware storage area, and the parameter adjustment data in the firmware storage area is preferentially loaded during the corresponding phase of the device's next cold start, thereby completing the parameter adjustment.

[0080] In an example of the present application, a model loading method is also provided, the method further comprising:

[0081] In response to detecting that parameter adjustment data belonging to the target phase exists in the firmware storage area during the target phase, a first parameter of the device is adjusted based on the parameter adjustment data. The target phase includes at least a hardware initialization phase and a driver startup phase.

[0082] For example, when the electronic device starts up and reaches the hardware initialization stage, it is detected that a parameter adjustment data is stored in the firmware storage area, and the parameter adjustment data indicates that the CPU frequency is set to 2.8 GHz. When the CPU is initialized, the CPU configuration parameters are set to the frequency of 2.8 GHz.

[0083] It should be noted that during the hardware initialization phase, hardware parameter adjustments require calling the PEI agent. During the driver startup phase, hardware parameter adjustments also require calling the DXE agent.

[0084] In the above solution, during each initialization phase of the electronic device's startup, the firmware storage area is checked for parameter adjustment data for the current phase. If so, the parameters are adjusted based on the parameter adjustment data. This mechanism effectively avoids the risk of transient state conflicts or physical damage that may be caused by dynamic adjustments in other phases. At the same time, through secure storage at the firmware layer and closed-loop write operations during the startup phase, the parameter modification process is protected from interference from the operating system environment or network attacks, ultimately optimizing the hardware configuration while improving system stability.

[0085] In an example of the present application, a model loading method is further provided, wherein executing the reply strategy includes:

[0086] A fault consequence is determined using the first model based on the target data, the target data also including module operation data.

[0087] The target data also includes module operation data, such as computing unit operation data (such as the frequency, temperature, voltage, etc. of CPU, GPU, TPU and other computing units), memory operation data (such as memory bandwidth utilization, delay parameters, refresh frequency, etc.), power supply operation data (such as input voltage, output voltage, etc.), etc.

[0088] When the user requires the first model to perform fault diagnosis, the first model diagnoses the current state of the device based on the device parameters and module operation data in the target data to determine whether the device has a fault.

[0089] Among them, Figure 5 As shown, executing a corresponding repair strategy based on the type of the fault result includes:

[0090] Step 401: If the fault result is of the first type, parameter adjustment data is generated based on the fault result and stored in the firmware storage area, so that the first parameter of the device is adjusted at the next startup to fix the fault.

[0091] If a fault is determined to exist and is determined to be the first type of fault based on the fault result, it means that the fault can be repaired by adjusting parameters. For example, if a system crash is caused by CPU or memory overclocking, the fault can be modified by lowering the CPU or memory frequency.

[0092] Step 402: If the fault result is of the second type, generate a repair suggestion based on the fault result, and output the repair suggestion to the user.

[0093] If a fault is determined to exist and is determined to be a second type of fault based on the fault result, it means that the fault cannot be repaired by adjusting parameters. For example, if the operating system cannot run due to bad sectors on the hard disk, a repair suggestion of replacing the hard disk will be output to the user.

[0094] In the above solution, when it is determined that the fault can be repaired by adjusting the parameters, parameter adjustment data is generated and stored in the firmware storage area to ensure that it is loaded and takes effect at the corresponding stage of the next cold start of the device, thereby achieving fault repair. For faults that cannot be repaired by adjusting the parameters (such as physical damage or irreversible errors in the firmware), the system generates actionable repair suggestions based on the target data (such as replacing a specified hardware module or upgrading the firmware version), outputs the repair suggestions to the user, and guides the user to quickly locate the source of the fault and take targeted measures. The self-healing capability of repairable faults is achieved, and the user's troubleshooting costs in unrepairable scenarios are reduced, reducing the user's trial and error operations, and ultimately achieving fault detection, decision diversion and fault repair, significantly improving the maintenance efficiency of the equipment and the availability of the system.

[0095] In an example of this application, a model loading method is also provided, such as Figure 6 As shown, executing the reply strategy includes:

[0096] Step 501: Obtain current device parameter data.

[0097] Step 502: Determine a judgment result based on the target data and the current device parameter data using the first model, where the target data also includes log data.

[0098] For example, Figure 7 As shown, Figure 7This is the user's interactive interface with the first model after it has been launched and is running during the operating system boot phase. The user enters input data into the first model to "check if firmware parameters have been tampered with." The first model then retrieves the device parameter data and log data from the target data. Based on the current device parameter data, the device parameter data from the target data, and the log data, the first model determines whether the CPU voltage configuration has been tampered with.

[0099] Step 503: Output the judgment result to the user, where the judgment result indicates whether the device parameters have been tampered with.

[0100] Following the above example, Figure 6 As shown, after determining that the CPU voltage configuration has been tampered with, the first model outputs a judgment result to the user, which includes an alarm prompt and a repair suggestion. The repair suggestion is "Please use a trusted recovery image to roll back the configuration."

[0101] In the above solution, the first model is used to analyze the current device parameter data for tampering based on the device parameter data and log data in the firmware storage area, generating a reliable judgment result. If the parameter is determined to be abnormal, the judgment result is output to the user, including a warning prompt and remediation suggestions (such as rollback or safe boot). This mechanism leverages the data isolation of the firmware layer and the reasoning power of the first model to accurately determine whether the device parameters have been tampered with, thereby improving device security.

[0102] In an example of this application, a model loading method is also provided, such as Figure 8 As shown, the method further includes:

[0103] Step 601: In response to completion of a target phase, module operation information of the target phase is obtained. The target phase at least includes a hardware initialization phase and a driver startup phase.

[0104] For example, after the hardware initialization phase of device startup is complete, module operation information for that phase is obtained, including the CPU temperature of 65°C, normal memory operation status, and fan speed of 1200 rpm. Also, after the driver startup phase of device startup is complete, module operation information for that phase is obtained, including the NVMe driver version 1.4.0, interrupt affinity configured to CPU Core 2, and DMA buffer allocation address 0x7F800000.

[0105] Step 602: Determine the module operation information as target data and store it in the firmware storage area, or update the target data in the firmware storage area based on the module operation information.

[0106] After the hardware initialization phase is completed, module operation information of that phase is obtained, and target data in the firmware storage area is updated based on the module operation information. And after the driver startup phase is completed, module operation information of that phase is obtained, and target data in the firmware storage area is updated based on the module operation information.

[0107] In this embodiment, the update method may be to convert the module operation information into log data and add it to the log data of the target data. Alternatively, the device parameter data of the target data may be updated based on some information in the module operation information. Alternatively, the module operation information may be directly added to the target data. In other embodiments, the target data may be updated based on the module operation information using any other method.

[0108] In the above solution, a dynamic target data update mechanism is established by obtaining module operation information at key stages of device startup (such as hardware initialization and driver startup). This mechanism can convert module operation data into target data logs and store them in the firmware storage area, or increment or optimize existing target data based on preset rules. This allows target data to be updated during each startup process, providing a traceable data foundation for long-term operation.

[0109] In an example of this application, a model loading method is also provided, such as Figure 9 As shown, the method further includes:

[0110] Step 701: In response to detecting a third target operation during the booting and loading of an operating system, the first model is closed and the operating system is run. The third target operation represents a user instruction to close the first model.

[0111] When the third target operation is detected during the stage of booting and loading the operating system, the first model is closed and the operating system is run and entered.

[0112] In this embodiment, the third target operation is an operation in which the user indicates that the first model needs to be closed, which may be the user clicking a button to close the first model, the user selecting an option to close the first model, or any other operation that can indicate that the first model needs to be closed.

[0113] Step 702 : In response to detecting a first target operation during the operating system running phase, calling a request interface to read target data from the firmware storage area.

[0114] Step 703: Read the second model data from the storage device.

[0115] Step 704: Run the second model during the operating system running phase based on the target data and the second model data.

[0116] When the first target operation is detected during the operating system operation phase, the request interface is called to read the target data from the firmware storage area and the second model data from the storage device, and then the second model is run based on the target data and the second model data.

[0117] In this embodiment, the storage device includes at least a solid-state drive, a mechanical hard drive, or a memory card. The firmware storage area also includes at least an SPI ROM (a serial external solid-state memory on an onboard chip such as a BIOS, EC, or TPM), an EEPROM (electrically erasable programmable read-only memory), or a Flash memory (a type of non-volatile memory). The target data also includes device parameter data, which includes hardware parameters, driver configuration parameters, etc. The second model data includes model architecture data and model parameters of the second model.

[0118] Similarly, the second model can be the same as or different from the first model, but the second model can also solve the needs raised by users through interaction with the second model based on the target data, such as problem consultation, parameter adjustment, fault diagnosis, fault repair, data erasure, and determining whether parameters have been tampered with.

[0119] Since the operating system cannot directly read data from the firmware storage area during the operating system's runtime, in order to share the same target data with the first model, the above solution, upon detecting the user's third target operation during the operating system boot-up phase, shuts down the first model, runs and enters the operating system, then calls a request interface to read the target data from the device's local firmware storage area and the second model data from the storage device. Based on this data, the second model runs during the operating system's runtime phase. This achieves the ability to run the model independently of network and cloud dependencies while sharing the same target data as the first model.

[0120] In an example of this application, a model loading method is also provided, such as Figure 10 As shown, the method further includes:

[0121] Step 801: Based on user input, obtain input data of the second model.

[0122] Similarly, after the second model is started and run during the operating system running phase, the user can interact with the electronic device through input devices such as a keyboard and a mouse. Based on the interaction between the user and the electronic device, input data of the second model is obtained.

[0123] Step 802: Determine a response strategy based on the input data using the second model.

[0124] Similarly, the second model determines a response strategy based on the user's input data. For example, if the input data is a question inquiry, the response strategy is to answer the user's question. For another example, if the input data is a parameter adjustment, the response strategy is to adjust the parameter requested by the user. For another example, if the input data is a fault diagnosis, the response strategy is to perform a fault diagnosis on the current state of the device based on the target data and output the diagnosis results to the user.

[0125] Step 803: executing the response strategy, wherein the response strategy at least includes generating an output result and outputting the output result, wherein the output result is used to respond to the input data.

[0126] After determining the response strategy, execute it. This response strategy at least involves generating and delivering output to the user in response to the user's input. Outputs can include answers to user questions, feedback on user requests and resolutions, and so on.

[0127] Step 804: calling a storage interface to update target data in the firmware storage area based on the output result.

[0128] After addressing the user's needs, the storage interface can be called to update the target data in the firmware storage area based on the output results. For example, log data in the target data can be generated based on the output results and stored in the firmware storage area, or the target data in the firmware storage area can be incremented or optimized based on the output results.

[0129] In the above solution, during the operating system's runtime, the system calls a request interface to read the locally stored target data and the second model data stored in the storage device, runs the second model, and then uses the second model to perform tasks such as problem consultation, fault diagnosis, security verification, or configuration optimization based on the user's input data. This eliminates the need for network or cloud involvement, thus avoiding network latency, service interruptions, and the risk of data leakage. Furthermore, after addressing the user's needs, the system can generate log data from the target data based on the output results and store it in the firmware storage area. Alternatively, the target data in the firmware storage area can be incremented or optimized based on the output results, thereby providing a traceable data foundation for the long-term operating environment.

[0130] An example of the present application provides an electronic device, Figure 11 A schematic block diagram of an example electronic device 900 is shown, which may be used to implement embodiments of the present disclosure.

[0131] like Figure 11 As shown, the electronic device 900 includes a processor 901 and a firmware storage area 902; the processor 901 and the firmware storage area 902 are electrically connected;

[0132] The processor 901 is used to boot and load the operating system, and after detecting the first target operation, reads the target data and the first model data from the firmware storage area 902, and runs the first model in this stage;

[0133] The firmware storage area 902 is used to store the target data and the first model data, where the target data includes device parameter data.

[0134] In which, the processor 901 is used to obtain input data of the first model based on user input; use the first model to determine a response strategy based on the input data; and execute the response strategy, which at least includes generating an output result and outputting the output result, and the output result is used to respond to the input data.

[0135] The processor 901 is used to generate parameter adjustment data based on the input data and the output result using the first model; and store the parameter adjustment data in the firmware storage area 902, and the parameter adjustment data is used to adjust the first parameter of the device at the next startup.

[0136] In which, the processor 901 is used to adjust the first parameter of the device based on the parameter adjustment data in response to detecting the presence of parameter adjustment data belonging to the target stage in the firmware storage area in the target stage, and the target stage at least includes a hardware initialization stage and a driver startup stage.

[0137] The processor 901 is configured to determine a fault result based on the target data using the first model, where the target data further includes module operation data;

[0138] The processor 901 is also used to, when the fault result is of the first type, generate parameter adjustment data based on the fault result and store it in the firmware storage area, so that the first parameter of the device can be adjusted to repair the fault at the next startup; and when the fault result is of the second type, generate a repair suggestion based on the fault result and output the repair suggestion to the user.

[0139] Among them, the processor 901 is used to obtain current device parameter data; use the first model to determine a judgment result based on the target data and the current device parameter data, and the target data also includes log data; and output the judgment result to the user, and the judgment result represents whether the device parameters have been tampered with.

[0140] The processor 901 is used to obtain module operation information of the target stage in response to completion of the target stage, where the target stage at least includes a hardware initialization stage and a driver startup stage; and determine the module operation information as target data and store it in the firmware storage area 902, or update the target data in the firmware storage area 902 based on the module operation information.

[0141] In which, the processor 901 is used to, in response to detecting a third target operation during the boot loading operating system stage, shut down the first model and run the operating system, where the third target operation represents a user instruction to shut down the first model; in response to detecting the first target operation during the operating system running stage, call a request interface to read target data from the firmware storage area 902; read second model data from a storage device; and run the second model during the operating system running stage based on the target data and the second model data.

[0142] Among them, the processor 901 is used to obtain input data of the second model based on user input; use the second model to determine a reply strategy based on the input data; execute the reply strategy, and the reply strategy at least includes generating an output result and outputting the output result, and the output result is used to respond to the input data; and call the storage interface to update the target data in the firmware storage area 902 based on the output result.

[0143] In order to implement the above model loading method, such as Figure 12 As shown, an example of the present application provides a model loading device, comprising:

[0144] The processing module 1001 is configured to read target data and first model data from a firmware storage area in response to detecting a first target operation during the booting and loading of an operating system, wherein the first target operation represents a user instruction to start a model;

[0145] The calculation module 1002 is configured to run the first model at this stage based on the target data and the first model data, wherein the target data includes device parameter data.

[0146] The processing module 1001 is further configured to obtain input data of the first model based on user input;

[0147] The calculation module 1002 is further configured to determine a response strategy based on the input data using the first model; and execute the response strategy, wherein the response strategy at least includes generating an output result and outputting the output result, wherein the output result is used to respond to the input data.

[0148] The calculation module 1002 is further configured to generate parameter adjustment data based on the input data and the output result using the first model;

[0149] The processing module 1001 is further configured to store the parameter adjustment data into the firmware storage area, where the parameter adjustment data is used to adjust the first parameter of the device during the next startup.

[0150] In which, the processing module 1001 is also used to adjust the first parameter of the device based on the parameter adjustment data in response to detecting that there is parameter adjustment data belonging to the target stage in the firmware storage area in the target stage, and the target stage at least includes a hardware initialization stage and a driver startup stage.

[0151] The calculation module 1002 is further configured to determine a fault result based on the target data using the first model, wherein the target data further includes module operation data;

[0152] The processing module 1001 is further configured to, when the fault result is of the first type, generate parameter adjustment data based on the fault result and store the data in the firmware storage area, so that the first parameter of the device is adjusted to fix the fault at the next startup;

[0153] The processing module 1001 is further configured to generate a repair suggestion based on the fault result when the fault result is of the second type, and output the repair suggestion to the user.

[0154] The processing module 1001 is further configured to obtain current device parameter data;

[0155] The calculation module 1002 is further configured to use the first model to determine a judgment result based on the target data and the current device parameter data, wherein the target data further includes log data;

[0156] The processing module 1001 is further configured to output the judgment result to the user, where the judgment result indicates whether the device parameters have been tampered with.

[0157] The processing module 1001 is further configured to obtain module operation information of the target phase in response to completion of the target phase, wherein the target phase includes at least a hardware initialization phase and a driver startup phase;

[0158] The processing module 1001 is further configured to determine the module operation information as target data and store it in the firmware storage area, or update the target data in the firmware storage area based on the module operation information.

[0159] The processing module 1001 is further configured to, in response to detecting a third target operation during the booting and loading of the operating system, shut down the first model and run the operating system, wherein the third target operation represents a user instruction to shut down the first model;

[0160] The processing module 1001 is further configured to, in response to detecting a first target operation during the operating system running phase, call a request interface to read target data from the firmware storage area;

[0161] The processing module 1001 is further configured to read the second model data from the storage device;

[0162] The calculation module 1002 is further configured to run a second model during the operating system running phase based on the target data and the second model data.

[0163] The processing module 1001 is further configured to obtain input data of the second model based on user input;

[0164] The calculation module 1002 is further configured to determine a response strategy based on the input data using the second model;

[0165] The calculation module 1002 is further configured to execute the response strategy, wherein the response strategy at least includes generating an output result and outputting the output result, wherein the output result is used to respond to the input data;

[0166] The processing module 1001 is further configured to call a storage interface and update target data in the firmware storage area based on the output result.

[0167] Various embodiments of the systems and techniques described above can be implemented in digital electronic circuit systems, integrated circuit systems, field programmable gate arrays (FPGAs), application specific integrated circuits (ASICs), application specific standard products (ASSPs), systems on a chip (SOCs), complex programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments can include being implemented in one or more computer programs that are executable and / or interpreted on a programmable system that includes at least one programmable processor, which can be a special purpose or general purpose programmable processor that can receive data and instructions from a storage system, at least one input device, and at least one output device, and transmit data and instructions to the storage system, the at least one input device, and the at least one output device.

[0168] The program code for implementing the method of the present disclosure can be written in any combination of one or more programming languages. These program codes can be provided to a processor or controller of a general-purpose computer, a special-purpose computer, or other programmable data processing device so that when the program code is executed by the processor or controller, the functions / operations specified in the flow chart and / or block diagram are implemented. The program code can be executed entirely on the machine, partially on the machine, as a stand-alone software package, partially on the machine and partially on a remote machine, or entirely on a remote machine or server.

[0169] In the context of the present disclosure, a machine-readable medium can be a tangible medium that can contain or store a program for use by or in conjunction with an instruction execution system, device or equipment. A machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. A machine-readable medium can include, but is not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, device or equipment, or any suitable combination of the foregoing. A more specific example of a machine-readable storage medium can include an electrical connection based on one or more lines, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing.

[0170] To provide interaction with a user, the systems and techniques described herein can be implemented on a computer having: a display device (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for displaying information to the user; and a keyboard and pointing device (e.g., a mouse or trackball) through which the user can provide input to the computer. Other types of devices can also be used to provide interaction with the user; for example, the feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including acoustic input, voice input, or tactile input).

[0171] The systems and techniques described herein can be implemented in a computing system that includes back-end components (e.g., as a data server), or a computing system that includes middleware components (e.g., an application server), or a computing system that includes front-end components (e.g., a user computer having a graphical user interface or a web browser through which a user can interact with implementations of the systems and techniques described herein), or a computing system that includes any combination of such back-end components, middleware components, or front-end components. The components of the system can be interconnected by any form or medium of digital data communication (e.g., a communication network). Examples of communication networks include a local area network (LAN), a wide area network (WAN), and the Internet.

[0172] A computer system may include a client and a server. The client and server are generally remote from each other and typically interact through a communication network. The client-server relationship arises through computer programs running on the respective computers and having a client-server relationship with each other. The server may be a cloud server, a server in a distributed system, or a server integrated with a blockchain.

[0173] It should be understood that the various forms of the processes shown above can be used to reorder, add, or delete steps. For example, the steps described in this disclosure can be performed in parallel, sequentially, or in a different order, as long as the desired results of the technical solutions disclosed in this disclosure can be achieved. This is not a limitation herein.

[0174] Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features being referred to. Thus, a feature defined as "first" or "second" may explicitly or implicitly include at least one such feature. Throughout the present disclosure, "plurality" means two or more, unless otherwise specifically defined.

[0175] The above description is merely a specific embodiment of the present disclosure, but the scope of protection of the present disclosure is not limited thereto. Any changes or substitutions that can be easily conceived by a person skilled in the art within the technical scope disclosed in this disclosure should be included in the scope of protection of the present disclosure. Therefore, the scope of protection of the present disclosure should be based on the scope of protection of the claims.

Claims

1. A model loading method, comprising: In response to detecting a first target operation during the booting and loading of the operating system, reading target data and first model data from the firmware storage area, wherein the first target operation represents a user instruction to start the model; A first model is run at this stage based on the target data and the first model data, the target data including device parameter data.

2. The method according to claim 1, further comprising: Based on user input, obtaining input data of the first model; determining a response strategy based on the input data using the first model; The response strategy is executed, where the response strategy at least includes generating an output result and outputting the output result, where the output result is used to respond to the input data.

3. The method according to claim 2, wherein executing the response strategy comprises: generating parameter adjustment data based on the input data and the output result using the first model; The parameter adjustment data is stored in the firmware storage area, and the parameter adjustment data is used to adjust the first parameter of the device when it is started next time.

4. The method according to claim 3, further comprising: In response to detecting that parameter adjustment data belonging to the target phase exists in the firmware storage area during the target phase, a first parameter of the device is adjusted based on the parameter adjustment data. The target phase includes at least a hardware initialization phase and a driver startup phase.

5. The method according to claim 2, wherein executing the response strategy comprises: determining a fault result based on the target data using the first model, the target data also including module operation data; Executing a corresponding repair strategy based on the type of the fault result includes: If the fault result is of the first type, generating parameter adjustment data based on the fault result and storing the data in the firmware storage area, so that the first parameter of the device is adjusted to fix the fault when the device is started next time; If the fault result is of the second type, a repair suggestion is generated based on the fault result, and the repair suggestion is output to the user.

6. The method according to claim 2, wherein executing the response strategy comprises: Get current device parameter data; Determining a judgment result based on the target data and the current device parameter data using the first model, wherein the target data also includes log data; The judgment result is output to the user, where the judgment result indicates whether the device parameters have been tampered with.

7. The method according to claim 1, further comprising: In response to completion of a target phase, obtaining module operation information of the target phase, the target phase including at least a hardware initialization phase and a driver startup phase; The module operation information is determined as target data and stored in the firmware storage area, or the target data in the firmware storage area is updated based on the module operation information.

8. The method according to claim 1, further comprising: In response to detecting a third target operation during the booting and loading of the operating system, shutting down the first model and running the operating system, wherein the third target operation represents a user instruction to shut down the first model; In response to detecting a first target operation during the operating system running phase, calling a request interface to read target data from the firmware storage area; reading second model data from a storage device; The second model is run during the operating system running phase based on the target data and the second model data.

9. The method according to claim 8, further comprising: Based on the user's input, obtaining input data of the second model; determining a response strategy based on the input data using the second model; executing the response strategy, wherein the response strategy at least includes generating an output result and outputting the output result, wherein the output result is used to respond to the input data; A storage interface is called to update target data in the firmware storage area based on the output result.

10. An electronic device comprising: Processor and firmware storage area; The processor is electrically connected to the firmware storage area; The processor is used to boot and load the operating system, and after detecting the first target operation, read the target data and the first model data from the firmware storage area, and run the first model in this stage; The firmware storage area is used to store the target data and the first model data, where the target data includes device parameter data.

Images