Access conversion method and device of peripheral register, electronic equipment and storage medium

Abstract

The embodiment of the invention discloses an access conversion method and device of a peripheral register, electronic equipment and a computer readable storage medium, and relates to the technical field of computers.The method comprises the steps that an equipment hardware access interface is created, and a memory mapping function is registered; responding to an application program access equipment hardware access interface, and calling a memory mapping function to apply for a shared memory corresponding to the application program; responding to the application program to access the shared memory, and calling a preset monitoring operation function; determining a physical address mapped by the shared memory based on a preset monitoring operation function, and establishing a memory monitoring service for the physical address; responding to the situation that the application program accesses the physical address through the memory monitoring service, and obtaining peripheral register data from the shared memory. Therefore, when the off-chip peripheral register is accessed, access can also be performed in a memory mapping base address and offset mode, and the operation of accessing the register by an application layer is simplified.

Description

Technical Field

[0001] This disclosure relates to the field of computer technology, specifically to a method, apparatus, electronic device, and computer-readable storage medium for accessing and converting peripheral registers. Background Technology

[0002] On the ARM (Advanced RISC Machine) platform, peripherals are generally divided into on-chip peripherals and off-chip peripherals. On-chip refers to the integrated circuit chip itself, and off-chip is similarly defined. Peripherals are devices located outside the integrated circuit chip. The connection between an integrated circuit chip and external devices typically requires dedicated interface circuits and bus connections (including control buses, address buses, and data buses). Due to the rapid development of large-scale integrated circuit technology, many chips now integrate some interface circuits and buses internally during manufacturing. At the software level, the CPU typically accesses on-chip peripherals using mmap (memory mapping) with a base address plus offset. Off-chip peripherals, however, require access via the bus. For a driver to access an off-chip device, it must first access the registers of that device, sending and receiving electrical signals through these registers to complete the access.

[0003] Driver engineers are responsible for driver development. In certain special scenarios, the application layer needs to directly access the registers of peripherals. At this time, the access methods of peripherals under different buses are different. Application engineers need to understand the relevant knowledge of drivers, which brings a lot of workload to application engineers.

[0004] Therefore, how to make it easier for the application layer to access the registers of external peripherals is a problem that needs to be solved. Summary of the Invention

[0005] This disclosure provides a method, apparatus, electronic device, and computer-readable storage medium for accessing and converting peripheral registers, aiming to at least partially solve one of the technical problems in the related art.

[0006] In a first aspect, embodiments of this disclosure provide a method for accessing and translating peripheral registers, the method comprising:

[0007] Create the device hardware access interface and register the memory mapping function;

[0008] In response to an application accessing the device hardware access interface, the memory mapping function is invoked to request shared memory corresponding to the application;

[0009] In response to the application's first access to the shared memory, a preset monitoring operation function is invoked;

[0010] Based on the preset monitoring operation function, the physical address mapped by the shared memory is determined, and a memory monitoring service is established for the physical address;

[0011] In response to the detection by the memory monitoring service that the application accesses the physical address, peripheral register data is obtained from the shared memory.

[0012] Secondly, embodiments of this disclosure also provide a peripheral register access translation device, the device comprising:

[0013] Create a module to create device hardware access interfaces and register memory mapping functions;

[0014] The first calling module is used to call the memory mapping function in response to the application accessing the device hardware access interface, so as to request the shared memory corresponding to the application;

[0015] The second calling module is used to call a preset monitoring operation function in response to the application's first access to the shared memory;

[0016] A module is established to determine the physical address mapped by the shared memory based on the preset monitoring operation function, and to establish a memory monitoring service for the physical address.

[0017] The acquisition module is configured to acquire peripheral register data from the shared memory in response to the memory monitoring service detecting that the application accesses the physical address.

[0018] Thirdly, this disclosure also provides an electronic device, which includes a memory, a processor, and a computer program stored in the memory and executable on the processor. When the computer program is executed by the processor, it implements the steps in the peripheral register access conversion method described above.

[0019] Fourthly, embodiments of this disclosure also provide a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps in the aforementioned peripheral register access and conversion method.

[0020] Fifthly, embodiments of this disclosure also provide a computer program product or computer program including computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the methods provided in various optional implementations of embodiments of this disclosure.

[0021] In this embodiment, a device hardware access interface is first created and a memory mapping function is registered. Then, in response to an application accessing the device hardware access interface, the memory mapping function is called to request shared memory corresponding to the application. Subsequently, in response to the application's first access to the shared memory, a preset monitoring operation function is called. Based on the preset monitoring operation function, the physical address mapped to the shared memory is determined, and a memory monitoring service is established for the physical address. Then, in response to the memory monitoring service detecting that the application accesses the physical address, peripheral register data is obtained from the shared memory. Thus, when accessing off-chip peripheral registers, access can also be achieved by adding an offset to the memory-mapped base address. This memory mapping simplifies the application-layer register access operation, eliminating the need for reprogramming based on different bus types, greatly simplifying the application-layer code for accessing peripheral registers, and reducing the workload of application engineers.

[0022] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and are not intended to limit this disclosure. Attached Figure Description

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

[0024] Figure 1 This is a flowchart illustrating the peripheral register access conversion method provided in an embodiment of this disclosure;

[0025] Figure 2 This is a diagram illustrating the interaction process between ISA device drivers and applications via memory mapping.

[0026] Figure 3 This is a schematic diagram illustrating the driver implementation process;

[0027] Figure 4 This is a diagram illustrating the hardware breakpoint triggering and handling process;

[0028] Figure 5This is a schematic diagram of the structure of the peripheral register access conversion device provided in the embodiments of this disclosure;

[0029] Figure 6 This is a schematic diagram of the structure of the electronic device provided in the embodiments of this disclosure. Detailed Implementation

[0030] Some embodiments of this disclosure will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description refers to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. Various changes, modifications, and equivalents of the methods, apparatus, and / or systems described herein will become apparent upon understanding this disclosure. For example, the order of operations described herein is merely illustrative and is not limited to those orders set forth herein, but can be changed as will become apparent upon understanding this disclosure, except for operations that must be performed in a particular order. Furthermore, for clarity and brevity, descriptions of features known in the art may be omitted.

[0031] The embodiments described in the following examples of this disclosure are not representative of all embodiments consistent with this disclosure. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this disclosure as detailed in the appended claims.

[0032] The following will explain some of the terms used in the embodiments of this application.

[0033] Memory mapping establishes a mapping relationship between a segment of physical memory in kernel space and a virtual address space in user space, allowing both spaces to directly read and write to the same physical memory without the need for traditional system calls to copy data. Memory mapping reduces the number of data copies between user space and kernel space, improving I / O efficiency (e.g., large file read / write, shared memory communication). User programs can directly manipulate files or devices as if they were memory. Application scenarios include file mapping (e.g., database index files), shared memory (inter-process communication), and device drivers (mapping hardware registers).

[0034] mmap is a memory-mapped file mechanism that directly maps the physical address of a file or device to the virtual address space of a process. This allows the process to access file content directly, as if it were accessing memory, without needing to copy data using traditional read / write system calls. This mechanism significantly improves I / O efficiency, and is particularly suitable for large file operations or scenarios requiring frequent file access.

[0035] The Memory Management Unit (MMU) is a hardware component in the CPU responsible for translating virtual addresses (VAs) used by programs into physical addresses (PAs). The MMU uses page tables to map virtual addresses to physical addresses. It controls process access permissions to memory regions (e.g., read-only, read-write). It supports programs using address spaces larger than physical memory, dynamically loading disk data through a paging mechanism. Memory mapping relies on the MMU to translate virtual addresses to physical addresses. When a user program accesses a mapped region via mmap, the MMU translates the virtual address into a physical address, potentially triggering a page fault to load data from disk. Because the MMU performs virtual-to-physical address translation, it allows the use of more memory space. Due to the principle of locality of reference, temporarily unused data can be stored on disk, and when accessed, a page fault occurs, loading the required data from disk into memory. Therefore, the MMU can be used to run programs larger than available memory and open files larger than available memory. Modern processors use segmentation and paging mechanisms to translate virtual addresses into physical addresses, typically supporting two-level or four-level page tables.

[0036] On-chip peripherals are hardware functional modules directly integrated inside a microprocessor chip, sharing the same silicon die as the CPU core and requiring no additional external circuitry. They are suitable for scenarios sensitive to real-time performance, power consumption, and cost, such as smart homes, industrial control, and consumer electronics. For example, on-chip peripherals of STM32 microcontrollers can be directly used for motor control (PWM) and sensor data acquisition (ADC).

[0037] Off-chip peripherals are hardware modules independent of the microprocessor chip. They connect to the CPU via external pins (I / O interfaces) of the chip and require additional circuit design and wiring. They are suitable for scenarios requiring special functions or high performance, such as multimedia devices (external cameras), IoT terminals (external Wi-Fi modules), and industrial equipment (external Ethernet chips).

[0038] It should be noted that the execution subject of the peripheral register access conversion method in this embodiment can be a peripheral register access conversion device, which can be configured in any type of electronic device and is not limited here.

[0039] In this embodiment of the disclosure, the "peripheral register access conversion device" will be used as the execution subject to describe the "peripheral register access conversion method", and no limitation will be made here.

[0040] It should be noted that the order of description of the following embodiments is not intended to limit the priority of the embodiments.

[0041] Figure 1 This is a flowchart illustrating the peripheral register access conversion method provided according to the first embodiment of this disclosure.

[0042] like Figure 1 As shown, the method includes:

[0043] Step 101: Create a device hardware access interface and register the memory mapping function.

[0044] The device hardware access interface can be the / dev / isa device node in a Linux system. In the Linux file system, the / dev directory stores device files that represent connected hardware devices. An ISA device node is represented as a file in the file system (usually located under the / dev / directory). In Linux, / dev / isa is a directory used to store device files related to the ISA bus. In Linux, the ISA (Industry Standard Architecture) device node is an abstract interface created by the kernel for hardware devices, enabling interaction between user space and hardware. ISA was a bus standard used in early PCs to connect the CPU, memory, and peripherals (such as sound cards and network cards). The Linux kernel uses the term ISA device to refer generally to hardware devices connected via standard buses, including devices on buses such as PCI, USB, and SPI.

[0045] The memory mapping function is the mmap() function. In the Linux kernel, drivers register their device operation interfaces with the system through the file_operations structure, and the mmap() function is a key member of this structure, used to implement memory mapping functionality.

[0046] The specific implementation method for creating a device hardware access interface can be as follows: First, a device hardware access interface is created in the file system through the driver. The device hardware access interface is the interface for interaction between the device driver and the user space application.

[0047] The driver acts as a bridge between the kernel and hardware devices, responsible for handling device initialization, data transfer, interrupt handling, and other operations. For ISA devices, the driver needs to create the corresponding device node in the kernel and provide an interface for user space to access the device. The `file_operations` structure is a kernel data structure that defines the kernel functions corresponding to various operations performed by user-space programs on the device file.

[0048] Memory mapping is a mechanism that directly maps the physical address of a file or device to the virtual address space of a process. Using `mmap()`, a process can directly access the physical memory or I / O space of a device as if it were memory, avoiding the data copying overhead between user space and kernel space caused by traditional `read()` / `write()` system calls. The registers or buffers of ISA devices are typically located at specific physical addresses; `mmap()` allows user-space programs to directly manipulate these addresses, improving efficiency.

[0049] Step 102: In response to the application accessing the device hardware access interface, a memory mapping function is called to request the shared memory corresponding to the application.

[0050] Shared memory is a virtual memory region allocated by the driver.

[0051] The application can access the device hardware access interface, open the device node (such as / dev / isa_device), call the mmap() function, and pass in parameters such as file descriptor, target virtual address pointer, memory size, and protection flag. After receiving the mmap request, the kernel calls the .mmap method registered in the driver. The driver layer processes the mmap request. The .mmap method in the driver needs to complete the following tasks: (1) Allocate shared memory. For physical memory allocation, the driver requests a block of physical memory through kmalloc(), dma_alloc_coherent(), or a reserved memory area. The memory size needs to match the mapping length (length parameter) requested by the application. If it is DMA shared memory, it is necessary to ensure that the memory has DMA consistency. (2) Register page fault handling function. Page fault exception handling: When the user space accesses a virtual address (shared memory) that has not been actually mapped for the first time, a page fault exception will be triggered. The driver establishes the mapping from virtual address to physical page frame through remap_pfn_range() or io_remap_pfn_range(). If dynamic handling of page faults is required (such as on-demand allocation of physical pages), a custom fault function needs to be registered: define the `.fault` method in `struct vm_operations_struct` to handle physical page allocation and mapping during page faults. (3) Establish virtual address mapping: use `remap_pfn_range()` to map the page frame number (PFN) of physical memory to the virtual address range in user space. If more complex control is required (such as non-contiguous physical pages), it can be achieved through `vm_insert_page()` or a custom fault function.

[0052] For example, after an application accesses the device's hardware access interface, it can call a memory mapping function to obtain a virtual address. This triggers the execution of the `mmap` function provided by the driver. In this function, the driver requests shared memory, which can be accessed by both the application and the driver for data exchange. Simultaneously, the driver registers a `fault` function with the kernel to handle page faults. When an application accesses the device's hardware access interface and a page fault is triggered, the kernel calls the registered `fault` function to complete physical memory allocation, address mapping establishment, and other operations to ensure that the application can subsequently access the relevant memory region normally.

[0053] Step 103: In response to the application's first access to shared memory, a preset monitoring operation function is invoked.

[0054] Specifically, the application can attempt to read and write virtual address regions mapped via mmap. If the virtual address is not actually mapped to a physical page (i.e., the page table entry is invalid), the CPU will trigger a page fault. The kernel calls the driver's Fault function: the kernel checks the vm_area_struct structure corresponding to the virtual address and finds that this area is associated with a custom fault function registered by the driver. It then calls the .fault method provided by the driver. The tasks of the Fault function are: Allocating physical memory: If the page fault is caused by the first access, the driver may need to dynamically allocate physical pages (e.g., via alloc_page or kmalloc). For pre-allocated shared memory, it directly establishes a mapping from the virtual address to the existing physical page. Updating the page table: It fills the page table entry with the Physical Page Frame Number (PFN) to establish a mapping from the virtual address to the physical address. It uses vm_insert_page or directly manipulates the page table (requiring a page table lock). Synchronization and cache maintenance: If DMA memory is involved, it is necessary to ensure the consistency between the CPU cache and the device memory. If the `.fault` function establishes a mapping from a virtual address to a physical address, subsequent accesses to that address will be directly translated by the MMU, eliminating the need to trigger a page fault interrupt again. The CPU can find the corresponding physical address by consulting the page table, achieving efficient access.

[0055] Step 104: Based on the preset monitoring operation function, determine the physical address mapped by the shared memory, and establish a memory monitoring service for the physical address.

[0056] Among these, the monitoring operation functions can be fault functions, used for page fault handling. Specifically, the monitoring operation functions can be used to create shared memory regions and create memory relationship tables.

[0057] Understandably, when user space accesses an unmapped virtual address, the kernel calls the driver's monitoring function. The driver determines the corresponding physical address based on the virtual address offset or other contextual information. This physical address may come from a pre-allocated shared memory pool or a fixed physical address of a hardware register.

[0058] Optionally, a shared memory region corresponding to the shared memory can be created based on a preset monitoring operation function, and then a shared memory mapping relationship can be created, where the shared memory mapping relationship is the mapping relationship between the shared memory region and the corresponding physical address.

[0059] In particular, during the monitoring operation function or driver initialization phase, a memory monitoring mechanism can be registered to capture access to physical addresses. For example, hardware breakpoints can be set, read / write / execution breakpoints can be set using debug registers, or it can be achieved through the kernel interface or by directly manipulating hardware registers.

[0060] If the hardware does not support breakpoints, monitoring can be simulated by periodically checking changes in memory content. The monitoring service needs to specify trigger conditions (such as read access, write access, or execution). When the CPU accesses the monitored physical address, the hardware or software mechanism captures the event. After triggering, the kernel calls the callback function registered by the driver. The callback function can perform the following operations: record access logs, modify memory content or prevent access, or notify user space. If monitoring involves DMA memory, it is necessary to ensure the consistency between the CPU cache and device memory, use locks (such as spinlocks) to protect shared data structures, and avoid race conditions. Through preset monitoring operation functions, the driver can dynamically determine the physical address in the event of a page fault and establish a memory monitoring service in conjunction with hardware or software mechanisms.

[0061] Step 105: In response to the detection by the memory monitoring service that the application is accessing a physical address, peripheral register data is retrieved from shared memory.

[0062] As one possible approach, in response to the detection of an application accessing a physical address via a memory monitoring service, the driver retrieves the target data from the peripheral registers, updates the shared memory based on the target data, and then the peripheral register data can be retrieved from the updated shared memory.

[0063] Optionally, the driver can access the registers of the FPGA via the PCIe high-speed bus for peripheral component interconnection, and then operate the industry-standard architecture ISA bus through the FPGA registers to read the target data in the peripheral registers of the ISA device.

[0064] Specifically, the driver detects application access to specific physical addresses through preset memory monitoring services (such as hardware breakpoints or software polling). When the monitoring service is triggered, the kernel calls the callback function registered by the driver to notify of the access event. In the callback function, the driver determines the shared memory region corresponding to the accessed physical address. Based on the address mapping relationship, it identifies the peripheral device to be accessed (such as a PCIe device or an ISA device), and then can obtain data from the peripheral device registers. Peripheral access path: PCIe to FPGA to ISA bus (optional path): PCIe access to FPGA: The driver accesses the FPGA's configuration space or memory-mapped registers through the PCIe bus. It communicates with the FPGA using the PCIe's BAR (Base Address Register) space or a custom MMIO region. FPGA operation of the ISA bus: The FPGA implements the ISA bus controller through its logic and accesses the registers of the connected ISA devices. The driver indirectly controls the ISA bus timing through the FPGA's registers to read the target data. Direct ISA access (if applicable): If the system supports direct ISA access (such as traditional x86 platforms), the driver can directly read and write ISA ports or memory addresses.

[0065] The driver reads target data from peripheral registers and writes it to a pre-allocated shared memory region. The atomicity and consistency of the write operation are ensured. If the shared memory is accessed by multiple processes, data must be protected by locking. The application accesses the shared memory through the virtual address mapped by mmap. After the driver updates the shared memory, the application can directly read the latest data without initiating a new system call. This process achieves an efficient data path from hardware registers to user space by monitoring peripheral access via memory monitoring. Key points include the monitoring trigger mechanism, peripheral bus operation, and data consistency guarantees, which need to be optimized based on the specific hardware platform and driver requirements.

[0066] In this embodiment, a device hardware access interface is first created and a memory mapping function is registered. Then, in response to an application accessing the device hardware access interface, the memory mapping function is called to request shared memory corresponding to the application. Following this, in response to the application accessing the shared memory, a preset monitoring operation function is called. Based on the preset monitoring operation function, the physical address mapped to the shared memory is determined, and a memory monitoring service is established for the physical address. Finally, in response to the memory monitoring service detecting application access to the physical address, peripheral register data is retrieved from the shared memory. Therefore, when accessing off-chip peripheral registers, access can also be achieved using a memory-mapped base address plus an offset. This memory mapping simplifies application-layer register access operations, eliminating the need for reprogramming based on different bus types, significantly simplifying the application-layer code for accessing peripheral registers and reducing the workload of application engineers.

[0067] Figure 2 This is a schematic diagram illustrating the interaction process between ISA device drivers and applications via memory mapping. The following is a detailed explanation of the diagram: This flowchart describes the process by which the driver and application use the mmap function to implement memory mapping, thereby accessing ISA device registers. The process is mainly divided into two parts: driver-side initialization settings and application-side access operations, involving mechanisms such as page interrupts and memory access monitoring.

[0068] Step 1 (Driver Entry Point Related Operations): Starting from the "driver entry point," the first step is to "create / dev / isa." This step creates a device node in the file system, providing an interface for subsequent applications to access the device. Next, the "mmap function is registered with the kernel." This allows the kernel to know that the driver provides memory mapping functionality so that it can be called when appropriate.

[0069] Step 2 (Application Entry Point Related Operations): Starting from the "application entry point," first, "open / dev / isa" to obtain the handle for the device file, establishing a connection between the application and the device driver. Then, call the mmap function to "obtain the virtual address," acquiring the virtual address corresponding to the device's shared memory through memory mapping. Afterward, access memory using "base address + offset," which is the specific method the application uses to access shared memory. If it's the first access, a page interrupt will be triggered, subsequently calling the fault function and following the fault function's related process. If it's not the first access, directly "obtain register data," completing operations such as reading device register data.

[0070] Step 3 (mmap function related operations): When certain conditions are met (such as an application requesting memory mapping), the mmap function is called. The mmap function performs a "shared memory request" operation, allocating shared memory space for data interaction between the driver and the application. Then, it "registers the fault function with the kernel." The fault function is used to handle page faults and is triggered when the accessed memory address has not yet been allocated a physical page.

[0071] Step 4 (Fault function related operations): The fault function is called when a page fault is triggered on the first access. The fault function first "creates a shared memory region," formally establishing the shared memory space structure. Next, it "creates a memory mapping table" to establish the mapping relationship between virtual addresses and physical addresses, facilitating subsequent memory access. Finally, it "creates a breakpoint memory watchpoint" to monitor access to a specific memory region; subsequent access to that region will trigger a breakpoint.

[0072] Step 5 (Subsequent Access Operations): This step is initiated after a breakpoint is triggered by a subsequent access. First, the target register is obtained, determining the specific device register to be operated on. Then, bus register operations are used to access the actual device register through bus-related operations. Next, shared memory data is updated by retrieving data from the device register and updating it in shared memory for the application to read. Finally, the process ends.

[0073] Figure 3 This demonstrates the driver implementation process, primarily focusing on creating a device node in the file system and providing a series of related operation functions for that node to enable access and control of the ISA device. The process begins with driver initialization, progressively setting up various function pointers and operations, until finally achieving access to hardware registers and data processing. The following is a detailed explanation of each part.

[0074] `alloc_chrdev_region`: Allocates a range of character device numbers, preparing for the creation of device nodes in the file system. This is fundamental for driver-managed devices. `cdev_init`: Initializes a character device structure (cdev) and associates the device's operation functions with this structure. These operation functions include functions like `mmap`, which will be used later, informing the kernel how to interact with the device. `cdev_add`: Adds the initialized character device to the kernel's character device management list, allowing the kernel to recognize and manage the device. `class_create`: Creates a device class and a corresponding directory under ` / sys / class` for easy device classification, management, and identification. `device_create`: Based on the previously created device class, actually creates the device node in the ` / dev` directory of the file system, completing the device's representation in the file system. Applications can access the device through this node. Provides registration for the `mmap` function and virtual memory operation functions. The `file_operations` structure is set up, where the `mmap` function pointer points to the `mmap` function provided by the driver. When an application executes the `mmap` system call on the device node, the kernel calls the `mmap` function provided by the driver. In the `mmap` function, memory space is allocated, and `vm_ops` is set (`vma->vm_ops=&my_vm_ops`, where `my_vm_ops` is a custom virtual memory operation structure). Virtual memory operation service functions are registered; these functions will play a role in subsequent virtual memory operations. Regarding the `vm_operations` structure: the `vmalloc_to_page` function may be used to convert virtual memory addresses to corresponding page structures, a fundamental operation in virtual memory management. The core of the virtual memory operation functions is the page fault monitoring function (a function pointed to by the function pointer in the `vm_operations` structure). When the application first actually accesses shared memory, a page fault exception will be triggered because the physical memory mapping may not yet be properly established, and the system will call this page fault monitoring function. In this function, a memory monitoring service is created (such as setting up breakpoint-related monitoring mechanisms) to prepare for subsequent memory access monitoring. When the application accesses the previously mapped memory segment, an interrupt will be triggered (because the previously set memory monitoring mechanism is in effect). At this point, the system calls the breakpoint service function, which is specifically designed to handle such memory access trigger events. Within the breakpoint service function, the FPGA registers are first accessed via the system's PCIe bus. The FPGA acts as a bridge here, manipulating its registers to operate the ISA bus and ultimately read the ISA device's registers.After reading the data, the result is copied back to the shared memory, completing the process of obtaining data from the hardware register and feeding it back to the shared memory, thus realizing the data interaction and conversion between software and hardware.

[0075] Figure 4 This is a diagram illustrating the hardware breakpoint triggering and handling process. The following is a detailed explanation of the diagram's content: The process begins with "configuring the breakpoint register." Developers or debugging tools write relevant configuration information to the CPU's breakpoint register using specific instructions or interfaces. This information includes the breakpoint type (execution breakpoint or memory breakpoint), breakpoint address (program address for execution breakpoints, memory range address for memory breakpoints), and trigger conditions (such as read, write, or execute operations). This step is fundamental for setting hardware breakpoints, informing the CPU under what conditions to trigger them. After configuring the breakpoint register, the CPU continues to execute the program instruction flow normally, running according to the established program logic. During CPU execution, when the pre-set breakpoint conditions are met—that is, when the address within the breakpoint is accessed (execution breakpoints execute to the set program address; memory breakpoints operate on the set memory range)—the subsequent process is triggered. When the CPU accesses the address within the breakpoint, an exception is triggered. The CPU suspends the currently executing normal program flow and enters the exception handling path. Decoding the ISS reveals the exception type as ESR_ELx_EC_BREAKPT_CUR: When a CPU exception occurs, it stores exception-related information in specific registers. The system analyzes the contents of the ISS register to determine that the exception type is "ESR_ELx_EC_BREAKPT_CUR," indicating that the exception was triggered by a hardware breakpoint. The system then finds the service function corresponding to ESR_ELx_EC_BREAKPT_CUR from the exception vector table: The exception vector table is a predefined table that records the addresses of handling functions for different types of exceptions. After determining the exception type to be "ESR_ELx_EC_BREAKPT_CUR," the system uses this exception type as an index to search for the corresponding service function address in the exception vector table. Once the corresponding service function is found, the CPU jumps to that service function to begin execution. Within a service function, a series of operations are typically performed, such as saving the current CPU context (register values, etc.) for later program resumption; notifying debugging tools (such as debuggers) that a hardware breakpoint has been triggered, allowing developers to view the current program state (variable values, stack information, etc.) for debugging and analysis; and potentially allowing developers to decide how the program will execute (such as single-stepping or continuing execution). After the service function completes, depending on the specific circumstances, the CPU can either continue running the program normally or trigger the breakpoint again (if the program execution again meets the breakpoint conditions), forming a loop processing flow.

[0076] To facilitate better implementation of the peripheral register access conversion method of this disclosure, this disclosure also provides a peripheral register access conversion apparatus based on the above-described peripheral register access conversion method. The meanings of the terms used are the same as in the peripheral register access conversion method described above, and specific implementation details can be found in the descriptions of the method embodiments.

[0077] Please see Figure 5 , Figure 5 This is a schematic diagram of the structure of a peripheral register access translation device 500 provided in an embodiment of this disclosure. The peripheral register access translation device 500 includes:

[0078] Create module 510 to create the device hardware access interface and register memory mapping functions;

[0079] The first calling module 520 is used to call the memory mapping function in response to the application accessing the device hardware access interface, so as to request the shared memory corresponding to the application.

[0080] The second calling module 530 is used to call a preset monitoring operation function in response to the application's first access to the shared memory;

[0081] A module 540 is established to determine the physical address mapped by the shared memory based on the preset monitoring operation function, and to establish a memory monitoring service for the physical address.

[0082] The acquisition module 550 is configured to acquire peripheral register data from the shared memory in response to the memory monitoring service detecting that the application accesses the physical address.

[0083] Optionally, the creation module is specifically used for:

[0084] The device hardware access interface is created in the file system by the driver. The device hardware access interface is the interface through which the device driver interacts with the user space application.

[0085] Optionally, the acquisition module is specifically used for:

[0086] When the memory monitoring point detects that the physical address is accessed by the application, the target data is obtained from the peripheral register based on the driver.

[0087] Update the shared memory based on the target data;

[0088] Obtain the peripheral register data from the updated shared memory.

[0089] Optionally, the acquisition module is specifically used for:

[0090] The driver accesses the registers of the FPGA via the PCIe high-speed bus for peripheral component interconnection.

[0091] The target data in the peripheral registers of the ISA device is read by operating the industry-standard architecture ISA bus through the registers of the FPGA.

[0092] Optionally, the establishment module is further configured to:

[0093] The monitoring operation function is registered with the kernel and is used to handle page faults.

[0094] In this embodiment, a device hardware access interface is first created and a memory mapping function is registered. Then, in response to an application accessing the device hardware access interface, the memory mapping function is called to request shared memory corresponding to the application. Following this, in response to the application accessing the shared memory, a preset monitoring operation function is called. Based on the preset monitoring operation function, the physical address mapped to the shared memory is determined, and a memory monitoring service is established for the physical address. Finally, in response to the memory monitoring service detecting application access to the physical address, peripheral register data is retrieved from the shared memory. Therefore, when accessing off-chip peripheral registers, access can also be achieved using a memory-mapped base address plus an offset. This memory mapping simplifies application-layer register access operations, eliminating the need for reprogramming based on different bus types, significantly simplifying the application-layer code for accessing peripheral registers and reducing the workload of application engineers.

[0095] In addition, this disclosure also provides an electronic device, such as Figure 6 As shown, it illustrates a schematic diagram of the structure of the electronic device involved in this disclosure, specifically:

[0096] The electronic device may include components such as a processor 601 with one or more processing cores, a memory 602 with one or more computer-readable storage media, a power supply 603, and an input unit 604. Those skilled in the art will understand that... Figure 6 The electronic device structure shown does not constitute a limitation on the electronic device and may include more or fewer components than shown, or combine certain components, or have different component arrangements. Wherein:

[0097] The processor 601 is the control center of the electronic device. It connects various parts of the electronic device via various interfaces and lines, and performs various functions and processes data by running or executing software programs and / or modules stored in the memory 602, and by calling data stored in the memory 602, thereby providing overall monitoring of the electronic device. Optionally, the processor 601 may include one or more processing cores; preferably, the processor 601 may integrate an application processor and a modem processor, wherein the application processor mainly handles the operating system, user interface, and applications, and the modem processor mainly handles wireless communication. It is understood that the modem processor may not be integrated into the processor 601.

[0098] The memory 602 can be used to store software programs and modules. The processor 601 executes various functional applications and data processing by running the software programs and modules stored in the memory 602. The memory 602 may mainly include a program storage area and a data storage area. The program storage area may store the operating system, application programs required for at least one function (such as sound playback function, image playback function, etc.), etc.; the data storage area may store data created according to the use of the electronic device, etc. In addition, the memory 602 may include high-speed random access memory, and may also include non-volatile memory, such as at least one disk storage device, flash memory device, or other volatile solid-state storage device. Accordingly, the memory 602 may also include a memory controller to provide the processor 601 with access to the memory 602.

[0099] The electronic device also includes a power supply 603 that supplies power to the various components. Preferably, the power supply 603 can be logically connected to the processor 601 through a power management system, thereby enabling functions such as charging, discharging, and power consumption management through the power management system. The power supply 603 may also include one or more DC or AC power supplies, recharging systems, power equipment debugging circuits, power converters or inverters, power status indicators, and other arbitrary components.

[0100] The electronic device may also include an input unit 604, which can be used to receive input digital or character information and generate keyboard, mouse, joystick, optical or trackball signal inputs related to user settings and function control.

[0101] Although not shown, the electronic device may also include a display unit, etc., which will not be described in detail here. Specifically, in this embodiment, the processor 601 in the electronic device loads the executable files corresponding to the processes of one or more application programs into the memory 602 according to the following instructions, and the processor 601 runs the application programs stored in the memory 602, thereby implementing the steps in any of the peripheral register access conversion methods provided in the embodiments of this disclosure.

[0102] In this embodiment, a device hardware access interface is first created and a memory mapping function is registered. Then, in response to an application accessing the device hardware access interface, the memory mapping function is called to request shared memory corresponding to the application. Following this, in response to the application accessing the shared memory, a preset monitoring operation function is called. Based on the preset monitoring operation function, the physical address mapped to the shared memory is determined, and a memory monitoring service is established for the physical address. Finally, in response to the memory monitoring service detecting application access to the physical address, peripheral register data is retrieved from the shared memory. Therefore, when accessing off-chip peripheral registers, access can also be achieved using a memory-mapped base address plus an offset. This memory mapping simplifies application-layer register access operations, eliminating the need for reprogramming based on different bus types, significantly simplifying the application-layer code for accessing peripheral registers and reducing the workload of application engineers.

[0103] For details on the implementation of each of the above operations, please refer to the previous examples, which will not be repeated here.

[0104] Those skilled in the art will understand that all or part of the steps in the various methods of the above embodiments can be performed by instructions, or by instructions controlling related hardware. These instructions can be stored in a computer-readable storage medium and loaded and executed by a processor.

[0105] To this end, this disclosure provides a computer-readable storage medium storing a computer program that can be loaded by a processor to execute the steps of any of the peripheral register access translation methods provided in this disclosure.

[0106] For details on the implementation of each of the above operations, please refer to the previous examples, which will not be repeated here.

[0107] The computer-readable storage medium may include: read-only memory (ROM), random access memory (RAM), disk or optical disk, etc.

[0108] Since the instructions stored in the computer-readable storage medium can execute the steps in any of the peripheral register access conversion methods provided in this disclosure, the beneficial effects that any of the peripheral register access conversion methods provided in this disclosure can achieve can be realized, as detailed in the preceding embodiments, and will not be repeated here.

[0109] The foregoing has provided a detailed description of a peripheral register access conversion method, apparatus, electronic device, and computer-readable storage medium provided in this disclosure. Specific examples have been used to illustrate the principles and implementation methods of the present invention. The descriptions of the above embodiments are only for the purpose of helping to understand the method and core ideas of the present invention. At the same time, those skilled in the art will recognize that, based on the ideas of the present invention, there will be changes in the specific implementation methods and application scope. Therefore, the content of this specification should not be construed as a limitation of the present invention.

Claims

1. A method for accessing and converting peripheral registers, characterized in that, include: Create the device hardware access interface and register the memory mapping function; In response to an application accessing the device hardware access interface, the memory mapping function is invoked to request shared memory corresponding to the application; In response to the application's first access to the shared memory, a preset monitoring operation function is invoked; Based on the preset monitoring operation function, the physical address mapped by the shared memory is determined, and a memory monitoring service is established for the physical address; In response to the detection by the memory monitoring service that the application accesses the physical address, peripheral register data is obtained from the shared memory.

2. The method according to claim 1, characterized in that, The creation of the device hardware access interface includes: The device hardware access interface is created in the file system by the driver. The device hardware access interface is the interface through which the device driver interacts with the user space application.

3. The method according to claim 2, characterized in that, The step of retrieving peripheral register data from the shared memory in response to the detection by the memory monitoring service that the application accesses the physical address includes: In response to the memory monitoring service detecting that the application accesses the physical address, the target data is obtained from the peripheral register based on the driver. Update the shared memory based on the target data; Obtain the peripheral register data from the updated shared memory.

4. The method according to claim 3, characterized in that, The step of obtaining target data from peripheral registers based on the driver includes: The driver accesses the registers of the FPGA via the PCIe high-speed bus for peripheral component interconnection. The target data in the peripheral registers of the ISA device is read by operating the industry-standard architecture ISA bus through the registers of the FPGA.

5. The method according to claim 1, characterized in that, Before determining the physical address mapped to the shared memory based on the preset monitoring operation function, the method further includes: The monitoring operation function is registered with the kernel and is used to handle page faults.

6. The method according to claim 1, characterized in that, Determining the physical address mapped by the shared memory includes: Create the shared memory region corresponding to the shared memory; Create a shared memory mapping relationship, wherein the shared memory mapping relationship is a mapping relationship between the shared memory region and the corresponding physical address.

7. A peripheral register access conversion device, characterized in that, include: Create a module to create device hardware access interfaces and register memory mapping functions; The first calling module is used to call the memory mapping function in response to the application accessing the device hardware access interface, so as to request the shared memory corresponding to the application; The second calling module is used to call a preset monitoring operation function in response to the application's first access to the shared memory; A module is established to determine the physical address mapped by the shared memory based on the preset monitoring operation function, and to establish a memory monitoring service for the physical address. The acquisition module is configured to acquire peripheral register data from the shared memory in response to the memory monitoring service detecting that the application accesses the physical address.

8. The apparatus according to claim 7, characterized in that, The creation module is specifically used for: The device hardware access interface is created in the file system by the driver. The device hardware access interface is the interface through which the device driver interacts with the user space application.

9. An electronic device, characterized in that, It includes a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor, when executing the computer program, implements the steps of the method as described in any one of claims 1-5.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the steps of the method as described in any one of claims 1-5.

Images