Operating system startup method, device and storage medium

Abstract

The present disclosure provides an operating system startup method, a device and a storage medium. The method comprises: in response to initialization of an operating system, reading startup parameters; if the startup parameters indicate delayed scanning of PCIe devices, creating a root bridge device node, and skipping PCIe device scanning processing; initializing other hardware devices and software, and displaying a user login interface; and, if an instruction input by a user for PCIe device scanning is received, executing PCIe device scanning processing. The startup parameters are set to control the execution of a PCIe device scanning process, such that the PCIe device scanning process is skipped during the operating system startup stage, and after the operating system is started, PCIe device scanning is performed according to needs, thus shortening the startup time of operating systems.

Description

[0001] Operating System Boot Method, Device, and Storage Medium. This disclosure claims priority to Chinese patent application number 202311841733.3, filed with the China Patent Office on December 28, 2023, entitled "Operating System Boot Method, Device, and Storage Medium," the entire contents of which are incorporated herein by reference. Technical Field: This disclosure relates to the field of computer device technology, and more particularly to an operating system boot method, device, and storage medium. Background: During chip development, to ensure that the chip's functionality and performance meet requirements, the chip must be verified and tested to verify that the various software and hardware functions within the chip are functioning properly. Conventional chip verification equipment includes field programmable gate array (FPGA) verification equipment and emulator (EMU) verification equipment. Simply put, during chip verification, the chip verification equipment acts as an emulator, simulating the software and hardware environment of the chip being verified. For example, by building the chip's hardware environment and running the relevant software code on the chip. To ensure stability and accuracy during the verification process, chip verification equipment often uses a lower clock frequency. Furthermore, factors such as the complex logic of chip designs and resource limitations of the verification equipment can cause the chip verification equipment to operate at speeds significantly lower than the actual chip speed in actual applications. For example, when verifying a system-on-chip (SoC) chip, it's necessary to test the Basic Input / Output System (BIOS), Unified Extensible Firmware Interface (UEFI), firmware, device drivers, operating system boot and diagnostic tools, and other functions. Sometimes, it's even necessary to optimize the entire software stack for specific middleware frameworks, workloads, and applications. All of these processes require running an operating system (OS) on the chip verification equipment. Device scanning. In a third aspect, embodiments of the present disclosure provide an operating system startup method, applied to a chip verification device for verifying a chip. The chip verification device simulates the chip's hardware and software environment, including the chip's corresponding operating system and other software, as well as various PCIe devices, including a root host bridge device, and other hardware devices. The method comprises: reading startup parameters in response to operating system initialization; if the startup parameters indicate a delayed scan of PCIe devices, creating a root host bridge device node; initializing other hardware devices and software; displaying a user login interface; and executing a PCIe device scan upon receiving a user-input instruction to scan PCIe devices. In a fourth aspect, embodiments of the present disclosure provide an electronic device, comprising: a memory, a processor, and a communication interface; wherein the memory stores executable code, and when the processor executes the executable code, the processor is enabled to implement at least the operating system startup method described in the first or third aspect. In a fifth aspect, embodiments of the present disclosure provide a non-transitory machine-readable storage medium storing executable code. When the executable code is executed by a processor of an electronic device, the processor is enabled to implement at least the operating system startup method described in the first or third aspect. In a sixth aspect, embodiments of the present disclosure provide a computer program product comprising a computer program. When executed by a processor, the computer program implements the operating system startup method described in the first or third aspect. In embodiments of the present disclosure, the operating system startup steps include power-on self-test, BIOS startup, boot program loading, operating system loading, system initialization (initializing the operating system), and user login. The operating system initialization stage can be further divided into hardware initialization and software initialization, such as starting system services and loading third-party applications. The hardware initialization stage includes initializing Peripheral Component Interconnect Express (PCIe) devices and other hardware initialization. During PCIe device initialization, the system first reads the startup parameters. If the startup parameters indicate a delayed scan (or enumeration) of PCIe devices, a root host bridge node is created. Other hardware and software initialization then proceeds to complete the system initialization phase and display the user login interface. After the login interface is displayed, the user can trigger a PCIe device scan as needed.When a user-input instruction to scan PCIe devices is received, a PCIe device scan is performed. By setting startup parameters to control the execution of the PCIe device scan process, the PCIe device scan process is skipped during the operating system startup phase. After the operating system starts, PCIe devices are scanned on demand, thereby reducing operating system startup time. BRIEF DESCRIPTION OF THE DRAWINGS To more clearly illustrate the technical solutions in the embodiments of the present disclosure, the following briefly introduces the drawings used in describing the embodiments. Obviously, the drawings described below represent some embodiments of the present disclosure. Those skilled in the art can derive other drawings based on these drawings without inventive effort. Figure 1 is a schematic diagram of an operating system startup process according to an embodiment of the present disclosure; Figure 2 is a schematic diagram of a PCIe device topology visible to a CPU after a PCIe device scan according to an embodiment of the present disclosure; Figure 3 is a flowchart of an operating system startup method according to an embodiment of the present disclosure; Figure 4 is a flowchart of an operating system startup method according to an embodiment of the present disclosure; Figure 5 is a schematic diagram of an operating system startup process according to an embodiment of the present disclosure; Figure 6 is a schematic diagram of a PCIe device topology visible to a CPU during the PCIe device initialization phase according to an embodiment of the present disclosure; Figure 7 is a schematic diagram of the structure of an operating system startup apparatus according to an embodiment of the present disclosure; and Figure 8 is a schematic diagram of the structure of an electronic device according to an embodiment of the present disclosure. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS To further clarify the objectives, technical solutions, and advantages of the embodiments of the present disclosure, the technical solutions of the embodiments of the present disclosure will be described clearly and completely below in conjunction with the accompanying drawings. It should be understood that the described embodiments represent only a portion of the embodiments of the present disclosure, but not all of them. All other embodiments derived by persons of ordinary skill in the art based on the embodiments of the present disclosure without inventive effort are within the scope of protection of the present disclosure. It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, storage, and display) involved in the embodiments of this disclosure are all authorized by the user or fully authorized by all parties. The collection, use, and processing of relevant data must comply with the relevant laws, regulations, and standards of relevant countries and regions, and corresponding operation portals are provided for users to choose to authorize or reject. The following detailed description of some embodiments of this disclosure is provided in conjunction with the accompanying drawings. The following embodiments and features may be combined unless there is a conflict between them. Furthermore, the step sequence in the following method embodiments is provided for illustrative purposes only and is not intended to be a strict limitation.Let's first explain the terms and concepts involved in the embodiments of this disclosure: Chip: A chip refers to a system on a chip (SoC), which is an integrated circuit that integrates multiple functional modules such as a processor, memory, and peripherals. Operating system: During the chip verification phase, developers need to run an operating system on a verification device. An operating system is software that manages hardware and software resources and provides services to applications. In chip verification scenarios, the operating system runs on the verification device, that is, it runs in the environment provided by the verification device. When the chip is used in a terminal device, the operating system runs in the terminal device and is activated by the chip. Verification device: A verification device is a hardware device used to verify the chip's functions and performance. It can be a customizable hardware device such as an FPGA that simulates the chip's behavior. The verification device provides an environment that enables developers to test and debug hardware and software resources such as the BIOS / UEFI, firmware, device drivers, operating system startup, and diagnostic tools.

[0002] CPU: The CPU is a core component in a chip, responsible for executing instructions, processing data, and controlling computer operations. On verification equipment, the CPU can be a simulated processor implemented in an FPGA, executing instructions for operating system startup and various software. Chip verification equipment is a hardware device used to verify chip functionality before mass production. Verification equipment is used to test and validate chip design and functionality to ensure the chip's correctness and reliability in real-world applications. During the chip verification phase, verification equipment typically uses customizable hardware devices such as FPGAs to simulate chip behavior. Developers load the chip's design code, verification code, and test programs into the verification equipment, simulating chip behavior for verification. The code and test programs running on the verification equipment verify the chip's design and functionality, ensuring that the chip correctly performs the required operations and functions. Therefore, verification equipment is used not only to verify the chip's hardware design but also its functionality and performance. By verifying the chip, developers can identify and resolve potential issues, optimize the chip's design and performance, and ensure that the chip meets expected requirements before mass production. During chip verification, the verification device first needs to boot the operating system in the simulated chip's hardware and software environment, then perform verification of other functions. As shown in Figure 1, the operating system startup steps include power-on self-test, booting the BIOS, loading the bootloader, loading the operating system, initializing the operating system, and user login. The operating system initialization phase can be further divided into hardware initialization and software initialization phases such as booting system services and loading third-party applications. The hardware initialization phase includes PCIe device initialization and other hardware device initialization. As shown in Figure 1, the PCIe device initialization phase can include the following steps:

[0003] (1) Create a root host bridge node;

[0004] (2) Create the root bus node (i.e., bus 0), which can be accomplished by executing the pc1_create_root_bus function. (3) Scan all PCIe devices under the root bus node. This can be accomplished by executing the pci_scan_child_bus function. The PCIe device scan process uses a deep traversal method to traverse all PCIe devices, so this is the main time-consuming operation during the operating system startup process.

[0005] (4) Allocate resources to PCIe devices. For example, allocate memory, registers and other resources. After executing the complete PCIe device scanning process, the CPU will see the complete PCIe device topology, as shown in Figure 2. After completing other initialization processes, the user login interface will be displayed. In Figure 2, it is assumed that the root host bridge device (root host bridge) node is connected to the created root bus node: bus 0, and it is assumed that two PCIe devices connected to bus0 are obtained through PCIe device scanning: PCIe bridge1 and PCIe bridge2. In addition, as shown in Figure 2, it is assumed that the PCIe bridge1 device is connected to the bus1 sub-bus, and the bus1 bus is connected to a PCIe device leaf node: endpoint device1; it is assumed that the PCIe bridge2 device is connected to the bus2 sub-bus, and the bus2 bus is connected to a PCIe device leaf node: endpoint device2 o In chip verification equipment, the total operating system boot time is relatively long, with the PCIe device initialization phase accounting for a significant portion of this time. The PCIe device initialization phase primarily involves traversing all PCIe devices using a deep traversal algorithm, allocating resources for them, and loading drivers. This results in a lengthy PCIe device initialization process, slowing down the operating system boot and reducing chip verification efficiency. During chip verification, the operating system must boot quickly, and in many cases, it does not rely on PCIe devices. Therefore, excessive time spent on PCIe device initialization during operating system boot increases the chip verification cycle. Based on this, embodiments of the present disclosure propose a method for accelerating operating system boot by delaying PCIe device scanning. This method not only accelerates operating system boot during the chip verification phase and improves chip verification efficiency, but can also accelerate operating system boot in terminal devices such as personal computers (such as PCs) that do not rely heavily on PCIe devices. The following describes the operating system boot solution provided by embodiments of the present disclosure. The following details the execution process of the operating system boot method provided by embodiments of the present disclosure, with reference to the accompanying figures. This operating system startup method can be executed by the aforementioned verification device or other computer devices, and is not limited to chip verification scenarios. FIG3 is a flowchart of an operating system startup method provided by an embodiment of the present disclosure. As shown in FIG3 , the method includes the following steps:

[0006] 301. In response to initialization of the operating system, read startup parameters.

[0007] 302. If the startup parameter indicates to delay scanning of PCIe devices, create a root host bridge device node.

[0008] 303. Initialize other hardware devices and software.

[0009] 304. Display the user login interface.

[0010] 305. If a user-input instruction to scan PCIe devices is received, PCIe device scanning is performed. The improved operating system startup method in the disclosed embodiment is specifically initiated upon entering the operating system initialization phase, specifically during the PCIe device initialization phase of the hardware initialization phase. Therefore, reading startup parameters in response to operating system initialization in step 301 means that upon commencing PCIe device initialization, the kernel code being executed first reads the configured startup parameters. These startup parameters are used during the operating system startup process, specifically during the PCIe device initialization phase. They indicate whether to delay PCIe device scanning. In the disclosed embodiment, before booting the operating system, a user (e.g., a chip developer) can set startup parameters by modifying a boot loader configuration file. The boot loader then passes these startup parameters to the operating system kernel, allowing the kernel to perform relevant processing according to the configuration during startup. For example, the kernel performs operating system initialization according to the configuration file during kernel startup. The startup parameter values ​​include two types: a first parameter value (delay) indicating a delay in PCIe device scanning; and a second parameter value (no_delay) indicating no delay in PCIe device scanning. Therefore, during the operating system initialization phase, after detecting the first parameter value, the PCIe device initialization process creates the root host bridge device node and returns directly, skipping the root bus creation, PCIe device scanning, and resource allocation processes. Other operating system initialization operations (such as initializing other hardware and software (e.g., loading third-party applications and system services)) are then completed. The operating system boots up and the user login interface is then displayed. In specific implementations, after detecting the first parameter value, the Advanced Configuration and Power Interface (AGPI) is first parsed to obtain the Differentiated System Description Table (DSDT).

[0011] The DSDT table is generated by the ACPI compiler in the system BIOS or UEFI firmware. The DSDT table is a large binary data structure used to describe the characteristics, configuration, and control methods of system hardware devices. The DSDT table contains device objects and methods defined by ACPI, which are used to operate and manage system hardware. Simply put, the DSDT table describes information about many system hardware devices, one of which is the root host bridge device. The DSDT table can contain the device identifier of the root host bridge device. If the DSDT table contains the device identifier of the root host bridge device, it indicates that the root host bridge device exists. Based on this device identifier, the root host bridge device driver can be invoked. PCIe device initialization is performed using the attach function included in the root host bridge device driver. Specifically, in this embodiment, the attach function creates a root host bridge device node. In this solution, during the PCIe device initialization process, only the root host bridge device node creation is required; other operations are not performed, thereby shortening the operating system startup time. After the operating system boots, in a chip verification scenario, verification of other chip software and hardware functions independent of PCIe devices can be performed. When a PCIe device needs to be booted, the user can scan for PCIe devices as needed within the booted operating system. At this point, the user can enter a command to scan for PCIe devices, thereby triggering the PCIe device scan. The PCIe device scan includes: creating a root bus node, scanning for PCIe devices connected to the root bus node, and allocating resources for the scanned PCIe devices. Drivers may also be loaded for the scanned PCIe devices. Optionally, in this embodiment of the present disclosure, if a user-triggered boot command is received for a first file mounted in the first file interface directory, the PCIe device scan is performed based on the first file. The first file is used to complete the steps of "creating a root bus node, scanning for PCIe devices connected to the root bus node, and allocating resources for the scanned PCIe devices." The first file interface directory is, for example, / sys / acpi / firmware / . This directory serves as a file interface. The first file is mounted under this directory to form an interface file. For example, the first file is named "force_rescan," thereby forming the following file interface: / sys / acpi / firmware / force_rescan oThe user can call the first file by entering a command line instruction to enable the first file. In practical applications, the interface file can be created after calling the driver of the root host bridge device and before the user login interface is displayed. In summary, by setting startup parameters to control the execution of the PCIe device scanning process, the PCIe device scanning process is skipped during the operating system startup phase. After the operating system starts, PCIe devices are scanned on demand, thereby reducing the operating system startup time. Figure 4 is a flowchart of an operating system startup method provided by an embodiment of the present disclosure. As shown in Figure 4, the method includes the following steps:

[0012] 401. In response to initialization of the operating system, read startup parameters.

[0013] 402. If the startup parameter indicates to delay scanning of PCIe devices, then create a root host bridge device node and a root bus node.

[0014] 403. Initialize other hardware devices and software.

[0015] 404. Display the user login interface.

[0016] 405. If a user-input instruction to scan for PCIe devices is received, PCIe devices connected to the root bus node are scanned, and resources are allocated for the scanned PCIe devices. In this embodiment, optionally, in the case of delayed PCIe device scanning, the attach function can complete the creation of the root host bridge device node and the root bus node and then return, then perform other hardware and software initialization, and then display the user login interface. After the user login interface is displayed, the user can trigger a PCIe device scan instruction as needed. In this case, based on this instruction, PCIe devices connected to the root bus node are scanned, and resources are allocated for the scanned PCIe devices. Specifically, if a user-initiated start instruction is received for a second file mounted in the second file interface directory, PCIe devices connected to the root bus node are scanned based on the second file, and resources are allocated for the scanned PCIe devices. The second file is used to complete the "scanning for PCIe devices connected to the root bus node and resource allocation for the scanned PCIe devices." The second file interface directory, for example, is / sys / bus / pci / . This directory serves as a file interface that can only be used after the root bus has been initialized. A second file is mounted in this directory, forming an interface file. For example, this second file is named "rescan," thus forming the following file interface: / sys / bus / pci / rescan. Users can invoke this second file by entering a command line instruction to enable it. In practice, the interface file can be created after invoking the driver for the root host bridge device and before the user login interface is displayed. The above embodiments provide different methods for delayed PCIe device scanning. It is understood that if the startup parameters indicate immediate PCIe device scanning, the PCIe device initialization phase requires the complete steps of creating a root host bridge device node, creating a root bus node, scanning for PCIe devices connected to the root bus node, and allocating resources for the scanned PCIe devices. Subsequently, other hardware and software initialization is performed, and the user login interface is displayed. FIG5 is a schematic diagram of an operating system startup process provided by an embodiment of the present disclosure. FIG5 illustrates the operating system startup process in the aforementioned embodiment with startup parameters _= delay and no_delay. Furthermore, as shown in FIG6 , during the PCIe device initialization phase, after only the root host bridge device node is created, the CPU can only see the root host bridge device node and cannot see other buses and PCIe devices connected to it.In summary, by setting startup parameters to control the execution of the PCIe device scanning process, the PCIe device scanning process is skipped during the operating system startup phase, thereby reducing operating system startup time. Each operating system startup can delay the PCIe device scan to accelerate operating system startup. Furthermore, after the operating system starts, PCIe device scanning can be performed on demand through the system file interface. The following describes in detail the operating system startup device according to one or more embodiments of the present disclosure. Those skilled in the art will appreciate that these devices can be constructed using commercially available hardware components and configured according to the steps taught in this solution. Figure 7 is a schematic diagram of the structure of an operating system startup device provided by an embodiment of the present disclosure. As shown in Figure 7, the device includes: an acquisition module 11, a first initialization module 12, a second initialization module 13, and a display module 14. The acquisition module 11 is configured to read startup parameters in response to operating system initialization. The first initialization module 12 is configured to create a root host bridge device node if the startup parameters indicate delayed PCIe device scanning. The second initialization module 13 is configured to display the information displayed by the first initialization module 12. Then, PCIe device scanning is performed. Optionally, the first initialization module 12 is specifically configured to: parse the advanced configuration and power interface to obtain a differentiated system description table; invoke the driver of the root host bridge device based on the identifier of the root host bridge device in the differentiated system description table; and create a root host bridge device node through a connection function in the driver. Optionally, the first initialization module 12 is specifically configured to: create a root bus node under the root host bridge device node; scan for PCIe devices connected to the root bus node; and allocate resources for the scanned PCIe devices. Optionally, the first initialization module 12 is specifically configured to: upon receiving a user-triggered startup instruction for a first file mounted in the first file interface directory, perform PCIe device scanning based on the first file. Optionally, the first initialization module 12 is specifically configured to: if the startup parameter indicates immediate scanning of PCIe devices, create a root host bridge device node, create a root bus node under the root host bridge device node, scan for PCIe devices connected to the root bus node, and allocate resources for the scanned PCIe devices; initialize other hardware devices and software; and display a user login interface. Optionally, the first initialization module 12 is specifically configured to: if the startup parameter indicates delayed scanning of PCIe devices, create a root host bridge device node, create a root bus node under the root host bridge device node; initialize other hardware devices and software; display a user login interface; and, upon receiving a user input instruction to scan for PCIe devices, scan for PCIe devices connected to the root bus node and allocate resources for the scanned PCIe devices. Optionally, the first initialization module 12 is specifically configured to: upon receiving a user-triggered startup instruction for a second file mounted in the second file interface directory, scan for PCIe devices connected to the root bus node based on the second file, and allocate resources for the scanned PCIe devices. The device shown in FIG7 can execute the steps provided in the aforementioned embodiments. The detailed execution process and technical effects are described in the aforementioned embodiments and are not further elaborated here. In one possible design, the structure of the operating system startup device shown in FIG7 can be implemented as an electronic device. As shown in FIG8 , the electronic device may include a processor 21, a memory 22, and a communication interface 23. The memory 22 stores executable code. When executed by the processor 21, the executable code enables the processor 21 to at least implement the operating system startup method provided in the aforementioned embodiments.In addition, embodiments of the present disclosure provide a non-transitory machine-readable storage medium storing executable code. When the executable code is executed by a processor of an electronic device, the processor is enabled to at least implement the operating system startup method provided in the aforementioned embodiments. Furthermore, embodiments of the present disclosure provide a computer program product comprising a computer program. When executed by the processor, the computer program implements the operating system startup method provided in the aforementioned embodiments. The apparatus embodiments described above are merely illustrative. The network elements described as separate components may or may not be physically separate. Some or all of these modules may be selected based on actual needs to achieve the objectives of the present embodiments. Persons of ordinary skill in the art can understand and implement these embodiments without inventive effort. Through the above description of the embodiments, persons of ordinary skill in the art can clearly understand that each embodiment can be implemented by adding necessary general-purpose hardware devices, or alternatively, by a combination of hardware and software. Based on this understanding, the essence of the above-mentioned technical solutions, or the portion that contributes to the prior art, can be embodied in the form of a computer product. The present disclosure can take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk drives, CD-ROMs, optical storage devices, etc.) containing computer-usable program code. Finally, it should be noted that the above embodiments are merely illustrative of the technical solutions of the present disclosure, and are not intended to limit them. While the present disclosure has been described in detail with reference to the aforementioned embodiments, those skilled in the art will understand that the technical solutions described in the aforementioned embodiments may be modified, or some of the technical features thereof may be replaced by equivalents. Such modifications or replacements do not deviate from the essence of the corresponding technical solutions from the spirit and scope of the technical solutions of the various embodiments of the present disclosure.

Claims

Claims 1. A method for starting an operating system, comprising: Upon initialization of the operating system, read the startup parameters; If the startup parameters indicate a delayed scan of PCIe devices, create a root complex device node; Perform initialization processing of other hardware devices and software; display the user login interface; if a command to scan PCIe devices is received from the user, then perform PCIe device scan processing.

2. The method according to claim 1, wherein creating the root host bridge device node comprises: Parse the Advanced Configuration and Power Interface to obtain the Differentiated System Description Table; According to the identifier of the root complex device in the Differentiated System Description Table, call the driver of the root complex device; Create a root complex device node through the connection function in the driver; 3. The method according to claim 1 or 2, wherein performing the PCIe device scan processing includes: Create a root bus node under the root complex device node; Scan the PCIe devices connected under the root bus node; Allocate resources for the scanned PCIe devices.

4. The method according to any one of claims 1 to 3, wherein if an instruction to scan a PCIe device is received from a user, PCIe device scan processing is performed, including: If a startup command triggered by the first file mounted in the first file interface directory is received from the user, then perform PCIe device scan processing according to the first file.

5. The method according to any one of claims 1 to 4, the method further comprising: If the startup parameters indicate an immediate scan of PCIe devices, create a root complex device node, create a root bus node, scan the PCIe devices connected under the root bus node, and allocate resources for the scanned PCIe devices; Perform initialization processing of other hardware devices and software; Display the user login interface.

6. The method according to claim 1 or 2, after creating the root host bridge device node, further comprising: Create a root bus node under the root complex device node; The performing of PCIe device scan processing includes: scanning the PCIe devices connected under the root bus node and allocating resources for the scanned PCIe devices.

7. The method according to claim 6, wherein scanning the PCIe devices connected under the root bus node and allocating resources to the scanned PCIe devices comprises: If a startup command triggered by the second file mounted in the second file interface directory is received from the user, then scan the PCIe devices connected under the root bus node according to the second file and allocate resources for the scanned PCIe devices.

8. An operating system startup method, applied to a chip verification device for verifying a chip, where the chip verification device simulates the software and hardware environment of the chip, and includes: Upon initialization of the operating system, read the startup parameters; if the startup parameters indicate a delayed scan of PCIe devices, then create a root complex device node; Perform initialization processing of other hardware devices and software; Display the user login interface; if a command to scan PCIe devices is received from the user, then perform PCIe device scan processing.

9. An electronic device, comprising: A memory, a processor, a communication interface; wherein, the memory stores executable code that, when executed by the processor, causes the processor to execute the operating system startup method according to any one of claims 1 to 8.

10. A non-transitory machine-readable storage medium storing executable code that, when executed by a processor of an electronic device, causes the processor to execute the operating system startup method according to any one of claims 1 to 8.

11. A computer program product comprising a computer program that, when executed by a processor, implements the operating system startup method according to any one of claims 1 to 8. 9

Images