Data processing method, multi-core heterogeneous system and computer readable storage medium

Abstract

The invention discloses a data processing method, a multi-core heterogeneous system and a computer readable storage medium, and belongs to the technical field of data processing.The method comprises the steps that in the initialization stage of a hardware system, a physical storage space is allocated based on a predefined physical address boundary, and the physical storage space comprises a shared space; writing predefined configuration data corresponding to the shared space into a configuration register of the storage management module and latching the configuration register, wherein the configuration data comprises an access control strategy and a storage attribute; in the starting stage of the operating system, an address mapping relation is obtained, the address mapping relation comprises a target mapping relation, and under the condition that the operating system runs, a storage management module is triggered based on an instruction of a target operation to execute the target operation based on the address mapping relation, configuration data and a virtual address corresponding to the instruction, the target operation is read operation or write operation. The calculation amount of the processor is greatly reduced, and the time consumption for reading and writing data is reduced on the whole.

Description

Technical Field

[0001] This application relates to the field of data processing technology, and more specifically, to a data processing method, a multi-core heterogeneous system, and a computer-readable storage medium. Background Technology

[0002] In asymmetric multi-processing (AMP) heterogeneous systems, the central processing unit (CPU) comprises multiple processing cores. These cores do not share a common operating system scheduler. If one core modifies shared memory while other cores still have old data in their caches, cache inconsistency occurs. Existing methods for implementing inter-core communication in asymmetric multi-processing heterogeneous systems are time-consuming. Summary of the Invention

[0003] This application proposes a data processing method, a multi-core heterogeneous system, and a computer-readable storage medium to improve the above-mentioned deficiencies.

[0004] In a first aspect, this application provides a data processing method applied to a processor in a multi-core heterogeneous system, the multi-core heterogeneous system further including a storage management module. The method includes: during the hardware system initialization phase, allocating physical storage space based on predefined physical address boundaries, the physical storage space including a shared space; during the hardware system initialization phase, writing predefined configuration data corresponding to the shared space into the configuration register of the storage management module and latching the configuration register, the configuration data including access control policies and storage attributes; during the operating system startup phase, obtaining an address mapping relationship, the address mapping relationship including a target mapping relationship, the target mapping relationship being the correspondence between the physical address and the virtual address of the shared space; and during operating system operation, triggering the storage management module to execute the target operation based on the address mapping relationship, the configuration data, and the virtual address corresponding to the instruction, the target operation being a read operation or a write operation.

[0005] Optionally, in one possible implementation, the processor includes multiple processing cores, and the physical storage space further includes private spaces for each of the processing cores. The step of obtaining the address mapping relationship during the operating system startup phase includes: determining the physical address of the shared space and the physical address of the private space of each processing core based on the device tree during the operating system startup phase; and establishing an address mapping relationship based on the physical address of the shared space and the physical address of the private space of each processing core.

[0006] Optionally, in one possible implementation, determining the physical address of the shared space and the physical address of the private space of each processing core based on the device tree during the operating system startup phase includes: determining whether the device tree matches the information stored in each register of the storage management module, and determining whether the device tree matches the physical address boundary; if the device tree matches the information stored in each register of the storage management module and matches the physical address boundary, then determining the physical address of the shared space and the physical address of the private space of each processing core based on the device tree.

[0007] Optionally, in one possible implementation, the target mapping relationship includes multiple sub-mapping relationships, each of which is a correspondence between the physical address of the shared space and the virtual address of one of the processing cores.

[0008] Optionally, in one possible implementation, the device tree is predefined based on the physical address boundaries.

[0009] Secondly, this application also provides a multi-core heterogeneous system, including: a storage management module and a processor, wherein the processor is used to execute the data processing method described in the first aspect.

[0010] Optionally, in one possible implementation, the storage management module includes a memory management unit, a global memory protection unit, a cache controller, and a storage controller. The configuration register of the global memory protection unit is used to store the configuration data. The memory management unit is used to determine the target physical address corresponding to the instruction based on the address mapping relationship and the target virtual address corresponding to the instruction. The global memory protection unit is used to determine the access permissions of the target physical address based on the target physical address and the access control policy. The cache controller is used to determine a caching policy based on the storage attributes of the target physical address if the target physical address has access permissions. The storage controller is used to execute the target operation based on the caching policy and the target physical address.

[0011] Optionally, in one possible implementation, the processor includes multiple processing cores, at least two of the processing cores include cache modules, and the storage attributes of the shared space include a caching strategy corresponding to each cache module.

[0012] Fourthly, this application also provides a computer-readable medium storing processor-executable program code that, when executed by the processor, causes the processor to perform the above-described method.

[0013] Fifthly, this application also provides a computer program product, including a computer program / instructions that, when executed by a processor, implement the above-described method.

[0014] In this embodiment, firstly, during the hardware system initialization phase, physical storage space is allocated based on predefined physical address boundaries, including shared space; secondly, during the hardware system initialization phase, predefined configuration data corresponding to the shared space is written into the configuration register of the storage management module and latched, the configuration data including access control policies and storage attributes; then, during the operating system startup phase, address mapping relationships are obtained, including target mapping relationships, which are the correspondence between the physical address and virtual address of the shared space; finally, when the operating system is running, the storage management module is triggered to execute the target operation based on the address mapping relationship, the configuration data, and the virtual address corresponding to the instruction, the target operation being a read operation or a write operation.

[0015] Compared to existing methods that use explicit instructions and software protocols to achieve data synchronization, the CPU has a larger workload and the data reading and writing time is longer.

[0016] This application allocates physical storage space, including a shared space, during the hardware system initialization phase and stores the configuration data corresponding to the shared space in the configuration register of the storage management module, thus solidifying the hardware policy. Then, during the operating system startup phase, it obtains the address mapping relationship, including the mapping relationship of the shared space. While the operating system is running, the processor only needs to execute the instruction for the target operation, and the storage management module can automatically execute the target operation. The CPU in this application only needs to execute one instruction; the hardware can automatically synchronize the cache and automatically execute the target operation. The CPU is unaware of the synchronization and requires no software protocol, significantly reducing the CPU's computational load and overall reducing the time spent reading and writing data.

[0017] Other features and advantages of this application will be set forth in the following description and will be apparent in part from the description or may be learned by practicing the application. The objectives and other advantages of this application may be realized and obtained by means of the structures particularly pointed out in the written description, claims, and drawings. Attached Figure Description

[0018] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0019] Figure 1 The structural block diagram of an existing asymmetric multi-core heterogeneous system is shown; Figure 2 A flowchart of the data processing method provided in an embodiment of this application is shown; Figure 3 A flowchart of a data processing method provided in another embodiment of this application is shown; Figure 4 A flowchart of a data processing method according to another embodiment of this application is shown; Figure 5 A structural block diagram of a multi-core heterogeneous system provided in an embodiment of this application is shown; Figure 6 A structural block diagram of a multi-core heterogeneous system provided in another embodiment of this application is shown; Figure 7 A structural block diagram of a multi-core heterogeneous system provided in another embodiment of this application is shown; Figure 8 A structural block diagram of a computer-readable storage medium provided in an embodiment of this application is shown; Figure 9 A structural block diagram of a computer program product provided in an embodiment of this application is shown. Detailed Implementation

[0020] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of the present application, and not all of them. The components of the embodiments of the present application described and shown in the accompanying drawings can generally be arranged and designed in various different configurations. Therefore, the following detailed description of the embodiments of the present application provided in the accompanying drawings is not intended to limit the scope of the claimed application, but merely represents selected embodiments of the present application. All other embodiments obtained by those skilled in the art based on the embodiments of the present application without inventive effort are within the scope of protection of the present application.

[0021] It should be noted that similar reference numerals and letters in the following figures indicate similar items; therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures. Furthermore, in the description of this application, terms such as "first," "second," etc., are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0022] In asymmetric multi-core heterogeneous systems, the Central Processing Unit (CPU) comprises multiple processing cores. These cores do not share an operating system scheduler. If one core modifies shared memory while other cores still have old data in their caches, cache inconsistency occurs. Existing methods for implementing inter-core communication in asymmetric multi-core heterogeneous systems are time-consuming.

[0023] Please see Figure 1 The diagram illustrates the architecture of an asymmetric multi-core heterogeneous system. This system comprises two processing cores, CPU0 and CPU1. CPU0 has a cache (Cache 0), and CPU1 has a cache (Cache 1). The off-chip main memory (Double Data Rate, DDR) peripheral is configured as an insecure address space. CPU0 runs a Linux system, while CPU1 runs a bare-metal system. If CPU0 writes data to a memory address, the DDR must be flushed before CPU1 can read the updated data.

[0024] It should be noted that in asymmetric multi-core heterogeneous systems, different processing cores do not share the same operating system scheduler. There are existing solutions to achieve cache coherency by adding hardware. However, when it is not possible to add hardware, existing methods use user instructions and software drivers to achieve data synchronization between multiple cores, which takes a long time to read and write data.

[0025] For example, in one scenario, CPU0 writes data first, and then CPU1 reads data. First, CPU0 performs the following steps to write data.

[0026] 1. CPU0 executes a "data write" instruction. The result of executing this instruction is that the data is stored in CPU0's cache 0 (dirty state), but it is not visible to other processing cores.

[0027] 2. CPU0 executes the "data cache clear write" instruction. The result of executing this instruction is that a cache line flush operation is triggered, and CPU0 must wait for the flush operation to complete.

[0028] 3. CPU0 executes a "memory barrier" instruction. The result of executing this instruction is that all cache operations are completed and the CPU0 pipeline pauses at this point.

[0029] 4. CPU0 executes the "Set Ready Flag" instruction. The result of executing this instruction is that a "Data Ready" signal is written to the non-cached memory to notify CPU1.

[0030] Then, CPU1 performs the following steps to read the data: 1. CPU1 executes the "polling ready flag" instruction. The result of executing this instruction is: to read the flag bit in a loop until the "data ready" signal of CPU0 is detected.

[0031] 2. CPU1 executes the "cache line invalidation" instruction. The result of executing this instruction is that the old data in CPU1's cache 1 is forcibly invalidated, and CPU1 must wait for the data invalidation to complete.

[0032] 3. CPU1 executes a "memory barrier" instruction. The result of executing this instruction is to ensure that the invalidation operation is completed and to prevent subsequent read operations from being executed prematurely.

[0033] 4. CPU1 executes the "read data" instruction. The result of executing this instruction is that data is eventually retrieved from cache 1 or the DDR peripheral (depending on the cache state).

[0034] Therefore, it can be seen that the existing method requires the CPU to explicitly execute 3-5 synchronization instructions to perceive the synchronization process. The CPU actively controls when the cache is refreshed and when it is invalidated, and software protocols (flag bits and interrupts) are needed to notify other processing cores. Obviously, this scheme of implementing data synchronization through explicit instructions and software protocols results in a large workload for the CPU and a long time consumption for reading and writing data.

[0035] Therefore, this application provides a data processing method, a multi-core heterogeneous system, and a computer-readable storage medium to solve or partially solve the above-mentioned problems.

[0036] Please see Figure 2 The document illustrates a flowchart of a data processing method provided in an embodiment of this application. The method is applied to a processor in a multi-core heterogeneous system, which further includes a storage management module. Specifically, it includes steps S201 to S204.

[0037] It should be noted that the startup process of a known asymmetric multi-core heterogeneous system can be divided into six key stages: power-on and hardware reset, loading of the First Stage Bootloader (FSBL) into the read-only memory (BootROM), FSBL system initialization and image loading, booting of the main core (Bootstrap Processor, BP) operating system, booting of the slave cores (Application Processor, AP), and operating system initialization and read / write readiness. Each stage ensures the system gradually transitions from a hardware reset state to a state where multiple cores operate independently and can perform read / write operations, as detailed below: Phase 1: Power-on and hardware reset.

[0038] The main steps of the first phase include: 1. Power stability detection: The system detects a rise in power supply voltage and waits for it to stabilize.

[0039] 2. Reset signal release: The reset circuit releases the reset signal after the voltage reaches the target value, and the central processing unit enters the default state.

[0040] 3. Automatic execution from the BootROM: After the reset, the CPU begins execution from the fixed BootROM address (e.g., 0x0). The BootROM is an unmodifiable read-only memory embedded inside the chip, used to store the most basic startup code.

[0041] The main functions of the first phase include: Ensure safe hardware initialization: Avoid operating under unstable voltages, which could damage the device.

[0042] Establish the basic execution environment: restore the CPU registers to their default values, and set the program counter to the BootROM entry point.

[0043] Provide a trusted boot root: The BootROM serves as an immutable first-stage code and is responsible for subsequent security verification.

[0044] Second stage: BootROM loads FSBL.

[0045] The main steps of the second phase include: 1. Boot mode detection: Read the boot mode pin / register to determine the boot device, such as a four-wire serial peripheral interface, a secure digital card, an embedded multimedia card, or a non-volatile memory.

[0046] 2. Image Search and Verification: Search for legitimate image files from the boot device and verify the validity of the image header.

[0047] 3. Load FSBL into On-Chip Memory (OCM): Copy the FSBL into the OCM for execution.

[0048] 4. Handover of permissions: Jump to the FSBL entry address in OCM, and the BootROM mission ends.

[0049] The main functions of the second phase include: Enables flexible booting: Supports multiple storage media and adapts to different hardware configurations.

[0050] Security foundation: Authenticate / decrypt the FSBL to prevent malicious code from running.

[0051] Resource pre-configuration: Initialize necessary peripherals (such as the Flash controller) to create conditions for FSBL to run.

[0052] Phase 3: FSBL system initialization and image loading.

[0053] The main steps of the third phase include: 1. Basic CPU configuration: Initialize the vector table, disable the cache or memory management unit (MMU), and unlock the system control registers. The memory management unit is responsible for virtual address to physical address translation and access permission checks.

[0054] 2. Processing System (PS) Subsystem Initialization: Configure Multiplexed I / O (MIO), Phase-Locked Loop, Clock, and DDR Controller, and perform DDR read / write tests to verify memory availability.

[0055] 3. Programmable Logic (PL) Configuration (if applicable): If the image contains a bitstream file, configure the Field-Programmable Gate Array (FPGA) logic via the Processor Configuration Access Port (PCAP).

[0056] 4. Load partition image: Parse the partition header of the boot binary file (BOOT.BIN) and load subsequent images (such as the Second Stage Boot Loader (SSBL), Universal Boot Loader (U-Bboot), and AMP kernel operating system (OS) image, etc.) to the specified DDR address.

[0057] 5. Preparation for permission transfer: Clear the cache and disable the predictor to prepare to jump to the next level of the program.

[0058] The main functions of the third stage include: Building the runtime environment: DDR initialization is a prerequisite for OS operation, and read / write tests ensure memory reliability.

[0059] Hardware resource allocation: Allocate independent physical memory space for each AMP core to achieve resource isolation between cores.

[0060] Heterogeneous configuration: Configure the PL section to implement hardware acceleration or peripheral expansion to support heterogeneous computing needs.

[0061] Phase 4: The main core operating system starts up.

[0062] The main steps of the fourth phase include: 1. Start the main kernel OS: FSBL transfers execution control to the entry address of the main kernel operating system (such as Linux).

[0063] 2. Kernel decompression and initialization: The main kernel OS completes self-decompression, establishes page tables, initializes the scheduler and other core data structures.

[0064] 3. Device Tree Parsing: Read the Device Tree Blob (DTB) to obtain CPU topology, memory layout, and peripheral configuration information.

[0065] 4. Topology discovery and modeling: The cpu_topology hierarchical structure is constructed through the init_cpu_topology() function, which translates physical topology information into data structures that the kernel can use.

[0066] 5. Slave Core Pre-configuration: An independent board-level driver is set up for each slave core to ensure resource allocation isolation. During the multi-core boot process, the BP executes the BootROM and Bootloader, and after initialization, wakes up the AP via inter-core interrupts or shared memory to achieve multi-core collaborative work.

[0067] The main functions of the fourth stage include: Establish a main control core: The main core serves as the system management core, responsible for overall resource scheduling and AP core lifecycle management.

[0068] AMP environment preparation: Complete the address space mapping configuration to ensure that the code segments of each core are shared and the data segments are physically isolated.

[0069] Hardware abstraction: Provides a unified set of operations for AP core startup, shielding hardware differences.

[0070] Phase 5: Start-up from the nuclear core.

[0071] The main steps of the fifth stage include master core triggering and slave core self-execution: The main core triggering steps are as follows: 1. State initialization: Set the asymmetric multiprocessing process status variable (amproc.stat) to the startup state. amproc.stat is the "status flag" polled by the main core. After the AP core starts, amproc.stat is updated to "startup complete".

[0072] 2. Interrupt masking: Disables local CPU interrupts to prevent interference with the startup process.

[0073] 3. Cache refresh: Execute a memory barrier to refresh the cache to a consistency point.

[0074] 4. Set the boot address: Configure the AP core's software reset address register as its lightweight real-time system image entry address.

[0075] 5. Reset and Unreset: First, reset the AP core and clear its cache, then unreset to release the AP core to run.

[0076] 6. Status polling: The main core continuously checks amproc.stat, waiting for the AP core to update to the "boot complete" status.

[0077] 7. Interrupt recovery: After the AP core starts successfully, the main core restores local interrupt enable.

[0078] The steps of AP core self-execution are as follows: 1. Independent initialization: The AP core starts from the reset vector and independently completes the configuration of MMU, local peripherals and input / output address mapping.

[0079] 2. Lightweight real-time system startup: Runs an independent real-time operating system (such as FreeRTOS or Zephyr) and initializes the local kernel task scheduling.

[0080] 3. Resource isolation verification: Verification allows access to authorized resources only, and prohibits unauthorized cross-core access.

[0081] The main functions of the fifth stage include: Achieve differentiated operation: Each AP core can run a different OS to meet heterogeneous computing needs (such as real-time control + general computing).

[0082] Ensuring inter-core isolation: Independent address mapping and drivers ensure fault isolation and improve system security.

[0083] Parallel processing capability: Activate multi-core parallel processing to improve overall system performance.

[0084] Phase 6: Operating system initialization and read / write functionality ready.

[0085] The main steps of the sixth stage include: 1. File system mounting: After each core OS is initialized, the root file system is mounted to the storage device.

[0086] 2. Storage driver loading: Load the storage media driver (such as a secure digital card, embedded multimedia card, or non-volatile memory) and establish a block device access channel.

[0087] 3. File system layer initialization: Initialize the file system management layer, such as the Virtual File System (VFS), Fourth Extended File System (ext4), or File Allocation Table (FAT).

[0088] 4. Application layer initialization: Start system services and mount user directories.

[0089] 5. Read / Write Interface Exposure: Provides standard file access interfaces to applications through system calls (open, read, or write).

[0090] The main functions of the sixth stage include: Data persistence capability: Establish a complete data path from application to storage medium.

[0091] Multi-core independent access: Each core has an independent file system view or storage area, supporting data exchange between cores.

[0092] Functionality Ready: At this point, the system has completed full-stack initialization from hardware to software and can respond to user read and write requests.

[0093] This application represents an improvement to the existing startup process for asymmetric heterogeneous systems, as detailed below: Step S201: During the hardware system initialization phase, physical storage space is allocated based on predefined physical address boundaries, including shared space.

[0094] It is understandable that the physical address boundary is the user-defined physical address of each processing core and the address of the shared storage space.

[0095] It should be noted that the hardware system initialization phase in this application is the aforementioned third phase (FSBL system initialization and image loading), which mainly includes CPU basic configuration, PS subsystem initialization, PL configuration, loading the partition image, and permission transfer preparation. Before loading the partition image in the third phase, this application allocates physical storage space based on predefined physical address boundaries, including shared space. Specifically, the processor parses the shared space descriptor preset by the developer, that is, reads the physical base address, size, access mask, and storage attributes of the shared area preset by the developer from the BOOT.BIN header, and then reserves shared physical space based on the shared space descriptor, that is, marks the shared area as "shared storage" in the DDR memory manager to prevent subsequent loading and overwriting.

[0096] Step S202: During the hardware system initialization phase, predefined configuration data corresponding to the shared space is written into the configuration register of the storage management module and the configuration register is latched. The configuration data includes access control policies and storage attributes.

[0097] Understandably, resolving the shared space descriptor yields the physical base address, size, access mask, and storage attributes of the shared area predefined by the developers. Therefore, after allocating physical storage space, predefined configuration data corresponding to the shared space needs to be written to the configuration register of the storage management module and latched to prevent subsequent loading and overwriting. The configuration data includes access control policies and storage attributes. The access control policies at least include the access permissions granted to each processing core to the physical address, and the storage attributes at least include the caching policies of the caches of each processing core corresponding to that physical address.

[0098] In one alternative embodiment, the configuration data includes the shared area physical base address, size, access mask (i.e., access control policy), and storage attributes.

[0099] In one example, the user presets the first 400 bytes of address 0x30000 as shared space and sets the configuration data corresponding to the shared space. The user adds the designed information to the original FSBL source code. In the third stage, this application allocates physical storage space based on predefined physical address boundaries. The physical storage space includes the shared space (the first 400 bytes of address 0x30000) and writes the predefined configuration data corresponding to the shared space into the configuration register of the storage management module and latches the configuration register. The configuration data includes access control policies and storage attributes. This realizes that in the FSBL stage of system startup, the access rules of shared memory are burned into the hardware register at one time and permanently locked, so that subsequent software (including the operating system) cannot change them. The hardware automatically processes all memory access requests according to these solidified policies, that is, the hardware policy is solidified.

[0100] It should be noted that in the third stage, this application allocates physical storage space based on predefined physical address boundaries. The physical storage space includes a shared space, and predefined configuration data corresponding to the shared space is written into the configuration register of the storage management module and latched. The configuration data includes access control policies and storage attributes, which realizes hardware policy solidification and provides a hardware foundation for the hardware to automatically access the shared space or the private space of each processing core based on instructions.

[0101] Step S203: During the operating system startup phase, obtain the address mapping relationship, which includes the target mapping relationship, which is the correspondence between the physical address and the virtual address of the shared space.

[0102] It is understandable that the address mapping relationship includes the target mapping relationship, as well as the mapping relationship between the physical address and virtual address of the private space of each processing core.

[0103] It should be noted that the operating system startup stage of this application is the aforementioned fourth stage (main kernel operating system startup) and fifth stage (slave kernel startup). During the operating system startup stage, the address mapping relationship is obtained, which can provide a basis for subsequent access to shared space and private space.

[0104] It should be noted that the processors in a multi-core heterogeneous system include a master processor and at least one slave processor. Specifically, during the "core operating system boot" main phase, the address mapping relationship of the master processor (including the mapping relationship between the physical addresses in the shared space and the virtual addresses of the master processor, as well as the mapping relationship between the private space of the master processor and the virtual addresses of the master processor) is obtained. During the "slave core boot" phase, the address mapping relationship of the slave processor (including the mapping relationship between the physical addresses in the shared space and the virtual addresses of the slave processor, as well as the mapping relationship between the private space of the slave processor and the virtual addresses of the slave processor) is obtained.

[0105] In one optional embodiment, during the operating system startup phase, the physical address of the shared space and the physical address of the private space of each processing core are determined based on the device tree; an address mapping relationship is established based on the physical address of the shared space and the physical address of the private space of each processing core. For details, please refer to subsequent embodiments.

[0106] Step S204: When the operating system is running, the storage management module is triggered to execute the target operation based on the address mapping relationship, the configuration data, and the virtual address corresponding to the instruction, where the target operation is a read operation or a write operation.

[0107] It should be noted that this application corresponds to the sixth stage (operating system initialization and read / write functionality readiness) mentioned above when the operating system is running. The processor executes the target operation, and the storage management module executes the target operation based on the address mapping relationship, the configuration data, and the virtual address corresponding to the instruction. The target operation is either a read operation or a write operation.

[0108] It is understandable that the function of the storage management module is automatically implemented by the hardware. This application allocates shared space before the operating system runs and stores the configuration data corresponding to the shared space in the configuration register of the storage management module. This enables the access rules of shared memory to be burned into the hardware register at one time and permanently locked, so that subsequent software (including the operating system) cannot change them. When the target operation is executed, the hardware (storage management module) automatically processes all memory access requests according to these fixed policies.

[0109] An exemplary boot process for an asymmetric multi-core heterogeneous system can be divided into six key stages. The first stage involves power-on and hardware reset. The second stage loads the FSBL from the BootROM. The third stage, based on FSBL system initialization and image loading, adds the allocation of physical storage space based on predefined physical address boundaries, and the writing and latching of predefined configuration data corresponding to the shared space into the configuration register of the storage management module. This allows for hardware policy solidification, establishing unbypassable cross-core access rules before the AP core boots. Then, based on the fourth and fifth stages, address mapping relationships are obtained, including target mapping relationships, which are the correspondence between physical addresses and virtual addresses in the shared space. In the sixth stage, with operating system initialization and read / write functionality ready, this application can trigger the storage management module to execute the target operation based on the address mapping relationship, the configuration data, and the virtual address corresponding to the instruction when performing read / write commands. This enables the hardware to automatically execute the target operation based on the target operation instruction.

[0110] In one optional embodiment, the storage management module includes a memory management unit, a global memory protection unit, a cache controller, and a storage controller. The configuration register of the global memory protection unit is used to store the configuration data. The memory management unit is used to determine the target physical address corresponding to the instruction based on the address mapping relationship and the target virtual address corresponding to the instruction. The global memory protection unit is used to determine the access permissions of the target physical address based on the target physical address and the access control policy. The cache controller is used to determine a caching policy based on the storage attributes of the target physical address if the target physical address has access permissions. The storage controller is used to execute the target operation based on the caching policy and the target physical address.

[0111] In one exemplary scenario, when the operating system is running, to execute a target operation, the memory management unit determines the target physical address corresponding to the instruction based on the address mapping relationship and the target virtual address corresponding to the instruction. The global memory protection unit determines the access permissions of the target physical address based on the target physical address and the access control policy. If the target physical address has access permissions, the cache controller determines whether it has a cache consistency policy based on the storage attributes of the target physical address. If it has a cache consistency policy, the storage controller accesses the corresponding cache to execute the target operation. If it does not have a cache consistency policy, the storage controller accesses the corresponding private space to execute the target operation. If the target physical address does not have access permissions, an execution failure message is returned. Upon receiving this feedback, the processor can execute other instructions.

[0112] In one example, CPU0 writes data first, and then CPU1 reads data. First, CPU0 performs a step to write data.

[0113] 1. CPU0 executes a "data write" instruction. The result of executing this instruction is that the data is stored in CPU0's cache and automatically made visible to other cores by the hardware.

[0114] Then, CPU1 executes a step to read the data: 1. CPU1 executes the "read data" instruction. The result of executing this instruction is that the data is directly retrieved from the CPU0 cache without any preparation. The hardware will automatically achieve cache coherency.

[0115] Therefore, it can be seen that the CPU of this application only needs to execute one instruction, and the hardware can automatically realize cache synchronization and automatically execute the target operation.

[0116] In this embodiment, firstly, during the hardware system initialization phase, physical storage space is allocated based on predefined physical address boundaries, including shared space; secondly, during the hardware system initialization phase, predefined configuration data corresponding to the shared space is written into the configuration register of the storage management module and latched, the configuration data including access control policies and storage attributes; then, during the operating system startup phase, address mapping relationships are obtained, including target mapping relationships, which are the correspondence between the physical address and virtual address of the shared space; finally, when the operating system is running, the storage management module is triggered to execute the target operation based on the address mapping relationship, the configuration data, and the virtual address corresponding to the instruction, the target operation being a read operation or a write operation.

[0117] Compared to existing methods that use explicit instructions and software protocols to achieve data synchronization, the CPU has a larger workload and the data reading and writing time is longer.

[0118] This application allocates physical storage space, including a shared space, during the hardware system initialization phase and stores the configuration data corresponding to the shared space in the configuration register of the storage management module, thus solidifying the hardware policy. Then, during the operating system startup phase, it obtains the address mapping relationship, including the mapping relationship of the shared space. While the operating system is running, the processor only needs to execute the instruction for the target operation, and the storage management module can automatically execute the target operation. The CPU in this application only needs to execute one instruction; the hardware can automatically synchronize the cache and automatically execute the target operation. The CPU is unaware of the synchronization and requires no software protocol, significantly reducing the CPU's computational load and overall reducing the time spent reading and writing data.

[0119] In one alternative embodiment, after the operating system boots up, user programs do not need to use the `memcpy` function for memory copying; the cache will automatically synchronize. The purpose of the cache is to store frequently used data in the cache when the CPU reads and writes memory, allowing subsequent accesses to directly read from the cache, which is much faster than accessing physical memory. The reason for not using `memcpy` is that the Translation Lookaside Buffer (TLB) has already mapped the virtual addresses, and the cache caches data according to this mapping. As long as the memory data is in the cache, the CPU will automatically hit the cache when accessing it, without needing to manually copy it using `memcpy`. The cache has a hardware and software consistency mechanism (such as write-back and write-through). When data is updated, the cache automatically synchronizes the changes to physical memory (or synchronizes with a delayed synchronization policy), ensuring consistency between the memory data and the "copy" in the cache, without requiring user program intervention.

[0120] An exemplary data read / write process is as follows: 1. The user program sends a virtual address. 2. The CPU checks the TLB and determines the physical address mapping based on the virtual address. 3. The physical address is used to check the cache. If the data is in the cache, it is read directly; if the data is not in the cache, it is read from physical memory. 4. When writing data back, the cache is synchronized to physical memory according to a strategy. Throughout this process, the TLB accelerates address translation, and the cache accelerates data access. Together, they make memory operations fast and stable, allowing user programs to use memory efficiently without manually copying data (memcpy). In other words, the TLB makes address translation faster, and the cache makes data read / write faster; each step in the process is designed to work seamlessly with the Linux system, ultimately enabling user programs to access memory more efficiently without manually copying data. This embodiment improves data cache sharing efficiency, CPU performance, and operational data exchange efficiency.

[0121] Please see Figure 3 The document illustrates a flowchart of a data processing method provided in an embodiment of this application. The method is applied to a processor in a multi-core heterogeneous system. The multi-core heterogeneous system further includes a storage management module. The processor includes multiple processing cores, and the physical storage space includes private spaces for each of the processing cores. Specifically, the method includes steps S301 to S305.

[0122] Step S301: During the hardware system initialization phase, physical storage space is allocated based on predefined physical address boundaries, including shared space.

[0123] Step S302: During the hardware system initialization phase, predefined configuration data corresponding to the shared space is written into the configuration register of the storage management module and the configuration register is latched. The configuration data includes access control policies and storage attributes.

[0124] Step S303: During the operating system startup phase, determine the physical address of the shared space and the physical address of the private space of each processing core based on the device tree.

[0125] It should be noted that the operating system startup phase refers to the aforementioned fourth and fifth phases. The fourth phase mainly includes steps such as starting the main OS kernel, kernel decompression and initialization, device tree resolution, topology discovery and modeling, and slave kernel pre-configuration. Since this application adds the allocation of shared space and the storage of shared space configuration data into the configuration register of the storage management module on top of the existing startup process, the device tree in this application also corresponds to the shared space. The physical address of the shared space and the physical address of the private space of each processing core can be determined based on the device tree.

[0126] Step S304: Establish an address mapping relationship based on the physical address of the shared space and the physical address of the private space of each processing core.

[0127] After obtaining the physical address of the shared space and the physical address of the private space of each processing core, an address mapping relationship is established based on the physical address of the shared space and the physical address of the private space of each processing core.

[0128] Specifically, an address mapping relationship is established based on the physical address of the shared space, as well as an address mapping relationship for the private space.

[0129] In one exemplary manner, in the fourth stage, the master processor establishes a mapping between the physical addresses of the shared space and the virtual addresses of the master processor, and the master processor also establishes a mapping between the physical addresses of its corresponding private space and the virtual addresses of the master processor. In the fifth stage, each slave processor establishes a mapping between the physical addresses of the shared space and the virtual addresses of that slave processor, and each slave processor also establishes a mapping between the physical addresses of its corresponding private space and the virtual addresses of that slave processor.

[0130] It should be noted that the configuration can be set so that every slave processor can access the shared space, or it can be set so that some slave processors can access the shared space while others cannot. Slave processors that cannot access the shared space only need to establish a mapping between the physical address of their corresponding private space and the virtual address of that slave processor.

[0131] Step S305: When the operating system is running, the storage management module is triggered to execute the target operation based on the address mapping relationship, the configuration data, and the virtual address corresponding to the instruction, where the target operation is a read operation or a write operation.

[0132] Please see Figure 4 The document illustrates a flowchart of a data processing method provided in an embodiment of this application. The method is applied to a processor in a multi-core heterogeneous system. The multi-core heterogeneous system further includes a storage management module. The processor includes multiple processing cores, and the physical storage space includes private spaces for each of the processing cores. Specifically, the method includes steps S401 to S406.

[0133] Step S401: During the hardware system initialization phase, physical storage space is allocated based on predefined physical address boundaries, including shared space.

[0134] Step S402: During the hardware system initialization phase, predefined configuration data corresponding to the shared space is written into the configuration register of the storage management module and the configuration register is latched. The configuration data includes access control policies and storage attributes.

[0135] Step S403: During the operating system startup phase, determine whether the device tree matches the information stored in each register of the storage management module, and determine whether the device tree matches the physical address boundary.

[0136] It should be noted that the device tree is used to store memory layout, peripheral addresses, and related configurations such as the Translation Lookaside Buffer (TLB). The operating system makes calls based on the hardware description information described in the device tree. If the information described in the device tree file is inconsistent with the hardware information, the operating system may encounter problems. Therefore, during the operating system startup phase, it is necessary to determine whether the device tree matches the information stored in the registers of the memory management module, and whether the device tree matches the physical address boundaries.

[0137] It should be noted that during the FSBL and main kernel operating system startup phases, the device tree is parsed, requiring multi-level verification to ensure the correctness of hardware configuration and system security. Specifically, the third stage of device tree verification mainly includes: format and structural integrity verification, hardware resource legality verification, and security verification. The fourth stage of device tree verification mainly includes: driver compatibility verification, runtime security verification, and AMP-specific verification. If device tree verification fails in the third stage, the startup process stops, error codes are printed via serial port, and the system restarts. If device tree verification fails in the fourth stage, that node is skipped, a warning is recorded, and other devices are started. The third stage of device tree verification focuses on hardware implementability, while the fourth stage focuses on software driverability; together, they verify the device tree to ensure the consistency of hardware resource views across different cores in a heterogeneous system.

[0138] In this application, determining whether the device tree matches the information stored in each register of the storage management module and whether the device tree matches the physical address boundary during the operating system startup phase are additional verification steps for the device tree based on existing device tree verification methods.

[0139] Step S404: If the device tree matches the information stored in each register of the storage management module and matches the physical address boundary, then determine the physical address of the shared space and the physical address of the private space of each processing core based on the device tree.

[0140] It is understood that the device tree matches the information stored in each register of the storage management module, and the device tree determines the physical address of the shared space and the physical address of the private space of each processing core. This indicates that the hardware configuration information is consistent with the hardware description information of the device tree, ensuring the correct operation of the operating system. Therefore, the physical address of the shared space and the physical address of the private space of each processing core are determined based on the device tree.

[0141] For example, if the information stored in the device tree does not match the information stored in the registers of the storage management module, or if the physical address boundaries of the device tree do not match, the user will be fed back with a startup failure message during the operating system startup phase, so as to guide the user to perform maintenance.

[0142] Step S405: Establish an address mapping relationship based on the physical address of the shared space and the physical address of the private space of each processing core.

[0143] Step S406: When the operating system is running, the storage management module is triggered to execute the target operation based on the address mapping relationship, the configuration data, and the virtual address corresponding to the instruction, where the target operation is a read operation or a write operation.

[0144] In one alternative embodiment, the device tree is predefined based on the physical address boundaries.

[0145] It should be noted that users can customize the physical address of the shared space and the corresponding configuration data. Users will modify the original device tree file based on their custom design (this is achieved by modifying the source code).

[0146] In one alternative embodiment, cache consistency is measured by loading a test driver after modifying the device tree.

[0147] In one optional embodiment, the target mapping relationship includes multiple sub-mapping relationships, each of which is a correspondence between the physical address of the shared space and the virtual address of a processing core.

[0148] In one example, the processor includes a master core and at least one slave core. The target mapping relationship corresponding to the master core is a first sub-mapping relationship, which is the correspondence between the physical addresses in the shared space and the virtual addresses of the master core. The target mapping relationship corresponding to the slave core is a second sub-mapping relationship, which is the correspondence between the physical addresses in the shared space and the virtual addresses of the slave core. Furthermore, the timing of the master core determining the target mapping relationship differs from the timing of the slave core determining the target mapping relationship. The master core determines the target mapping relationship in the aforementioned fourth stage, while the slave core determines the target mapping relationship in the aforementioned fifth stage.

[0149] In one alternative embodiment, please refer to Figure 5 It shows a structural block diagram of a multi-core heterogeneous system 500 provided in an embodiment of this application, including: The system includes a storage management module 510 and a processor 520, wherein the processor 520 is used to execute the aforementioned data processing method. The multi-core heterogeneous system 500 also includes a DDR peripheral 530, and the storage management module 510 is used to access the DDR peripheral 530 based on instructions from the processor 520's target operation.

[0150] In one alternative embodiment, please refer to Figure 6 This document illustrates a structural block diagram of a multi-core heterogeneous system 500 provided in an embodiment of this application. The multi-core heterogeneous system 500 further includes a DDR peripheral 530. A storage management module 510 is used to access the DDR peripheral 530 based on the instruction of the target operation of the processor 520. The DDR peripheral 530 includes a shared space and private spaces for each processing core. The storage management module 510 includes a memory management unit 511, a global memory protection unit 512, a cache controller 513, and a storage controller 514. The configuration register of the global memory protection unit 511 is used to store the configuration data. The memory management unit 511 is used to determine the target physical address corresponding to the instruction based on the address mapping relationship and the target virtual address corresponding to the instruction. The global memory protection unit 512 is used to determine the access permissions of the target physical address based on the target physical address and the access control policy. The cache controller 513 is used to determine a caching policy based on the storage attributes of the target physical address when the target physical address has access permissions. The storage controller 514 is used to execute the target operation based on the caching policy and the target physical address.

[0151] In one optional embodiment, the processor includes multiple processing cores, at least two of the processing cores include cache modules, and the storage attributes of the shared space include a caching strategy corresponding to each cache module.

[0152] For an example, please refer to Figure 7This document illustrates a structural block diagram of a multi-core heterogeneous system provided in an embodiment of this application. The asymmetric multi-core heterogeneous system includes CPU0, CPU1, ..., CPUN, a total of N processing cores. Each processing core corresponds to a cache: cache 0 for CPU0, cache 1 for CPU1, and cache N for CPUN. DDR peripherals represent memory, and the shared space is configured as a non-secure address space. In the existing asymmetric multi-core heterogeneous system startup process, power-on and hardware reset are performed in the first stage, FSBL is loaded from the BootROM in the second stage, and system initialization and image loading of FSBL are implemented in the third stage. This is supplemented by allocating physical storage space based on predefined physical address boundaries. The physical storage space includes a shared space, a private space 0 corresponding to CPU0, a private space 1 corresponding to CPU1, ..., and a private space N corresponding to CPUN. Furthermore, the document adds the operation of writing predefined configuration data corresponding to the shared space into the configuration register of the storage management module and latching the configuration register. This enables hardware policy solidification, providing a hardware foundation for automatic hardware access to the shared space or the private space of each processing core based on instructions. An unbypassable cross-core access rule is established before the AP core starts. Then, based on the fourth and fifth stages, an address mapping relationship is obtained. This address mapping relationship includes a target mapping relationship, which is the correspondence between the physical address and the virtual address of the shared space. When performing read / write instructions in the sixth stage, this application can trigger the storage management module to execute the target operation based on the address mapping relationship, the configuration data, and the virtual address corresponding to the instruction. That is, the hardware can automatically execute the target operation based on the target operation instruction.

[0153] Compared to existing methods that use explicit instructions and software protocols to achieve data synchronization, the CPU has a larger workload and the data reading and writing time is longer.

[0154] This application allocates physical storage space, including a shared space, during the hardware system initialization phase and stores the configuration data corresponding to the shared space in the configuration register of the storage management module, thus solidifying the hardware policy. Then, during the operating system startup phase, it obtains the address mapping relationship, including the mapping relationship of the shared space. While the operating system is running, the processor only needs to execute the instruction for the target operation, and the storage management module can automatically execute the target operation. The CPU in this application only needs to execute one instruction; the hardware can automatically synchronize the cache and automatically execute the target operation. The CPU is unaware of the synchronization and requires no software protocol, significantly reducing the CPU's computational load and overall reducing the time spent reading and writing data.

[0155] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working process of the above-described device and module can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0156] In the several embodiments provided in this application, the coupling between modules can be electrical, mechanical, or other forms of coupling.

[0157] Furthermore, the functional modules in the various embodiments of this application can be integrated into one processing module, or each module can exist physically separately, or two or more modules can be integrated into one module. The integrated modules described above can be implemented in hardware or as software functional modules.

[0158] Please refer to Figure 8 This diagram illustrates a structural block diagram of a computer-readable medium provided in an embodiment of this application. The computer-readable medium 800 stores program code that can be called by a processor to execute the methods described in the above method embodiments.

[0159] The computer-readable medium 800 may be an electronic storage device such as flash memory, EEPROM (Electrically Erasable Programmable Read-Only Memory), EPROM, hard disk, or ROM. Optionally, the computer-readable medium 800 includes a non-transitory computer-readable storage medium. The computer-readable medium 800 has storage space for program code 810 that performs any of the method steps described above. This program code can be read from or written to one or more computer program products. The program code 810 may be compressed, for example, in a suitable form.

[0160] Please refer to Figure 9 The diagram illustrates a structural block diagram 900 of a computer program product provided in an embodiment of this application. The computer program product 900 includes a computer program / instructions 910, which, when executed by a processor, implements the steps of the aforementioned method.

[0161] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application.

Claims

1. A data processing method, characterized in that, A processor applied to a multi-core heterogeneous system, wherein the multi-core heterogeneous system further includes a memory management module, the method comprising: During the hardware system initialization phase, physical storage space is allocated based on predefined physical address boundaries, including shared space. During the hardware system initialization phase, predefined configuration data corresponding to the shared space is written into the configuration register of the storage management module and the configuration register is latched. The configuration data includes access control policies and storage attributes. During the operating system startup phase, the address mapping relationship is obtained, which includes the target mapping relationship, which is the correspondence between the physical address and the virtual address of the shared space; When the operating system is running, the storage management module is triggered by the instruction of the target operation to execute the target operation based on the address mapping relationship, the configuration data, and the virtual address corresponding to the instruction. The target operation is a read operation or a write operation.

2. The method according to claim 1, characterized in that, The processor includes multiple processing cores, and the physical storage space also includes private spaces for each of the processing cores. The step of obtaining the address mapping relationship during the operating system startup phase includes: During the operating system startup phase, the physical address of the shared space and the physical address of the private space of each processing core are determined based on the device tree. An address mapping relationship is established based on the physical address of the shared space and the physical address of the private space of each processing core.

3. The method according to claim 2, characterized in that, The step of determining the physical address of the shared space and the physical address of the private space of each processing core based on the device tree during the operating system startup phase includes: During the operating system startup phase, it is determined whether the device tree matches the information stored in each register of the storage management module, and whether the device tree matches the physical address boundary. If the device tree matches the information stored in each register of the storage management module and matches the physical address boundary, then the physical address of the shared space and the physical address of the private space of each processing core are determined based on the device tree.

4. The method according to claim 2, characterized in that, The target mapping relationship includes multiple sub-mapping relationships, each of which is a correspondence between the physical address of the shared space and the virtual address of a processing core.

5. The method according to claim 2, characterized in that, The device tree is predefined based on the physical address boundaries.

6. A multi-core heterogeneous system, characterized in that, include: A storage management module and a processor, wherein the processor is configured to execute the data processing method according to any one of claims 1-5.

7. The multi-core heterogeneous system according to claim 6, characterized in that, The storage management module includes a memory management unit, a global memory protection unit, a cache controller, and a storage controller. The configuration register of the global memory protection unit is used to store the configuration data. The memory management unit is used to determine the target physical address corresponding to the instruction based on the address mapping relationship and the target virtual address corresponding to the instruction. The global memory protection unit is used to determine the access permissions of the target physical address based on the target physical address and the access control policy. The cache controller is used to determine the caching policy based on the storage attributes of the target physical address when the target physical address has access permissions. The storage controller is used to execute the target operation based on the caching policy and the target physical address.

8. The multi-core heterogeneous system according to claim 6, characterized in that, The processor includes multiple processing cores, at least two of the processing cores include cache modules, and the storage attributes of the shared space include a caching strategy corresponding to each cache module.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium contains program code that can be invoked by a processor to execute the method as described in any one of claims 1-5.

10. A computer program product comprising a computer program / instructions, characterized in that, When the computer program / instructions are executed by the processor, they implement the method described in any one of claims 1-5.

Images