An operating system booting method and device based on a Feiteng processor platform

Abstract

The application discloses a kind of based on the booting method and device of operating system of Feiteng processor platform, the method includes when detecting the selection operation of real-time operating system, read target file corresponding to real-time operating system, and determine system type according to the identification data in target file;Head data is determined in target file based on system type, and the entry address corresponding to real-time operating system is obtained according to head data;Real-time operating system is guided based on system type and entry address processing.The application is parsed to the file head of the ELF format file of real-time system, to obtain system type and entry address, and address jump is realized using the function corresponding to system type, to complete the booting of real-time operating system, in addition, before detecting the selection operation of real-time operating system, booting system option can be added in UEFI BIOS interface, to solve the problem that booting real-time operating system and installing Linux operating system cannot be considered.

Description

Technical Field

[0001] This application relates to the field of computer science and technology, and in particular to an operating system booting method and apparatus based on the Phytium processor platform. Background Technology

[0002] Currently, general-purpose motherboards based on domestically produced Phytium processors are mainly used for Linux operating systems and real-time operating systems (RTOS), including VxWorks and ReWorks. Regarding the installation and booting of the operating system, existing technologies primarily employ two methods: using UEFI BIOS to install and boot the Linux operating system; or using U-Boot to install and boot the Linux operating system, as well as booting the ROS.

[0003] However, while the former has a display interface, making operating system installation more convenient, it cannot boot a real-time operating system; while the latter can boot a real-time operating system, the lack of a display interface makes installing a Linux operating system inconvenient, thus failing to simultaneously meet the needs of booting a real-time operating system and installing a Linux operating system. Summary of the Invention

[0004] To address the aforementioned problem of simultaneously failing to meet the requirements of booting a real-time operating system and installing a Linux operating system, this application provides a real-time system booting method and apparatus based on the Phytium processor platform, the technical solution of which is as follows:

[0005] In a first aspect, embodiments of this application provide a real-time system booting method based on the Phytium processor platform, including:

[0006] When a real-time operating system selection operation is detected, the target file corresponding to the real-time operating system is read, and the system type is determined based on the identification data in the target file.

[0007] Based on the system type, the header data is determined in the target file, and the entry address corresponding to the real-time operating system is obtained from the header data.

[0008] The real-time operating system is booted based on the system type and entry address.

[0009] In one alternative to the first aspect, it also includes:

[0010] When a selection operation for the Linux operating system is detected, the boot file corresponding to the Linux operating system is obtained based on a preset path;

[0011] The bootloader, which corresponds to the boot file, loads the Linux operating system kernel and then starts the Linux operating system from the loaded kernel.

[0012] In another alternative to the first aspect, reading the target file corresponding to the real-time operating system includes:

[0013] Based on the preset filename, obtain the file path corresponding to the preset filename;

[0014] Read the target file in the target terminal based on the file path.

[0015] In another alternative to the first aspect, header data is determined in the target file based on the system type, including:

[0016] When the system type is identified as the first type, the first data corresponding to the first type is obtained based on the target file and the preset first length, and the first data is used as the header data;

[0017] When the system type is identified as the second type, the second data corresponding to the second type is obtained based on the target file and the preset second length, and the second data is used as the header data; wherein, the preset second length is greater than the preset first length.

[0018] In another alternative to the first aspect, the entry address corresponding to the real-time operating system is obtained based on the header data, including:

[0019] Find the field value corresponding to the preset field name in the header data;

[0020] When a field value is detected to be empty, the preset field value is used as the entry address corresponding to the real-time operating system.

[0021] When a field value is detected to be non-empty, the field value is used as the entry address corresponding to the real-time operating system.

[0022] In another alternative to the first aspect, the real-time operating system is booted based on the system type and entry address, including:

[0023] When the system type is identified as Type 1, the target execution state of the processor is determined.

[0024] Based on the preset first function, the processor's current execution state is switched to the target execution state, and the corresponding address jump operation is executed according to the entry address to guide the real-time operating system;

[0025] When the system type is identified as the second type, the corresponding address jump operation is executed based on the preset second function and entry address to guide the real-time operating system.

[0026] In another alternative to the first aspect, after obtaining the entry address data corresponding to the real-time operating system based on the header data, and before performing boot processing on the real-time operating system based on the system type and the entry address data, the method further includes:

[0027] Determine the amount of data change in at least two registers within a preset time period, and designate the register whose data change falls within a preset threshold range as the first register;

[0028] The register that has the same name prefix as the Linux operating system among at least two registers is used as the second register;

[0029] The first register and the second register are turned off.

[0030] Secondly, embodiments of this application provide a real-time system boot device based on the Phytium processor platform, comprising:

[0031] The first processing module is used to read the target file corresponding to the real-time operating system when a selection operation of the real-time operating system is detected, and to determine the system type based on the identification data in the target file.

[0032] The second processing module is used to determine the header data in the target file based on the system type, and obtain the entry address corresponding to the real-time operating system based on the header data.

[0033] The third processing module is used to boot the real-time operating system based on the system type and entry address.

[0034] Thirdly, embodiments of this application also provide a real-time system boot device based on the Phytium processor platform, including a processor and a memory;

[0035] The processor is connected to the memory;

[0036] Memory, used to store executable program code;

[0037] The processor runs a program corresponding to the executable program code by reading the executable program code stored in the memory, so as to implement the real-time system booting method based on the Phytium processor platform provided in the first aspect or any implementation of the first aspect of the embodiments of this application.

[0038] Fourthly, embodiments of this application provide a computer storage medium storing a computer program, which includes program instructions. When executed by a processor, the program instructions can implement the real-time system booting method based on the Phytium processor platform provided in the first aspect or any implementation of the first aspect of this application.

[0039] The beneficial effects of the technical solutions provided in some embodiments of this specification include at least the following:

[0040] In the boot process of a real-time operating system (RTOS) based on the Phytium processor platform, when a ROS selection operation is detected, the target file corresponding to the ROS is read, and the system type is determined based on the identification data in the target file. Based on the system type, header data is determined in the target file, and the entry address corresponding to the ROS is obtained from the header data. The ROS is then booted based on the system type and entry address. By parsing the header of the ROS's ELF format file to obtain the system type and entry address, and using the boot function corresponding to the system type to perform address jumps, the boot of the ROS is completed. Simultaneously, before detecting the ROS selection operation, specific system options, such as VxWorks, ReWorks, and Linux, can be added in the UEFI BIOS interface to detect the selected system. This achieves the effect of using UEFI BIOS to boot the ROS without affecting the installation or booting of the Linux system, solving the problem of not being able to simultaneously meet the needs of booting the ROS and installing the Linux operating system. Attached Figure Description

[0041] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the embodiments will be briefly introduced below. Obviously, the 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.

[0042] Figure 1 A flowchart illustrating an overall system booting method based on the Phytium processor platform provided in this application embodiment;

[0043] Figure 2 A schematic diagram of a real-time system boot device based on the Phytium processor platform provided in an embodiment of this application;

[0044] Figure 3 This is a schematic diagram of another real-time system boot device based on the Phytium processor platform provided in an embodiment of this application. Detailed Implementation

[0045] The technical solutions in the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings.

[0046] In the following description, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance. The following description provides multiple embodiments of this application, which can be substituted or combined with each other. Therefore, this application can also be considered to include all possible combinations of the same and / or different embodiments described. Thus, if one embodiment includes features A, B, and C, and another embodiment includes features B and D, then this application should also be considered to include embodiments containing one or more other possible combinations of A, B, C, and D, even if such embodiments are not explicitly described in the following text.

[0047] The following description provides examples and does not limit the scope, applicability, or examples set forth in the claims. Changes may be made to the function and arrangement of the described elements without departing from the scope of this application. Various processes or components may be appropriately omitted, substituted, or added to the examples. For example, the described methods may be performed in a different order than described, and various steps may be added, omitted, or combined. Furthermore, features described with respect to some examples may be combined into other examples.

[0048] Please see Figure 1 , Figure 1 The diagram shows an overall flowchart of a real-time system booting method based on the Phytium processor platform provided in an embodiment of this application.

[0049] like Figure 1 As shown, this real-time system booting method based on the Phytium processor platform may include at least the following steps:

[0050] Step 101: When a real-time operating system selection operation is detected, read the target file corresponding to the real-time operating system and determine the system type based on the identification data in the target file.

[0051] In this embodiment, the real-time operating system booting method based on the Phytium processor platform can be applied to, but is not limited to, the Phytium processor platform. By parsing the header of the ELF format file of the real-time operating system, the system type and entry address of the real-time operating system are obtained, and address jump is implemented using the function corresponding to the system type, thus completing the booting of the real-time operating system. In addition, before detecting the selection operation of the real-time operating system, the boot system option can be added in the UEFI BIOS interface to detect the selected system, thereby achieving the simultaneous fulfillment of the requirements for booting the real-time operating system and installing the Linux operating system.

[0052] Specifically, during the boot process of a real-time operating system based on the Phytium processor platform, when a user clicks a button corresponding to a real-time operating system on the UEFI BIOS interface, the Phytium processor platform detects that the system to be booted or installed is a real-time operating system based on the type of click event. The real-time operating system includes, but is not limited to, VxWorks and ReWorks.

[0053] Understandably, UEFI (Unified Extensible Firmware Interface) defines the interface between the operating system and platform firmware, and is a standard released by the UEFI Forum; BIOS (Basic Input / Output System) is a boot firmware based on the processor platform, used for hardware detection, device initialization, operating system booting, and providing a configuration interface; a real-time operating system is an operating system that can complete specific functions within a certain time limit, characterized by timely response and high reliability. It is worth noting that UEFI BIOS not only supports larger hard drives and higher-level operating systems, but also, due to its flexible graphical interface settings (such as the ability to add system option buttons), it has richer options and functions, gradually becoming the mainstream system firmware. Furthermore, based on the name of the real-time operating system, a system file (i.e., the target file) with the same system name and in ELF format is read. The reading methods include, but are not limited to, the following four: First, sequential reading, which reads bytes or characters from the beginning of the file one by one; second, using standard library functions, which uses standard library functions provided by the programming language that support file reading, such as fopen and fread functions provided by C to read the contents of the ELF file; third, using a dedicated ELF processing library, which uses libraries provided by the programming language or tools specifically for parsing and processing ELF files. These libraries provide a set of APIs and functions that can read and manipulate various parts and fields of the ELF file, such as libelf or elfio libraries in C; and fourth, using specific tools, which uses specific ELF processing tools or command-line tools to read the ELF file, such as objdump and readelf.

[0054] Afterwards, the first 16 bytes of data in the ELF file can be read to obtain the array data used to identify the type and attributes of the ELF file, namely the e_ident field. Since the field identifying the system type is fixed in the fifth data in the array, namely e_ident[4], the system type can be determined by the value of the fifth byte of data (i.e., e_ident[4]). The determination method is as follows: e_ident[4]==1 represents a 32-bit system type, and e_ident[4]==2 represents a 64-bit system type.

[0055] As an optional embodiment of this application, it also includes:

[0056] When a selection operation for the Linux operating system is detected, the boot file corresponding to the Linux operating system is obtained based on a preset path;

[0057] The bootloader, which corresponds to the boot file, loads the Linux operating system kernel and then starts the Linux operating system from the loaded kernel.

[0058] Specifically, during the real-time system boot process based on the Phytium processor platform, when the user clicks the button corresponding to the Linux operating system on the UEFI BIOS interface, the Phytium processor platform detects that the system to be booted or installed is the Linux operating system based on the type of click event.

[0059] Next, the BOOTAA64.efi file, corresponding to the Linux operating system, can be found on the device according to the preset paths. These preset paths include, but are not limited to, EFI\BOOT\BOOTAA64.efi, EFI\ubuntu\BOOTAA64.efi, and EFI\arch\BOOTAA64.efi. It's understood that the BOOTAA64.efi file is usually located in a subfolder of the EFI folder, which is the folder of the EFI system partition. This partition typically contains a device with a file system, such as a hard drive, USB flash drive, or optical disc.

[0060] Next, the BOOTAA64.efi file can be executed to load the GRUB bootloader. GRUB loads the Linux operating system kernel into memory and starts the kernel to boot and install the Linux system.

[0061] As another optional embodiment of this application, reading the target file corresponding to the real-time operating system includes:

[0062] Based on the preset filename, obtain the file path corresponding to the preset filename;

[0063] Read the target file in the target terminal based on the file path.

[0064] Specifically, during the process of reading the target file, the target terminal can first be searched for based on the preset filename to obtain the file path of the target file. Then, the file path can be passed as a parameter to the file reading function (such as fopen) to read the target file. The preset filename can be the filename corresponding to the system name on the system option button on the UEFI BIOS interface, and the target terminal includes, but is not limited to, hard drives and USB flash drives.

[0065] Step 102: Determine the header data in the target file based on the system type, and obtain the entry address corresponding to the real-time operating system based on the header data.

[0066] Specifically, the structure and size of the header data corresponding to the system type can be determined based on the system type. This header data refers to the portion of the ELF file containing the file's basic information; it is located at the beginning of the entire file content and contains the entry address corresponding to the real-time operating system. It is worth noting that the entry address differs between different header data types. For example, in a 32-bit system, the entry address in the ELF file header is a 32-bit unsigned integer, while in a 64-bit system, it is a 64-bit unsigned integer.

[0067] As another optional embodiment of this application, the header data is determined in the target file based on the system type, including:

[0068] When the system type is identified as the first type, the first data corresponding to the first type is obtained based on the target file and the preset first length, and the first data is used as the header data;

[0069] When the system type is identified as the second type, the second data corresponding to the second type is obtained based on the target file and the preset second length, and the second data is used as the header data; wherein, the preset second length is greater than the preset first length.

[0070] Specifically, the method for determining different header data based on the system type can be, but is not limited to, the following: When the system type is identified as 32-bit (i.e., the first type), the header data corresponding to the 32-bit system (i.e., the first data) can be obtained in the target file based on the length of the header data corresponding to the 32-bit system—52 bytes (i.e., the preset first length); when the system type is identified as 64-bit (i.e., the second type), the header data corresponding to the 64-bit system (i.e., the second data) can be obtained in the target file based on the length of the header data corresponding to the 64-bit system—72 bytes (i.e., the preset second length). The method for obtaining the header data can be, but is not limited to, positioning the file pointer at the beginning of the header file, using a file operation function such as fseek() to move the file pointer to the offset position in the header file, and creating a buffer to store the header data, the size of which is at least equal to the length of the header data.

[0071] Here, please refer to the following header data example corresponding to a 32-bit system:

[0072] Elf32_Ehdr includes:

[0073] unsigned char e_ident[EI_NIDENT] (magic number and other information);

[0074] Elf32_Half e_type (file type);

[0075] Elf32_Half e_machine (system architecture);

[0076] Elf32_Word e_version (version);

[0077] Elf32_Addr e_entry (entry address);

[0078] Elf32_Off e_phoff (file offset of the program header table);

[0079] Elf32_Off e_shoff (file offset of the section header table);

[0080] Elf32_Word e_flags (flags);

[0081] Elf32_Half e_ehsize (size of header data);

[0082] Elf32_Half e_phentsize (header size);

[0083] Elf32_Half e_phnum (the number of entries in the program header table);

[0084] Elf32_Half e_shentsize (header size);

[0085] Elf32_Half e_shnum (the number of entries in the program header table);

[0086] Elf32_Half e_shstrndx (string segment index).

[0087] As another optional embodiment of this application, the entry address corresponding to the real-time operating system is obtained based on the header data, including:

[0088] Find the field value corresponding to the preset field name in the header data;

[0089] When a field value is detected to be empty, the preset field value is used as the entry address corresponding to the real-time operating system.

[0090] When a field value is detected to be non-empty, the field value is used as the entry address corresponding to the real-time operating system.

[0091] Specifically, after obtaining the header data corresponding to the system type, since the field name storing the entry address in the header data is fixed, it is used as a preset field name (i.e., e_entry), and this is used as the search condition to query the field value corresponding to this field name in the header data. When the value of e_entry is found and obtained, the entry address corresponding to the real-time operating system can be determined based on whether the entry address is empty. The determination method can be, but is not limited to: when the entry address is empty, the preset field value is used as the entry address corresponding to the real-time operating system; when the entry address is not empty, the obtained value of e_entry is used as the entry address corresponding to the real-time operating system. The preset field value includes, but is not limited to, the common default entry address 0x80100000 for 32-bit ELF files and the common default entry address 0x4000000000 for 64-bit ELF files.

[0092] Step 103: Perform boot processing on the real-time operating system based on the system type and entry address.

[0093] Specifically, after obtaining the entry address, the boot function corresponding to the system type can be determined. The boot function for a 32-bit system is `armv8_el2_to_aarch32`, and the boot function for a 64-bit system is `do_bootelf_exec`. Furthermore, the entry address can be passed as a parameter to the corresponding boot function, which then performs the boot process for the real-time operating system.

[0094] As another optional embodiment of this application, the real-time operating system is booted based on the system type and entry address, including:

[0095] When the system type is identified as Type 1, the target execution state of the processor is determined.

[0096] Based on the preset first function, the processor's current execution state is switched to the target execution state, and the corresponding address jump operation is executed according to the entry address to guide the real-time operating system;

[0097] When the system type is identified as the second type, the corresponding address jump operation is executed based on the preset second function and entry address to guide the real-time operating system.

[0098] Specifically, before booting the real-time operating system, the system type can be determined first. When the system type is 32-bit (i.e., type 1), since the Phytium processor is 64-bit, the target execution state (aarch32 state) of the processor can be determined first, which is the execution state applicable to a 32-bit system. Next, the execution state is switched using the armv8_el2_to_aarch32 function (i.e., the preset first function). The process includes, but is not limited to, the following six steps: initializing the timer, initializing the MPIDR register, disabling the coprocessor, initializing the hypervisor control register, initializing the system control register, and returning from EL2 mode to EL1 mode. EL1 and EL2 are two different privileged modes; EL1 is generally used for the operating system or some privileged functions, while EL2 is generally used for virtualization. Then, the entry address is passed as a parameter, and the armv8_el2_to_aarch32 function receives this parameter and performs the corresponding address jump operation to boot the real-time operating system.

[0099] When the system type is 64-bit (i.e., type 2), the entry address can be passed to the do_bootelf_exec function (i.e., the preset type 2 function), and this function can directly perform the address jump operation to realize the boot process of the real-time operating system.

[0100] It's understandable that booting an operating system essentially involves jumping to a specific memory address. A jump address is an instruction that transfers execution from the current instruction sequence to a specified memory address. During the boot process, the bootloader uses jump instructions to transfer control to the operating system's entry point, allowing the operating system to begin execution.

[0101] It's worth noting that booting an operating system involves more processes, such as initializing hardware, setting environment variables, and loading drivers. However, overall, the core step in booting an operating system is to transfer control to the operating system via a jump address.

[0102] As another optional embodiment of this application, after obtaining the entry address data corresponding to the real-time operating system based on the header data, and before performing boot processing on the real-time operating system based on the system type and the entry address data, the method further includes:

[0103] Determine the amount of data change in at least two registers within a preset time period, and designate the register whose data change falls within a preset threshold range as the first register;

[0104] The register that has the same name prefix as the Linux operating system among at least two registers is used as the second register;

[0105] The first register and the second register are turned off.

[0106] Specifically, after obtaining the entry address and before booting the real-time operating system, the usage of at least two registers can be determined based on the amount of data change in the registers within a preset time period. When the amount of data change is within a preset threshold range, it can be regarded as a register temporarily used during the boot process, i.e., the first register. The preset time period can be, but is not limited to, the time period from the detection of the selection operation to the acquisition of the entry address.

[0107] Next, based on the name prefixes of at least two registers, it can be determined whether the register is a system control register and used as the second register. For example, in the x86 architecture, system control registers generally start with CR, such as CR0, CR2, CR3, etc.

[0108] Afterwards, the first and second registers can be disabled to free up resources for subsequent system use. Simultaneously, in the UEFI BIOS setup interface, you can access the "Boot" or "Startup" options, find options such as "Fast Startup," "Fast Boot," and "Fast Startup Mode," and disable them to improve system startup speed.

[0109] It is worth noting that during the real-time system boot process based on the Phytium processor platform, since the Phytium processor is a multi-core processor, it is also necessary to wake up the slave cores to ensure normal multi-core operation. This waking up of the slave cores must occur at least before the aforementioned register shutdown and service disabling.

[0110] Please see Figure 2 , Figure 2This illustration shows a schematic diagram of a real-time system boot device based on the Phytium processor platform provided in an embodiment of this application.

[0111] like Figure 2 As shown, the real-time system boot device based on the Phytium processor platform may include at least a first processing module 201, a second processing module 202, a third processing module 203, and a fourth processing module 204, wherein:

[0112] The first processing module 201 is used to read the target file corresponding to the real-time operating system when a selection operation of the real-time operating system is detected, and to determine the system type based on the identification data in the target file.

[0113] The second processing module 202 is used to determine the header data in the target file based on the system type, and obtain the entry address corresponding to the real-time operating system based on the header data.

[0114] The third processing module 203 is used to perform boot processing on the real-time operating system based on the system type and entry address.

[0115] In some possible embodiments, it also includes:

[0116] The first processing module 201 is specifically used for:

[0117] When a selection operation for the Linux operating system is detected, the boot file corresponding to the Linux operating system is obtained based on a preset path;

[0118] The bootloader, which corresponds to the boot file, loads the Linux operating system kernel and then starts the Linux operating system from the loaded kernel.

[0119] In some possible embodiments, reading the target file corresponding to the real-time operating system includes:

[0120] The first processing module 201 is specifically used for:

[0121] Based on the preset filename, obtain the file path corresponding to the preset filename;

[0122] Read the target file in the target terminal based on the file path.

[0123] In some possible embodiments, header data is determined in the target file based on the system type, including:

[0124] The second processing module 202 is specifically used for:

[0125] When the system type is identified as the first type, the first data corresponding to the first type is obtained based on the target file and the preset first length, and the first data is used as the header data;

[0126] When the system type is identified as the second type, the second data corresponding to the second type is obtained based on the target file and the preset second length, and the second data is used as the header data; wherein, the preset second length is greater than the preset first length.

[0127] In some possible embodiments, the entry address corresponding to the real-time operating system is obtained based on the header data, including:

[0128] The second processing module 202 is specifically used for:

[0129] Find the field value corresponding to the preset field name in the header data;

[0130] When a field value is detected to be empty, the preset field value is used as the entry address corresponding to the real-time operating system.

[0131] When a field value is detected to be non-empty, the field value is used as the entry address corresponding to the real-time operating system.

[0132] In some possible embodiments, the real-time operating system is booted based on the system type and entry address, including:

[0133] The third processing module 203 is specifically used for:

[0134] When the system type is identified as Type 1, the target execution state of the processor is determined.

[0135] Based on the preset first function, the processor's current execution state is switched to the target execution state, and the corresponding address jump operation is executed according to the entry address to guide the real-time operating system;

[0136] When the system type is identified as the second type, the corresponding address jump operation is executed based on the preset second function and entry address to guide the real-time operating system.

[0137] In some possible embodiments, after obtaining the entry address data corresponding to the real-time operating system based on the header data, and before performing boot processing on the real-time operating system based on the system type and the entry address data, the method further includes:

[0138] The third processing module 203 is specifically used for:

[0139] Determine the amount of data change in at least two registers within a preset time period, and designate the register whose data change falls within a preset threshold range as the first register;

[0140] The register that has the same name prefix as the Linux operating system among at least two registers is used as the second register;

[0141] The first register and the second register are turned off.

[0142] Please see Figure 3 , Figure 3 This illustration shows a schematic diagram of another real-time system boot device based on the Phytium processor platform provided in an embodiment of this application.

[0143] like Figure 3 As shown, the real-time system boot device 300 based on the Phytium processor platform may include at least one processor 301, at least one network interface 304, a user interface 303, a memory 305, and at least one communication bus 302.

[0144] The communication bus 302 can be used to realize the connection and communication of the above components.

[0145] The user interface 303 may include buttons, and the optional user interface may also include a standard wired interface or a wireless interface.

[0146] The network interface 304 may include, but is not limited to, Bluetooth modules, NFC modules, Wi-Fi modules, etc.

[0147] The processor 301 may include one or more processing cores. The processor 301 connects to various parts of the real-time system boot device 300 based on the Phytium processor platform using various interfaces and lines. It executes various functions and processes data of the real-time system boot device 300 by running or executing instructions, programs, code sets, or instruction sets stored in memory 305, and by calling data stored in memory 305. Optionally, the processor 301 may be implemented using at least one hardware form of DSP, FPGA, or PLA. The processor 301 may integrate one or more of the following: CPU, GPU, and modem. The CPU primarily handles the operating system, user interface, and applications; the GPU is responsible for rendering and drawing the content required for display; and the modem handles wireless communication. It is understood that the modem may also not be integrated into the processor 301 and may be implemented as a separate chip.

[0148] The memory 305 may include RAM or ROM. Optionally, the memory 305 may include a non-transitory computer-readable medium. The memory 305 may be used to store instructions, programs, code, code sets, or instruction sets. The memory 305 may include a program storage area and a data storage area, wherein the program storage area may store instructions for implementing an operating system, instructions for at least one function (such as touch function, sound playback function, image playback function, etc.), instructions for implementing the above-described method embodiments, etc.; the data storage area may store data involved in the above-described method embodiments, etc. Optionally, the memory 305 may also be at least one storage device located remotely from the aforementioned processor 301. Figure 3 As shown, the memory 305, which serves as a computer storage medium, may include an operating system, a network communication module, a user interface module, and a real-time system boot application based on the Phytium processor platform.

[0149] Specifically, processor 301 can be used to call the real-time system boot application based on the Phytium processor platform stored in memory 305, and specifically perform the following operations:

[0150] When a real-time operating system selection operation is detected, the target file corresponding to the real-time operating system is read, and the system type is determined based on the identification data in the target file.

[0151] Based on the system type, the header data is determined in the target file, and the entry address corresponding to the real-time operating system is obtained from the header data.

[0152] The real-time operating system is booted based on the system type and entry address.

[0153] This application also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the above-described method. The computer-readable storage medium may include, but is not limited to, any type of disk, including floppy disks, optical disks, DVDs, CD-ROMs, microdrives, as well as magneto-optical disks, ROMs, RAMs, EPROMs, EEPROMs, DRAMs, VRAMs, flash memory devices, magnetic cards or optical cards, nanosystems (including molecular memory ICs), or any type of medium or device suitable for storing instructions and / or data.

[0154] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that this application is not limited to the described order of actions, as some steps may be performed in other orders or simultaneously according to this application. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are preferred embodiments, and the actions and modules involved are not necessarily essential to this application.

[0155] In the above embodiments, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions in other embodiments.

[0156] In the several embodiments provided in this application, it should be understood that the disclosed apparatus can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some service interface; the indirect coupling or communication connection between apparatuses or units may be electrical or other forms.

[0157] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0158] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0159] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage device (CMD). Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a memory and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this application. The aforementioned memory includes various media capable of storing program code, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard drive, magnetic disk, or optical disk.

[0160] Those skilled in the art will understand that all or part of the steps in the various methods of the above embodiments can be implemented by a program instructing related hardware. The program can be stored in a computer-readable storage medium, which may include: a flash drive, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk, etc.

[0161] The above are merely exemplary embodiments of this disclosure and should not be construed as limiting the scope of this disclosure. Any equivalent changes and modifications made in accordance with the teachings of this disclosure shall still fall within the scope of this disclosure. Those skilled in the art will readily conceive of embodiments of this disclosure upon considering the specification and practicing the disclosure herein. This application is intended to cover any variations, uses, or adaptations of this disclosure that follow the general principles of this disclosure and include common knowledge or customary techniques in the art not described herein. The specification and embodiments are to be considered exemplary only, and the scope and spirit of this disclosure are defined by the claims.

Claims

1. An operating system booting method based on the Phytium processor platform, characterized in that, include: When a real-time operating system selection operation is detected, the target file corresponding to the real-time operating system is read, and the system type is determined based on the identification data in the target file; Based on the system type, the header data is determined in the target file, and the entry address corresponding to the real-time operating system is obtained based on the header data; The real-time operating system is booted based on the system type and the entry address. The process of determining the header data in the target file based on the system type includes: When the system type is identified as the first type, first data corresponding to the first type is obtained based on the target file and a preset first length, and the first data is used as header data; When the system type is identified as the second type, second data corresponding to the second type is obtained based on the target file and a preset second length, and the second data is used as header data; wherein, the preset second length is greater than the preset first length; The step of obtaining the entry address corresponding to the real-time operating system based on the header data includes: Find the field value corresponding to the preset field name in the header data; When the field value is detected to be empty, the preset field value is used as the entry address corresponding to the real-time operating system; When the field value is detected to be non-empty, the field value is used as the entry address corresponding to the real-time operating system; The booting process of the real-time operating system based on the system type and the entry address includes: When the system type is identified as the first type, the target execution state of the processor is determined; Based on a preset first function, the processor's current execution state is switched to the target execution state, and a corresponding address jump operation is performed according to the entry address to guide the real-time operating system. When the system type is identified as the second type, a corresponding address jump operation is executed based on the preset second function and the entry address to guide the real-time operating system. After obtaining the entry address data corresponding to the real-time operating system based on the header data, and before performing boot processing on the real-time operating system based on the system type and the entry address data, the method further includes: Determine the amount of data change in at least two registers within a preset time period, and designate the register whose data change falls within a preset threshold range as the first register; The register that has the same name prefix as the Linux operating system among the at least two registers shall be used as the second register; The first register and the second register are closed.

2. The method according to claim 1, characterized in that, Also includes: When a selection operation for the Linux operating system is detected, the boot file corresponding to the Linux operating system is obtained based on a preset path; The kernel of the Linux operating system is loaded based on the boot program corresponding to the boot file, and the loaded kernel of the Linux operating system is then started.

3. The method according to claim 1, characterized in that, The reading of the target file corresponding to the real-time operating system includes: Based on a preset filename, obtain the file path corresponding to the preset filename; The target file is read in the target terminal according to the file path.

4. An operating system boot device based on the Phytium processor platform, characterized in that, include: The first processing module is used to read the target file corresponding to the real-time operating system when a selection operation of the real-time operating system is detected, and to determine the system type based on the identification data in the target file; The second processing module is used to determine the header data in the target file based on the system type, and to obtain the entry address corresponding to the real-time operating system based on the header data. The third processing module is used to perform boot processing on the real-time operating system based on the system type and the entry address; Based on the system type, the header data is determined in the target file, including: The second processing module is also specifically used for: When the system type is identified as the first type, the first data corresponding to the first type is obtained based on the target file and the preset first length, and the first data is used as the header data; When the system type is identified as the second type, the second data corresponding to the second type is obtained based on the target file and the preset second length, and the second data is used as the header data; wherein the preset second length is greater than the preset first length. The entry address corresponding to the real-time operating system is obtained based on the header data. The second processing module is also specifically used for: Find the field value corresponding to the preset field name in the header data; When a field value is detected to be empty, the preset field value is used as the entry address corresponding to the real-time operating system. When a field value is detected to be non-empty, the field value is used as the entry address corresponding to the real-time operating system. The real-time operating system is booted based on system type and entry address, including: The third processing module is also specifically used for: When the system type is identified as Type 1, the target execution state of the processor is determined. Based on the preset first function, the processor's current execution state is switched to the target execution state, and the corresponding address jump operation is executed according to the entry address to guide the real-time operating system; When the system type is identified as the second type, the corresponding address jump operation is executed based on the preset second function and entry address to guide the real-time operating system. After obtaining the entry address data corresponding to the real-time operating system from the header data, and before performing boot processing on the real-time operating system based on the system type and entry address data, the following steps are also included: The third processing module is also specifically used for: Determine the amount of data change in at least two registers within a preset time period, and designate the register whose data change falls within a preset threshold range as the first register; The register that has the same name prefix as the Linux operating system among at least two registers is used as the second register; The first register and the second register are turned off.

5. An operating system boot device based on the Phytium processor platform, characterized in that, Including the processor and memory; The processor is connected to the memory; The memory is used to store executable program code; The processor runs a program corresponding to the executable program code stored in the memory to perform the steps of the method as described in any one of claims 1-3.

6. A computer-readable storage medium having a computer program stored thereon, characterized in that, The computer-readable storage medium stores instructions that, when executed on a computer or processor, cause the computer or processor to perform the steps of the method as described in any one of claims 1-3.

Images