A multi-core processor amp architecture real-time operating system starting method

Abstract

The present application relates to the technical field of embedded operating system, and particularly relates to a multi-core processor AMP architecture real-time operating system starting method, which comprises reserving real-time operating system memory by defining nodes in U-Boot and Linux device tree, setting specific attributes to prevent resource conflicts; disabling the real-time operating system core in the Linux device tree, and defining nodes to reserve inter-core communication shared memory. After related images are solidified by a burning tool, the U-Boot loads the real-time operating system image to the reserved address first, starts the corresponding core by means of the CPU_ON function of the power management interface specification, then loads the Linux kernel and the file system to start Linux, and the dual system communicates through the shared memory segment. The real-time operating system starting speed is improved, the high real-time scene demand is met, and the starting delay risk is reduced.

Description

Technical Field

[0001] This invention belongs to the field of embedded operating system technology, specifically relating to a method for starting a real-time operating system based on a multi-core processor AMP architecture. Background Technology

[0002] As SoC performance continues to improve due to the integration of homogeneous or heterogeneous multi-core processors, and as application scenarios become increasingly complex, requiring both real-time performance and high throughput, more and more devices are allowing the simultaneous deployment and running of multiple different operating systems (OS) on the same hardware platform. This fully utilizes hardware resources and meets the needs of different scenarios. For example, running both a Linux operating system and a real-time operating system (RTOS) on the same SoC and providing a dual-system IPC communication mechanism can fully leverage the ecosystem resources of the Linux community while ensuring the real-time performance and stability of the system.

[0003] Existing patent 1 (publication number CN118939565A) discloses a hypervisor as a virtual machine monitor, situated between the physical hardware and the operating system. It is an intermediate software layer that virtualizes a single physical resource into multiple independent virtual environments, allowing multiple operating systems or applications to share hardware resources. It is responsible for initializing the hardware, allocating resources such as CPU, memory, and peripherals for each system, and then running Linux and RTOS through the hypervisor. However, this technology has drawbacks: the hypervisor consumes additional CPU resources, and the software development cycle is lengthy and complex.

[0004] Existing patent 2 (publication number CN114327929A) discloses a priority processing method based on the AMP architecture. In this architecture, Linux and RTOS run on different CPU cores, operating independently without sharing a scheduler. In this type of existing asymmetric multiprocessing architecture, the startup of the real-time operating system relies on Linux. Generally, after Linux starts, Linux loads the real-time operating system image into designated memory and starts the real-time operating system through instructions. This startup method makes the startup speed of the real-time operating system slow, making it difficult to meet the application scenarios with stringent real-time requirements.

[0005] In view of this, the present invention is hereby proposed. Summary of the Invention

[0006] To address the aforementioned technical problems in the existing technology, this invention provides a method for starting a real-time operating system based on a multi-core processor AMP architecture, thereby improving the startup speed of the real-time operating system, meeting the requirements of high real-time scenarios, and reducing the risk of startup delay.

[0007] To achieve the above objectives, the technical solution of the present invention is as follows:

[0008] A method for booting a real-time operating system on a multi-core processor AMP architecture includes:

[0009] S1. Reserve memory resources for the real-time operating system in both the U-Boot and Linux device trees;

[0010] S2. Disable the cores and peripherals used by the real-time operating system, and reserve shared memory for inter-core communication;

[0011] S3. Transfer the U-Boot, real-time operating system, and Linux image to the storage.

[0012] S4. U-Boot loads the image of the real-time operating system to the reserved address, and brings the CPU core online and starts the real-time operating system through the power management interface.

[0013] S5 and U-Boot then load the Linux kernel and file system and start Linux.

[0014] Furthermore, the U-Boot and Linux device tree reserving memory resources for the real-time operating system in step S1 specifically includes:

[0015] The remote_core node is defined in both the U-Boot and Linux device trees, and the node contains... <reg>The properties are used to configure the starting address and size of the memory, and are set... <no-map>This attribute prevents Linux from accessing this memory.

[0016] Furthermore, the core of disabling the real-time operating system used in step S2 specifically includes:

[0017] Set the status="disabled" attribute in the CPU core node of the Linux device tree to prevent Linux from scheduling the core and peripherals.

[0018] Furthermore, the shared memory reserved for inter-core communication mentioned in step S2 specifically includes:

[0019] Define the openamp_reserved node in the device tree, through <reg>The attribute configures the address range of the shared memory segment.

[0020] Furthermore, the power management interface specification described in step S4 is implemented on the CPU core, specifically including:

[0021] The U-Boot calls the CPU_ON function in the power management interface specification standard interface, and passes in parameters including the CPU core ID where the real-time operating system is located and the image loading address, to wake up and start the target core.

[0022] Furthermore, the real-time operating system runs on an independent CPU core in the multi-core processor, while Linux runs on the remaining CPU cores. The two communicate with each other through a shared memory segment defined by the device tree.

[0023] Furthermore, the step of saving the image to the memory in S3 specifically includes:

[0024] The U-Boot image, real-time operating system image, Linux kernel image, and Linux file system image are burned using a burning tool.

[0025] Furthermore, the real-time operating system runs on at least one CPU core independently allocated in the multi-core processor, while Linux runs on multiple CPU cores.

[0026] Furthermore, when U-Boot loads the Linux kernel and file system in S5, it specifically includes:

[0027] Configure the Linux boot environment using preset boot parameters and boot commands. The boot parameters include at least console parameters, root file system path, and mount method.

[0028] Compared with the prior art, the present invention has the following beneficial effects:

[0029] The present invention provides a method for booting a real-time operating system (RTOS) on a multi-core processor AMP architecture. This method boots the ROS first, followed by Linux, after U-Boot. Furthermore, it utilizes a power management interface specification to deploy the ROS kernel, ensuring that U-Boot can continue loading and booting the Linux operating system after the ROS boots. This solves the problem of ROS boot delay caused by Linux booting first, thus meeting the needs of applications with high real-time requirements. Attached Figure Description

[0030] Figure 1 This is a flowchart illustrating the startup method of a real-time operating system based on a multi-core processor AMP architecture provided in an embodiment of the present invention. Detailed Implementation

[0031] The technical solution of the present invention will be clearly described below with reference to the accompanying drawings. Obviously, the described embodiments are not all embodiments of the present invention. All other embodiments obtained by those skilled in the art without creative effort are within the protection scope of the present invention.

[0032] It should be noted that, unless otherwise specifically stated, the relative arrangement and numerical expressions of the components and steps described in these embodiments should not be construed as limiting the scope of the invention.

[0033] The following description of exemplary embodiments is merely illustrative and is not intended to limit the invention or its application or use in any way. Techniques, methods, and apparatus known to those skilled in the art may not be discussed in detail herein, but where applicable, such techniques, methods, and apparatus should be considered part of this specification.

[0034] See Figure 1 This is a flowchart illustrating the startup method of the real-time operating system on a multi-core processor AMP architecture proposed in this invention. Assuming the SoC has four CPU cores, Linux runs on CPU cores 0, 1, and 2, and the real-time operating system (RTOS) runs on CPU core 3, the specific steps of this invention may include:

[0035] S1, Device Tree Resource Reserved Configuration

[0036] Memory resources for the real-time operating system are reserved in both the U-Boot and Linux device trees, specifically including:

[0037] The remote_core node is defined in both the U-Boot and Linux device trees, and the node contains... <reg>The properties are used to configure the starting address and size of the memory, and are set... <no-map>This attribute prevents Linux from accessing this memory.

[0038] In the U-Boot device tree, memory is reserved for the real-time operating system. This resource, remote_core, is used independently by the real-time operating system, and its expression is:

[0039]

[0040] Additionally, the expression for reserving real-time operating system memory is:

[0041]

[0042] S2. Disable the core and peripherals used by the real-time operating system.

[0043] Disable the kernel and peripherals used by the real-time operating system, and reserve shared memory for inter-kernel communication. Set the status="disabled" attribute in the CPU kernel node of the Linux device tree to prevent Linux from scheduling that kernel; the expression for disabling the kernel and peripherals of the real-time operating system is:

[0044] cpu@3{

[0045] compatible="arm,cortex-a53\0arm,armv8";

[0046] device_type = "cpu";

[0047] enable-method="psci";

[0048] reg = ;

[0049] cpu-idle-states =
;

[0050] next-level-cache = ;

[0051] status = "disabled";

[0052] };

[0053] Additionally, an openamp_reserved node is defined in the device tree, through... <reg>The attribute configures the address range of the shared memory segment. The expression for the shared memory segment reserved for inter-core communication is:

[0054]

[0055] S3, Multiple images saved to memory

[0056] The U-Boot, real-time operating system, and Linux images are stored in the memory; the U-Boot image, real-time operating system image, Linux kernel image, and Linux file system image are then burned into the memory using a burning tool.

[0057] S4 and RTOS boot priority

[0058] U-Boot loads the image of the real-time operating system to a reserved address, brings the CPU core online via the Power Management Interface Specification (PSCI), and starts the real-time operating system; specifically, U-Boot loads rtos.bin to the reserved address using the following expression:

[0059] sfprobe

[0060] sfread0x01400000x033FFFF0x200000

[0061] In addition, U-Boot connects to CPU3 and starts the real-time operating system via PSCI using the method: invoke_psci_fn(CPU_ON_FUNCID,info.cpu_id,info.boot_addr,0);

[0062] Where cpu_id is the kernel where the RTOS resides, and boot_addr is the load address.

[0063] The PSCI-enabled CPU core startup specifically includes: U-Boot calling the CPU_ON function in the PSCI standard interface, passing parameters including the CPU core ID of the real-time operating system and the image loading address, to wake up and start the target core S5, followed by the subsequent boot of the Linux system.

[0064] U-Boot then loads the Linux kernel and file system and starts Linux. The real-time operating system runs on at least one independent CPU core in a multi-core processor, while Linux runs on multiple CPU cores. Inter-core communication between the two is achieved through a shared memory segment defined by the device tree. When U-Boot loads the Linux kernel and file system, it specifically includes:

[0065] Configure the Linux boot environment using preset boot parameters and boot commands. These boot parameters include at least console parameters, the root file system path, and the mount method; the specific expression is:

[0066] bootargs=console=ttyPS0,115200

[0067] earlycon=uart8250,mmio32,0xe0004000root= / dev / mtdblock2rootwaitrwrootfst ype=jffs2

[0068] bootcmd=run$modeboot||rundistro_bootcmd

[0069] In summary, the present invention has the following advantages:

[0070] 1. Improve the startup speed of the real-time operating system to meet the needs of high real-time scenarios and reduce the risk of startup delay;

[0071] 2. Optimize resource utilization, reserve memory for real-time operating system and shared memory for inter-core communication, avoid resource conflicts, and reduce additional CPU resource usage;

[0072] 3. Reduce development complexity and cost, and solve the complex development process caused by existing Hypervisor technology.

[0073] The above specific embodiments are only used to illustrate the technical solutions of the present invention and are not intended to limit it. Although the present invention has been described in detail with reference to examples, those skilled in the art should understand that modifications or equivalent substitutions can be made to the technical solutions of the present invention without departing from the scope of the technical solutions of the present invention, and all such modifications or substitutions should be covered within the scope of the claims of the present invention.< / reg> < / reg> < / reg> < / reg>

Claims

1. A method for booting a real-time operating system on a multi-core processor AMP architecture, characterized in that, include: S1. Reserve memory resources for the real-time operating system in both the U-Boot and Linux device trees, specifically including: The remote_core node is defined in both the U-Boot and Linux device trees, and the node contains... <reg>The properties are used to configure the starting address and size of the memory, and are set... <no-map> This property prevents the Linux side from accessing the real-time operating system's memory resources.< / no-map> < / reg> S2. Disable the cores and peripherals used by the real-time operating system, and reserve shared memory for inter-core communication; S3. Transfer the U-Boot, real-time operating system, and Linux image to the storage. S4. U-Boot loads the image of the real-time operating system to a reserved address, brings the CPU core online via the power management interface, and starts the real-time operating system. Specifically, this includes: The U-Boot calls the CPU_ON function in the standard interface of the power management interface specification, passing in parameters including the CPU core ID where the real-time operating system is located and the image loading address, to wake up and start the target core. S5 and U-Boot then load the Linux kernel and file system and start Linux.

2. The method for starting a real-time operating system on a multi-core processor AMP architecture according to claim 1, characterized in that, The step S2, which disables the core used by the real-time operating system, specifically includes: Set the status="disabled" attribute in the CPU core node of the Linux device tree to prevent Linux from scheduling the core and peripherals.

3. The method for starting a real-time operating system on a multi-core processor AMP architecture according to claim 1, characterized in that, The shared memory reserved for inter-core communication mentioned in step S2 specifically includes: Define the openamp_reserved node in the device tree, through <reg> The attribute configures the address range of the shared memory segment.< / reg> 4. The method for starting a real-time operating system on a multi-core processor AMP architecture according to claim 1, characterized in that, The real-time operating system runs on an independent CPU core in a multi-core processor, while Linux runs on multiple CPU cores. The two communicate with each other through a shared memory segment defined by the device tree.

5. The method for starting a real-time operating system on a multi-core processor AMP architecture according to claim 1, characterized in that, The step of mirroring to memory in S3 specifically includes: The U-Boot image, real-time operating system image, Linux kernel image, and Linux file system image are burned using a burning tool.

6. The method for booting a real-time operating system on a multi-core processor AMP architecture according to claim 1, characterized in that, The real-time operating system runs on at least one CPU core independently allocated in a multi-core processor, while Linux runs on multiple CPU cores.

7. The method for booting a real-time operating system on a multi-core processor AMP architecture according to claim 1, characterized in that, When U-Boot loads the Linux kernel and file system in S5, the specific steps include: Configure the Linux boot environment using preset boot parameters and boot commands. The boot parameters include at least console parameters, root file system path, and mount method.

Images