Multi-core processor AMP architecture real-time operating system starting method

Abstract

The invention relates to the technical field of embedded operating systems, in particular to a multi-core processor AMP architecture real-time operating system starting method, which comprises the following steps: reserving a real-time operating system memory in U-Boot and Linux equipment trees by defining nodes, and setting specific attributes to prevent resource conflicts; a real-time operating system core is forbidden in a Linux device tree, and a node is defined to reserve an inter-core communication shared memory. After the related mirror image is solidified by utilizing a burning tool, the U-Boot firstly loads the mirror image of the real-time operating system to a reserved address, starts a corresponding core by virtue of a CPUON function of a power management interface specification, then loads a Linux kernel and a file system to start the Linux, and the dual systems communicate through a shared memory segment; the starting speed of a real-time operating system is increased, the high-real-time scene requirement is met, and the starting delay risk is reduced.

Description

Technical Field

[0001] The present invention belongs to the technical field of embedded operating systems, and in particular relates to a method for starting a real-time operating system of a multi-core processor AMP architecture. Background Art

[0002] As SoC performance continues to improve due to the integration of homogeneous or heterogeneous multi-cores, and application scenarios become increasingly complex due to the need for both real-time performance and high throughput, more and more devices are allowing the simultaneous deployment and operation of multiple operating systems (OS) on the same hardware platform to fully utilize hardware resources and meet the needs of different scenarios. For example, running the Linux operating system and a real-time operating system (RTOS) simultaneously on the same SoC and providing an IPC communication mechanism between the two systems can fully utilize the ecological 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, located between 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 and partitioning resources such as the CPU, memory, and peripherals used by each system, allowing Linux and RTOS to run through the hypervisor. However, this technology has drawbacks. The hypervisor consumes additional CPU resources, and the software development cycle is long and complex.

[0004] Existing Patent 2 (Announcement No. CN114327929A) discloses a priority processing method based on the AMP architecture. In this architecture, Linux and the RTOS run on different CPU cores, operating independently and not sharing a scheduler. In this type of existing asymmetric multi-processing architecture, the real-time operating system (RTOS) boot relies on Linux. Generally, after Linux boots, Linux loads the RTOS image into designated memory and starts the RTOS through instructions. This boot method results in a slow RTOS boot speed, making it difficult to meet application scenarios with strict real-time requirements.

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

[0006] In order to solve the above technical problems existing in the prior art, the present invention provides a multi-core processor AMP architecture real-time operating system startup method to improve the startup speed of the real-time operating system, meet the needs of high real-time scenarios, and reduce the risk of startup delay.

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

[0008] A method for starting a real-time operating system of a multi-core processor AMP architecture, comprising:

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

[0010] S2. disabling the core and peripherals used by the real-time operating system and reserving shared memory for inter-core communication;

[0011] S3, mirroring the U-Boot, real-time operating system and Linux into a memory;

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

[0013] S5. U-Boot then loads the Linux kernel and file system and starts Linux.

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

[0015] Define remote_core nodes in the U-Boot and Linux device trees respectively, and the nodes contain <reg>Properties to configure the memory start address and size, and set <no-map>Attributes prevent the Linux side from accessing that memory.

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

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

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

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

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

[0021] The U-Boot calls the CPU_ON function in the power management interface specification standard interface, and the incoming parameters include 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 a multi-core processor, and Linux runs on the remaining CPU cores, and the two realize inter-core communication through a shared memory segment defined by a device tree.

[0023] Furthermore, the step of solidifying the image into the memory in S3 specifically includes:

[0024] Use the burning tool to solidify the U-Boot image, real-time operating system image, Linux kernel image, and Linux file system image.

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

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

[0027] The Linux startup environment is configured through preset startup parameters and startup commands, wherein the startup parameters at least include console parameters, root file system path and mounting 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 with an AMP architecture. This method boots the RTOS before booting Linux after U-Boot. Furthermore, the RTOS core is brought online using the power management interface specification, ensuring that U-Boot can continue loading and booting the Linux operating system after the RTOS is booted. This method solves the problem of RTOS startup delays caused by Linux booting first, meeting the requirements for some applications with high real-time requirements. BRIEF DESCRIPTION OF THE DRAWINGS

[0030] Figure 1 A flowchart of a method for starting a real-time operating system of a multi-core processor AMP architecture provided by an embodiment of the present invention. DETAILED DESCRIPTION

[0031] The technical solution of the present invention will be clearly described below in conjunction with the accompanying drawings. Obviously, the described embodiments are not all embodiments of the present invention. All other embodiments obtained by ordinary technicians in this field without making creative work are within the scope of protection of the present invention.

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

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

[0034] See Figure 1 , which is a flowchart of a method for starting a real-time operating system on a multi-core processor AMP architecture proposed in the present invention. Assuming that there are four CPU cores on an SoC, Linux runs on CPU cores 0, 1, and 2, and a real-time operating system (RTOS) runs on CPU core 3, the specific steps of the present invention may include:

[0035] S1. Device tree resource reservation configuration

[0036] Reserve real-time operating system memory resources in U-Boot and Linux device trees respectively, including:

[0037] Define remote_core nodes in the U-Boot and Linux device trees respectively, and the nodes contain <reg>Properties to configure the memory start address and size, and set <no-map>The attribute prevents the Linux side from accessing that memory.

[0038] Among them, in the U-Boot device tree, the real-time operating system memory is reserved. This resource is remote_core used independently by the real-time operating system. The expression is:

[0039]

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

[0041]

[0042] S2, disable the core and peripherals used by the real-time operating system

[0043] Disable the core and peripherals used by the real-time operating system and reserve shared memory for inter-core communication. Set the status="disabled" attribute in the CPU core node of the Linux device tree to prohibit Linux from scheduling the core. The expression for disabling the core 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] In addition, define the openamp_reserved node in the device tree, through <reg>The address range of the property configuration shared memory segment, the expression of the shared memory segment reserved for inter-core communication is:

[0054]

[0055] S3, multiple images are solidified to storage

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

[0057] S4, RTOS starts first

[0058] U-Boot loads the image of the real-time operating system to the reserved address, goes online through the Power Management Interface Specification (PSCI) and starts the real-time operating system; wherein, U-Boot loads rtos.bin to the reserved address, the expression is:

[0059] sfprobe

[0060] sfread0x01400000x033FFFF0x200000

[0061] In addition, U-Boot goes online to CPU3 through PSCI and starts the real-time operating system. The method used is: invoke_psci_fn(CPU_ON_FUNCID,info.cpu_id,info.boot_addr,0);

[0062] Among them, cpu_id is the core where the RTOS is located, and boot_addr is the loading address.

[0063] The PSCI online CPU core specifically includes: U-Boot calls the CPU_ON function in the PSCI standard interface, and the incoming parameters include the CPU core ID and image loading address where the real-time operating system is located, wakes up and starts the target core S5, and the Linux system is subsequently started

[0064] U-Boot then loads the Linux kernel and file system and boots 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. The two communicate with each other through shared memory segments defined in the device tree. U-Boot loads the Linux kernel and file system, specifically including:

[0065] Configure the Linux startup environment through preset startup parameters and startup commands. The startup parameters at least include console parameters, root file system path and 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 real-time operating systems to meet the needs of high-real-time scenarios and reduce the risk of startup delays;

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

[0072] 3. Reduce development complexity and costs, and solve the complex development process brought 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 the present invention. Although the present invention has been described in detail with reference to examples, those skilled in the art should understand that the technical solutions of the present invention may be modified or replaced by equivalents without departing from the scope of the technical solutions of the present invention, and all of these should be included in the scope of the claims of the present invention.< / reg> < / reg> < / reg> < / reg>

Claims

1. A method for starting a real-time operating system of a multi-core processor AMP architecture, characterized in that: include: S1. Reserve real-time operating system memory resources in U-Boot and Linux device trees respectively; S2. disabling the core and peripherals used by the real-time operating system and reserving shared memory for inter-core communication; S3, mirroring the U-Boot, real-time operating system and Linux into a memory; S4. U-Boot loads the image of the real-time operating system to the reserved address, goes online through the power management interface specification, and starts the CPU core and the real-time operating system; S5. U-Boot then loads the Linux kernel and file system and starts Linux.

2. The method for starting a multi-core processor AMP architecture real-time operating system according to claim 1, characterized in that: The U-Boot and Linux device tree in step S1 reserve real-time operating system memory resources, specifically including: Define remote_core nodes in the U-Boot and Linux device trees respectively, and the nodes contain <reg>Properties to configure the memory start address and size, and set <no-map> Attributes prevent the Linux side from accessing that memory.< / no-map> < / reg> 3. The method for starting a multi-core processor AMP architecture real-time operating system according to claim 1, characterized in that: Disabling the core used by the real-time operating system in step S2 specifically includes: Setting the status="disabled" attribute in the CPU core node of the Linux device tree prohibits Linux from scheduling the core and peripherals.

4. The method for starting a multi-core processor AMP architecture real-time operating system according to claim 1, characterized in that: The shared memory reserved for inter-core communication in step S2 specifically includes: Define the openamp_reserved node in the device tree, through <reg> The property configures the address range of the shared memory segment.< / reg> 5. The method for starting a multi-core processor AMP architecture real-time operating system according to claim 1, characterized in that: The power management interface specification is brought online to the CPU core in step S4, specifically including: The U-Boot calls the CPU_ON function in the standard interface of the power management interface specification, and the incoming parameters include 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.

6. The method for starting a multi-core processor AMP architecture real-time operating system according to claim 5, characterized in that: The real-time operating system runs on an independent CPU core in a multi-core processor, and Linux runs on multiple CPU cores. The two realize inter-core communication through a shared memory segment defined by a device tree.

7. The method for starting a multi-core processor AMP architecture real-time operating system according to claim 1, characterized in that: The step of solidifying the image into the storage in S3 specifically includes: Use the burning tool to solidify the U-Boot image, real-time operating system image, Linux kernel image, and Linux file system image.

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

9. The method for starting a multi-core processor AMP architecture real-time operating system according to claim 1, characterized in that: When U-Boot in S5 loads the Linux kernel and file system, it specifically includes: The Linux startup environment is configured through preset startup parameters and startup commands, wherein the startup parameters at least include console parameters, root file system path and mounting method.

Images