A calling method, system, chip and server of a hardware device

Abstract

The application provides a calling method, system, chip and server of a hardware device. The method is applied to a calling system, and the calling system comprises an application layer, a hardware abstraction layer and a driver layer in sequence. The method comprises the following steps: sending a service operation to the hardware abstraction layer based on the application layer; matching a corresponding hardware operation according to the service operation based on the hardware abstraction layer, and sending the hardware operation to the driver layer; and controlling the hardware device according to the hardware operation based on the driver layer. The hardware abstraction layer between the application layer and the driver layer decouples the application software and the I2C driver. The hardware abstraction layer completes the corresponding processing of the service operation and the hardware operation, so that the application software only pays attention to the service operation, the I2C driver only pays attention to the hardware operation, the influence of the service operation on the I2C driver is shielded, and the applicability of the I2C driver is improved. Without developing the corresponding I2C driver for different application software, the technical personnel do not need to understand the I2C driver architecture, and the development difficulty and development cost are reduced.

Description

Technical Field

[0001] This application relates to the field of server technology, and in particular to a method for invoking a hardware device, a system, a chip, and a server. Background Technology

[0002] Currently, the variety of application software for server Baseboard Management Controllers (BMCs) is becoming increasingly diverse. BMC application software is an application program or operating system that runs on the server or management host. The BMC application software communicates with hardware devices connected to the I2C bus through the corresponding Inter-Integrated Circuit (I2C) bus to realize hardware operations.

[0003] Some BMC application software has strong coupling between hardware operations and business operations. When the BMC application software needs to control the underlying hardware device, it sends both business operations and hardware operations to the corresponding I2C driver. The I2C driver then controls the underlying hardware device based on the business operations and hardware operations.

[0004] In related technologies, I2C drivers need to handle not only hardware operations but also business operations. However, the business operations of different BMC application software vary significantly. Using only one I2C driver cannot handle the business operations of different BMC application software, causing some BMC application software to malfunction. Therefore, it is necessary to design corresponding I2C drivers for various different BMC application software, resulting in high development costs. Furthermore, technical personnel not only need to understand the relevant knowledge of the application software but also the relevant content of the I2C driver architecture, leading to a high overall development difficulty. Summary of the Invention

[0005] In view of this, embodiments of this application provide a method, system, chip, and server for invoking hardware devices, aiming to solve the problems of high difficulty and high cost in developing BMC application software.

[0006] In a first aspect, embodiments of this application provide a method for invoking a hardware device, applied to a calling system, the system sequentially comprising an application layer, a hardware abstraction layer, and a driver layer, the method comprising:

[0007] The application layer sends service operations to the hardware abstraction layer.

[0008] Based on the hardware abstraction layer, the corresponding hardware operation is matched according to the business operation, and the hardware operation is sent to the driver layer;

[0009] Based on the driver layer, the hardware device is controlled according to the hardware operation to execute the business operation.

[0010] In this embodiment, a hardware abstraction layer between the application layer and the driver layer decouples the application software from the I2C driver. The hardware abstraction layer handles the mapping between business operations and hardware operations, allowing the application software to focus solely on business operations and the I2C driver to focus solely on hardware operations. This shields the I2C driver from the impact of business operations, improving its applicability. There is no need to develop corresponding I2C drivers for different application software, and technical personnel do not need to understand the I2C driver architecture, reducing development difficulty and costs.

[0011] In one possible implementation, the matching of corresponding hardware operations based on the business operations according to the hardware abstraction layer includes:

[0012] Based on the hardware abstraction layer, the service operation is matched with the corresponding hardware operation according to the configuration information, and the configuration information includes the hardware operation corresponding to the service operation.

[0013] In this embodiment, configuration information is used to store the correspondence between business operations and hardware operations, as well as each hardware operation. Based on the configuration information, the corresponding hardware operation can be matched to the business operation, decoupling the business operations from the hardware operations while preserving their correspondence, thus achieving isolation between the application layer and the driver layer. When new hardware devices need to be added, the system can be expanded more easily. Only a new driver layer and an adapted hardware abstraction layer need to be developed, without modifying existing system code.

[0014] In one possible implementation, sending the hardware operation to the driver layer includes:

[0015] The hardware operation is translated into a general message based on the hardware abstraction layer, and the general message is sent to the driver layer. The general message is used to describe the hardware operation.

[0016] In this embodiment, by abstracting specific hardware operations into a generic message format, application software in the application layer can operate hardware devices more simply and conveniently. This not only improves development efficiency but also reduces the application software's dependence on hardware devices, thereby enhancing the application software's portability.

[0017] In one possible implementation, sending the general message to the driver layer includes:

[0018] The hardware abstraction layer calls the general interface provided by the driver layer to send the general message to the driver layer.

[0019] In this embodiment, a universal interface is used as a unified interface, making it easier for application software to match different types of hardware devices. The application software can be ported and run in different hardware environments without requiring extensive modifications. By using a hardware abstraction layer and a universal interface, the complexity of direct hardware interaction can be avoided during application software development and maintenance. Developers do not need to delve into the details of each hardware device, reducing development and maintenance costs caused by hardware differences.

[0020] In one possible implementation, the method further includes:

[0021] The driver layer obtains the operation result of sending the control command to the hardware device and feeds back the operation result to the hardware abstraction layer.

[0022] In this embodiment of the application, the driver layer can obtain the operation results obtained by the hardware device executing control instructions, and the hardware abstraction layer feeds back the operation results to the application layer so as to show the user the hardware device call results.

[0023] In one possible implementation, the configuration information further includes processing conditions corresponding to the business operation; the method further includes:

[0024] Based on the hardware abstraction layer, the operation result is processed according to the processing conditions corresponding to the business operation, and the processed operation result is returned to the application layer.

[0025] In this embodiment, the hardware abstraction layer can process the operation results using the processing conditions corresponding to the business operations stored in the configuration file. Different business operations have different processing conditions, and the operation results are obtained through hardware device control. By storing the processing conditions corresponding to the business operations in the configuration file, the processing conditions used to process the operation results are decoupled from the business operations, but the correspondence is retained. The configuration file can determine the processing conditions corresponding to the business operations, decoupling the application layer and the driver layer, and improving the portability of the application software.

[0026] In one possible implementation, the step of controlling the hardware device based on the hardware operation according to the driver layer includes:

[0027] The driver layer receives the general message and controls the hardware device based on the general message.

[0028] Secondly, embodiments of this application provide a hardware device invocation system, the system comprising an application layer, a hardware abstraction layer, and a driver layer in sequence;

[0029] The application layer is used to send business operations to the hardware abstraction layer according to the application services provided by the application layer.

[0030] The hardware abstraction layer is used to match the corresponding hardware operation according to the business operation and send the hardware operation to the driver layer.

[0031] The driver layer is used to control the hardware device according to the hardware operation to execute the business operation.

[0032] In one possible implementation, the hardware abstraction layer matches corresponding hardware operations based on the business operations, including:

[0033] The hardware abstraction layer matches the corresponding hardware operation for the service operation based on the configuration information, wherein the configuration information includes the hardware operation corresponding to the service operation.

[0034] In one possible implementation, the hardware abstraction layer sends the hardware operation to the driver layer, including:

[0035] The hardware abstraction layer translates the hardware operations into a general message and sends the general message to the driver layer. The general message describes the hardware operations.

[0036] In one possible implementation, the hardware abstraction layer sends the general message to the driver layer, including:

[0037] The hardware abstraction layer sends the general message to the driver layer by calling the general interface provided by the driver layer.

[0038] In one possible implementation, the driver layer is further configured to obtain the operation result obtained by sending the control command to the hardware device, and to feed back the operation result to the hardware abstraction layer.

[0039] In one possible implementation, the configuration information also includes the processing conditions corresponding to the business operation;

[0040] The hardware abstraction layer is also used to process the operation result according to the processing conditions corresponding to the business operation, and return the processed operation result to the application layer.

[0041] In one possible implementation, the driver layer controls the hardware device according to the hardware operation, including:

[0042] The driver layer receives the general message and controls the hardware device according to the general message.

[0043] Thirdly, embodiments of this application provide a hardware device invocation apparatus, applied to an invocation system, the apparatus comprising:

[0044] The sending module is used to send service operations to the hardware abstraction layer based on the application layer;

[0045] The matching module is used to match the corresponding hardware operation based on the business operation according to the hardware abstraction layer, and send the hardware operation to the driver layer;

[0046] The control module is used to control the hardware device based on the hardware operation according to the driver layer, so as to execute the business operation.

[0047] In one possible implementation, the matching module is specifically used to match the hardware operation corresponding to the service operation based on the hardware abstraction layer and configuration information, wherein the configuration information includes the hardware operation corresponding to the service operation.

[0048] In one possible implementation, the matching module is specifically used to perform message translation on the hardware operation based on the hardware abstraction layer to obtain a general message, and send the general message to the driver layer, wherein the general message is used to describe the hardware operation.

[0049] In one possible implementation, the matching module is specifically used to call the general interface provided by the driver layer based on the hardware abstraction layer, and send the general message to the driver layer.

[0050] In one possible implementation, the control module is further configured to obtain the operation result obtained by sending the control command to the hardware device based on the driver layer, and to feed back the operation result to the hardware abstraction layer.

[0051] In one possible implementation, the configuration information also includes the processing conditions corresponding to the business operation;

[0052] The matching module is also used to process the operation result based on the processing conditions corresponding to the business operation according to the hardware abstraction layer, and return the processed operation result to the application layer.

[0053] In one possible implementation, the control module is specifically used to receive the general message based on the driver layer and control the hardware device according to the general message.

[0054] Fourthly, embodiments of this application provide a BMC chip, which is used to implement the method of calling a hardware device as described in any embodiment of the first aspect.

[0055] Fifthly, embodiments of this application provide a server, a processor, and a memory communicatively connected to the processor; the memory is used to store computer execution instructions; the processor is used to execute the computer execution instructions stored in the memory to implement the method of invoking a hardware device as described in any one of the first aspects.

[0056] In a sixth aspect, embodiments of this application provide an apparatus comprising a memory and a processor, the memory for storing instructions or code, and the processor for executing the instructions or code to cause the apparatus to perform the hardware device invocation method described in any one of the first and second aspects.

[0057] In a seventh aspect, embodiments of this application provide a computer storage medium storing code, wherein when the code is executed, a device executing the code implements the hardware device invocation method described in any of the first aspects above. Attached Figure Description

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

[0059] Figure 1 This is an architecture diagram of a hardware device's calling system in the prior art.

[0060] Figure 2 This application provides a schematic diagram of the architecture of a hardware device invocation system.

[0061] Figure 3 An architecture diagram of a BMC chip provided for an embodiment of this application;

[0062] Figure 4 This application provides an architectural diagram of another hardware device invocation system.

[0063] Figure 5 An architectural diagram of another BMC chip provided in an embodiment of this application;

[0064] Figure 6 A timing diagram of a hardware device invocation method provided in an embodiment of this application;

[0065] Figure 7 A schematic diagram of a data structure provided in an embodiment of this application;

[0066] Figure 8A schematic diagram illustrating the connection between a hardware abstraction layer and a general-purpose I2C driver, provided in an embodiment of this application;

[0067] Figure 9 This application provides a schematic diagram illustrating the operation of a general I2C driver.

[0068] Figure 10 This is a flowchart illustrating a method for invoking a hardware device, as provided in an embodiment of this application. Detailed Implementation

[0069] It should be noted that the embodiments described in this application are only some embodiments of this application, and not all embodiments. Based on the embodiments in this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0070] To make the following embodiments clear, the technical terms involved in this application will be introduced first.

[0071] A Baseboard Management Controller (BMC) is a hardware module embedded in a server or network device. A BMC system refers to the hardware management controller embedded on the motherboard of a server, network device, or other embedded system, responsible for hardware monitoring and management functions. It typically consists of a BMC chip (such as ASPEED, BMC solutions, etc.) and related firmware, and has its own independent processor and memory. By isolating itself from the host processor and operating system, the BMC system provides remote monitoring, configuration, control, and management functions, allowing administrators to perform management operations without direct access to the device.

[0072] BMC application software is an application or operating system that runs on a server or management host to implement the various functions of the BMC system. BMC application software can be commercial software or an open-source solution. It can provide a graphical user interface (GUI) and a command-line interface (CLI), allowing technicians to use the BMC system's functions to manage, monitor, configure, and troubleshoot hardware devices.

[0073] The Inter-Integrated Circuit (I2C) driver is responsible for controlling and managing various external devices connected to the I2C bus. The I2C driver handles data transmission and reception, acting as an intermediary when reading and setting device register values. When the application layer needs to perform hardware operations, it invokes the corresponding I2C driver through relevant instructions to execute the corresponding I2C communication. The I2C driver is responsible for handling the underlying I2C transmission protocol, including sending and receiving data, and controlling bus timing. Through the I2C driver, the application layer can send read and write commands to the underlying hardware devices to obtain device status or configure device parameters.

[0074] Business operations typically refer to operations related to specific business needs or functions. They are designed for specific application scenarios or business objectives. Examples include configuring network parameters, starting or stopping services, and managing user permissions. Different BMC application software may offer different business operations.

[0075] Hardware operations refer to the control and manipulation of low-level hardware devices. These operations involve direct interaction with the physical hardware, such as reading and writing hardware registers, controlling the power state of hardware devices, and adjusting hardware parameters. Hardware operations can be implemented through communication between the hardware device and its driver (such as an I2C driver).

[0076] For some BMC application software, business operations and hardware operations are tightly coupled. When technicians implement a certain function through the BMC application software, the BMC application software sends the corresponding business operations and hardware operations to the corresponding I2C driver, which then controls the hardware device to implement the corresponding function.

[0077] like Figure 1 As shown, Figure 1 This is an architecture diagram of a hardware device calling system in the prior art. Figure 1 In this diagram, I2C driver 1 is the I2C driver corresponding to BMC application software 1, and I2C driver 2 is the I2C driver corresponding to BMC application software 2. BMC application software 1 cannot control hardware devices connected to the I2C bus through I2C driver 2, and BMC application software 2 cannot control hardware devices connected to the I2C bus through I2C driver 1.

[0078] Significant differences exist between the I2C drivers used by different BMC application software programs. A BMC application software cannot control hardware devices using the I2C drivers of other BMC application software. Therefore, engineers need to design a corresponding I2C driver for each BMC application software during development. Otherwise, the incompatible I2C driver will prevent the BMC application software from accurately sending commands to the underlying hardware devices, ultimately causing the application software to malfunction and fail to provide its intended functionality.

[0079] To address the aforementioned technical problems, embodiments of this application provide a method, system, chip, and server for invoking a hardware device. By adding a hardware abstraction layer between the application software and the I2C driver, the application software and the I2C driver are decoupled. The hardware abstraction layer handles the mapping between business operations and hardware operations, allowing the application software to focus solely on business operations and the I2C driver to focus solely on hardware operations. This shields the I2C driver from the impact of business operations, improving its applicability. Furthermore, it eliminates the need to develop corresponding I2C drivers for different application software, reducing development difficulty and costs.

[0080] The technical solutions in the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. See also: Figure 2 , Figure 2 This is a schematic diagram of the architecture of a hardware device calling system provided in an embodiment of this application.

[0081] Figure 2 In the call system shown, a hardware abstraction layer is added below the application layer where BMC application software 1 and BMC application software 2 are located. The hardware abstraction layer stores various hardware operations and the correspondence between hardware operations and business operations in the form of configuration information.

[0082] The application layer includes multiple BMC application software, which provide application services for various BMC systems and issue business operations, such as monitoring hardware status, configuring system settings, and remote control.

[0083] The Hardware Abstraction Layer (HAL) is a software layer located between the application layer and the driver. Its role is to encapsulate the low-level hardware operations and details, providing a simple and unified interface for the application layer to use. This allows BMC application software to avoid needing to concern itself with I2C drivers and hardware operations.

[0084] The Hardware Abstraction Layer (HAL) matches corresponding hardware operations to business operations, enabling BMC application software to adapt more flexibly to different hardware platforms. When BMC application software needs to be migrated to other hardware platforms, only the configuration information in the HAL needs to be modified, without modifying the BMC application software itself. This reduces development and maintenance complexity and improves the portability and maintainability of the application software.

[0085] The driver layer includes general-purpose drivers, such as general-purpose I2C drivers. The driver layer receives hardware operations from the hardware abstraction layer and then controls the hardware to perform corresponding actions based on these hardware operations.

[0086] In one possible implementation, BMC application software 1 and BMC application software 2 only need to issue business operations. The hardware abstraction layer matches the corresponding hardware operation based on the business operation and sends the hardware operation to the general I2C driver in the form of a general message. The relevant content of the business operation is stored in the hardware abstraction layer. After receiving the general message through the general interface, the general I2C driver only controls the corresponding hardware device to perform actions based on the hardware operation, without needing to pay attention to the business operation.

[0087] By invoking the hardware abstraction layer and driver layer in the system, business operations can be decoupled from hardware operations, and a connection can be established between them. BMC application software only needs to issue business operations without needing to concern itself with specific hardware operations. The hardware abstraction layer can match corresponding hardware operations to different business operations using predefined mapping rules or configuration information, and send the hardware operations to the general I2C driver in the driver layer in the form of a generic message.

[0088] By having the Hardware Abstraction Layer (HAL) handle both business and hardware operations, BMC application software can be decoupled from the I2C driver. BMC application software only needs to interact with the HAL, eliminating the need to adapt specific I2C drivers for different BMC application software.

[0089] Similarly, by using a single, universal I2C driver, hardware devices can be operated uniformly without the need to adapt different I2C drivers for different business operations. The universal I2C driver only needs to process the received hardware operations and transmit them to the hardware devices for control via the I2C bus.

[0090] The calling system provided in this application embodiment enables different BMC application software to share a common I2C driver and control hardware devices, and achieves the connection between business operations and hardware operations through a hardware abstraction layer. Furthermore, when developing extended BMC application software, there is no need to design corresponding I2C drivers simultaneously; the mapping relationship between business operations and hardware operations can be added in the hardware abstraction layer. This provides greater flexibility and scalability, and reduces the development difficulty of BMC application software.

[0091] based on Figure 2 This application also provides an architecture diagram of a BMC chip, such as... Figure 3 As shown. BMC application software 1 and BMC application software 2 are installed in the BMC chip. Normally, two BMC application software programs do not coexist in a BMC chip. To more clearly highlight the technical effects achievable by the embodiments of this application, in... Figure 3 The BMC chip shown displays both BMC application software 1 and BMC application software 2.

[0092] A hardware abstraction layer is set up under BMC application software 1 and BMC application software 2. When a technician triggers a business function through BMC application software 1 (or BMC application software 2), BMC application software 1 (or BMC application software 2) sends the business operation to the hardware abstraction layer. The hardware abstraction layer matches the corresponding hardware operation to the business operation using pre-set configuration information, and converts the hardware operation into a general message that can be adapted by a general I2C driver.

[0093] The Hardware Abstraction Layer (HAL) connects to the I2C driver, which is a generic I2C driver. After receiving the generic messages converted by the HAL, the generic I2C driver sends control commands to the I2C bus through the I2C controller based on the generic messages, thereby controlling the hardware devices connected to the I2C bus.

[0094] BMC application software 1 and BMC application software 2 only need to issue business operations, and the hardware abstraction layer matches the corresponding hardware operations based on the business operations, so that BMC application software 1 and BMC application software 2 do not need to directly pay attention to hardware operations. At the same time, the hardware abstraction layer converts hardware operations into general messages, so that the general I2C driver does not need to pay attention to business operations, but only controls the hardware devices connected to the I2C bus according to the general messages.

[0095] In some hardware device monitoring scenarios, the hardware devices connected to the I2C bus are various sensors. BMC application software needs to acquire data from these sensors to monitor and alarm on the hardware devices, providing hardware monitoring services for technicians.

[0096] like Figure 4 As shown, after the BMC application software sends business operations related to hardware monitoring services to the hardware abstraction layer, the hardware abstraction layer matches the corresponding hardware operations to the business operations and converts the hardware operations into corresponding general messages, which are then sent to the general I2C driver. Upon receiving the general message, the general I2C driver reads data from the sensors connected to the I2C bus through the I2C controller, enabling the BMC application software to provide hardware monitoring services to technicians based on the sensor data.

[0097] In this embodiment, the hardware device can be an LM75 temperature sensor. The LM75 temperature sensor can be used to monitor the internal temperature of a computer or server to ensure that the device operates within a suitable operating temperature range, and can issue an alarm signal when the internal temperature exceeds a temperature threshold to prevent overheating damage to internal components.

[0098] like Figure 5 As shown, Figure 5 This is an architecture diagram of another BMC chip provided in an embodiment of this application. Taking a business operation issued by BMC application software 1 as an example, after BMC application software 1 calls the interface to send the business operation to the hardware abstraction layer, the hardware abstraction layer matches the corresponding processing conditions and hardware operations for the business operation according to the configuration information. Then, the hardware abstraction layer obtains a general message by translating the hardware operation into a message. The general message includes the hardware device address, read / write length, flag bits, offset, and a buffer for storing register values. The process of the hardware abstraction layer translating the hardware operation into a message can be found in [reference needed]. Figure 7 and Figure 7 Related explanations will not be elaborated here.

[0099] After the hardware abstraction layer sends general messages to the general I2C driver through the general interface provided by the general I2C driver, the general I2C driver controls the hardware device (such as...) through the I2C controller according to the general messages. Figure 5 (The LM75 temperature sensor shown). After obtaining the operation result of the hardware device, the general I2C driver sends the operation result to the hardware abstraction layer through the general interface. The hardware abstraction layer processes the operation result using the processing conditions corresponding to the business operation and feeds back the processed operation result to the BMC application software 1.

[0100] like Figure 6 As shown, taking the BMC application software 1 reading the lm75 temperature sensor connected to the I2C bus as an example, the process of BMC application software 1 calling the lm75 temperature sensor is introduced. Among them, steps S601-S604 are the process of BMC application software 1 sending instructions to the general I2C driver, and steps S605-S607 are the process of the general I2C driver feeding back data to BMC application software 1.

[0101] S601: BMC application software 1 sends business operations to the hardware abstraction layer.

[0102] In one application scenario, the business operation is used to indicate the temperature of the BMC chip.

[0103] In one possible implementation, the process of BMC application software 1 sending business operations to the Hardware Abstraction Layer typically involves referencing header files and calling specific interface functions. The source code of BMC application software 1 usually includes header files pointing to the Hardware Abstraction Layer. These header files typically contain function declarations, structure definitions, and constant definitions. When calling the interface functions, BMC application software 1 sends business operations to the Hardware Abstraction Layer.

[0104] S602: The hardware abstraction layer determines the corresponding hardware operation from the configuration information based on the business operation.

[0105] In one possible implementation, Figure 2 The hardware abstraction layer shown stores configuration information. This configuration information describes the mapping between service operations and hardware operations. The configuration information includes the hardware operations corresponding to each service operation. Through this configuration information, the hardware abstraction layer can map the service operations sent by BMC application software 1 to the corresponding hardware operations.

[0106] like Figure 7 As shown, Figure 7 This is a schematic diagram of a data structure for business operations and hardware operations provided in an embodiment of this application.

[0107] Business operations can include a buffer for storing the processing results of register values, operation type (read operation and write operation), number of retries, and timeout. The number of retries and timeout can be freely set according to the corresponding business function in BMC application software 2.

[0108] A buffer used to store the results of register value processing refers to a buffer that stores the operation results of the hardware abstraction layer on the feedback from the general I2C driver.

[0109] The operation type specifies the type of business operation, which can be a read operation or a write operation. A read operation is used to read register values ​​from a hardware device, while a write operation is used to write data to a register on a hardware device.

[0110] The retry count is the number of times an operation will be retried if an error or failure occurs. For example, if a read or write operation fails on the first attempt, the hardware abstraction layer can retry multiple times according to the given number of retries to improve the success rate of the operation.

[0111] The timeout period is the timeout time set for a business operation, meaning the operation must be completed within the specified time. If the operation is not completed within the specified timeout period, the hardware abstraction layer can handle the timeout according to a custom strategy, such as returning a timeout error or retrying.

[0112] The parameters mentioned above (buffer for storing register value processing results, operation type, number of retries, and timeout) can be provided in the business operation so that the hardware abstraction layer can perform the corresponding operation after receiving the business operation. For example, the hardware abstraction layer can read or write the processing result of the corresponding register value according to the operation type and store the processing result in the buffer provided by the business operation. During a read operation, the hardware abstraction layer can check the number of bytes returned to ensure that the read data is consistent with the expectation. During a write operation, the hardware abstraction layer can return corresponding feedback based on the result of the write operation.

[0113] Using the parameters described above, the hardware abstraction layer can flexibly process data according to the needs of business operations and provide results related to register value processing. This enables read and write operations on hardware device registers and allows for corresponding feedback and control based on the processing results.

[0114] Hardware operations may include hardware device type, I2C channel number, hardware device address, buffer for storing register values, read / write length, offset, and flags.

[0115] The hardware device type indicates the type of hardware device to be accessed, such as the LM75 temperature sensor. The I2C channel number specifies the specific channel number used when communicating via the I2C bus. The hardware device address is a unique address that identifies the hardware device, allowing communication with that specific device. The buffer for storing register values ​​stores data read from or written to the hardware device; it can be a pointer to memory.

[0116] The read / write length indicates the length of data to be read or written. For example, when reading the register value of a temperature sensor, the number of bytes to read needs to be specified. The offset indicates the offset of the register to be read or written. For some devices, data may be stored in multiple registers; specifying the offset allows selection of a specific register. Flags specify specific flags or identifiers, playing an auxiliary role in hardware operation. For example, flags can be used to enable / disable a hardware module.

[0117] In this embodiment of the application, after receiving the service operation, the hardware abstraction layer determines the hardware device type of the BMC temperature sensor as an lm75 temperature sensor, the hardware device address of the lm75 temperature sensor, the I2C channel for communicating with the lm75 temperature sensor using the I2C bus, the buffer for storing data read from the lm75 temperature sensor, the read / write length, the offset, and the flag bit based on the configuration information.

[0118] S603: The hardware abstraction layer translates hardware operations into messages to obtain general messages.

[0119] Figure 2 The hardware abstraction layer (HAL) shown is used to translate hardware operations into general messages after determining the corresponding hardware operations for a business operation. In the HAL, the process of translating hardware operations into general messages is the process of converting hardware operations into general messages. A general message is an abstract representation used to describe the hardware operation to be executed and its related parameters.

[0120] like Figure 7 As shown, the general message includes information related to the hardware operation. The general message may include the hardware device address, a buffer for storing register values, and additional parameters (such as read / write length, offset, and flags) that need to be passed to the general I2C driver.

[0121] General messages can be represented by defining specific data structures, where fields or attributes correspond to the parameters that need to be passed to the general I2C driver. The design of general messages can be flexibly defined according to specific application scenarios and hardware requirements.

[0122] By translating messages, the Hardware Abstraction Layer (HAL) converts hardware operations into generic messages, decoupling business operations from hardware operations. This allows the HAL to handle different hardware devices and business operations uniformly. Sending hardware operations using generic messages facilitates interaction between the generic I2C driver and the HAL, while also freeing the generic I2C driver from focusing on business operations, thus improving its scalability.

[0123] S604: The hardware abstraction layer sends general messages to the general I2C driver through a general interface.

[0124] Figure 2 The generic I2C driver shown exposes a generic interface to the hardware abstraction layer. After converting hardware operations into generic messages, the hardware abstraction layer can pass these generic messages to the generic I2C driver by calling the generic interface.

[0125] Since different BMC application software may use different calling formats, in this embodiment of the application, the hardware abstraction layer can improve the universality of the interface by converting all the different calling formats of each BMC application software into calls to the general interface.

[0126] A generic interface connects the Hardware Abstraction Layer (HAL) and the generic I2C driver. The generic interface parses generic messages and passes relevant parameters to the I2C driver. The generic I2C driver receives the generic message and executes corresponding hardware operations based on the parameters. The functionality of the generic interface can be implemented through generic interface functions. These functions can perform parameter processing, data conversion, and interface calls according to specific interface specifications to meet the interaction requirements between the generic I2C driver and the HAL.

[0127] In one possible implementation, the generic I2C driver communicates with the hardware device mounted on the I2C bus using a given I2C channel number and hardware device address. Based on the instructions in the generic message, the generic I2C driver can read or write registers associated with the offset and store the register values ​​in a provided buffer. After completing the read / write operation, the generic I2C driver can return the result to the generic interface, which then passes the result to the hardware abstraction layer that called the generic interface.

[0128] Through step S604, the Hardware Abstraction Layer (HAL) can pass general messages to the general I2C driver, thereby enabling communication and operation with the corresponding hardware devices. It should be noted that the design of the general interface and the general I2C driver must adhere to consistent interface specifications to ensure compatibility and scalability when the HAL interacts with the general I2C driver.

[0129] S605: The general-purpose I2C driver controls hardware devices and obtains operation results based on general messages.

[0130] The general-purpose I2C driver communicates with hardware devices through the I2C bus to control the hardware devices and obtain operation results by sending request messages and receiving response messages.

[0131] Upon receiving a general message, the general-purpose I2C driver can initialize the I2C bus and hardware devices according to the parameters in the message, such as initializing based on the hardware device address. Then, the general-purpose I2C driver sends control commands to the hardware device via the I2C bus. After successfully sending the control commands, the general-purpose I2C driver waits for the hardware device to complete the corresponding operation. The waiting time may vary depending on the response speed of the hardware device and the complexity of the operation.

[0132] After the hardware device completes the operation according to the control command, it transmits the operation result back to the general-purpose I2C driver via the I2C bus. The operation result may include the execution result of the control command, register values, or other relevant data. After receiving the operation result, the general-purpose I2C driver returns the operation result to the hardware abstraction layer through a general interface.

[0133] It should be noted that the implementation of a general I2C driver may vary depending on the platform, operating system, or hardware device requirements. The above is merely an example provided by an embodiment of this application; specific implementations may involve certain details and operations, such as error handling and timeout mechanisms.

[0134] S606: The hardware abstraction layer receives operation results through a generic interface.

[0135] When performing a read operation, the generic interface function corresponding to the generic interface can return the data read from the hardware device to the hardware abstraction layer. The generic interface function can copy register values ​​to a pre-allocated buffer and return the number of bytes read. If the hardware operation involves reading or writing multiple registers or data blocks, the generic interface function can return a data structure containing the relevant data so that the hardware abstraction layer can process it further.

[0136] In this embodiment of the application, after receiving a general message, the general I2C driver can return the register value read from the lm75 temperature sensor to the hardware abstraction layer through a general interface function, such as reading the value of the lm75 temperature sensor through the I2C bus.

[0137] The hardware abstraction layer can interact with the general I2C driver through a general interface and obtain results related to the operation of the hardware device. The hardware abstraction layer then returns these results to the BMC application software 1 in an appropriate manner to realize the control and management of the hardware device.

[0138] S607: The hardware abstraction layer processes the operation results according to the processing conditions corresponding to the business operation.

[0139] After receiving the operation result, the hardware abstraction layer can process the received operation result appropriately, such as error handling and data parsing, and then feed the processed operation result back to the BMC application software 1.

[0140] In one possible implementation, the configuration information also includes processing conditions corresponding to the business operation. After receiving a business operation from the BMC application software 1, the hardware abstraction layer can match the corresponding processing conditions and hardware operation from the configuration information based on the business operation. When the hardware abstraction layer receives the operation result from the general I2C driver for that hardware operation, it can process the operation result based on the processing conditions corresponding to the hardware operation and the business operation. Processing conditions may include, for example, unit conversion of the read temperature value or comparison with a preset temperature threshold.

[0141] In this embodiment, after the general I2C driver reads and feeds back the register value in the lm75 temperature sensor to the hardware abstraction layer, the hardware abstraction layer, upon receiving the register value, can read the processing conditions corresponding to the service operation of the BMC temperature according to the instruction, that is, convert the register value into a Celsius value, and convert the register value in the lm75 temperature sensor into the corresponding Celsius value.

[0142] S608: The hardware abstraction layer returns the processed operation results to the BMC application software 1.

[0143] In this embodiment, the processed operation result is the Celsius value converted from the register value. After processing the operation result according to the processing conditions corresponding to the business operation, the hardware abstraction layer feeds back the processed operation result to the BMC application software 1 through the interface with the BMC application software 1.

[0144] Upon receiving the processed operation result, namely the temperature value in degrees Celsius, BMC application software 1 can perform further processing as needed, such as logging, generating alarms, and making decisions.

[0145] The hardware device invocation system and invocation method provided in this application utilize a hardware abstraction layer (HAL) as an intermediary between the application layer and the driver layer. The HAL stores the hardware operations and processing conditions corresponding to each business operation. When an application software implements a function, it only needs to send the business operation to the HAL. The HAL adapts the corresponding hardware operation based on the business operation and converts it into a general message that can be recognized by the general I2C driver. After receiving the general message, the general I2C driver can control the hardware device connected to the I2C bus according to the parameters in the general message.

[0146] By leveraging a hardware abstraction layer to handle the mapping between business operations and hardware operations, the application software in the application layer and the general-purpose I2C driver in the driver layer can decouple business operations from hardware operations. Application software only needs to focus on the business operations, without needing to concern itself with hardware operations; while the general-purpose I2C driver only needs to focus on the hardware operations transformed by the hardware abstraction layer, without needing to concern itself with business operations, thus making the general-purpose I2C driver more versatile.

[0147] When developing application software, engineers do not need to consider the driver architecture related to the general I2C driver; they can simply set the corresponding hardware operations in the hardware abstraction layer. This decouples the application software from the I2C driver, eliminating the need to create a dedicated I2C driver for each application. Later, when maintaining the I2C driver, only one general-purpose I2C driver needs to be maintained, reducing maintenance costs. When the chip running the system is updated, only one general-purpose I2C driver needs to be developed to adapt to various application software, similarly reducing the development costs of chip iteration.

[0148] In one possible implementation, a generic I2C driver can conform to the kernel style or other easily extensible I2C driver frameworks, providing a general interface related to hardware devices to meet the specific needs of various BMC application software. A generic I2C driver can provide basic I2C communication functionality and has an easily extensible structure, facilitating the addition of modules with specific functions.

[0149] Kernel style refers to a common coding style and standard used in operating system kernel development. Kernel style improves code readability and maintainability, making it easier for different developers to understand and follow consistent standards when reading and modifying code. This makes kernel code easier to maintain, debug, and extend, and reduces the error rate during development.

[0150] A general-purpose I2C driver provides a common interface for communicating with hardware devices via the I2C bus. It serves as a foundational platform for various BMC application software. By focusing solely on hardware operations, the general-purpose I2C driver reduces development and maintenance workload.

[0151] One possible implementation uses the kernel-style devfs character device framework as the framework for the general I2C driver, and uses system calls such as read, write, and ioctl to ensure interface universality and extensibility. For example... Figure 8 As shown, Figure 8This diagram illustrates the connection between a hardware abstraction layer and a general-purpose I2C driver, as provided in an embodiment of this application. The general-purpose I2C driver includes the read system call, write system call, and ioctl system call.

[0152] The `read` system call is used to read data from a file descriptor. The `write` system call is used to write data to a file descriptor. The `ioctl` system call is a general-purpose device control interface used to perform various control operations on a device. The `ioctl` system call includes configuration timing, bus mode, and other `ioctl` commands.

[0153] Timing is crucial for communication in some hardware devices, and specific timing parameters can be configured using the ioctl system call. By defining corresponding commands, the functionality of setting and retrieving timing parameters can be implemented in a general I2C backup driver.

[0154] The I2C bus supports different modes, such as standard mode, fast mode, and high-speed mode. The operating mode of the I2C bus can be configured through commands defined using the ioctl system call, thus adapting to specific hardware requirements or business needs.

[0155] In kernel development, the character device framework is a commonly used device driver framework. The `read` system call allows reading from a character device using file operation functions, enabling read operations on the hardware device. The `write` system call allows writing to a character device using file operation functions, enabling write operations on the hardware device.

[0156] Using the ioctl system call provides the ability to extend general-purpose I2C drivers, adapting to hardware operations beyond the basic driver framework. Developers can define their own commands and implement the processing logic for these commands within the general-purpose I2C driver through ioctl system calls. The ioctl system call can satisfy the specific operations of different BMC applications on hardware devices, maintaining the universality and extensibility of the general-purpose I2C driver.

[0157] It should be noted that when implementing extended commands via the ioctl system call, the corresponding processing function needs to be implemented in the general I2C driver. The general I2C driver selects the appropriate processing function based on the extended command, thereby implementing the corresponding hardware operation, such as configuring registers, sending a specific sequence, or performing a specific operation, to ensure the correct execution of the command and the normal operation of the device.

[0158] The generic I2C driver exposes typical operations (such as reading, writing, configuring timing, and configuring bus mode) to the hardware abstraction layer as general interfaces. These interfaces are independent of specific business operations and only concern themselves with hardware operations related to hardware devices.

[0159] In one possible implementation, after the general-purpose I2C driver receives a general message sent by the hardware abstraction layer, the workflow of the general-purpose I2C driver is as follows: Figure 9 As shown:

[0160] S901: The general I2C driver uses the corresponding processing function of the system call to process general messages.

[0161] System calls include the read, write, and ioctl system calls. When the BMC application software invokes a system call, the Hardware Abstraction Layer (HAL) uses the generic interface provided by the generic I2C driver for that system call to send a generic message to the generic I2C driver. The generic I2C driver receives the message using the generic interface and then selects the appropriate processing function based on the system call used by the HAL to process the message.

[0162] By processing general-purpose I2C messages, the general-purpose I2C driver can determine relevant parameters for hardware operations, such as hardware device addresses, buffers for storing register values, and additional parameters that need to be passed to the general-purpose I2C driver (such as read / write length, offset, and flags).

[0163] The ioctl system call is used to send ioctl command words to the general I2C driver to perform control operations. The ioctl command word is a parameter of the ioctl system call, which specifies the desired operation.

[0164] An ioctl command word is an unsigned long integer value defined by the device and its driver, and passed between the Hardware Abstraction Layer (HAL) and the generic I2C driver. The ioctl command word identifies a specific operation, such as reading device status, configuring device parameters, or sending control commands. When invoking an ioctl system call, an appropriate command word must be provided as an argument to inform the generic I2C driver what operation to perform. The ioctl command word is then parsed by the generic I2C driver, which controls the execution of the corresponding operation on the appropriate hardware device.

[0165] S902: General I2C driver verifies the validity of general messages.

[0166] During the processing using the processing functions, the general I2C driver verifies and validates the general message to ensure its validity. For example, it checks whether the buffer address is valid and whether the data length meets the requirements.

[0167] By validating the validity of general messages, erroneous parameters can be prevented from being passed to hardware devices, thereby reducing the risk of errors or system crashes caused by incorrect parameters. For example, if the incoming parameters exceed the acceptable range of the hardware device or are incorrectly formatted, the hardware device may be unable to process the request correctly, leading to abnormal behavior.

[0168] S903: General I2C driver checks the operating conditions of the I2C bus.

[0169] Before performing hardware operations, the general-purpose I2C driver needs to ensure that the I2C bus meets the operating conditions. For example, check whether the power supply of the hardware devices on the I2C bus is normal; check whether the clock frequency of the hardware devices is consistent; check whether the address settings of the hardware devices are correct; and check whether each hardware device can correctly respond to the signals on the I2C bus.

[0170] S904: The general-purpose I2C driver sends control commands to hardware devices on the I2C bus through the I2C controller.

[0171] Upon receiving a general message, the general-purpose I2C driver controls the hardware devices on the I2C bus based on the processing result of the message. For example, the hardware device address in the general message can determine the hardware device to be controlled; the read / write length can determine the length of data to be read or written. Through the I2C controller, the general-purpose I2C driver sends control commands to the hardware device indicated by the hardware device address.

[0172] After receiving a control command, the hardware device executes the corresponding operation, such as a sensor reading data or an actuator sending instructions. During the execution of the operation, the hardware device can store the operation result in an internal register, and after the execution is completed, return the operation result to the general I2C driver in the form of a response message.

[0173] It is important to note that the specifications of hardware devices and the implementation of general-purpose I2C drivers may have different requirements regarding message formats, opcodes, and data formats. Therefore, in actual development, it is necessary to refer to the hardware device documentation and the requirements of the general-purpose I2C driver to construct the correct control commands to ensure normal communication between the general-purpose I2C driver and the hardware device.

[0174] Additionally, some special operations may require waiting for a response from the hardware device or polling the hardware device's status to ensure successful completion. This may require the general I2C driver to wait appropriately after sending the request message and check the device's response or status within a certain time.

[0175] S905: The general I2C driver returns the operation result.

[0176] The general I2C driver sends the return value to the hardware abstraction layer based on the result of the operation, so that the hardware abstraction layer can perform further operations based on the return value.

[0177] A generic I2C driver contains only operations related to the I2C bus and I2C controller logic, and does not include specific business logic. This allows all hardware abstraction layers to communicate with the generic I2C driver, enabling general control and communication with hardware devices. Specific business logic can be implemented in the hardware abstraction layer above the driver. This makes the generic I2C driver more versatile, easier to maintain, and more reusable.

[0178] Based on the hardware device invocation system provided in the above embodiments, this application also provides a hardware device invocation method, which is based on... Figure 2 The system implementation shown is as follows: Figure 10 As shown, the method includes:

[0179] S1001: Sending service operations from the application layer to the hardware abstraction layer.

[0180] The application layer includes at least one application software. When an application software in the application layer provides an application service, or when a user invokes an application software, a business operation is sent to the hardware abstraction layer through the application layer. A business operation refers to the operation that provides the application service to the user. An example of a business operation is obtaining the chip temperature.

[0181] S1002: Based on the hardware abstraction layer, match the corresponding hardware operation according to the business operation.

[0182] When the hardware abstraction layer receives a business operation from the application layer, it matches the corresponding hardware operation to the business operation. For example, if the business operation is to obtain the chip temperature, the hardware operation could be to read the register value of the temperature sensor.

[0183] The hardware abstraction layer stores configuration files, which include the hardware operations corresponding to business operations. Through these configuration files, the hardware abstraction layer can determine the correspondence between business operations and hardware operations, and identify the corresponding hardware operations for each business operation.

[0184] S1003: Sends hardware operations to the driver layer based on the hardware abstraction layer.

[0185] After the hardware abstraction layer determines the hardware operation, it can send the hardware operation to the driver layer so that the general I2C driver in the driver layer can control the hardware according to the hardware operation.

[0186] In one possible implementation, the hardware abstraction layer can translate hardware operations into general messages and send the hardware operations to the driver layer in the form of general messages.

[0187] In one possible implementation, the hardware abstraction layer can send general messages to the driver layer by calling a general interface provided by the driver layer.

[0188] S1004: Based on the driver layer, control hardware devices according to hardware operations.

[0189] After receiving a hardware operation, the driver layer controls the hardware device to perform the corresponding action based on the hardware operation. If the hardware operation is, for example, reading the register value of a temperature sensor, the driver layer can send a control command to the temperature sensor, so that the temperature sensor responds to the control command and feeds back the register value to the driver layer.

[0190] The above are some specific implementations of the hardware device invocation method provided in the embodiments of this application. Based on this, this application also provides a corresponding hardware device invocation device. The hardware device invocation device provided in the embodiments of this application will be described below from the perspective of functional modularity. This device includes:

[0191] The sending module is used to send service operations to the hardware abstraction layer based on the application layer;

[0192] The matching module is used to match the corresponding hardware operation based on the business operation according to the hardware abstraction layer, and send the hardware operation to the driver layer;

[0193] The control module is used to control the hardware device based on the hardware operation according to the driver layer, so as to execute the business operation.

[0194] The above are some specific implementations of the hardware device invocation method provided in the embodiments of this application. Based on this, this application also provides corresponding chips and servers. The chips and servers provided in the embodiments of this application will be described below in conjunction with the above hardware device invocation method.

[0195] This application also provides a BMC chip. This BMC chip is used to implement the technical solutions described in any of the foregoing embodiments.

[0196] This application embodiment also provides a server, characterized in that it includes: a processor, and a memory communicatively connected to the processor;

[0197] The memory is used to store computer-executed instructions;

[0198] The processor is used to execute computer execution instructions stored in the memory to implement the hardware device invocation method described in any of the foregoing embodiments.

[0199] This application also provides corresponding devices and computer storage media for implementing the solutions provided in this application.

[0200] The device includes a memory and a processor. The memory is used to store instructions or code, and the processor is used to execute the instructions or code to cause the device to perform the data transmission method described in any embodiment of this application.

[0201] This application also provides a computer-readable storage medium. The computer-readable storage medium can be any available medium that a computing device can store, or a data storage device such as a data center that includes 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 drive). The computer-readable storage medium includes instructions that instruct the computing device to execute a method for invoking a hardware device, or instruct the computing device to execute a method for invoking a hardware device.

[0202] In the embodiments of this application, the terms "first" and "second" (if they exist) are used only as name identifiers and do not represent the order of first and second.

[0203] As can be seen from the above description of the embodiments, those skilled in the art can clearly understand that all or part of the steps in the methods of the above embodiments can be implemented by means of software plus a general-purpose hardware platform. Based on this understanding, the technical solution of this application can be embodied in the form of a software product. This computer software product can be stored in a storage medium, such as a read-only memory (ROM) / RAM, magnetic disk, optical disk, etc., including several instructions to cause a computer device (which may be a personal computer, a server, or a network communication device such as a router) to execute the methods described in various embodiments or some parts of the embodiments of this application.

[0204] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on its differences from other embodiments. In particular, the apparatus embodiments are basically similar to the method embodiments, so the description is relatively simple; relevant parts can be referred to the descriptions in the method embodiments. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. Those skilled in the art can understand and implement this without creative effort.

[0205] The above description is merely an exemplary implementation of this application and is not intended to limit the scope of protection of this application.

Claims

1. A method for invoking a hardware device, characterized in that, Applied to a calling system, the system sequentially comprising an application layer, a hardware abstraction layer, and a driver layer, the method includes: The application layer sends service operations to the hardware abstraction layer. Based on the hardware abstraction layer, the corresponding hardware operation is matched according to the business operation, and the hardware operation is sent to the general driver in the driver layer in the form of a general message; Based on the general driver, the hardware device is controlled according to the hardware operation to execute the business operation; There are multiple hardware devices, and these multiple hardware devices are controlled by the same general driver.

2. The method according to claim 1, characterized in that, The matching of corresponding hardware operations based on the business operations according to the hardware abstraction layer includes: Based on the hardware abstraction layer, the service operation is matched with the corresponding hardware operation according to the configuration information, and the configuration information includes the hardware operation corresponding to the service operation.

3. The method according to claim 1, characterized in that, Sending the hardware operation to the driver layer includes: The hardware operation is translated into a general message based on the hardware abstraction layer, and the general message is sent to the driver layer. The general message is used to describe the hardware operation.

4. The method according to claim 3, characterized in that, Sending the general message to the driver layer includes: The hardware abstraction layer calls the general interface provided by the driver layer to send the general message to the driver layer.

5. The method according to claim 1, characterized in that, The method further includes: The driver layer obtains the operation result obtained by sending control commands to the hardware device, and feeds back the operation result to the hardware abstraction layer.

6. The method according to claim 5, characterized in that, The configuration information includes the processing conditions corresponding to the business operations; the method also includes: Based on the hardware abstraction layer, the operation result is processed according to the processing conditions corresponding to the business operation, and the processed operation result is returned to the application layer.

7. The method according to claim 3 or 4, characterized in that, The method of controlling hardware devices based on the driver layer according to the hardware operation includes: The driver layer receives the general message and controls the hardware device based on the general message.

8. A hardware device invocation system, characterized in that, The system comprises, in sequence, an application layer, a hardware abstraction layer, and a driver layer; The application layer is used to send business operations to the hardware abstraction layer according to the application services provided by the application layer. The hardware abstraction layer is used to match the corresponding hardware operation according to the business operation, and send the hardware operation to the general driver in the driver layer in the form of a general message; The driver layer is used to control hardware devices based on the general driver and the hardware operation to execute the business operation; There are multiple hardware devices, and these multiple hardware devices are controlled by the same general driver.

9. A BMC chip, characterized in that, The BMC chip is used to implement the method for calling the hardware device as described in any one of claims 1-7.

10. A server, characterized in that, include: A processor, and a memory communicatively connected to the processor; The memory is used to store computer-executed instructions; The processor is used to execute computer execution instructions stored in the memory to implement the method of invoking the hardware device as described in any one of claims 1-7.

Images