Interface calling method, chip and computing device

Abstract

Embodiments of the present application provide an interface calling method, a chip and a computing device. A specific implementation of the method includes: receiving an access request of a first application based on a general interface, the access request being used to access a Joint Test Action Group (JTAG) register; calling an intermediate interface based on the access request, the intermediate interface being used to call a first operation instruction registered in a JTAG structure; and performing an access operation on the JTAG register through a JTAG controller based on the first operation instruction to respond to the access request. Thus, when the JTAG controller or the JTAG register changes, only the first operation instruction needs to be reconstructed to maintain the original general interface and the intermediate interface to respond to the access request, thereby improving the development efficiency of the system and reducing the maintenance cost of the system.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to an interface calling method, a chip, and a computing device. Background Technology

[0002] The Joint Test Action Group (JTAG) is an IEEE standard developed in the 1980s to address issues in electronic board manufacturing. More commonly used, it's a protocol for programming, debugging, and probing ports, primarily for managing or testing JTAG devices (devices with JTAG interfaces, such as CPLDs and FPGAs). JTAG is both a protocol and an interface used to connect control units to JTAG devices.

[0003] The control unit (e.g., the BMC control chip) provides an external JTAG interface. During firmware upgrades or testing of JTAG devices via the JTAG interface, the JTAG driver in the control unit kernel plays a communication role. It coordinates the control unit's JTAG module to send the firmware upgrade package or other control commands stored in the control unit to the JTAG device through the JTAG interface, according to the application requirements of the control unit. It also transmits data such as requests or feedback sent by the JTAG device to the JTAG module through the JTAG interface to the application, thereby enabling the control unit to manage and test the JTAG device. The control unit's JTAG module includes a JTAG controller and JTAG registers.

[0004] However, different manufacturers integrate different JTAG modules into their control units. If users replace the control unit based on business upgrade requirements, they will face the problem of upgrading the application software version to adapt to the original JTAG driver, or reconstructing the original JTAG driver to adapt to the original application. Therefore, the development and maintenance costs remain high. Summary of the Invention

[0005] This application provides an interface calling method, a chip, and a computing device, which can improve system development efficiency and reduce system maintenance costs when users replace control units.

[0006] In a first aspect, embodiments of this application provide an interface invocation method, the method comprising: receiving an access request from a first application based on a general interface; the access request being used to access the Joint Test Action Group JTAG register; the general interface being used to provide interfaces for multiple applications, including the first application; invoking an intermediate interface based on the access request, the intermediate interface being used to invoke a first operation instruction registered in a JTAG structure; the first operation instruction being generated based on the access address information of the JTAG register; and performing an access operation on the JTAG register through a JTAG controller based on the first operation instruction in response to the access request.

[0007] Therefore, based on the general interface, the system first receives the access request from the first application for accessing the Joint Test Action Group's JTAG registers. Then, it calls the intermediate interface to invoke the first operation instruction registered in the JTAG structure. Based on the first operation instruction, the JTAG controller executes the access operation on the JTAG registers, thus responding to the access request. Therefore, even if the JTAG controller or JTAG registers change, only the first operation instruction needs to be refactored to maintain the original general and intermediate interfaces to respond to access requests, thereby improving system development efficiency and reducing system maintenance costs.

[0008] In one possible implementation, before receiving the access request from the first application, the method further includes: obtaining access address information of the JTAG register; generating multiple operation instructions based on the access address information; the multiple operation instructions correspond to multiple access operations of the JTAG controller to the JTAG register, and the first operation instruction is one of the multiple operation instructions; and registering the multiple operation instructions to the JTAG structure respectively.

[0009] Therefore, multiple operation instructions are generated based on the access address information, and these multiple operation instructions are registered to the JTAG structure so that the first application can indirectly call the first operation instruction by calling the intermediate interface.

[0010] In one possible implementation, multiple operation instructions are generated based on access address information, including: determining multiple target operations based on the control logic of the JTAG controller; and setting each of the multiple target operations as an operation instruction of the JTAG controller on the JTAG register based on the access address information to obtain multiple operation instructions.

[0011] Therefore, if the access address information of the JTAG register or the control logic of the JTAG controller changes, multiple operation instructions can be regenerated based only on the access address information of the JTAG register and the control logic of the JTAG controller, while maintaining the original general interface and intermediate interface.

[0012] In one possible implementation, obtaining the access address information of the JTAG register includes obtaining the access address information of the JTAG register based on the system's device tree information.

[0013] Therefore, the first operation instruction can be updated by modifying only the access address information in the device tree without changing the control logic of the JTAG controller.

[0014] In one possible implementation, registering to the JTAG structure includes: setting the first function pointer corresponding to the first structure element of the JTAG structure to point to the function corresponding to the first operation instruction.

[0015] Therefore, even if the access address information of the JTAG register or the JTAG controller changes, multiple operation instructions can be maintained solely through the JTAG structure, thus preserving the original general interface and intermediate interface.

[0016] In one possible implementation, the intermediate interface also invokes additional operation instructions related to the access request.

[0017] Therefore, by calling the intermediate interface, in addition to executing the first operation instruction, related additional functions can be flexibly implemented according to the requirements of the access request.

[0018] In one possible implementation, the first application uses either the devfs or sysfs file system to call a generic interface.

[0019] In one possible implementation, the generic interface is obtained by registering character devices to the devfs file system or registering sys device attributes to the sysfs file system; wherein, the character device corresponds to the JTAG controller, and the sys device attributes correspond to the control logic of the JTAG controller.

[0020] Therefore, a general interface can be provided for the primary application to invoke. Even if the access address information of the JTAG registers or the JTAG controller changes, the original general interface can be maintained for application versions to call, and the original primary application can be preserved.

[0021] Secondly, embodiments of this application provide an interface invocation apparatus, comprising: a receiving module, configured to receive an access request from a first application based on a general interface; the access request is for accessing the Joint Test Action Group JTAG register; the general interface is used to provide interfaces for multiple applications, including the first application; an invocation module, configured to invoke an intermediate interface based on the access request, the intermediate interface being used to invoke a first operation instruction registered in a JTAG structure; the first operation instruction is generated based on access address information of the JTAG register; and a processing module, configured to perform access operations on the JTAG register through a JTAG controller based on the first operation instruction, in response to the access request.

[0022] Thirdly, embodiments of this application provide a chip, including: at least one memory for storing a program; at least one processor for executing the program stored in the memory; the chip further includes a JTAG controller and a JTAG register; the processor is used to control the JTAG controller to access the JTAG register; wherein, when the program stored in the memory is executed, the processor is used to execute the method described in the first aspect or any possible implementation of the first aspect.

[0023] Fourthly, embodiments of this application provide a computing device, including: at least one memory for storing a program; and at least one processor for executing the program stored in the memory; wherein, when the program stored in the memory is executed, the processor is used to execute the method described in the first aspect or any possible implementation of the first aspect.

[0024] Fifthly, embodiments of this application provide a computer storage medium storing instructions that, when executed on a computer, cause the computer to perform the method described in the first aspect or any possible implementation thereof.

[0025] In a sixth aspect, embodiments of this application provide a computer program product containing instructions that, when executed on a computer, cause the computer to perform the method described in the first aspect or any possible implementation thereof.

[0026] It is understood that the beneficial effects of the second to sixth aspects mentioned above can be found in the relevant descriptions in the first aspect mentioned above, and will not be repeated here. Attached Figure Description

[0027] To more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings used in the following description of the embodiments will be briefly introduced. 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.

[0028] Figure 1 This is a system framework diagram based on the JTAG interface provided by related technologies;

[0029] Figure 2 This is a schematic diagram of a JTAG driver call provided by related technologies;

[0030] Figure 3 This is an architecture diagram of a JTAG driver provided in an embodiment of this application;

[0031] Figure 4 This is an architecture diagram of a JTAG driver device interface layer module provided in an embodiment of this application;

[0032] Figure 5 This is an architecture diagram of a JTAG driver device core layer module provided in an embodiment of this application;

[0033] Figure 6 This is an architecture diagram of a JTAG driver hardware shielding layer module provided in an embodiment of this application;

[0034] Figure 7 This is a flowchart of an interface calling method provided in an embodiment of this application;

[0035] Figure 8 This is a schematic diagram of a JTAG driver call provided in an embodiment of this application.

[0036] Figure 9 This is a diagram of an interface calling device provided in an embodiment of this application;

[0037] Figure 10 This is a schematic diagram of the structure of a chip provided in an embodiment of this application. Detailed Implementation

[0038] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions in the embodiments of this application will be described below with reference to the accompanying drawings.

[0039] In the description of the embodiments in this application, any embodiment or design that is “exemplary,” “for example,” or “by way of example” should not be construed as being more preferred or advantageous than other embodiments or designs. Specifically, the use of terms such as “exemplary,” “for example,” or “by way of example” is intended to present the relevant concepts in a concrete manner.

[0040] Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the indicated technical features. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature. The terms "comprising," "including," "having," and variations thereof all mean "including but not limited to," unless otherwise specifically emphasized. "At least one" can refer to one or more, where multiple can refer to two or more.

[0041] For a very large-scale integrated circuit (VLSI) that expands upon a central processing unit (CPU) with numerous interfaces, such as a System-on-Chips (SoC), its high performance, low power consumption, and high flexibility enable a single chip to perform complete electronic system functions. Commonly, some SoCs, in addition to expanding control modules for various external devices, also integrate power management modules, temperature management modules, and so on. For example, a baseboard management controller (BMC) integrates hardware managers for servers, network devices, and other computer systems. Its role is to monitor the hardware status of devices, perform remote management operations, and provide monitoring and control functions for devices. Furthermore, a JTAG module can also be integrated into the BMC to implement JTAG protocol-related functions.

[0042] For example, Figure 1 A system framework diagram based on the JTAG interface provided by related technologies is shown.

[0043] like Figure 1 As shown, the MainBoard (which can be deployed on a server) includes a BMC and a JTAG device. The BMC provides an external JTAG interface and integrates a processor and a JTAG module internally. The JTAG module includes a JTAG controller and JTAG registers.

[0044] The JTAG controller is a dedicated hardware logic within the BMC (Browser Control Center). It handles high-level (e.g., application layer) commands, such as reading and writing memory, reading and writing JTAG registers, and JTAG interface control. JTAG registers are obtained by allocating independent storage space for the JTAG controller through the BMC; they are used to store instructions to be executed or data to be transferred. JTAG devices are devices with a JTAG interface, such as CPLDs and FPGAs.

[0045] The JTAG interface is the physical interface connecting the BMC (Browser Control Unit) and JTAG devices, responsible for communication between them. This interface typically includes essential JTAG signal pins such as the time cycle clock (TCK), test mode select (TMS), test data input (TD1), and test data input (TD1). TCK provides an independent, basic clock signal for management or test operations; TMS sets the JTAG interface to a specific test mode; TD1 is sampled on the rising edge of TCK and used to input data into the JTAG register; and T1 is used to serially output data from the JTAG register under the drive of TCK. Additionally, the JTAG interface may also include a ground pin (GND) and a reset pin (TRST).

[0046] like Figure 1 As shown, within the BMC, the processor and JTAG module are connected via a control bus. The processor coordinates various modules within the BMC, such as the JTAG module, power management module, and temperature management module, to perform timing control, interrupt, or memory access operations according to instructions. Externally, the BMC connects to JTAG devices via a JTAG interface to manage (e.g., firmware upgrades) or perform testing operations on the JTAG devices.

[0047] Additionally, within the BMC, the operating system kernel implements and manages the JTAG driver for the JTAG module. A JTAG driver is a special type of software that enables the operating system to communicate with the hardware associated with the JTAG interface (such as the JTAG controller and JTAG registers). It provides a standardized interface to the operating system, allowing it to execute general commands without needing to understand the specific implementation details of the hardware.

[0048] Specifically, in the process of managing (such as firmware upgrades) or testing JTAG devices based on the JTAG interface, the JTAG driver in the BMC kernel plays a communication role. It coordinates the JTAG modules inside the BMC to send firmware upgrade packages or other control commands stored in the BMC to the JTAG device through the JTAG interface according to the application requirements of the BMC. It also passes the requests or feedback data sent by the JTAG device to the JTAG module through the JTAG interface to the application, so as to realize the function of managing (such as firmware upgrades) or testing JTAG devices through the BMC.

[0049] It is understandable that different operating systems can be used in the BMC kernel, and these different operating systems typically implement and manage JTAG drivers using different strategies. The following will use the Linux operating system as an example to describe the solution proposed in this invention in detail.

[0050] For example, Figure 2 The diagram illustrates a JTAG driver call provided by related technologies.

[0051] like Figure 2 As shown, device drivers, including JTAG drivers, are a type of software that runs in the operating system kernel, controls the operation of the device, and provides some available program interfaces so that other programs can interact with the device.

[0052] For example, a JTAG driver can provide other parts of the BMC with the ability and methods to use JTAG modules by providing unified program interfaces such as open, read, write, and ioctl. The JTAG driver only provides the various capabilities for using JTAG modules to other parts of the BMC; the method of using JTAG modules is determined by the BMC's application. For instance, the application can use the read interface to call drv_read to read data from JTAG registers. Similarly, the open interface is used to call drv_open for hardware initialization of JTAG registers, the write interface is used to call drv_write for writing data to JTAG registers, and the ioctl interface is used to call drv_ioctl for read / write control of JTAG registers, and so on.

[0053] The specific pins used by the BMC for control / data transfer with the JTAG registers, and how to control the JTAG controller's access to the JTAG registers, are determined by the BMC's chip operation manual. Therefore, the code for drv_open, drv_read, drv_write, and drv_ioctl in the JTAG driver is also written with reference to the BMC's chip operation manual.

[0054] It's understandable that different BMC vendors design their integrated JTAG controllers differently, and the address spaces allocated to the JTAG registers for the JTAG controllers also differ. This means that the chip operation manuals for different vendors' BMCs vary, resulting in differences in the northbound and southbound interfaces of the original JTAG drivers. The northbound interface refers to the interface provided to the application for access and management; that is, the interface provided upwards, such as... Figure 2The JTAG driver provides the drv_open, drv_read, drv_write, and drv_ioctl interfaces to applications. Southbound interfaces refer to the interfaces that manage the device, i.e., the interfaces provided downwards, such as... Figure 2 The JTAG driver provides the drv_open, drv_read, drv_write, and drv_ioctl interfaces to JTAG devices.

[0055] like Figure 1 As shown, if the motherboard and the components on the motherboard are used to implement server functions, and if the server manufacturer needs to replace the BMC due to business upgrades, then the north-south interface of the original JTAG driver needs to be adapted for the replaced BMC.

[0056] Typically, after replacing the BMC, you can use the original JTAG driver provided by the BMC vendor, keeping the northbound interface of the JTAG driver unchanged, while the details of southbound interface access to the JTAG module are implemented by the BMC vendor. Server vendors, on the other hand, modify the interface of the BMC application that accesses the JTAG driver to adapt to the original JTAG driver, for example, by modifying... Figure 2 The example shown includes functions like open, read, write, and ioctl. In this approach, on the one hand, if the driver provided by the BMC vendor does not implement the program interface for a certain function, the application's business functionality will be limited; on the other hand, because the application's software version is coupled with a specific BMC, it is not conducive to later maintenance.

[0057] Alternatively, after replacing the BMC, you can develop your own JTAG driver based on the BMC vendor's specifications to provide the northbound interface required by the application. This means maintaining the application's access interface to the JTAG driver, for example... Figure 2 The example shown includes open, read, write, ioctl, etc.; while changing the interfaces provided by the JTAG driver, such as modifying... Figure 2 The example shown includes drv_open, drv_read, drv_write, and drv_ioctl. In this approach, on the one hand, server vendors need to maintain different JTAG drivers for different BMCs, so each time the BMC is changed, the JTAG driver needs to be rebuilt, resulting in very low JTAG driver reusability; on the other hand, due to the lack of support from BMC vendors, the development and maintenance costs for server vendors are very high.

[0058] Therefore, this application first receives an access request from a first application to access the Joint Test Action Group's JTAG registers based on a general interface, and then calls an intermediate interface to invoke a first operation instruction registered in the JTAG structure. Based on the first operation instruction, the JTAG controller performs an access operation on the JTAG registers, thus responding to the access request. Therefore, when the JTAG controller or JTAG registers change, only the first operation instruction needs to be refactored while maintaining the original general and intermediate interfaces to respond to access requests, thereby improving system development efficiency and reducing system maintenance costs.

[0059] For example, Figure 3 An architecture diagram of a JTAG driver provided in an embodiment of this application is shown.

[0060] like Figure 3 As shown, a three-layer driver architecture for the JTAG driver is constructed based on the device interface layer, the device core layer, and the hardware shielding layer. Applications perform internal operations on the JTAG registers by calling the JTAG driver.

[0061] In the device interface layer, since Linux defines system drivers in the form of files, the JTAG module is registered in the BMC operating system's file system to obtain multiple general interfaces, such as general interface 1, 2, etc., to provide access to applications.

[0062] Figure 4 This diagram illustrates the architecture of a JTAG driver device interface layer module provided in an embodiment of this application.

[0063] like Figure 4 As shown, in Linux systems, devfs / sysfs is a memory-based file system that provides kernel information to applications in the form of files. devfs is mounted under the / dev directory, and each file under / dev corresponds to a device. A device refers to any hardware component that can interact with the system control unit. These devices can be internal, such as hard drives, solid-state drives, RAM, graphics cards, sound cards, network cards, etc.; or external, such as printers, scanners, external hard drives, mice, keyboards, monitors, network routers, etc. By manipulating these files, applications can interact with the kernel. sysfs is mounted under the / sys directory and is also used to manage system devices. It organizes the devices and buses actually connected to the system into hierarchical files, which applications can also use to interact with the kernel.

[0064] Devices in a Linux system can be broadly categorized into three types: character devices, block devices, and network devices. Character devices have no buffer, process data sequentially in bytes, and do not support random access. Common examples include ordinary printers, system serial ports, terminal displays, simple buttons in embedded devices, and graphics tablets. Block devices process data in blocks during input and output; typical examples include hard drives and optical drives. Network devices operate at the network protocol layer, such as network interface cards (NICs) and modems. Character and block devices operate at the file system layer; their access interfaces are a set of file-based system calls, such as `read` and `write`.

[0065] It is understood that in this embodiment, the JTAG module is a block device integrated within the BMC.

[0066] For example, the device interface layer can register JTAG modules for the devfs or sysfs interfaces accessed by the application layer. This could involve creating a character device in the ` / dev / jtag` directory and registering related device file operations such as `ioctl`. Another example is creating sysfs device read / write attributes in the ` / sys / class / jtag` directory and registering related device operation attributes such as `show` and `store`. The functionality is implemented as follows... Figure 4 As shown, the device interface layer only focuses on the northbound interface of the JTAG driver. For the interaction between the underlying layer and the hardware and the implementation logic, it is implemented by calling the intermediate interface of the device core layer.

[0067] Figure 5 This paper illustrates an architecture diagram of a JTAG driver core layer module provided in an embodiment of this application.

[0068] like Figure 5 As shown, in the Linux system, `file_operation` is a key data structure that associates system calls with device drivers. Each member of this structure corresponds to a system call. The `file_operation` structure is defined in the header file `linux / fs.h` and is used to store function pointers (determined by the type, number, and order of parameters) provided by the driver kernel module to perform various operations on the device. By reading the corresponding function pointer from `file_operation` and then transferring control to the function, the work of the Linux device driver is completed.

[0069] For example, the device core layer creates a jtag structure similar to `file_operations`, denoted as `jtag_class_operations`, to maintain function pointer members for all operations of the JTAG module. Each operation of the JTAG module is encapsulated as an intermediate interface, exposed to the device interface layer for invocation. Each intermediate interface invokes a function pointer from the `jtag_class_operations` operation set. The device core layer provides an interface for the hardware shielding layer to register and unregister JTAG modules, and the hardware shielding layer populates the function pointer members in `jtag_class_operations`.

[0070] Furthermore, in the device core layer, the `jtag_class_operations` structure maintains the set of all operation instructions for the JTAG module. This set includes read / write operations to the device and other command functions. Multiple intermediate interfaces 1-n are generated based on the `jtag_class_operations` structure for use by the general interfaces 1-2 of the device interface layer.

[0071] The definition of general interface 1-2 is as follows: Figure 3 As shown, in the device interface layer, since Linux defines system drivers in the form of files, the JTAG module is registered in the file system of the BMC operating system to obtain multiple general interfaces, such as general interface 1, 2, etc., to provide access to applications.

[0072] Intermediate interfaces 1-n each contain a structure member of the jtag_class_operations structure, meaning that intermediate interfaces 1-n each correspond to an operation instruction in the set of operation instructions.

[0073] Figure 6 This diagram illustrates the architecture of a JTAG driver hardware shielding layer module provided in an embodiment of this application.

[0074] like Figure 6 As shown, in Linux, drivers are part of the kernel. Drivers can directly access hardware and can be loaded as modules; applications must access hardware through driver loading. Linux drivers do not have a main function; they only implement interfaces, each implementing specific read / write logic for the hardware. For example... Figure 2 The following are some commonly used interfaces: drv_open(), drv_read(), drv_write(), and drv_ioctl(), which correspond to the application's program interfaces open(), read(), write(), and ioctl(), respectively.

[0075] For example, the hardware shielding layer is used to mask the implementation differences of JTAG controllers in different BMCs. First, it obtains the JTAG register address information from the device storage management system and implements the operation instructions (specific read and write logic) for accessing the JTAG registers. It requests a jtag_class_operations structure from the device core layer, assigns its function pointer members to the operation instructions for each hardware operation, and then calls the device registration interface provided by the device core layer to register the assigned structure with the device core layer.

[0076] Furthermore, within the hardware shielding layer, JTAG registers are accessed via operation instructions 1-n from the operation instruction set. Each operation instruction in operation instructions 1-n is determined based on the JTAG controller's control logic and the access address information of the JTAG registers. It's easy to understand that if the BMC needs to be replaced—that is, if different control logic is required to access register information at different address units—hardware adaptation only needs to be performed at this layer. Subsequently, each operation instruction corresponding to each access function is registered in the `jtag_class_operations` structure of the device core layer, without needing to modify the code of the intermediate interface in the device core layer and the general interface in the device interface layer.

[0077] like Figure 3 As shown, if the BMC before the replacement allocates JTAG register 1 to JTAG controller 1, and the BMC after the replacement allocates JTAG register 2 to JTAG controller 2, then only the code corresponding to operation instructions 1-n needs to be updated according to the information of the replaced JTAG controller 2 and JTAG register 2. The code involved in the device core layer and device interface layer can remain unchanged. Therefore, the original northbound interface can be maintained, solving the problem of inconsistent northbound interfaces in JTAG drivers.

[0078] In addition, by encapsulating each logic implementation of the JTAG controller accessing the JTAG register in a corresponding operation instruction within the hardware shielding layer, and registering the operation instruction in the Jtag_class_operations structure of the device core layer for maintenance, the problem of inconsistent southbound interfaces of the JTAG driver is also solved.

[0079] In summary, by designing a JTAG driver framework implemented using the aforementioned device interface layer, device core layer, and hardware shielding layer, the northbound and southbound interfaces of the JTAG driver are abstracted. The northbound interface is standardized and unified by the device interface layer, while the southbound interface is implemented by the hardware shielding layer for each specific BMC, with specific JTAG register access logic implemented and registered with the device core layer. This achieves standardization and unification of the northbound and southbound interfaces of the JTAG driver, improves the development and maintenance efficiency of JTAG drivers for BMC vendors, and reduces maintenance costs.

[0080] Next, based on Figures 3-6 The content here describes an interface calling method provided in the embodiments of this application.

[0081] For example, Figure 7 A flowchart of an interface calling method provided in an embodiment of this application is shown.

[0082] It is understood that this method applies to the BMC, which includes the JTAG controller and JTAG registers. This method can be executed by the processor within the BMC. Figure 3 As shown, the BMC's JTAG driver includes multiple general interfaces and multiple intermediate interfaces for providing services to applications. The general interfaces are configured to call the intermediate interfaces separately. The JTAG driver consists of a three-layer driver architecture built from a device interface layer, a device core layer, and a hardware shield layer. Specifically, the device interface layer unifies the northbound interface, the hardware shield layer unifies the southbound interface, and the device core layer handles the northbound and southbound call logic.

[0083] Based on similar Figure 1 The hardware architecture shown includes a BMC that internally comprises a JTAG controller and JTAG registers, and externally provides a JTAG interface. The JTAG module consists of the JTAG registers and the JTAG controller. The JTAG controller is a hardware management unit integrated within the BMC. According to the chip's operating manual, the BMC allocates dedicated storage space for the JTAG controller as the JTAG registers.

[0084] For example, device interfaces can be registered for JTAG modules in the kernel filesystem devfs / sysfs for application access. The general interface is obtained by registering a character device to the devfs filesystem or by registering sys device attributes to the sysfs filesystem. Here, the character device corresponds to the JTAG controller, and the sys device attributes correspond to the control logic of the JTAG controller.

[0085] Specifically, a character device is created in the ` / dev / jtag` directory to obtain the corresponding devfs interface (i.e., the general interface), and related device file operations such as `ioctl` are registered. Here, the character device is the JTAG module, corresponding to the JTAG controller. Alternatively, device read / write attributes are created in the ` / sys / class / jtag` directory to obtain the corresponding sysfs interface (i.e., the general interface), and related device operation attributes such as `show` and `store` are registered. Here, the sys device attributes correspond to the control logic of the JTAG controller. Applications can access the JTAG module using system call interfaces or by accessing the attribute file corresponding to ` / sys / class / jtag`.

[0086] like Figure 7 As shown, the interface call method includes steps 701-703, wherein:

[0087] Step 701: Based on the generic interface, receive an access request from the first application. The access request is for accessing the Joint Test Action Group JTAG register. The generic interface is used to provide interfaces for multiple applications, including the first application.

[0088] In this embodiment, the first application is an application in the user space of the BMC operating system, used to complete one or more specific system tasks (such as temperature acquisition, power monitoring, external JTAG device management, etc.). It runs in user mode and can interact with the user by providing a user interface or access commands. It is understood that the user space can include multiple applications, and the first application is one of them.

[0089] A generic interface is an interface obtained by registering a device in the file system of the BMC operating system. Here, "device" refers to any hardware component that can interact with the BMC. These hardware components can be functional modules integrated within the BMC, such as a JTAG module, or peripheral chips deployed outside the BMC, such as storage chips.

[0090] For example, because Linux defines system drivers as files, such as Figure 3 As shown, the JTAG module is registered in the devfs file system of the BMC operating system to obtain general interface 1, or registered in the sysfs file system to obtain general interface 2, so that it can be accessed by multiple applications. The first application uses the devfs file system to access general interface 1 or uses the sysfs file system to access general interface 2 to receive access requests initiated by users for the first application.

[0091] The devfs module is mounted under the / dev directory, and each file under / dev corresponds to a device that interacts with the BMC. The sysfs module is mounted under the / sys directory, and it organizes the devices and buses actually connected to the BMC into multiple hierarchical files for management. The JTAG module includes the JTAG controller and JTAG registers. The JTAG controller is dedicated hardware logic within the BMC, and the JTAG registers can be obtained by allocating independent storage space for the JTAG controller through the BMC. The JTAG driver enables the operating system to communicate with the hardware related to the JTAG interface (JTAG controller and JTAG registers, etc.). The JTAG interface is a JTAG-compliant interface provided by the BMC to the outside world.

[0092] Users can initiate access requests to the first application by clicking, swiping, or entering access commands provided by the first application in its user interface, or through its debug interface. Specifically, this access request is used to access the Joint Test Action Group (JTAG) registers. Since the JTAG module has registered with the BMC operating system's file system devfs / sysfs to obtain the corresponding general interface 1-2, it can receive user access requests for the first application based on this general interface 1-2.

[0093] For example, such as Figure 3 As shown, in the JTAG driver, the JTAG module is registered with the application layer's file system devfs or sysfs through the device interface layer, obtaining generic interface 1 (devfs interface) and generic interface 2 (sysfs interface). The generic interface accessed by the first application when receiving an access request can be determined based on the parameters of the access command entered by the user in the debugging interface of the first application. For example, if the command includes the parameter " / dev / jtag", the generic interface accessed is the devfs interface; if the command includes the parameter " / sys / class / jtag", the generic interface accessed is the sysfs interface.

[0094] Step 702: Based on the access request, invoke the intermediate interface. The intermediate interface is used to invoke the first operation instruction registered in the JTAG structure. The first operation instruction is generated based on the access address information of the JTAG register.

[0095] In this embodiment, the intermediate interface is located at Figure 3 The device core layer shown has an intermediate interface that is an interface function that includes a structure element of a JTAG structure.

[0096] In Linux systems, `file_operation` is a key data structure that associates system calls with drivers. For example... Figure 5As shown, the device core layer creates a `jtag` structure similar to `file_operations` to maintain function pointer members for all operations of the JTAG module. Within the JTAG structure, each of the multiple structure elements corresponds to a function pointer, and each structure element points to the function corresponding to one of the multiple operation instructions.

[0097] For example, such as Figure 5 As shown, the device kernel layer of the JTAG driver creates a jtag structure similar to file_operations, denoted as jtag_class_operations, to maintain function pointer members for all operations of the JTAG module. Each operation of the JTAG module is encapsulated into an intermediate interface, exposed to the device interface layer for invocation. Each intermediate interface calls a function pointer in the jtag_class_operations operation set. The device kernel layer provides an interface for the hardware shield layer to register and unregister JTAG modules, and the hardware shield layer populates the function pointer members in jtag_class_operations.

[0098] Furthermore, within the device core layer, the `jtag_class_operations` structure maintains the complete set of operation commands for the JTAG module. This set includes read / write operations to the device and other command functions. Multiple intermediate interfaces 1-n are generated based on the `jtag_class_operations` structure, allowing multiple applications (including the first application) to invoke these interfaces based on user access requests.

[0099] For example, the JTAG structure is located in Figure 3 The device core layer shown is a pointer to a structure similar to `file_operations`, denoted as `jtag_class_operations`, created for the JTAG module. The `jtag_class_operations` structure maintains the complete set of operation instructions for the JTAG module, including read / write operations and other command functions.

[0100] On one hand, multiple intermediate interfaces are generated based on the jtag_class_operations structure for use by the general interfaces of the device interface layer. Each of the multiple intermediate interfaces contains a structure member of the jtag_class_operations structure, meaning that each intermediate interface corresponds to an operation instruction in the operation instruction set.

[0101] On the other hand, the jtag_class_operations structure provides an interface for registering and unregistering JTAG modules to the hardware shield, and sets callback functions for the hardware shield to populate the function pointer members in jtag_class_operations.

[0102] like Figure 3 As shown, the device core layer includes multiple intermediate interfaces. The intermediate interface called by the first application can be determined based on the format of the access command initiating the user's access request. For example, when the general interface is the devfs interface, if the access command format is ioctl(), then the intermediate interface is the one among the multiple intermediate interfaces that calls the first operation command drv_ioctl. It can be understood that the first operation command is one of all operation commands in the JTAG module's set. An operation command is a function that implements access operations on JTAG registers through the JTAG controller. Access operations include reading / writing JTAG registers and other command functions.

[0103] In Linux systems, `file_operation` is a key data structure that associates system calls with drivers. Each member of this structure corresponds to a system call. For example... Figure 3 As shown, a jtag structure of type file_operations, denoted as jtag_class_operations, is created in the device core layer to maintain function pointer members for all operations of the JTAG module.

[0104] The first operation instruction, `drv_ioctl`, is registered in the `jtag_class_operations` structure pointer. For example, registration can be achieved by setting the first function pointer corresponding to the first element of the JTAG structure to point to the function corresponding to the first operation instruction. Alternatively, other data structures, such as the linked list `jtag_class_operations`, can be used to register the first operation instruction; this is not limited to this method.

[0105] Optionally, additional operation code related to the access operation request can be written for each intermediate interface. The corresponding additional operation code and the operation instruction corresponding to each intermediate interface can be encapsulated to obtain each intermediate interface. For example, in addition to implementing the operation instruction function corresponding to an intermediate interface, additional operation code can be written to record the number of times that intermediate interface is called by the general interface related to the access operation request in the device interface layer, thereby implementing additional statistical functions.

[0106] Therefore, by calling the intermediate interface, in addition to executing the first operation instruction, related additional functions can be flexibly implemented according to the requirements of the access request.

[0107] Accordingly, before responding to user interactions via the user interface, it is necessary to first obtain the access address information of the JTAG registers based on the BMC's device management mode. Multiple operation instructions are generated based on the access address information, each corresponding to a different access operation of the JTAG registers by the JTAG controller. The first operation instruction is understood to be one of these multiple operation instructions. These multiple operation instructions are then registered to the JTAG structure.

[0108] For example, to manage information about external devices (such as JTAG modules), BMC can use simple descriptions to describe devices in the platform_device section of its device management platform. For instance, a platform_device structure can be used to specify device resources. Another example is using a device tree source (DTS) to describe device information.

[0109] In one implementation, the access address information of the JTAG registers (e.g., reg = <0x800000000x40000000>) can be stored in the device tree source file jtag.dts / dtsi. These device tree source files, like C code, cannot be used directly. The dts / dtsi files need to be compiled using the dtc tool to generate a machine-executable dtb binary file, which is the file that the kernel can use. For example, when the MainBoard is running, the device tree file used by the system exists in the / boot directory for the JTAG driver to call.

[0110] As can be understood, a device tree is a data storage method with a tree-like storage structure. In a typical device tree source code, there are root node attributes and information of multiple child nodes. The device tree is responsible for managing the specific information of all devices in the BMC, and the information related to the JTAG register is one of the multiple child nodes.

[0111] Analysis reveals that the system's device tree information is used to separate JTAG driver code from device information. In the device management mode using the device tree in the BMC, the JTAG driver code is only responsible for handling the JTAG driver logic, while specific information about the JTAG module is stored in the device tree file jtag.dts / dtsi. Thus, if only the hardware interface information changes without any change in driver logic, driver developers only need to modify the jtag.dts / dtsi device tree file information, without needing to rewrite the JTAG driver code, thereby achieving a unified southbound interface.

[0112] For example, the operation instruction corresponds to the JTAG controller's access operation to the JTAG register, located in Figure 3 The diagram shows the hardware shielding layer of the three-layer JTAG driver architecture. Based on the control logic of the JTAG controller, multiple target operations are determined. Based on the acquired JTAG register access address information, each of the multiple target operations is set as an operation instruction of the JTAG controller on the JTAG register, thus obtaining multiple operation instructions.

[0113] Specifically, based on the control logic of the JTAG controller and after determining the multiple target operations supported by the JTAG controller, the JTAG controller's operation function on the JTAG registers is implemented based on the JTAG register access address information and the corresponding implementation code of the target operations, thus obtaining the operation instructions corresponding to the target operations. Based on each operation instruction corresponding to each target operation among the multiple target operations, the following is obtained: Figure 3 The multiple operation instructions 1-n are shown.

[0114] It's understandable that the control logic functions of the JTAG controllers included in the BMC are not entirely the same before and after switching to different manufacturers / versions of BMC. For example, before different JTAG controllers can read or write to the corresponding JTAG registers, some require enabling the target address unit of the JTAG register, while others do not have this enabling capability.

[0115] Before and after changing to a different manufacturer / version of BMC, the address units of the JTAG registers allocated by the BMC to its included JTAG controllers are also different.

[0116] Therefore, the multiple operation instructions for accessing JTAG registers by the JTAG controller will inevitably differ before and after changing to different manufacturers / versions of BMC. Based on this... Figure 3 The unified southbound interface in the three-layer JTAG driver architecture shown can retain or add corresponding target operations based on the JTAG controller, and modify the operation code and operation address information in the corresponding operation instruction of the target operation, thereby reducing the maintenance cost of JTAG driver for BMC users.

[0117] Step 703: Based on the first operation instruction, access the JTAG register through the JTAG controller to respond to the access request.

[0118] In this embodiment, the intermediate interface is determined based on the format of the access instruction in the user's access request for the first application. Therefore, the intermediate interface calls the first operation instruction corresponding to the access instruction. The first operation instruction is one of the operation instructions in the set of all operation instructions of the JTAG module. The operation instruction is a function that implements access operations on the JTAG register through the JTAG controller. The access operations include reading / writing the JTAG register and other command functions.

[0119] By executing the first operation instruction registered to the JTAG structure, the JTAG controller can perform a first access operation on the JTAG register corresponding to the first operation instruction. For example, if the first operation instruction is drv_ioctl, then the first access operation performed by the JTAG controller on the JTAG register is ioctl.

[0120] Thus, the JTAG controller performs a first access operation on the JTAG register and transmits the result of the first access operation to the JTAG interface. Figure 1 The external JTAG device shown in the BMC enables the management or testing of the JTAG device.

[0121] Therefore, this application first receives an access request from a first application to access the Joint Test Action Group's JTAG registers based on a general interface, and then calls an intermediate interface to invoke a first operation instruction registered in the JTAG structure. Based on the first operation instruction, the JTAG controller performs an access operation on the JTAG registers, thus responding to the access request. Therefore, when the JTAG controller or JTAG registers change, only the first operation instruction needs to be refactored while maintaining the original general and intermediate interfaces to respond to access requests, thereby improving system development efficiency and reducing system maintenance costs.

[0122] It is understandable that the process of writing, compiling, and loading JTAG driver code needs to be completed before the JTAG driver can be executed.

[0123] For example, in Linux, based on Figure 3 The JTAG driver writing process, as shown, generally includes: 1. Creating a pointer to a structure similar to `file_operations` for the JTAG module, denoted as `jtag_class_operations`; 2. Setting corresponding operation instructions for the function pointer members in `jtag_class_operations`, where the operation instructions are determined based on the device's control logic and the access address information specified by the BMC; 3. Registering the JTAG module through the interface provided by the device core layer to the hardware shield layer (this interface is also used to perform a deregistration operation after the JTAG module has finished using it); 4. Registering the JTAG module at the device interface layer for access by the application layer via the devfs or sysfs interface to provide it to the application.

[0124] The BMC includes at least the U-Boot program that implements kernel functions, application programs that implement user functions, and driver functions that implement low-level hardware drivers. Different toolchains can be used to compile different programs sequentially; for example, compile the kernel U-Boot program first, then compile the device drivers that depend on the kernel, and finally compile the application programs.

[0125] JTAG driver loading includes at least two methods: static loading and dynamic loading. Static loading involves compiling the driver directly into the kernel, allowing it to be used immediately after system startup. The disadvantage of static loading is that debugging is cumbersome; every modification requires recompiling and downloading the kernel, resulting in lower efficiency. Dynamic loading allows the driver to be loaded using the `insmod` command after system startup and unloaded using the `rmmod` command when no longer needed. Dynamic loading is generally used on desktop computers. In embedded products, dynamic loading can be used for initial debugging, followed by compilation into the kernel after debugging is complete.

[0126] Figure 8 The diagram shows a JTAG driver call provided in an embodiment of this application.

[0127] like Figure 8 As shown, the first application resides in user space and is one of the applications executed by the user based on the BMC. The BMC receives data (e.g., firmware upgrade packages) that needs to be transmitted via the JTAG interface and stores it in the form of a data structure `data`. The data structure `data` can be an array, pointer, or linked list, etc. When the instruction `ioctl(" / dev / jtag", tansfer, data)` is executed within the first application, the first application transmits the data in the data structure `data` from the JTAG interface to the specified data according to the method set by the function `tansfer`. Figure 1The diagram shows the external JTAG device of the BMC. Specifically, the JTAG driver of the JTAG module is called according to the device file name "jtag" carried in the ioctl instruction. The device file name has a major device number and a minor device number (for example, the major device number is "jtag"). The ioctl instruction triggers a system call (systemcalI) through the kernel's software interrupt function (for example, interrupt number 0x80). The system call penetrates the Virtual File System (VFC) and finds the corresponding driver in the kernel's driver list through the virtual file device number, that is, it finds the JTAG driver (the 4th driver) in the kernel space through the devfs general interface. Then, the devfs general interface is used to call the corresponding intermediate interface in the driver program, and the first operation instruction "drv_ioctl()" is called through the intermediate interface to perform the ioctl operation of the JTAG controller on the JTAG register. That is, according to the method set by the tansfer function, the data in the data structure "data" is serially read into the JTAG register for transmission through the JTAG interface.

[0128] During the execution of the JTAG driver, the first operation instruction drv_ioctl() function is pre-registered into the JTAG driver's structure pointer jtag_class_operations, the jtag_class_operations structure is pre-added to the kernel's driver list, and the first general interface corresponding to the JTAG module is pre-registered into the file system devfs.

[0129] It is not difficult to see that the JTAG driver only provides other parts of the BMC with the ability to use JTAG modules, and the method of using JTAG modules is determined by the first application.

[0130] Based on the methods in the above embodiments, this application provides an interface invocation device. Please refer to... Figure 9 , Figure 9 This is a diagram of an interface calling device provided in an embodiment of this application. For example... Figure 9 As shown, device 900 may include:

[0131] The receiving module 910 is used to receive access requests from the first application based on a generic interface. The access request is for accessing the Joint Test Action Group JTAG register. The generic interface provides an interface for multiple applications, including the first application.

[0132] Module 920 is invoked to call an intermediate interface based on an access request. This intermediate interface then invokes the first operation instruction registered in the JTAG structure. The first operation instruction is generated based on the access address information in the JTAG register.

[0133] The processing module 930 is used to perform access operations on the JTAG register through the JTAG controller based on the first operation instruction in response to the access request.

[0134] It should be understood that the above-described device is used to execute the methods in the above embodiments. The implementation principle and technical effect of the corresponding program modules in the device are similar to those described in the above methods. The working process of the device can be referred to the corresponding process in the above methods, and will not be repeated here.

[0135] Based on the methods described in the above embodiments, this application provides a chip. Please refer to... Figure 10 , Figure 10 This is a schematic diagram of a chip structure provided in an embodiment of this application. Figure 10 As shown, chip 1000 includes: at least one memory 1001 for storing a program; at least one processor 1002 for executing the program stored in the memory; chip 1000 also includes: a JTAG controller 1003 and a JTAG register 1004; processor 1002 is used to control JTAG controller 1003 to access JTAG register 1004; wherein, when the program stored in memory 1001 is executed, processor 1002 is used to execute the method in the above embodiment.

[0136] Optionally, chip 1000 may also include a bus 1005 and a communication interface 1006. The memory 1001, processor 1002, JTAG controller 1003, and JTAG register 1004 communicate via bus 1005. Chip 1000 can be deployed on a server or terminal device. It should be understood that the embodiments of this application do not limit the number of processors and memories in chip 1000.

[0137] The memory 1001 may include volatile memory, such as random access memory (RAM). It may also include non-volatile memory, such as read-only memory (ROM), flash memory, hard disk drive (HDD), or solid state drive (SSD).

[0138] The processor 1002 may include any one or more processors such as a central processing unit (CPU), a graphics processing unit (GPU), a microprocessor (MP), or a digital signal processor (DSP).

[0139] JTAG controller 1003 can be used to send or receive data, instructions or information. Processor 1002 can use the data, instructions or other information received by JTAG controller 1003 to process the data, instructions or other information, and can send the processed information out through JTAG controller 1003.

[0140] JTAG register 1004 is used to store data, instructions, or other information sent or received by JTAG controller 1003.

[0141] Bus 1005 can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be divided into address buses, data buses, control buses, etc. For ease of representation, Figure 10 The bus 1005 may be represented by a single line, but this does not mean that there is only one bus or one type of bus. The bus 1005 may include a path for transmitting information between various components of the chip 1000 (e.g., memory 1001, processor 1002, JTAG controller 1003, JTAG register 1004).

[0142] The communication interface 1006 uses transceiver modules such as, but not limited to, network interface cards and transceivers to enable communication between the chip 1000 and other devices or communication networks.

[0143] Based on the methods in the above embodiments, this application provides a computing device. The computing device may include: at least one memory for storing a program; and at least one processor for executing the program stored in the memory; wherein, when the program stored in the memory is executed, the processor executes the methods in the above embodiments.

[0144] Based on the methods in the above embodiments, this application provides a computer-readable storage medium storing a computer program that, when run on a processor, causes the processor to execute the methods in the above embodiments.

[0145] Based on the methods in the above embodiments, this application provides a computer program product, characterized in that, when the computer program product is run on a processor, the processor executes the methods in the above embodiments.

[0146] It should be understood that each step of the above method embodiments can be completed by hardware logic circuits or software instructions in a processor.

[0147] It is understood that the sequence number of each step in the above embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application. In addition, in some possible implementations, each step in the above embodiments may be selectively executed according to the actual situation, and may be partially or fully executed, which is not limited here.

[0148] It is understood that the processor in the embodiments of this application can be a central processing unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, transistor logic devices, hardware components, or any combination thereof. A general-purpose processor can be a microprocessor or any conventional processor.

[0149] The method steps in the embodiments of this application can be implemented in hardware or by a processor executing software instructions. The software instructions can consist of corresponding software modules, which can be stored in random access memory (RAM), flash memory, read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), registers, hard disks, portable hard disks, CD-ROMs, or any other form of storage medium known in the art. An exemplary storage medium is coupled to the processor, enabling the processor to read information from and write information to the storage medium. Of course, the storage medium can also be a component of the processor. The processor and the storage medium can reside in an AS1C.

[0150] In the above embodiments, implementation can be achieved entirely or partially through software, hardware, firmware, or any combination thereof. When implemented using software, it can be implemented entirely or partially in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted through the computer-readable storage medium. The computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that integrates one or more available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., solid-state disk (SSD)).

[0151] It is understood that the various numerical designations used in the embodiments of this application are merely for descriptive convenience and are not intended to limit the scope of the embodiments of this application.

Claims

1. An interface invocation method, characterized in that, The method is applied to a BMC chip, which includes a JTAG controller and a JTAG register; the BMC chip is connected to a JTAG device to manage or test the JTAG device; the method includes: Obtain the access address information of the JTAG register; Multiple operation instructions are generated based on the access address information; the multiple operation instructions correspond to multiple access operations of the JTAG controller to the JTAG register, and the first operation instruction is one of the multiple operation instructions. Register the various operation instructions to a JTAG structure respectively; Based on a general interface, an access request from a first application is received; the access request is used to access the JTAG register; the general interface is used to provide interfaces for multiple applications, including the first application. Based on the access request, an intermediate interface is invoked, which is used to invoke a first operation instruction registered in the JTAG structure; the first operation instruction is generated based on the access address information of the JTAG register. Based on the first operation instruction, the JTAG register is accessed through the JTAG controller in response to the access request; the first operation instruction is a function that implements the access operation of the JTAG register through the JTAG controller; the intermediate interface is encapsulated based on additional operation code and the operation instruction corresponding to the intermediate interface, and the additional operation code is code related to the access operation request written for the intermediate interface.

2. The method according to claim 1, characterized in that, The generation of multiple operation instructions based on the access address information includes: Based on the control logic of the JTAG controller, multiple target operations are determined; Based on the access address information, each of the plurality of target operations is set as an operation instruction of the JTAG controller on the JTAG register to obtain the plurality of operation instructions.

3. The method according to claim 1, characterized in that, The step of obtaining the access address information of the JTAG register includes obtaining the access address information of the JTAG register based on the system's device tree information.

4. The method according to any one of claims 1-3, characterized in that, The registration to the JTAG structure includes: Set the first function pointer corresponding to the first structure element of the JTAG structure to point to the function corresponding to the first operation instruction.

5. The method according to any one of claims 1-4, characterized in that, The intermediate interface also invokes additional operation instructions related to the access request.

6. The method according to any one of claims 1-5, characterized in that, The first application uses the devfs file system or sysfs file system to call the general interface.

7. The method according to claim 6, characterized in that, The general interface is the interface obtained by registering a character device to the devfs file system or registering the sys device attributes to the sysfs file system; The character device corresponds to the JTAG controller, and the sys device attribute corresponds to the control logic of the JTAG controller.

8. A chip, characterized in that, include: At least one memory for storing programs; At least one processor is provided for executing a program stored in the memory; the chip also includes a JTAG controller and a JTAG register. The processor is used to control the JTAG controller to access the JTAG registers; When the program stored in the memory is executed, the processor is used to perform the method as described in any one of claims 1-7.

9. A computing device, characterized in that, include: At least one memory for storing programs; At least one processor for executing the program stored in the memory; When the program stored in the memory is executed, the processor is used to perform the method as described in any one of claims 1-7.

Images