Simulated start method and related devices

Abstract

The application provides a simulation starting method and related equipment, including: calling QEMU to obtain a starting command, including a first starting mode; in the instantiation stage of the starting controller in the QEMU, calling the starting controller to parse the first starting mode into a first starting address, and the instantiation stage is located in the process of initializing a virtual machine by the QEMU; calling the starting controller to control the processor to start a first boot program from the first starting address. It can be seen that the embodiment of the application allows only the starting mode to be specified in the command, and the starting controller implemented in the QEMU parses the starting mode into the starting address to start the boot program from the starting address. In this way, the user inputs less information, reduces the probability of user input information error and the operation complexity of the user, and further reduces the starting failure rate.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a simulated boot method and related equipment. Background Technology

[0002] QEMU (Quick Emulator) is a processor emulation software. In a QEMU-based RISC-V (Reduced Instruction Set Computer-Five) architecture virtualization simulation environment, users typically need to simulate the processor's boot process under different boot modes to verify firmware, bootloaders, or operating systems. For example, boot modes can be Flash boot mode, ROM (Read-Only Memory) boot mode, etc. Flash boot mode means the boot source is Flash, and ROM boot mode means the boot source is ROM.

[0003] In existing technologies, there are two common approaches to the boot process of QEMU emulating a processor under different boot modes. The first common approach is to modify the hard-coded boot address in the QEMU source code, with different hard-coded boot addresses corresponding to different boot modes. The second common approach is to manually specify the boot address, firmware, and other information using the instruction `-device loader`.

[0004] However, both of these methods are complex and have a high failure rate. Summary of the Invention

[0005] This application provides a simulated startup method and related equipment to solve problems in related technologies.

[0006] In a first aspect, embodiments of this application provide a simulated boot method, comprising: calling QEMU to obtain a boot command, the boot command including a first boot mode; during the instantiation phase of the boot controller in the fast emulator QEMU, calling the boot controller to resolve the first boot mode into a first boot address, the instantiation phase being located during the QEMU virtual machine initialization process, the boot controller registering through the QEMU object model; and calling the boot controller to control the processor to start a first boot program from the first boot address.

[0007] Secondly, embodiments of this application provide a simulated startup device, comprising: The command acquisition module is used to call QEMU to obtain the startup command, which includes: the first startup mode.

[0008] The parsing module is used in the instantiation phase of the startup controller in the QEMU fast simulator to call the startup controller to parse the first startup mode into the first startup address. The instantiation phase is located during the QEMU virtual machine initialization process, and the startup controller is registered through the QEMU object model.

[0009] The startup module is used to call the startup controller to control the processor to start the first boot program from the first startup address.

[0010] Thirdly, embodiments of this application provide an electronic device, including: a processor and a memory for storing processor-executable instructions; wherein the processor is configured to execute the instructions to implement the simulated boot method as described above.

[0011] Fourthly, embodiments of this application also provide a computer-readable storage medium that, when the instructions in the computer-readable storage medium are executed by a processor of an electronic device, enables the electronic device to perform the aforementioned simulated startup method.

[0012] Fifthly, embodiments of this application also provide a computer program product, including a computer program that, when executed by a processor, is used to implement the above-described simulated startup method.

[0013] In this embodiment, QEMU is invoked to obtain a startup command. The startup command includes: invoking a first startup mode in QEMU; during the instantiation phase of the startup controller in QEMU, the startup controller resolves the first startup mode to a first startup address. The instantiation phase occurs during the QEMU virtual machine initialization process, and the startup controller registers through the QEMU Object Model (QOM); the startup controller then controls the processor to start the first bootloader from the first startup address. It can be seen that this embodiment allows specifying only the startup mode in the command, with the startup controller implemented in QEMU resolving the startup mode to a startup address to start the bootloader from that address. This reduces user input, lowers the probability of incorrect user input, and reduces user operational complexity, thereby reducing the startup failure rate. Furthermore, the bootloader can be directly compiled into the QEMU executable file, eliminating the need for the user to provide an additional bootloader, further reducing user operational complexity and costs.

[0014] The above description is only an overview of the technical solution of this application. In order to better understand the technical means of this application, it can be implemented according to the contents of the specification. In order to make the above and other objects, features and advantages of this application more obvious and understandable, the following are specific embodiments of this application. Attached Figure Description

[0015] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0016] Figure 1 This is a schematic diagram of an application scenario provided by an embodiment of this application; Figure 2 This is a flowchart illustrating the steps of a simulated startup method provided in an embodiment of this application; Figure 3 This is a flowchart of another simulated startup method provided in an embodiment of this application; Figure 4 This is a schematic diagram of the structure of a simulated start-up device provided in an embodiment of this application; Figure 5 This is a schematic diagram of another simulated start-up device provided in an embodiment of this application; Figure 6 This is a schematic diagram of the structure of a first electronic device provided in an embodiment of this application; Figure 7 This is a schematic diagram of the structure of a second electronic device provided in an embodiment of this application. Detailed Implementation

[0017] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0018] The terms "first," "second," etc., used in the specification and claims of this application are used to distinguish similar objects and not to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that embodiments of this application can be implemented in orders other than those illustrated or described herein, and the objects distinguished by "first," "second," etc., are generally of the same class and are not limited in number; for example, a first object can be one or more. Furthermore, the term "and / or" in the specification and claims is used to describe the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A alone, A and B simultaneously, and B alone. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship. In the embodiments of this application, the term "multiple" refers to two or more, and other quantifiers are similar.

[0019] The embodiments of this application are applicable to QEMU to simulate the startup process of the processor in different startup modes. Figure 1 This is a schematic diagram illustrating an application scenario of an embodiment of this application, with reference to... Figure 1 As shown, one or more virtual machines can run on the host machine, and a fast emulator can run on each virtual machine to perform simulations. Figure 1 Two virtual machines 11 and 12 are provided as an example, on which fast emulator 111 and fast emulator 121 are run respectively.

[0020] One approach involves modifying the hard-coded QEMU boot address to enable booting from different boot modes. This approach requires modifying the QEMU code and is therefore quite complex.

[0021] In another approach, the boot address, firmware, and other information are specified via the `-device loader` command to enable booting in different boot modes. For example, the following command can be used to boot from ROM: The command `qemu-system-riscv64-machine bosc-kmh –device loader,file=rom.bin,addr=0x1000,cpu-num=0 –S -bios fw_payload.bin` boots from Flash memory using the following command: `qemu-system-riscv64 –machine bosc-kmh -device loader,file=flash.bin,addr=0x10000000,cpu-num=0 -S -bios fw_payload.bin`.

[0022] As can be seen, the commands differ depending on the boot mode, and these commands require numerous user input parameters, resulting in high complexity. Examples include the ROM start address or Flash start address, the debug flag "-S", the firmware image "rom.bin" or "flash.bin", and the program counter (PC) for controlling the processor initialization. Therefore, the probability of incorrect parameter specification is high, leading to a high boot failure rate.

[0023] To address the aforementioned technical issues, embodiments of this application allow specifying only the boot mode in the command. The boot controller implemented in QEMU resolves the boot mode into a boot address, from which the bootloader is started. Users do not need to modify the QEMU source code or maintain multiple boot scripts; input is minimal, and boot mode switching can be achieved through concise and semantically clear commands. This reduces the probability of user input errors and operational complexity, thereby lowering the boot failure rate. Furthermore, the bootloader can be directly compiled into the QEMU executable file, eliminating the need for users to provide an additional bootloader. This further reduces user operational complexity and costs.

[0024] The aforementioned boot controller is located in QEMU. Therefore, QEMU itself provides the function of switching between different boot modes, while the native QEMU in the prior art does not have this function.

[0025] For example, Figure 1 A startup controller can be set in any of the fast emulators in any virtual machine.

[0026] The technical solution of this application and how the technical solution of this application solves the above-mentioned technical problems are described in detail below with specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments. The embodiments of this application will be described below with reference to the accompanying drawings.

[0027] Figure 2 This is a flowchart illustrating the steps of a simulated startup method provided in an embodiment of this application, as follows: Figure 2 As shown, the method includes: S101. Call the fast emulator to obtain the startup command, which includes: the first startup mode.

[0028] S102. In the instantiation phase of the start controller in the fast emulator, the start controller is called to resolve the first start mode into the first start address. The instantiation phase is located during the process of the fast emulator initializing the virtual machine.

[0029] The startup controller is registered through the object model of the fast simulator.

[0030] S103. Call the boot controller to control the processor to start the first boot program from the first boot address.

[0031] The above boot command instructs the bootloader to start from the boot source corresponding to the first boot mode. The bootloader is the program that boots the operating system; it can also be called firmware. For example, BIOS (Basic Input Output System) is a conventional bootloader.

[0032] In one implementation, the user can manually enter the boot command via an input device. For example, the user can directly enter: qemu-system-riscv64 -machine bosc-kmh -hw-switch,boot=rom -bios fw_payload.bin as the boot command. Here, boot=rom indicates that the first boot mode is ROM boot mode, meaning the bootloader is started from ROM.

[0033] In another implementation, the user can operate the target switch to switch its state, and QEMU can generate the aforementioned startup commands, including different first startup modes, based on the target switch's state. Specifically, obtaining the startup command includes: obtaining the current state of the target switch; determining the first startup mode based on the current state, with different first startup modes corresponding to different target switch states; and generating the startup command based on the first startup mode.

[0034] The target switch mentioned above can be a physical switch or a virtual switch; this application embodiment does not limit the form of the switch. The current state of the target switch can be the default state, and the user can also switch the current state of the target switch. For example, when the current state of the target switch is the first state, the first boot mode can be the ROM boot mode, and the generated boot command is: qemu-system-riscv64 -machine bosc-kmh -hw-switch,boot=rom -bios fw_payload.bin; when the current state of the target switch is the second state, the first boot mode can be Flash, and the generated boot command is: qemu-system-riscv64 -machine bosc-kmh -hw-switch,boot=flash -bios fw_payload.bin, to instruct the bootloader to be started from Flash.

[0035] As can be seen, the embodiments of this application can achieve the switching of the current state by switching the target switch, and the switching is implemented in the form of a switch, similar to a DIP switch or jumper cap, which conforms to the semantics of hardware abstraction. Users only need to operate the target switch and do not need to input complex commands, which helps to further reduce the complexity of user operation.

[0036] The mapping relationship between the current state and the first startup mode is preset and can be flexibly set according to the actual scenario.

[0037] Upon receiving the aforementioned boot command, QEMU begins initializing its virtual machine. The virtual machine initialization phase includes the instantiation phase of the boot controller (hw-switch). The boot controller can be understood as a virtual device used to switch boot modes. The boot controller has a configurable attribute `boot`, set by the first boot mode in the boot command. In this embodiment, during the boot controller instantiation phase, the boot controller enables the bootloader to start from the first boot mode. Specifically, the boot controller needs to resolve the first boot mode to a first boot address, which is the physical address of the boot source for the first boot mode. Different first boot modes correspond to different first boot addresses. For example, when the first boot mode is ROM, the first boot address is the starting address of the boot source ROM, 0x1000; when the second boot mode is Flash, the first boot address is the starting address of the boot source Flash, 0x10000000.

[0038] In one possible implementation, the boot controller can record the mapping relationship between the second boot mode and the second boot address. Upon receiving the first boot address, the first boot mode is matched against each of the second boot modes in the mapping relationship. When the first boot mode successfully matches one of the second boot modes, the second boot address corresponding to that second boot mode recorded in the mapping relationship can be used as the first boot address.

[0039] The above mapping relationship can be a list of correspondences between multiple second boot modes and multiple second boot addresses.

[0040] In another possible implementation, resolving the first boot mode to the first boot address includes: reading the mapping relationship between the second boot mode and the second boot address from the configuration file; and querying the first boot address corresponding to the first boot mode from the mapping relationship.

[0041] The mapping relationships described above are configured in the configuration file; therefore, updating the configuration file updates the mapping relationships. Compared to the mapping relationships residing in the boot controller, updating the configuration file does not require recompilation, thus quickly applying the updated mapping relationships and improving update efficiency. It can be understood that a second boot mode existing in the configuration file is a boot mode that the boot controller supports switching between; a boot mode not existing in the configuration file is a boot mode that the boot controller does not support switching between. For example, the configuration file may contain two mapping relationships: a mapping between the second boot mode ROM and the second boot address 0x1000, and a mapping between the second boot mode Flash and the second boot address 0x10000000. Therefore, the boot controller supports ROM boot mode and Flash boot mode, and can switch between these two boot modes. If additional boot modes are needed, a mapping relationship needs to be configured in the configuration file to indicate the addition of a second boot mode and its corresponding second boot address. Of course, users can flexibly update the configuration file; for example, modifying the second boot mode, modifying the corresponding second boot address, adding a mapping relationship, or deleting a mapping relationship.

[0042] The configuration file can also specify the storage address for each second boot mode. This allows the first boot mode to be matched with each of the second boot modes during startup. A successful match yields both the first boot address and the storage address of the first boot program. A single successful match provides both of the necessary information for starting the first boot program, improving startup efficiency.

[0043] In some possible implementations, when there is no first boot address corresponding to the first boot mode in the mapping relationship, the similarity between the second boot mode and the first boot mode is determined from the mapping relationship; the user is prompted to change the first boot mode to the second boot mode with the highest similarity.

[0044] The absence of the aforementioned first boot address can be understood as the first boot mode being different from any second boot mode. This means the user is very likely to have entered the wrong first boot mode. To ensure accuracy, QEMU can prompt the user to correct it and provide the correct second boot mode. This reduces user complexity and helps the user quickly input the correct second boot mode.

[0045] After resolving the first boot address, the boot controller can control the processor to start the first boot program from that address. The boot controller loads the first boot program from its memory address to the first boot address, causing the processor to start the first boot program from that address. Specifically, invoking the boot controller to control the processor to start the first boot program from the first boot address includes: By using the startup controller, the first boot program corresponding to the first boot mode is loaded into the first boot address; by using the startup controller, the first boot address is written into the processor's program counter, so that the processor runs the first boot program from the first boot address in the program counter.

[0046] The mapping relationship between the first boot mode and the first bootloader can be preset. For example, the first boot mode can be included in the name of the first bootloader, or the mapping relationship between the first boot mode and the storage address of the first bootloader can be stored in a configuration file.

[0047] The processor here can be any processor in the virtual machine. The boot controller randomly selects a processor from one or more processors in the virtual machine and writes the first boot address into the program counter of that processor. The program counter is a register of the processor used to store the address of the instruction currently being executed by the processor.

[0048] The startup controller writes the first startup address into the processor's program counter, and the processor can then execute the first boot program at the first startup address.

[0049] The startup controller can control the loading and execution of the first boot program through the processor's program counter, making the implementation simple.

[0050] When the first bootloader is a program other than the QEMU executable, the boot controller needs to load the first bootloader from an external source into the first boot address. The executable is a binary code package compiled from QEMU.

[0051] When the first bootloader is pre-compiled into the QEMU executable file, the first bootloader corresponding to the first boot mode is loaded into the first boot address, including: determining the storage address of the first bootloader in the QEMU executable file according to the first boot mode; and loading the first bootloader from the storage address to the first boot address.

[0052] Understandably, the boot controller can match the first boot mode with the various code names in the QEMU executable file to determine the storage address of the first bootloader. This application embodiment not only supports booting from external bootloaders but also allows one or more bootloaders to be compiled into QEMU, supporting bootloaders from multiple sources, offering great flexibility and wide applicability. Furthermore, for bootloaders compiled into the QEMU executable file, they can be used out of the box, internally supporting multiple bootloaders, allowing users to choose any one without needing to provide an additional bootloader, thus reducing user operational complexity and costs.

[0053] Furthermore, by starting the controller, the first boot address is written into the processor's program counter, including: The startup controller obtains the processor information of the virtual machine; the startup controller determines the target processor from at least one processor of the virtual machine based on the processor information; the startup controller calls the target interface of the target processor and writes the first startup address into the program counter of the target processor.

[0054] The processor information may include, but is not limited to: the number of processors in the virtual machine, the type, status, and performance parameters of each processor. The type may include master processor and slave processor, the status may include busy or idle state, and the performance parameters may include: clock speed, number of cores, number of threads, cache, supported memory types, manufacturing process, etc.

[0055] The target processor can be a processor selected based on at least one of the above-mentioned types, states, and performance parameters. For example, it can be the main processor, a processor in an idle state, or a processor with the highest clock speed.

[0056] The aforementioned target interface is an interface for writing an address to the program counter, and its parameters can be the address to be written and the program counter identifier. In this embodiment, the address to be written is the first startup address.

[0057] The embodiments of this application can select the target processor for running the first boot program through processor information, which helps to improve the execution efficiency of the first boot program.

[0058] In other implementations, the target processor can also be selected in conjunction with information from the first bootloader. Specifically, the boot controller determines the target processor from at least one processor of the virtual machine based on processor information, including: Obtain information from the first bootloader; based on the information from the first bootloader and the processor information, determine the target processor from at least one processor, wherein the information of the target processor matches the information from the first bootloader.

[0059] The information for the first bootloader may include, but is not limited to, the type, function, creation time, size, and execution difficulty of the first bootloader. For example, if the first bootloader is large in size and has high execution difficulty, a processor with a high clock speed can be selected; or, a processor with high execution efficiency and accuracy for this type of first bootloader can be selected.

[0060] In this way, a compatible processor can be selected as the target processor based on the information of the first boot program and the processor information, which helps to improve the success rate and efficiency of the boot program.

[0061] In some possible implementations, when the first bootloader fails to start, a switch to a third boot mode can be made to attempt booting, which can improve the boot success rate. The third boot mode can be any boot mode other than the first boot mode. Specifically, this also includes: when the first bootloader fails to start, calling the boot controller to obtain the reason for the failure and determining the third boot mode based on the reason for the failure; calling the boot controller to resolve the third boot mode into a third boot address, and calling the boot controller to control the processor to start the third bootloader from the third boot address.

[0062] Different reasons for failure correspond to different third boot programs, and the third boot mode is a boot program without a reason for failure. For example, when the failure of the first boot program is due to a problem with the first boot program itself or an abnormality in its corresponding boot mode, another third boot program corresponding to a third boot mode can be randomly selected; when the failure of the first boot program is due to a mismatch between the processor and the first boot program, a third boot program that matches the processor can be selected.

[0063] This application allows switching to another bootloader when one bootloader fails to start. This improves the boot success rate.

[0064] Of course, in practical applications, a third boot mode different from the first boot mode can be randomly selected from the aforementioned configuration file, or other boot modes different from the first boot mode can be obtained from the boot modes supported by the aforementioned configuration file, and these other boot modes can be used as the third boot mode one by one. In this way, the boot success rate can be guaranteed as much as possible.

[0065] The supported boot modes mentioned above are all the second boot modes in the mapping relationship in the configuration file. For example, when the second boot mode in the configuration file is ROM or Flash, and the first boot mode is ROM, then the third boot mode can be Flash. In this way, it is possible to attempt to boot from Flash when ROM boot fails.

[0066] It should be noted that calling the boot controller to resolve the third boot mode to the third boot address, and then calling the boot controller to control the processor to start the third boot program from the third boot address, is the same as the aforementioned calling the boot controller to resolve the first boot mode to the first boot address, and then calling the boot controller to control the processor to start the first boot program from the first boot address. This will not be elaborated further here.

[0067] One application scenario of this application is a RISC-V SoC (System on Chip). Its hardware supports two boot modes: ROM boot mode and QSPI (Queued Serial Peripheral Interface) boot mode.

[0068] ROM boot: After reset, it executes from the internal mask ROM, starting at address 0x1000, and is used to load the secure boot program.

[0069] Flash boot: After reset, it executes from an external QSPI Flash, starting at address 0x10000000, and is used to run a complete firmware or operating system boot image.

[0070] In this embodiment, different second boot modes in the configuration file correspond to different second boot programs and different second boot addresses. For example, the second boot program corresponding to the second boot mode ROM is a secure boot program, and the second boot program corresponding to the second boot mode Flash is a complete firmware or operating system boot image.

[0071] In summary, the embodiments of this application allow specifying only the boot mode in the command. The boot controller implemented in QEMU resolves the boot mode into a boot address to start the bootloader from that address. This reduces user input, lowers the probability of input errors and the complexity of user operations, thereby reducing the boot failure rate. Furthermore, the bootloader can be directly compiled into the QEMU executable file, eliminating the need for users to provide an additional bootloader. This further reduces user complexity and costs. This lowers the barrier to entry and is particularly suitable for scenarios such as educational demonstrations, customer-delivered SDKs (Software Development Kits), or security verification environments, preventing boot failures caused by missing firmware, version mismatches, or incorrect paths.

[0072] Figure 3 This is a flowchart of another simulated startup method provided in an embodiment of this application, referred to... Figure 3 As shown, the above-mentioned simulated startup method includes: S201. The fast simulator obtains the current state of the target switch to determine the first start mode based on the current state. When the target switch is in different states, it corresponds to different first start modes.

[0073] S202. The fast emulator generates a startup command based on the first startup mode, which includes the first startup mode.

[0074] S203. During the instantiation phase of the startup controller in the fast emulator, the startup controller is called to read the mapping relationship between the second startup mode and the second startup address from the configuration file. The instantiation phase is located during the initialization of the virtual machine by the fast emulator. The startup controller is registered through the object model of the fast emulator.

[0075] S204. Call the startup controller to query the first startup address corresponding to the first startup mode from the mapping relationship.

[0076] If a first boot address exists, execute steps S205 to S210; if a first boot address does not exist, execute step S211.

[0077] S205. The startup controller is invoked to determine the storage address of the first boot program in the executable file of the fast emulator according to the first startup mode, so as to load the first boot program from the storage address to the first startup address.

[0078] S206. Obtain the virtual machine's processor information and the first bootloader information by starting the controller.

[0079] S207. The boot controller is invoked to determine the target processor from at least one processor based on the information of the first boot program and the processor information, and the information of the target processor is matched with the information of the first boot program.

[0080] S208. By calling the target interface of the target processor through the startup controller, the first startup address is written into the program counter of the target processor, so that the processor runs the first boot program from the first startup address in the program counter.

[0081] If the first bootloader runs successfully, the process ends; if the first bootloader fails to run, proceed to step S209.

[0082] S209. When the first boot program fails to run, the boot controller is called to obtain the reason for the failure, and the third boot mode is determined based on the reason for the failure.

[0083] S210: Call the boot controller to resolve the third boot mode into a third boot address, and call the boot controller to control the processor to start the third boot program from the third boot address.

[0084] S211. When there is no first boot address corresponding to the first boot mode in the mapping relationship, the boot controller is called to determine the similarity between the second boot mode and the first boot mode from the mapping relationship, and the user is prompted to change the first boot mode to the second boot mode with the highest similarity.

[0085] The order of S201 to S211 described above can be flexibly set independently of each other, and this application embodiment does not impose any restrictions on it. Furthermore, S201 to S211 can be referred to as described above. Figure 2 The detailed description of the illustrated embodiments will not be repeated here.

[0086] Figure 4 This is a schematic diagram of the structure of a simulated start-up device 300 provided in an embodiment of this application, with reference to... Figure 4 As shown, the simulated start-up device 300 includes: The command acquisition module 301 is used to call QEMU to obtain the startup command, which includes: the first startup mode.

[0087] The parsing module 302 is used to call the startup controller to parse the first startup mode into the first startup address during the instantiation phase of the startup controller in the QEMU fast simulator. The instantiation phase is located during the QEMU virtual machine initialization process, and the startup controller is registered through the QEMU object model.

[0088] The startup module 303 is used to call the startup controller to control the processor to start the first boot program from the first startup address.

[0089] In one possible implementation, the startup module 303 is further configured to: By using the startup controller, the first boot program corresponding to the first boot mode is loaded into the first boot address; by using the startup controller, the first boot address is written into the processor's program counter, so that the processor runs the first boot program from the first boot address in the program counter.

[0090] In one possible implementation, the startup module 303 is further configured to: Based on the first boot mode, determine the storage address of the first boot program in the QEMU executable file; load the first boot program from the storage address to the first boot address.

[0091] In one possible implementation, the startup module 303 is further configured to: The startup controller obtains the processor information of the virtual machine; the startup controller determines the target processor from at least one processor of the virtual machine based on the processor information; the startup controller calls the target interface of the target processor and writes the first startup address into the program counter of the target processor.

[0092] In one possible implementation, the startup module 303 is further configured to: Obtain information from the first bootloader; based on the information from the first bootloader and the processor information, determine the target processor from at least one processor, wherein the information of the target processor matches the information from the first bootloader.

[0093] In one possible implementation, the command acquisition module 301 is further configured to: Obtain the current state of the target switch; determine the first start mode based on the current state, and use different first start modes for different states of the target switch; generate a start command based on the first start mode.

[0094] In one possible implementation, the parsing module 302 is further configured to: Read the mapping relationship between the second boot mode and the second boot address from the configuration file; query the first boot address corresponding to the first boot mode from the mapping relationship.

[0095] In one possible implementation, refer to Figure 5 As shown, it also includes a prompting module 304, used for: If the first boot address corresponding to the first boot mode does not exist in the mapping relationship, determine the similarity between the second boot mode and the first boot mode from the mapping relationship; prompt the user to change the first boot mode to the second boot mode with the highest similarity.

[0096] In one possible implementation, refer to Figure 5 As shown, it also includes a failure handling module 305, used for: When the first bootloader fails to start, the boot controller is invoked to obtain the reason for the failure and to determine the third boot mode based on the reason for the failure. The boot controller is then invoked to resolve the third boot mode into a third boot address and to control the processor to start the third bootloader from the third boot address.

[0097] As the device embodiment is basically similar to the method embodiment, the description is relatively simple, and relevant parts can be found in the description of the method embodiment.

[0098] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on the differences from other embodiments. The same or similar parts between the various embodiments can be referred to each other.

[0099] Regarding the apparatus in the above embodiments, the specific manner in which each module performs its operation has been described in detail in the embodiments related to the method, and will not be elaborated upon here.

[0100] This application also provides an electronic device, including: a processor and a memory for storing processor-executable instructions; wherein the processor is configured to execute the instructions to implement a simulated boot method.

[0101] Figure 6 This is a block diagram illustrating a first electronic device 400 according to an exemplary embodiment. For example, the first electronic device 400 may be a mobile phone, computer, digital broadcasting terminal, messaging device, game console, tablet device, medical device, fitness equipment, personal digital assistant, etc.

[0102] Reference Figure 6 The first electronic device 400 may include one or more of the following components: a processing component 402, a first memory 404, a power supply component 406, a multimedia component 408, an audio component 410, an input / output (I / O) interface 412, a sensor component 414, and a communication component 416.

[0103] Processing component 402 typically controls the overall operation of the first electronic device 400, such as operations associated with display, telephone calls, data communication, camera operation, and recording operations. Processing component 402 may include one or more processors 420 to execute instructions to perform all or part of the steps of the methods described above. Furthermore, processing component 402 may include one or more modules to facilitate interaction between processing component 402 and other components. For example, processing component 402 may include a multimedia module to facilitate interaction between multimedia component 408 and processing component 402.

[0104] The first memory 404 is used to store various types of data to support the operation of the first electronic device 400. Examples of such data include instructions for any application or method operating on the first electronic device 400, contact data, phone book data, messages, pictures, multimedia, etc. The first memory 404 can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk.

[0105] Power supply component 406 provides power to various components of the first electronic device 400. Power supply component 406 may include a power management system, one or more power supplies, and other components associated with generating, managing, and distributing power to the first electronic device 400.

[0106] Multimedia component 408 includes a screen that provides an output interface between the first electronic device 400 and the user. In some embodiments, the screen may include a liquid crystal display (LCD) and a touch panel (TP). If the screen includes a touch panel, the screen may be implemented as a touchscreen to receive input signals from the user. The touch panel includes one or more touch sensors to sense touches, swipes, and gestures on the touch panel. The touch sensors may sense not only the boundaries of touch or swipe actions but also the duration and pressure associated with the touch or swipe operation. In some embodiments, multimedia component 408 includes a front-facing camera and / or a rear-facing camera. When the first electronic device 400 is in an operating mode, such as a shooting mode or a multimedia mode, the front-facing camera and / or the rear-facing camera may receive external multimedia data. Each front-facing camera and rear-facing camera may be a fixed optical lens system or have focal length and optical zoom capabilities.

[0107] Audio component 410 is used to output and / or input audio signals. For example, audio component 410 includes a microphone (MIC) used to receive external audio signals when the first electronic device 400 is in an operating mode, such as a call mode, recording mode, or voice recognition mode. The received audio signals may be further stored in the first memory 404 or transmitted via communication component 416. In some embodiments, audio component 410 also includes a speaker for outputting audio signals.

[0108] I / O interface 412 provides an interface between processing component 402 and peripheral interface modules, such as keyboards, click wheels, buttons, etc. These buttons may include, but are not limited to, home buttons, volume buttons, power buttons, and lock buttons.

[0109] Sensor assembly 414 includes one or more sensors for providing state assessments of various aspects of the first electronic device 400. For example, sensor assembly 414 may detect the on / off state of the first electronic device 400, the relative positioning of components such as the display and keypad of the first electronic device 400, changes in position of the first electronic device 400 or a component of the first electronic device 400, the presence or absence of user contact with the first electronic device 400, the orientation or acceleration / deceleration of the first electronic device 400, and temperature changes of the first electronic device 400. Sensor assembly 414 may include a proximity sensor configured to detect the presence of nearby objects without any physical contact. Sensor assembly 414 may also include a light sensor, such as a CMOS or CCD image sensor, for use in imaging applications. In some embodiments, sensor assembly 414 may also include an accelerometer, a gyroscope, a magnetometer, a pressure sensor, or a temperature sensor.

[0110] Communication component 416 facilitates wired or wireless communication between the first electronic device 400 and other devices. The first electronic device 400 can access wireless networks based on communication standards, such as WiFi, carrier networks (such as 2G, 3G, 4G, or 5G), or combinations thereof. In one exemplary embodiment, communication component 416 receives broadcast signals or broadcast-related information from an external broadcast management system via a broadcast channel. In one exemplary embodiment, communication component 416 also includes a near-field communication (NFC) module to facilitate short-range communication. For example, the NFC module may be implemented based on radio frequency identification (RFID) technology, Infrared Data Association (IrDA) technology, ultra-wideband (UWB) technology, Bluetooth (BT) technology, and other technologies.

[0111] In an exemplary embodiment, the first electronic device 400 may be implemented by one or more application-specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), field-programmable gate arrays (FPGAs), controllers, microcontrollers, microprocessors, or other electronic components to implement the methods provided in the embodiments of this application.

[0112] In an exemplary embodiment, a non-transitory computer-readable storage medium including instructions is also provided, such as a first memory 404 including instructions that can be executed by a processor 420 of a first electronic device 400 to perform the above-described method. For example, the non-transitory storage medium may be a ROM, random access memory (RAM), CD-ROM, magnetic tape, floppy disk, and optical data storage device, etc.

[0113] Figure 7 This is a block diagram illustrating a second electronic device 500 according to an exemplary embodiment. For example, the second electronic device 500 may be provided as a server. (Refer to...) Figure 7 The second electronic device 500 includes a processing component 522, which further includes one or more processors, and memory resources represented by a second memory 532 for storing instructions, such as application programs, that can be executed by the processing component 522. The application programs stored in the second memory 532 may include one or more modules, each corresponding to a set of instructions. Furthermore, the processing component 522 is configured to execute instructions to perform the methods provided in the embodiments of this application.

[0114] The second electronic device 500 may also include a power supply component 526 configured to perform power management of the second electronic device 500, a wired or wireless network interface 550 configured to connect the second electronic device 500 to a network, and an input / output (I / O) interface 558. The second electronic device 500 may operate on an operating system stored in a second memory 532, such as Windows Server™, MacOSX™, Unix™, Linux™, FreeBSD™, or similar.

[0115] This application also provides a computer-readable storage medium that, when the instructions in the computer-readable storage medium are executed by the processor of an electronic device, enables the electronic device to perform a simulated startup method.

[0116] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the methods described in the above embodiments.

[0117] Other embodiments of this application will readily occur to those skilled in the art upon consideration of the specification and practice of the application disclosed herein. This application is intended to cover any variations, uses, or adaptations of this application that follow the general principles of this application and include common knowledge or customary techniques in the art not disclosed herein. The specification and examples are to be considered exemplary only, and the true scope and spirit of this application are indicated by the following claims.

[0118] It should be understood that this application is not limited to the precise structure described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this application is limited only by the appended claims.

Claims

1. A simulated startup method, characterized in that, include: Call QEMU to obtain the startup command, which includes: a first startup mode; In the instantiation phase of the startup controller in the fast emulator QEMU, the startup controller is invoked to resolve the first startup mode into the first startup address. The instantiation phase is located during the process of QEMU initializing the virtual machine. The startup controller has configurable attributes, which are set by the first startup mode. The boot controller is invoked to control the processor to start the first boot program from the first boot address; Also includes: If the first bootloader fails to start, and the reason for the failure of the first bootloader is that the processor is incompatible with the first bootloader, then the boot controller is invoked to select a third bootloader that is compatible with the processor to start. The startup command is a startup script, and the startup controller is a virtual device registered through the QEMU object model for switching startup modes. The first bootloader is pre-compiled into the QEMU executable file so that the startup controller loads the first bootloader corresponding to the first startup mode from the executable file and runs it at the first startup address. The mapping relationship between the first startup mode and the first bootloader is set in the configuration file, or the name of the first bootloader includes the first startup mode. The mapping relationship between the first startup mode and the first startup address is set in the configuration file.

2. The method according to claim 1, characterized in that, Invoking the boot controller to control the processor to start the first boot program from the first boot address includes: The first boot program corresponding to the first boot mode is loaded into the first boot address through the boot controller; The boot controller writes the first boot address into the processor's program counter, so that the processor runs the first boot program from the first boot address in the program counter.

3. The method according to claim 2, characterized in that, Loading the first bootloader corresponding to the first boot mode into the first boot address includes: Based on the first boot mode, determine the storage address of the first boot program in the executable file of QEMU; The first bootloader is loaded from the storage address to the first startup address.

4. The method according to claim 2, characterized in that, The process of writing the first boot address into the processor's program counter via the boot controller includes: The processor information of the virtual machine is obtained through the boot controller; The boot controller determines the target processor from at least one processor of the virtual machine based on the processor information; The boot controller calls the target interface of the target processor and writes the first boot address into the program counter of the target processor.

5. The method according to claim 4, characterized in that, The boot controller determines a target processor from at least one processor of the virtual machine based on the processor information, including: Obtain information from the first bootloader; Based on the information from the first bootloader and the processor information, a target processor is determined from the at least one processor, wherein the information of the target processor matches the information from the first bootloader.

6. The method according to any one of claims 1 to 5, characterized in that, Obtain the startup command, including: Get the current state of the target switch; The first startup mode is determined based on the current state, and different first startup modes correspond to different states of the target switch; The startup command is generated based on the first startup mode.

7. The method according to any one of claims 1 to 5, characterized in that, The first boot mode is resolved to the first boot address, including: Read the mapping relationship between the second boot mode and the second boot address from the configuration file; Query the first startup address corresponding to the first startup mode from the mapping relationship.

8. The method according to claim 7, characterized in that, Also includes: When the first startup address corresponding to the first startup mode does not exist in the mapping relationship, the similarity between the second startup mode and the first startup mode is determined from the mapping relationship; The user is prompted to change the first startup mode to the second startup mode, which has the highest similarity.

9. The method according to any one of claims 1 to 5, characterized in that, Also includes: When the first bootloader fails to start, the boot controller is invoked to obtain the reason for the failure, and a third boot mode is determined based on the reason for the failure. The boot controller is invoked to resolve the third boot mode into a third boot address, and then the boot controller is invoked to control the processor to start the third boot program from the third boot address.

10. A simulated start-up device, characterized in that, include: The command acquisition module is used to call QEMU to obtain the startup command, which includes: a first startup mode; The parsing module is used to call the startup controller to parse the first startup mode into a first startup address during the instantiation phase of the startup controller in the QEMU fast emulator. The instantiation phase is located during the initialization of the virtual machine by QEMU. The startup controller has configurable attributes, which are set by the first startup mode. A startup module is used to invoke the startup controller to control the processor to start the first boot program from the first startup address; The startup module is further configured to: when the startup of the first boot program fails and the reason for the failure of the first boot program is that the processor is incompatible with the first boot program, call the startup controller to select a third boot program that matches the processor to start. The startup command is a startup script, and the startup controller is a virtual device registered through the QEMU object model for switching startup modes. The first bootloader is pre-compiled into the QEMU executable file so that the startup controller loads the first bootloader corresponding to the first startup mode from the executable file and runs it at the first startup address. The mapping relationship between the first startup mode and the first bootloader is set in the configuration file, or the name of the first bootloader includes the first startup mode. The mapping relationship between the first startup mode and the first startup address is set in the configuration file.

11. An electronic device, characterized in that, include: processor; Memory used to store the processor's executable instructions; The processor is configured to execute the instructions to implement the method as described in any one of claims 1 to 9.

12. A computer-readable storage medium, characterized in that, When the instructions in the computer-readable storage medium are executed by the processor of the electronic device, the electronic device is enabled to perform the method as described in any one of claims 1 to 9.

Images