Guiding method and device of RTEMS system, equipment and medium

Abstract

The embodiment of the invention provides a booting method of an RTEMS system, target data of a self-booting system program is burnt in a nonvolatile memory of a system chip, and the booting program and first system mirror image data correspond to the same compiling environment; under the condition that the bootstrap program is in a bootstrap mode, the first system mirror image data are read from the nonvolatile memory, and the RTEMS system is started according to the first system mirror image data; under the condition that the starting of the RTEMS system is abnormal, switching to an upgrading mode; under the condition that the working mode of the bootstrap program is an upgrading mode, acquiring second system mirror image data from the external equipment; performing second verification on the second system mirror image file according to the second verification information; and if the second verification is passed, starting the RTEMS system according to the second system mirror image file. According to the embodiment of the invention, the development efficiency, the starting success rate, the safety and the reliability of the RTEMS system software can be improved.

Description

Technical Field

[0001] The embodiments of the present application relate to the field of computer technologies, and particularly to a method, device, equipment and medium for booting an RTEMS system. Background Art

[0002] RTEMS (Real-Time Executive for Multiprocessor Systems) is an open-source, real-time, multiprocessor operating system, which is widely used in high-reliability fields such as aerospace, national defense, and industrial control. Currently, U-BOOT (Universal Boot Loader) is usually used to boot the RTEMS system.

[0003] The method for booting an RTEMS system in the prior art specifically includes the following steps:

[0004] Step of building a compilation environment: Build the compilation environments of U-BOOT and the RTEMS system respectively; the compilation environment of U-BOOT is used to compile the U-BOOT source code into an executable boot program suitable for the target hardware board; the compilation environment of the RTEMS system is used to compile and generate a runnable RTEMS system image.

[0005] Step of driver adaptation: Write or transplant the driver programs of U-BOOT and the RTEMS system respectively according to the specifications of the target hardware board; the driver program of U-BOOT is used to help the executable boot program identify and initialize the target hardware board; the driver program of RTEMS is used to provide hardware support for the normal operation of the RTEMS system image.

[0006] Step of burning and debugging: Burn the compiled executable boot program onto the target hardware board, and then debug the executable boot program until it can be normally started on the target hardware board; and use the compilation environment of the RTEMS system to make an RTEMS system image, which includes the kernel and related files of the RTEMS system.

[0007] Step of system booting: After the executable boot program is normally started, boot the RTEMS system image, and finally realize the normal startup and operation of the RTEMS system on the target hardware board.

[0008] In the method for booting an RTEMS system in the prior art, a large amount of time and effort are required for building the compilation environments of U-BOOT and the RTEMS system respectively, driver adaptation, burning and debugging, etc., which significantly lengthens the development cycle from building the compilation environment to the successful operation of the system, resulting in low development efficiency of the RTEMS system software. Summary of the Invention

[0009] An embodiment of the present application provides a method for booting an RTEMS system, which can improve the development efficiency, startup success rate, and safety and reliability of the RTEMS system software.

[0010] Correspondingly, an embodiment of the present application further provides a booting device for an RTEMS system, an electronic device, and a machine-readable medium to ensure the implementation and application of the above method.

[0011] To solve the above problems, an embodiment of the present application discloses a method for booting an RTEMS system. Target data of a self-booting system program is burned into the non-volatile memory of the system chip. The target data includes: a boot program and first system image data of the RTEMS system. The boot program and the first system image data correspond to the same compilation environment. The boot program runs after the system chip is powered on, and the method includes the following steps:

[0012] When the working mode of the boot program is the boot mode, read the first system image data from the non-volatile memory and start the RTEMS system according to the first system image data.

[0013] When the startup of the RTEMS system is abnormal, switch to the upgrade mode.

[0014] When the working mode of the boot program is the upgrade mode, obtain second system image data from an external device. The second system image data includes: second verification information and a second system image file.

[0015] Perform a second verification on the second system image file according to the second verification information.

[0016] If the second verification passes, start the RTEMS system according to the second system image file.

[0017] An embodiment of the present application further discloses a booting device for an RTEMS system. Target data of a self-booting system program is burned into the non-volatile memory of the system chip. The target data includes: a boot program and first system image data of the RTEMS system. The boot program and the first system image data correspond to the same compilation environment. The boot program runs after the system chip is powered on and includes the following modules:

[0018] A boot mode processing module, configured to, when the working mode of the boot program is the boot mode, read the first system image data from the non-volatile memory and start the RTEMS system according to the first system image data.

[0019] A mode switching module, configured to switch to an upgrade mode in case of a startup exception of the RTEMS system;

[0020] An external acquisition module, configured to acquire second system image data from an external device when the working mode of the bootloader is the upgrade mode; the second system image data includes: second verification information and a second system image file;

[0021] A second verification module, configured to perform a second verification on the second system image file according to the second verification information;

[0022] A system startup module, configured to start the RTEMS system according to the second system image file if the second verification is passed.

[0023] Optionally, the system startup module includes:

[0024] A second decompression module, configured to decompress the second system image file to a second address in the volatile memory; the second target system image file represents the decompressed second system image file;

[0025] A second pointer setting module, configured to set the program counter pointer of the processor in the system chip to the first program instruction address of the second target system image file to implement the startup of the RTEMS system.

[0026] Optionally, the second verification information includes: a second digital signature and a second public key;

[0027] The second verification module is specifically configured to determine the hash value corresponding to the second system image file; determine the verification hash value according to the second digital signature and the second public key; if the hash value is consistent with the verification hash value, the second verification is passed; or, if the hash value is inconsistent with the verification hash value, the second verification fails.

[0028] Optionally, the second verification information includes: a key ciphertext;

[0029] The second verification module is specifically configured to decrypt the key ciphertext by using a preset private key to obtain a key plaintext; decrypt the second system image file by using the key plaintext, if the decryption is successful, the second verification is passed, if the decryption fails, the second verification fails.

[0030] Optionally, the external acquisition module is specifically configured to acquire the second system image data from a server or an external storage device.

[0031] Optionally, the apparatus further includes:

[0032] A first working mode determination module, configured to determine the working mode of the bootloader according to jumpers on the board where the system chip is located and / or pins of the system chip before the RTEMS system starts; the working modes include: a boot mode or an upgrade mode; or

[0033] A second working mode determination module, configured to determine the working mode of the bootloader according to instructions interactively sent by a user via a graphical software interface, or a text command line tool, or an external programmable device after the RTEMS system starts.

[0034] Optionally, the device further includes:

[0035] An initialization module, configured to initialize a first preset component on the system chip before reading first system image data from a non-volatile memory when the working mode of the bootloader is the boot mode; the first preset component includes: a clock, a serial port, a network device, and a storage device.

[0036] Optionally, the boot mode processing module includes:

[0037] A first decompression module, configured to decompress a first system image file in the first system image data to a second address in a volatile memory; the first target system image file represents the decompressed first system image file;

[0038] A first pointer setting module, configured to set the program counter pointer of the processor in the system chip to the address of the first program instruction of the first target system image file to implement the startup of the RTEMS system.

[0039] An embodiment of the present application also discloses an electronic device, including: a processor; and a memory, on which executable code is stored, and when the executable code is executed, the processor is caused to execute the method as described in the embodiment of the present application.

[0040] An embodiment of the present application also discloses a machine-readable medium, on which executable code is stored, and when the executable code is executed, a processor is caused to execute the method as described in the embodiment of the present application.

[0041] The embodiments of the present application have the following advantages:

[0042] In the technical solution of the embodiment of the present application, the system-on-chip is pre-burned with a bootloader and first system image data corresponding to the same compilation environment. After the system is powered on, the bootloader starts running. In the case of the boot mode, the bootloader reads the first system image data from the non-volatile memory and starts the RTEMS system based on the first system image data. If an exception occurs during the startup process of the RTEMS system in the boot mode, the bootloader will switch to the upgrade mode, obtain the second system image data including the second verification information and the second system image file from an external device, and after the second system image file passes the second verification, start the RTEMS system using the second system image file.

[0043] Since the bootloader and the system image data of the embodiment of the present application adopt the same compilation environment, compared with building the compilation environment for the bootloader and the system image data separately, the development time of the RTEMS system software is reduced, so the development efficiency of the RTEMS system software can be improved.

[0044] Moreover, if an exception occurs during the startup process of the RTEMS system in the boot mode, the bootloader of the embodiment of the present application will switch to the upgrade mode and obtain new second system image data in the upgrade mode. The above processing provides an effective remedy for the abnormal startup situation of the RTEMS system, improving the startup success rate and system stability of the RTEMS system.

[0045] In addition, in the upgrade mode of the embodiment of the present application, the second system image data including the second verification information and the second system image file is obtained from an external device, and after the second system image file passes the second verification, the RTEMS system is started using the second system image file. The above second verification can detect the tampered second system image file and prevent it from being loaded onto the system-on-chip, thereby improving the security and reliability of the startup of the RTEMS system. Description of the Drawings

[0046] Figure 1 is a schematic flowchart of a method for booting an RTEMS system according to an embodiment of the present application;

[0047] Figure 2 is a schematic diagram of target data stored in a non-volatile memory according to an embodiment of the present application;

[0048] Figure 3 is a schematic diagram of a bootloader reading data from a non-volatile memory according to an embodiment of the present application;

[0049] Figure 4 is a schematic flowchart of a method for booting an RTEMS system according to an embodiment of the present application;

[0050] Figure 5Schematic structural diagram of a boot device of an RTEMS system according to an embodiment of the present application;

[0051] Figure 6 Schematic structural diagram of a device provided by an embodiment of the present application. Detailed implementation manners

[0052] To make the above objects, features, and advantages of the present application more obvious and understandable, the present application will be further described in detail below with reference to the accompanying drawings and specific implementation manners.

[0053] In the embodiment of the present application, the boot of the RTEMS system refers to a series of operation processes starting from the power-on or reset of the system chip where the RTEMS system is located until the kernel and related components of the RTEMS system are loaded and ready to run.

[0054] A system chip is an integrated circuit that integrates multiple functional modules on one chip. It usually includes components such as a CPU (Central Processing Unit), a GPU (Graphics Processing Unit), memory, and input / output interfaces, and can independently complete complex system functions, such as running an operating system and processing various data. It is the core component of an electronic device, which can greatly improve the device performance and reduce power consumption.

[0055] A hardware board is a physical board with a specific circuit structure, on which various electronic components and circuits are integrated. The hardware board provides electrical connection, physical support, and a working environment for the system chip and other electronic components, interacts with external devices through interfaces, and realizes functions such as data transmission and signal processing. It is an important part of an electronic device to achieve specific functions, and its functions can be flexibly expanded through expansion interfaces.

[0056] In the existing RTEMS system boot method, a large amount of time and effort are required for the construction of the compilation environments of U-BOOT and the RTEMS system respectively, driver adaptation, flashing, and debugging, etc., which significantly lengthens the development cycle from the construction of the compilation environment to the successful operation of the system, resulting in low development efficiency of the RTEMS system software.

[0057] Aiming at the technical problem of low development efficiency of the RTEMS system software in the existing technology, the embodiment of the present application provides a boot method for the RTEMS system. Target data of a self-boot system program is burned in the non-volatile memory of the system chip. The above target data includes: a boot program and first system image data of the RTEMS system; the above boot program and the first system image data correspond to the same compilation environment; the above boot program runs after the system chip is powered on and executes the following steps included in the above method:

[0058] When the operating mode of the bootloader is the boot mode, read the first system image data from the non-volatile memory and start the RTEMS system according to the above first system image data;

[0059] When the startup of the RTEMS system is abnormal, switch to the upgrade mode;

[0060] When the operating mode of the bootloader is the upgrade mode, obtain the second system image data from an external device; the above second system image data includes: second verification information and a second system image file;

[0061] Perform a second verification on the second system image file according to the above second verification information;

[0062] If the second verification passes, start the RTEMS system according to the above second system image file.

[0063] In the technical solution of the embodiment of the present application, the system chip is pre-burned with a bootloader and first system image data corresponding to the same compilation environment. After the system is powered on, the bootloader starts to run. In the case of the boot mode, the bootloader reads the first system image data from the non-volatile memory and starts the RTEMS system based on the first system image data. If an abnormality occurs during the startup process of the RTEMS system in the boot mode, the bootloader will switch to the upgrade mode, obtain the second system image data including the second verification information and the second system image file from an external device, and after the second system image file passes the second verification, start the RTEMS system using the second system image file.

[0064] Since the bootloader and the system image data of the embodiment of the present application adopt the same compilation environment, compared with separately building the compilation environment for the bootloader and the system image data, the development time of the RTEMS system software is reduced, so the development efficiency of the RTEMS system software can be improved.

[0065] Moreover, if an abnormality occurs during the startup process of the RTEMS system in the boot mode, the bootloader of the embodiment of the present application will switch to the upgrade mode and obtain new second system image data in the upgrade mode. The above processing provides an effective remedy for the abnormal startup situation of the RTEMS system, improving the startup success rate and system stability of the RTEMS system.

[0066] In addition, in the upgrade mode of the embodiments of the present application, second system image data including second verification information and a second system image file is obtained from an external device. After the second system image file passes the second verification, the RTEMS system is started using the second system image file. The above-mentioned second verification can detect a tampered second system image file and prevent it from being loaded onto the system chip, thereby improving the security and reliability of the RTEMS system startup.

[0067] Method Embodiment 1

[0068] Reference Figure 1 , which shows a schematic flowchart of the steps of the boot method of the RTEMS system according to an embodiment of the present application. Among them, target data of the self-boot system program is burned in the non-volatile memory of the system chip. The above-mentioned target data specifically includes: a boot program and first system image data of the RTEMS system; the above-mentioned boot program and the first system image data correspond to the same compilation environment; the above-mentioned boot program runs after the system chip is powered on and executes the following steps included in the above method:

[0069] Step 101: When the working mode of the boot program is the boot mode, read the first system image data from the non-volatile memory and start the RTEMS system according to the above first system image data;

[0070] Step 102: When the startup of the RTEMS system is abnormal, switch to the upgrade mode;

[0071] Step 103: When the working mode of the boot program is the upgrade mode, obtain second system image data from an external device; the above-mentioned second system image data specifically includes: second verification information and a second system image file;

[0072] Step 104: Perform a second verification on the second system image file according to the above second verification information;

[0073] Step 105: If the second verification passes, start the RTEMS system according to the above second system image file.

[0074] In the embodiments of the present application, a non-volatile memory refers to a memory that can still retain stored data without loss after the computer system is powered off. In contrast, there is a volatile memory, such as RAM (Random Access Memory), and once powered off, the data stored in it will be immediately lost.

[0075] Examples of non-volatile memories may include: ROM (Read-Only Memory), Flash Memory, HDD (Hard Disk Drive), PCM (Phase Change Memory), RRAM (Resistive Random Access Memory), and FRAM (Ferroelectric Random Access Memory), etc.

[0076] The self-booting system program of the embodiments of the present application may refer to a program that can automatically load and boot the operating system after the system chip is powered on.

[0077] The self-booting system program of the embodiments of the present application can be used to automatically load and boot the operation of the RTEMS system after the system chip is powered on.

[0078] The target data of the self-booting system program specifically includes: the boot program and the first system image data of the RTEMS system. Among them, the boot program is used to initialize the hardware components on the system chip, read the first system image data from the non-volatile memory, and create a memory space mapping to prepare the software and hardware environment for the RTEMS system. The first system image data is used to provide the core functions of the operating system, implement various system services, and define the system configuration and characteristics to realize the normal operation of the RTEMS system.

[0079] The embodiments of the present application can be implemented based on the software architecture of the RTEMS system. In other words, the development of the boot program can be carried out based on the software architecture of the RTEMS system.

[0080] Among them, the hardware drivers provided by the software architecture of the RTEMS system can enable the boot program to conveniently operate hardware components such as the CPU and memory to complete the initialization of hardware components and other tasks.

[0081] The interface standards provided by the software architecture of the RTEMS system can provide a unified specification for the interaction between the boot program and system modules, and achieve compatible interoperability and orderly operation between the boot program and system modules.

[0082] The resource management mechanism provided by the software architecture of the RTEMS system allows the boot program to reasonably allocate system resources such as memory, and avoid resource conflicts and waste caused by improper resource allocation.

[0083] The modular design of the software architecture of the RTEMS system enables the bootloader to reuse the code of common modules, reducing repetitive development work, improving development efficiency and code quality. For example, under the modular design, for two types of hardware components, namely the first preset component and the second preset component, if there are similarities in their initialization processes, the bootloader can, based on the software architecture of the RTEMS system, reuse the initialization code developed for the second preset component to complete the initialization work of the first preset component.

[0084] Among them, the bootloader is used to initialize the first preset component; the RTEMS system is used to initialize the second preset component. When the names of the first preset component and the second preset component are the same, the bootloader and the RTEMS system will initialize the corresponding hardware components at different processing stages respectively. This is because the bootloader is usually responsible for completing the basic initialization work of the hardware components in the early stage of system startup, building a basic environment for the subsequent normal operation of the system; while the RTEMS system further performs more comprehensive and detailed initialization configuration on the hardware components from the system level after the bootloader completes the preliminary initialization to ensure that it can operate stably and efficiently in the entire system architecture.

[0085] In these two stages, some initialization operations of the hardware components are similar, and there will be duplicate initialization code. Taking the hardware component of the clock as an example, in order to enable the system chip to start timing, the bootloader will perform basic settings on the clock, such as setting the initial clock division factor so that the clock starts working at a basic frequency. Starting from meeting the overall operation accuracy and task scheduling requirements of the system, the RTEMS system will set the clock again, and may adjust the clock division factor to obtain more accurate timing. In these two initialization processes for the clock, the part of the code for setting the clock division factor is repeated. Therefore, based on the software architecture of the RTEMS system, the bootloader can reuse part of the initialization code in the initialization stage of the RTEMS system to complete part of the initialization work of the hardware component (clock) by itself, improving development efficiency.

[0086] The embodiment of this application can complete the development of the self-booting system program based on the software architecture of the RTEMS system, thereby obtaining the source code of the bootloader and the source code of the system image. Then, using a preset same compilation environment, such as a specific compiler, these two parts of the source code are respectively compiled and converted into target machine code. Thereby generating an executable file of the bootloader and the first system image data, where the bootloader and the first system image data each contain the executable file and related data files generated from the corresponding source code. After successful compilation, with the help of a set burning tool, the bootloader and the first system image data are burned into the set address of the non-volatile memory of the system chip, laying a foundation for the subsequent self-booting of the system chip and the startup of the RTEMS system.

[0087] Referring to Figure 2 , a schematic diagram of target data stored in a non-volatile memory according to an embodiment of the present application is shown. Among them, the non-volatile memory is specifically a ROM. The boot program in the target data is stored at address A of the ROM, and the first system image data in the target data is stored at address B of the ROM. Address A and address B may be continuous or discontinuous in the storage space of the ROM. Those skilled in the art can flexibly plan the storage locations of the boot program and the first system image data according to the actual layout of the ROM storage space and the specific requirements of the system for storing the boot program and the system image data.

[0088] For example, address A can be set as the low address of the ROM. This setting method can make full use of the characteristics such as fast access speed of the low address space of the ROM to improve the access efficiency of the boot program. Memory or a storage device is divided into many storage units, and each storage unit has a unique address number. In this address numbering system, the part of the address with a smaller value is called the low address, and the part with a larger value is the high address. In other words, the number of the storage unit corresponding to address A can be less than the number of the storage unit corresponding to address B.

[0089] Moreover, the first instruction of the boot program is stored at the ROM address specified by the system chip for power-on startup. In this way, after the system chip is powered on, the first instruction of the boot program can be quickly located to achieve the fast startup of the boot program.

[0090] After the boot program runs, it can initialize the first preset components on the system chip; the first preset components specifically include: a clock, a serial port, a network device, and a storage device.

[0091] Among them, the clock can provide an accurate time reference for the system chip to coordinate the operation timings of various components and ensure the orderly operation of the system.

[0092] Serial port: The serial port is used for the system chip to transmit data bit by bit to and from external devices to achieve short-distance and low-speed data communication.

[0093] Examples of network devices may include: a network card. As a network device, the network card is responsible for receiving and sending data between the system chip and the network to achieve network connection and data interaction.

[0094] Examples of storage devices may include: a volatile memory. As a storage device, the volatile memory is used to temporarily store programs and data during system operation to provide a fast read / write working space for the system chip.

[0095] The bootstrap program can quickly complete the initialization of the first preset components such as the clock, serial port, network device, and storage device. Therefore, it can effectively shorten the startup time of the RTEMS system.

[0096] In practical applications, the bootstrap program can include: a program segment and a data segment. The program segment of the bootstrap program runs after the system chip is powered on and copies the data segment of the bootstrap program to the first address of the volatile memory.

[0097] The program segment is the part of the bootstrap program that contains executable code. It consists of a series of instructions that specify the operations to be performed by the computer and the order of the operations. The data segment is the part of the bootstrap program used to store data, including various data required during the operation of the bootstrap program, such as configuration parameters, variables, constants, tables, etc. These data are the operation objects and bases during the execution of the program segment, providing necessary information support for the operation of the program segment.

[0098] Volatile memory (such as RAM) usually has faster read and write speeds than ROM. Copying the data segment of the bootstrap program to the first address of the volatile memory can enable the program segment to read and write data more quickly when accessing data, thereby improving the operation efficiency of the bootstrap program and accelerating the startup speed of the RTEMS system.

[0099] The working modes of the bootstrap program specifically include: the boot mode or the upgrade mode.

[0100] Among them, the boot mode is used to read the first system image data from the non-volatile memory and start the RTEMS system accordingly after the system chip is powered on.

[0101] The upgrade mode is used to obtain new first system image data from an external device, verify the first system image data, and start the RTEMS system according to the verified first system image data in case of abnormal startup of the RTEMS system, so as to realize the upgrade or repair of the RTEMS system.

[0102] The embodiments of the present application do not limit the determination method of the working mode of the bootstrap program.

[0103] In one implementation, before the RTEMS system starts, the working mode of the bootstrap program is determined according to the jumpers on the board where the system chip is located and / or the pins of the system chip; the working mode includes: the boot mode or the upgrade mode.

[0104] The jumper can generally be regarded as the jumper on the hardware board where the system chip is located. From the perspective of hardware design, as an electrical connection method, the jumper can change the circuit state by connecting or disconnecting specific lines, providing different working signals for the system chip. The pins of the system chip are connected to the jumper on the hardware board. When the jumper state changes, the level signal and so on of the corresponding pins of the system chip also change accordingly. Then, the bootloader can determine whether the working mode is the boot mode or the upgrade mode according to the change of the pin signal.

[0105] In the embodiments of the present application, the working mode can be determined by detecting the level state, signal timing or combined state of the pins of the system chip.

[0106] Taking the detection of the level state as an example, it can be stipulated that different working modes correspond to different levels of specific pins. For example, a high level (such as 3.3V or 5V) represents the boot mode, and a low level (such as 0V) represents the upgrade mode. In this way, the bootloader determines the working mode by reading the level value of the pin.

[0107] Taking the detection of signal timing as an example, the pin may output a specific signal timing to indicate the working mode. For example, within a specific time after the system is powered on, if the signal of the pin has a transition from low level to high level (i.e., rising edge), and then there is a state of continuously maintaining high level, it represents the boot mode. Or, if the signal of the pin appears as a continuous pulse sequence, it represents the upgrade mode.

[0108] Taking the detection of the combined state of pins as an example, when pin A is at high level and pin B is at low level, it can represent the boot mode. Or, when both pin A and pin B are at high level, it represents the upgrade mode. In short, the bootloader can determine the working mode by reading the states of multiple pins and performing logical judgments.

[0109] In another implementation manner of the present application, after the RTEMS system is started, the working mode of the bootloader can be determined according to the instructions interactively sent by the user via the graphical software interface, text command line tool, or external programmable device.

[0110] In a specific implementation, the user can select the working mode of the bootloader by operating elements such as buttons and menus on the graphical software interface. These operations will be captured by the graphical software interface and converted into corresponding instruction codes, and then passed to the bootloader. After receiving the instruction code, the bootloader or the RTEMS system can determine what working mode the bootloader should adopt.

[0111] The user can input a specific command string in the text command line to specify the working mode of the bootloader. The command parsing module of the bootloader or the RTEMS system will parse and recognize the input command string, so as to determine the working mode of the bootloader.

[0112] The externally programmable device can receive user input according to the logic pre-set by the user or through its own interaction interface, and then send instructions in a specific format to the RTEMS system through a communication interface with the system, such as USB (Universal Serial Bus), serial port, etc. After receiving these instructions, the RTEMS system processes them and then determines the working mode that the bootloader is to enter.

[0113] Of course, before the RTEMS system starts, the working mode of the bootloader can be defaulted to the boot mode in the embodiments of the present application.

[0114] In step 101, in the boot mode, the bootloader can read the first system image data from the non-volatile memory.

[0115] Among them, the program segment of the bootloader can communicate with the non-volatile memory by using the interface provided by the hardware driver, find the address B where the first system image data is stored, read the first system image data into the system cache byte by byte or word by word, and then transfer it to the volatile memory. Subsequently, according to the startup process of the RTEMS system, the kernel, driver, configuration information, etc. in the first system image data are parsed and loaded.

[0116] Refer to Figure 3 , which shows a schematic diagram of the bootloader reading data from the non-volatile memory in an embodiment of the present application. Among them, the non-volatile memory is specifically a ROM. The bootloader in the target data is stored at address A of the ROM, and the first system image data in the target data is stored at address B of the ROM. The program segment of the bootloader first copies its own data segment to the first address of the RAM, and then converts the first system image data into a first target system image file and copies the first target system image file to the second address of the RAM. The first address can be a high address, and the second address can be a low address. The serial number of the storage unit corresponding to the second address can be less than the serial number of the storage unit corresponding to the first address.

[0117] The first system image file in the non-volatile memory can be a kind of system image file. The system image file is a file that contains the entire system content such as the operating system, related configuration information, software programs, etc.

[0118] It should be noted that the relationship between the first system image file in the non-volatile memory and the first target system image file in the volatile memory can be as follows:

[0119] Case A: The first system image file in the non-volatile memory is the same as the first target system image file in the volatile memory, and both contain the uncompressed plaintext of the first system image file.

[0120] For case A, the bootstrap program can quickly obtain the first system image data from the non-volatile memory and copy it to the second address of the volatile memory without additional verification, decryption, or decompression operations, which can effectively improve the loading speed and running efficiency of the RTEMS system, and reduce data processing time and resource consumption.

[0121] In case B, the first system image file in the non-volatile memory is different from the first target system image file in the volatile memory.

[0122] In case B1, the first system image data in the non-volatile memory includes: the first system image file and the first verification information; the first target system image file in the volatile memory includes: the first system image file after the first verification passes. The first verification information is used to perform the first verification on the first system image file.

[0123] In the technical solution of case B1, only the first system image file that passes the first verification can be used. Therefore, it can improve the security and accuracy of the first system image file during storage, enhance the stability and security of the RTEMS system, and prevent system failures caused by data tampering or damage.

[0124] In a specific implementation, the bootstrap program reads the first system image file and the first verification information from the non-volatile memory, uses the first verification information to perform the first verification on the first system image file. If the first verification passes, the first system image file that passes the first verification is stored in the volatile memory for use by the RTEMS system; if the first verification fails, the system will switch to the upgrade mode.

[0125] In practical applications, the first verification information includes: the first digital signature and the first public key. Then, the embodiments of the present application can perform the first verification on the first system image file according to the first verification information. The corresponding first verification process specifically includes: determining the first hash value corresponding to the first system image file; determining the first verification hash value according to the first digital signature and the first public key; if the first hash value is consistent with the first verification hash value, the first verification passes; or, if the hash value is inconsistent with the verification hash value, the first verification fails.

[0126] When performing the first verification on the first system image file, first calculate the first hash value of the first system image file using a specific hash algorithm. This first hash value is obtained by performing a hash algorithm operation on the content of the first system image file and can be used as the characteristic value of the first system image file. Based on the public key encryption system, the sender will use the first private key to encrypt the hash value of the first system image file to generate the first digital signature. After the receiver receives the first system image file, the first digital signature, and the first public key, it uses the first public key to decrypt the first digital signature to obtain the first verification hash value. In this way, compare the first hash value of the first system image file calculated with the first verification hash value obtained by decryption. If the two are consistent, it indicates that the first system image file has not been tampered with during transmission and its source is legal, and the first verification passes; if the two are inconsistent, it means that the first system image file may have been tampered with or its source is unreliable, and the first verification fails, thereby ensuring the integrity and authenticity of the first system image file.

[0127] In case B2, the first system image data in the non-volatile memory includes: the first system image file and the first verification information; the first system image file in the volatile memory includes: the first verification passed and the decompressed first target system image file. The first verification information is used to perform the first verification on the first system image file.

[0128] In the technical solution of case B2, since the first system image file that passes the first verification is a compressed image file, in addition to being able to improve the security and accuracy of the first system image file during storage, the embodiments of the present application can also save the storage space of the non-volatile memory.

[0129] In a specific implementation, the boot program reads the first system image file and the first verification information from the non-volatile memory, uses the first verification information to perform the first verification on the first system image file, performs a decompression operation on the first system image file after the first verification passes, and stores the decompressed first target system image file in the volatile memory.

[0130] The embodiments of the present application do not limit the compression algorithm corresponding to the first system image file. Examples of compression methods may include: GZIP (GNU compression), etc. Among them, GNU is the name of a free software operating system project. ZIP is a compression format.

[0131] In case B3, the first system image data in the non-volatile memory includes: the ciphertext of the first system image file and the first verification information; the first target system image file in the volatile memory includes: the plaintext of the first system image file. The first verification information is used to decrypt the ciphertext of the first system image file.

[0132] In the embodiment of the present application, the first system image file is encrypted and stored, and only through the correct decryption operation can the plaintext of the first system image file be obtained. Since it can prevent the plaintext of the first system image file from being illegally read and tampered with in the non-volatile memory, the security of the plaintext of the first system image file can be enhanced.

[0133] In a specific implementation, the first verification information includes: the ciphertext of the key. Then, the embodiment of the present application can perform a first verification on the first system image file according to the first verification information. The corresponding first verification process specifically includes: decrypting the ciphertext of the key by using a preset private key to obtain the plaintext of the key; decrypting the first system image file by using the plaintext of the key. If the decryption is successful, the first verification passes; if the decryption fails, the first verification fails.

[0134] In the embodiment of the present application, the sender can first encrypt the key used to decrypt the first system image file into the ciphertext of the key by using an encryption algorithm with a preset public key, and burn the ciphertext of the key and the first system image file into the non-volatile memory together. The receiver (bootloader) can decrypt the ciphertext of the key by using the preset private key paired with the preset public key to restore the original key, that is, the plaintext of the key. Then, try to decrypt the first system image file with the plaintext of the key. If the decryption is successful, it indicates that the key is correct and the first system image file has not been damaged or tampered with during transmission, and the first verification passes; if the decryption fails, it means that the key is incorrect or the file is damaged, and the first verification fails.

[0135] Case B4: The first system image data in the non-volatile memory includes: the compressed ciphertext of the first system image file and the first verification information; the first target system image file in the volatile memory includes: the decompressed plaintext of the first system image file. The first verification information is used to decrypt the ciphertext of the first system image file.

[0136] The embodiment of the present application combines the advantages of encryption and compression, which not only saves storage space but also improves the security of the first system image file, making the RTEMS system more efficient and secure in data storage and use.

[0137] In a specific implementation, the bootloader first reads the compressed ciphertext of the first system image file and the first verification information from the non-volatile memory, decrypts the compressed ciphertext by using the first verification information to obtain the compressed first system image file, and then performs a decompression operation on it to obtain the decompressed plaintext of the first system image file.

[0138] In an implementation manner of the present application, the process of starting the RTEMS system according to the first system image data in step 101 specifically includes: decompressing the first system image file in the first system image data to a second address in the volatile memory; the first target system image file represents the decompressed first system image file; setting the program counter pointer of the processor in the system chip to the address of the first program instruction of the first target system image file to implement the startup of the RTEMS system.

[0139] Among them, the first system image file is a compressed image file, which can save the storage space of the non-volatile memory.

[0140] Decompressing the first system image file in the first system image data to a second address in the volatile memory can specifically be: first decompressing the first system image file in the first system image data into the first target system image file, and then copying the first target system image file to the second address.

[0141] The program counter pointer is an important register of the processor, which points to the address of the program instruction to be executed currently. In the embodiment of the present application, the program counter pointer of the processor in the system chip is set to the address of the first program instruction of the first target system image file, which enables the processor to start from the address of the first program instruction of the first system image file and sequentially read and execute the program instructions of the first target system image file. Through such a setting, the processor can gradually execute the program instructions in the first target system image file to complete a series of operations such as system initialization and driver loading, thereby implementing the startup of the RTEMS system.

[0142] In step 102, during the process of starting the RTEMS system according to the first system image data, the bootloader can continuously monitor the preset metrics of the RTEMS system. These preset metrics mainly focus on aspects related to system operation, such as the memory initialization status, the kernel loading completion flag, etc. At the same time, considering the impact of the correctness of the first system image data on the startup of the RTEMS system, the first verification result of the first system image data will also be checked. In the case where the system preset metrics such as the memory initialization status and the kernel loading completion flag do not meet the expectations, or the first verification result shows that the verification fails, it is determined that the startup is abnormal, and the upgrade mode can be switched.

[0143] In step 103, the second system image data can be obtained from the server or an external storage device.

[0144] Specifically, in the upgrade mode, the bootstrap program can use communication interfaces such as serial ports and USB provided by the hardware driver to establish a connection with external devices (such as embedded multimedia cards and servers), and receive second system image data containing second verification information and a second system image file according to the data transmission protocol of the external device.

[0145] In step 104, the second verification can detect the tampered second system image file and prevent it from being loaded onto the system chip, thereby improving the security and reliability of the RTEMS system startup.

[0146] The embodiments of the present application can provide the following technical solutions for performing a second verification on the second system image file according to the above second verification information:

[0147] Technical solution A

[0148] In technical solution A, the second verification information specifically includes: a second digital signature and a second public key; the process of performing a second verification on the second system image file according to the second verification information specifically includes:

[0149] Step A1: Determine the hash value corresponding to the second system image file;

[0150] Step A2: Determine the verification hash value according to the second digital signature and the second public key;

[0151] Step A3: If the hash value is consistent with the verification hash value, the second verification passes; or, if the hash value is inconsistent with the verification hash value, the second verification fails.

[0152] Technical solution A is based on the hash function and digital signature technology, and verifies the integrity and authenticity of the source of the second system image file by comparing the hash value corresponding to the second system image file with the verification hash value recovered from the second digital signature.

[0153] In step A1, use the SM3 (Commercial Cryptography Algorithm No. 3) algorithm to calculate the hash value corresponding to the second system image file.

[0154] SM3 is a standard for cryptographic hash functions and belongs to the cryptographic hashing algorithm. It can convert an input message of any length into a hash value of a fixed length (256 bits, i.e., 32 bytes) through specific mathematical operations.

[0155] In practical applications, the second system image file can first be divided according to a certain data block size, and then each data block is processed sequentially. Through a series of logical operations and iterative operations, the 256-bit hash value of the entire file is finally obtained.

[0156] In step A2, the sender first calculates the file hash value of the second system image file, and then encrypts the file hash value using the second private key to generate a second digital signature. After receiving the second system image file, the second digital signature, and the second public key, the receiver decrypts the second digital signature using the second public key. Since the second public key and the second private key are a pair of matching keys, the data encrypted with the second private key can only be decrypted with the corresponding second public key. After decryption, the file hash value calculated by the sender can be obtained, which is the verification hash value.

[0157] In step A3, the hash value of the second system image file calculated in step A1 is compared with the verification hash value decrypted in step A2. If the two are consistent, it indicates that the second system image file has not been tampered with during the transmission process and is sent by a legitimate sender who owns the corresponding second private key, that is, the second verification passes; if the two are inconsistent, it indicates that the second system image file may have been tampered with or is not from a legitimate sender, and the second verification fails.

[0158] Technical solution B

[0159] In technical solution B, the second verification information specifically includes: the ciphertext of the key; according to the above second verification information, the process of performing the second verification on the second system image file specifically includes:

[0160] Step B1: Use the preset private key to decrypt the ciphertext of the key to obtain the plaintext of the key;

[0161] Step B1: Use the plaintext of the key to decrypt the second system image file. If the decryption is successful, the second verification passes; if the decryption fails, the second verification fails. In the case of successful decryption, the plaintext data of the second system image file can also be obtained.

[0162] Technical solution B is based on the public key encryption system. First, the preset private key is used to decrypt the ciphertext of the key to obtain the plaintext of the key, and then the plaintext of the key is used to attempt to decrypt the second system image file to verify the legality and integrity of the second system image file.

[0163] In step B1, the sender uses the preset public key to encrypt the key for decrypting the second system image file to obtain the ciphertext of the key. The receiver has the preset private key corresponding to the preset public key. By using the preset private key to decrypt the ciphertext of the key, the original key, that is, the plaintext of the key, can be restored.

[0164] In step B2, when the sender sends the second system image file, it encrypts the plaintext of the second system image file using a key. After obtaining the plaintext of the key, the receiver decrypts the second system image file using the plaintext of the key. If the decryption is successful, it indicates that the plaintext of the key is correct and the second system image file has not been damaged or tampered with during transmission, that is, the second verification passes; if the decryption fails, it indicates that the plaintext of the key may be incorrect or the second system image file has been damaged, and the second verification fails.

[0165] In step 105, if the second verification passes, it indicates that the second system image file is secure and reliable, so the RTEMS system can be started according to the second system image file.

[0166] In one implementation, the second system image file can be an uncompressed file. In this case, the second system image file can be first copied to the second address of the volatile memory; then, the program counter pointer of the processor in the system chip is set to the first program instruction address of the second system image file to start the RTEMS system.

[0167] In another implementation, the second system image file can be a compressed file. In this case, the second system image file can be first decompressed to the second address of the volatile memory; the second target system image file represents the decompressed second system image file; then, the program counter pointer of the processor in the system chip is set to the first program instruction address of the second target system image file to start the RTEMS system.

[0168] Considering that the second system image file may have undergone encryption processing before transmission, after the decryption operation is completed, the plaintext data of the second system image file can be stored at the second address of the volatile memory.

[0169] In summary, for the RTEMS system boot method in the embodiments of the present application, since the boot program and the system image data in the embodiments of the present application adopt the same compilation environment, compared with separately building the compilation environments for the boot program and the system image data, the development time of the RTEMS system software is reduced, so the development efficiency of the RTEMS system software can be improved.

[0170] Moreover, if an exception occurs during the startup process of the RTEMS system in the boot mode, the boot program in the embodiments of the present application will switch to the upgrade mode and obtain new second system image data in the upgrade mode. The above processing provides an effective remedy for the abnormal startup situation of the RTEMS system, and improves the startup success rate and system stability of the RTEMS system.

[0171] In addition, in the upgrade mode of the embodiments of the present application, second system image data including second verification information and a second system image file is obtained from an external device. After the second system image file passes the second verification, the RTEMS system is started using the second system image file. The above-mentioned second verification can detect a tampered second system image file and prevent it from being loaded onto the system chip, thereby improving the security and reliability of the RTEMS system startup.

[0172] Method Embodiment 2

[0173] Reference Figure 4 , which shows a schematic flow chart of the steps of the boot method of the RTEMS system according to an embodiment of the present application. Among them, target data of the self-boot system program is burned in the non-volatile memory of the system chip. The above-mentioned target data specifically includes: a boot program and first system image data of the RTEMS system; the above-mentioned boot program and the first system image data correspond to the same compilation environment; the above-mentioned boot program runs after the system chip is powered on and executes the following steps included in the above method:

[0174] Step 401, before the RTEMS system starts, determine the working mode of the boot program according to the jumpers on the board where the system chip is located and / or the pins of the system chip. If the working mode is the boot mode, execute step 402. If the working mode is the upgrade mode, execute step 404;

[0175] Step 402, read the first system image data from the non-volatile memory and start the RTEMS system according to the above first system image data;

[0176] Step 403, in the case of an abnormal startup of the RTEMS system, switch to the upgrade mode;

[0177] Step 404, obtain second system image data from an external device; the above-mentioned second system image data specifically includes: second verification information and a second system image file;

[0178] Step 405, perform a second verification on the second system image file according to the above second verification information;

[0179] Step 406, if the second verification passes, start the RTEMS system according to the above second system image file.

[0180] In the technical solution of the embodiment of the present application, after the system chip is powered on, the boot program burned in its non-volatile memory starts to run. The boot program first determines its working mode through the jumpers on the board where the system chip is located and / or the pins of the system chip. If it is the boot mode, the boot program reads the first system image data from the non-volatile memory and starts the RTEMS system accordingly; if an exception occurs during the startup process, the boot program automatically switches to the upgrade mode. If the determined working mode is the upgrade mode, the boot program obtains the second system image data including the second verification information and the second system image file from an external device, and then performs a second verification on the second system image file according to the second verification information. If the second verification passes, it starts the RTEMS system with the second system image file.

[0181] The embodiment of the present application provides a set of reliable and flexible boot processes for the RTEMS system. On the one hand, through the judgment of the working mode, the boot program can start the RTEMS system with the first system image data in the non-volatile memory in the normal boot mode; on the other hand, when an exception occurs during startup or the upgrade mode is actively selected, the boot program can obtain and verify the second system image data from an external device, and then start the system, enabling the RTEMS system to run smoothly when facing faults or needing updates, effectively improving the adaptability and stability of the system, reducing the risk of system faults caused by startup problems, and meeting the diverse application scenario requirements.

[0182] It should be noted that after the RTEMS system is started in the embodiment of the present application, the working mode of the boot program can be determined according to the instructions interactively issued by the user via the graphical software interface, the text command line tool, or the external programmable device. If the working mode is the upgrade mode, steps 404 to 406 can be executed.

[0183] In the state where the RTEMS system has been started in the embodiment of the present application, the user can intuitively operate through the graphical software interface, input instructions in the text command line tool, or interact with the system by means of the external programmable device, thereby determining the working mode of the boot program. When it is determined to be the upgrade mode, the subsequent steps 404 to 406 of obtaining the second system image data from the external, verifying, and starting the system can be executed. This method greatly improves the flexibility of system operation and user autonomy, meets the diverse needs of different users for system upgrade or conventional operation mode switching in different scenarios, and enhances the practicality and operability of the system.

[0184] It should be noted that for the method embodiments, for the sake of simple description, they are all expressed as a series of action combinations. However, those skilled in the art should know that the embodiments of the present application are not limited by the described action sequence, because according to the embodiments of the present application, certain steps can be performed in other sequences or simultaneously. Secondly, those skilled in the art should also know that the embodiments described in the specification are all preferred embodiments, and the actions involved are not necessarily essential for the embodiments of the present application.

[0185] Based on the above embodiments, this embodiment further provides a boot device for an RTEMS system. Referring to Figure 5 the structural schematic diagram shown, target data of a self-boot system program is burned in the non-volatile memory of the system chip. The target data includes: a boot program and first system image data of the RTEMS system; the boot program and the first system image data correspond to the same compilation environment; the boot program runs after the system chip is powered on and includes the following modules:

[0186] A boot mode processing module 501, configured to read the first system image data from the non-volatile memory and start the RTEMS system according to the first system image data when the working mode of the boot program is the boot mode;

[0187] A mode switching module 502, configured to switch to the upgrade mode when the startup of the RTEMS system is abnormal;

[0188] An external acquisition module 503, configured to acquire second system image data from an external device when the working mode of the boot program is the upgrade mode; the second system image data includes: second verification information and a second system image file;

[0189] A second verification module 504, configured to perform a second verification on the second system image file according to the second verification information;

[0190] A system startup module 505, configured to start the RTEMS system according to the second system image file if the second verification passes.

[0191] Optionally, the system startup module includes:

[0192] A second decompression module, configured to decompress the second system image file to a second address in the volatile memory; the second target system image file represents the decompressed second system image file;

[0193] A second pointer setting module, configured to set the program counter pointer of the processor in the system chip to the address of the first program instruction of the second target system image file to implement the startup of the RTEMS system.

[0194] Optionally, the second verification information includes: a second digital signature and a second public key;

[0195] The second verification module is specifically configured to determine a hash value corresponding to the second system image file; determine a verification hash value according to the second digital signature and the second public key; if the hash value is consistent with the verification hash value, the second verification passes; or, if the hash value is inconsistent with the verification hash value, the second verification fails.

[0196] Optionally, the second verification information includes: a key ciphertext;

[0197] The second verification module is specifically configured to decrypt the key ciphertext by using a preset private key to obtain a key plaintext; decrypt the second system image file by using the key plaintext, if the decryption is successful, the second verification passes, and if the decryption fails, the second verification fails.

[0198] Optionally, the external acquisition module is specifically configured to acquire second system image data from a server or an external storage device.

[0199] Optionally, the device further includes:

[0200] A first working mode determination module, configured to determine a working mode of a bootloader according to jumpers on a board where a system chip is located and / or pins of the system chip before the RTEMS system is started; the working mode includes: a boot mode or an upgrade mode; or

[0201] A second working mode determination module, configured to determine a working mode of a bootloader according to an instruction interactively sent by a user via a graphical software interface, or a text command line tool, or an external programmable device after the RTEMS system is started.

[0202] Optionally, the device further includes:

[0203] An initialization module, configured to initialize a first preset component on the system chip before reading first system image data from a non-volatile memory when the working mode of the bootloader is a boot mode; the first preset component includes: a clock, a serial port, a network device, and a storage device.

[0204] Optionally, the boot mode processing module includes:

[0205] A first decompression module, configured to decompress a first system image file in the first system image data to a second address in a volatile memory; the first target system image file represents the decompressed first system image file;

[0206] A first pointer setting module is configured to set the program counter pointer of the processor in the system-on-chip to the address of the first program instruction of the first target system image file, so as to implement the startup of the RTEMS system.

[0207] An embodiment of the present application also provides a non-volatile readable storage medium, in which one or more modules (programs) are stored. When the one or more modules are applied to a device, the device can execute instructions (instructions) for each method step in the embodiment of the present application.

[0208] Embodiments of the present application provide one or more machine-readable media, on which instructions are stored. When executed by one or more processors, the electronic device is caused to execute one or more of the methods as described in the above embodiments. In embodiments of the present application, the electronic device includes various types of devices such as terminal devices and servers (clusters).

[0209] Embodiments of the present disclosure can be implemented as a device configured with any suitable hardware, firmware, software, or any combination thereof, and the device may include: electronic devices such as terminal devices and servers (clusters). Figure 6 Exemplary device 1100 that can be used to implement the various embodiments described in the present application is schematically shown.

[0210] For one embodiment, Figure 6 Exemplary device 1100 is shown, which has one or more processors 1102, a control module (chipset) 1104 coupled to at least one of the (one or more) processors 1102, a memory 1106 coupled to the control module 1104, a non-volatile memory / storage device 1108 coupled to the control module 1104, one or more input / output devices 1110 coupled to the control module 1104, and a network interface 1112 coupled to the control module 1104.

[0211] Processor 1102 may include one or more single-core or multi-core processors, and processor 1102 may include any combination of general-purpose processors or dedicated processors (such as graphics processors, application processors, baseband processors, etc.). In some embodiments, device 1100 can function as the terminal device, server (cluster), etc. described in the embodiments of the present application.

[0212] In some embodiments, device 1100 may include one or more computer-readable media (such as memory 1106 or non-volatile memory / storage device 1108) having instructions 1114 and one or more processors 1102 combined with the one or more computer-readable media and configured to execute instructions 1114 to implement modules so as to perform the actions described in the present disclosure.

[0213] For one embodiment, the control module 1104 may include any suitable interface controller to provide any suitable interface to at least one of the processor(s) 1102 and / or any suitable device or component communicating with the control module 1104.

[0214] The control module 1104 may include a memory controller module to provide an interface to the memory 1106. The memory controller module may be a hardware module, a software module, and / or a firmware module.

[0215] The memory 1106 may be used to load and store data and / or instructions 1114 for the device 1100, for example. For one embodiment, the memory 1106 may include any suitable volatile memory, such as suitable DRAM (Dynamic Random Access Memory). In some embodiments, the memory 1106 may include double data rate type four synchronous dynamic random access memory.

[0216] For one embodiment, the control module 1104 may include one or more input / output controllers to provide an interface to the non-volatile memory / storage device 1108 and the input / output device(s) 1110.

[0217] For example, the non-volatile memory / storage device 1108 may be used to store data and / or instructions 1114. The non-volatile memory / storage device 1108 may include any suitable non-volatile memory (e.g., flash memory) and / or may include any suitable non-volatile storage device(s) (e.g., one or more hard disk drives, one or more optical disk drives, and / or one or more digital versatile disk drives).

[0218] The non-volatile memory / storage device 1108 may include storage resources that are physically part of a device on which the device 1100 is mounted, or it may be accessible by the device without being part of the device. For example, the non-volatile memory / storage device 1108 may be accessed via the input / output device(s) 1110 over a network.

[0219] (One or more) input / output devices 1110 may provide an interface for device 1100 to communicate with any other suitable devices. The input / output devices 1110 may include communication components, audio components, sensor components, etc. The network interface 1112 may provide an interface for device 1100 to communicate through one or more networks. Device 1100 may wirelessly communicate with one or more components of a wireless network according to any of one or more wireless network standards and / or protocols, such as accessing a wireless network based on communication standards, such as WiFi (Wireless Fidelity), 2G (2-Generation wireless telephone technology), 3G (3-Generation wireless telephone technology), 4G (4-Generation wireless telephone technology), 5G (5-Generation wireless telephone technology), etc., or a combination thereof for wireless communication.

[0220] For one embodiment, at least one of (one or more) processors 1102 may be logically packaged with one or more controllers (e.g., a memory controller module) of the control module 1104. For one embodiment, at least one of (one or more) processors 1102 may be logically packaged with one or more controllers of the control module 1104 to form a system-in-package. For one embodiment, at least one of (one or more) processors 1102 may be logically integrated with one or more controllers of the control module 1104 on the same die. For one embodiment, at least one of (one or more) processors 1102 may be logically integrated with one or more controllers of the control module 1104 on the same die to form a system-on-chip.

[0221] In various embodiments, device 1100 may be, but is not limited to: a server, a desktop computing device, or a mobile computing device (e.g., a laptop computing device, a handheld computing device, a touchscreen device, a netbook, etc.) and other terminal devices. In various embodiments, device 1100 may have more or fewer components and / or a different architecture. For example, in some embodiments, device 1100 includes one or more cameras, a keyboard, a liquid crystal display screen (including a touchscreen display), a non-volatile memory port, multiple antennas, a graphics chip, an application-specific integrated circuit, and speakers.

[0222] Among them, the main control chip can be used as the processor or control module in the detection device, sensor data, position information, etc. are stored in the memory or non-volatile memory / storage device, the sensor group can be used as an input / output device, and the communication interface can include a network interface.

[0223] For the device embodiments, since they are basically similar to the method embodiments, the description is relatively simple. For the relevant parts, please refer to the corresponding descriptions in the method embodiments.

[0224] Each embodiment in this specification is described in a progressive manner. The key point of each embodiment is to illustrate the differences from other embodiments. For the same or similar parts among the embodiments, reference can be made to each other.

[0225] The embodiments of the present application are described with reference to the flowcharts and / or block diagrams of the methods, terminal devices (systems), and computer program products according to the embodiments of the present application. It should be understood that each process and / or block in the flowcharts and / or block diagrams, and the combination of processes and / or blocks in the flowcharts and / or block diagrams, can be realized by computer program instructions. These computer program instructions can be provided to the processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing terminal devices to generate a machine, so that the instructions executed by the processor of the computer or other programmable data processing terminal devices generate a device for realizing the functions specified in one or more processes in the flowchart and / or one or more blocks in the block diagram.

[0226] These computer program instructions can also be stored in a computer-readable memory that can direct a computer or other programmable data processing terminal device to work in a specific manner, so that the instructions stored in the computer-readable memory generate a manufactured product including an instruction device, and the instruction device realizes the functions specified in one or more processes in the flowchart and / or one or more blocks in the block diagram.

[0227] These computer program instructions can also be loaded onto a computer or other programmable data processing terminal device, so that a series of operation steps are executed on the computer or other programmable terminal device to generate a computer-implemented process. Therefore, the instructions executed on the computer or other programmable terminal device provide steps for realizing the functions specified in one or more processes in the flowchart and / or one or more blocks in the block diagram.

[0228] Although the preferred embodiments of the embodiments of the present application have been described, those skilled in the art can make additional changes and modifications once they know the basic creative concepts. Therefore, the appended claims are intended to be construed to include the preferred embodiments and all changes and modifications falling within the scope of the embodiments of the present application.

[0229] Finally, it should also be noted that in this article, relational terms such as first and second are only used to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any actual relationship or order between these entities or operations. Moreover, the term "including", "comprising" or any other variant thereof is intended to cover non-exclusive inclusion, so that a process, method, article or terminal device including a series of elements not only includes those elements, but also includes other elements not expressly listed, or further includes elements inherent to such process, method, article or terminal device. Without further limitation, an element defined by the statement "including an..." does not exclude the presence of additional identical elements in the process, method, article or terminal device including the said element.

[0230] The above has introduced in detail a boot method and apparatus for an RTEMS system, an electronic device and a machine-readable medium provided by the present application. Specific examples are used in this article to elaborate on the principle and implementation manner of the present application. The description of the above embodiments is only used to help understand the method and its core idea of the present application; at the same time, for those of ordinary skill in the art, according to the idea of the present application, there will be changes in the specific implementation manner and application scenarios. In summary, the content of this specification should not be construed as a limitation to the present application.

Claims

1. A booting method for an RTEMS system, characterized in that The target data of the self - boot system program is burned in the non - volatile memory of the system - on - chip. The target data includes: a boot program and the first system image data of the RTEMS system; the boot program and the first system image data correspond to the same compilation environment; the boot program runs after the system - on - chip is powered on and executes the following steps included in the method: When the working mode of the boot program is the boot mode, read the first system image data from the non - volatile memory and start the RTEMS system according to the first system image data; When the startup of the RTEMS system is abnormal, switch to the upgrade mode; When the working mode of the boot program is the upgrade mode, obtain the second system image data from an external device; the second system image data includes: second verification information and a second system image file; Perform a second verification on the second system image file according to the second verification information; If the second verification passes, start the RTEMS system according to the second system image file.

2. The method according to claim 1, wherein The starting of the RTEMS system according to the second system image file includes: Decompress the second system image file to the second address in the volatile memory; the second target system image file represents the decompressed second system image file; Set the program counter pointer of the processor in the system - on - chip to the address of the first program instruction of the second target system image file to realize the startup of the RTEMS system.

3. The method according to claim 1, wherein The second verification information includes: a second digital signature and a second public key; The performing a second verification on the second system image file according to the second verification information includes: Determine the hash value corresponding to the second system image file; Determine the verification hash value according to the second digital signature and the second public key; If the hash value is consistent with the verification hash value, the second verification passes; or, if the hash value is inconsistent with the verification hash value, the second verification fails.

4. The method according to claim 1, characterized in that, The second verification information includes: a ciphertext of the key; The performing a second verification on the second system image file according to the second verification information includes: Use a preset private key to decrypt the ciphertext of the key to obtain the plaintext of the key; Use the plaintext of the key to decrypt the second system image file. If the decryption is successful, the second verification passes; if the decryption fails, the second verification fails.

5. The method according to claim 1, characterized in that The obtaining the second system image data from an external device includes: Obtain the second system image data from a server or an external storage device.

6. The method according to claim 1, wherein The method further includes: Before starting the RTEMS system, determine the working mode of the boot program according to the jumpers on the board where the system - on - chip is located and / or the pins of the system - on - chip; the working mode includes: the boot mode or the upgrade mode; or After starting the RTEMS system, determine the working mode of the boot program according to the instructions issued by the user through a graphical software interface, or a text command - line tool, or an external programmable device interaction.

7. The method according to claim 1, wherein Before reading the first system image data from the non - volatile memory when the working mode of the boot program is the boot mode, the method further includes: Initialize a first preset component on the system-on-chip; the first preset component includes: a clock, a serial port, a network device, and a storage device.

8. The method according to any one of claims 1 to 7, characterized in that The startup of the RTEMS system according to the first system image data includes: Decompress the first system image file in the first system image data to a second address in the volatile memory; the first target system image file represents the decompressed first system image file; Set the program counter pointer of the processor in the system-on-chip to the address of the first program instruction of the first target system image file to achieve the startup of the RTEMS system.

9. A boot device for an RTEMS system, characterized in that, Target data of a self-booting system program is burned in the non-volatile memory of the system-on-chip, and the target data includes: a boot program and first system image data of the RTEMS system; the boot program and the first system image data correspond to the same compilation environment; the boot program runs after the system-on-chip is powered on and includes the following modules: A boot mode processing module, configured to read the first system image data from the non-volatile memory and start the RTEMS system according to the first system image data when the working mode of the boot program is the boot mode; A mode switching module, configured to switch to the upgrade mode when the startup of the RTEMS system is abnormal; An external acquisition module, configured to acquire second system image data from an external device when the working mode of the boot program is the upgrade mode; the second system image data includes: second verification information and a second system image file; A second verification module, configured to perform a second verification on the second system image file according to the second verification information; A system startup module, configured to start the RTEMS system according to the second system image file if the second verification passes.

10. An electronic device, characterized in that, Includes: A processor; And A memory, on which executable code is stored, and when the executable code is executed, the processor is caused to execute the method according to any one of claims 1-8.

11. A machine-readable medium, on which executable code is stored, and when the executable code is executed, the processor is caused to execute the method according to any one of claims 1-8.

Images