Method and device for compatibility of driver middleware of cross-supplier hardware platform
By building a compatible driver middleware across hardware platforms, the driver compatibility and dynamic adaptation issues of the Zynq platform were resolved, enabling seamless operation and efficient maintenance of the software on different hardware platforms.
Patent Information
- Application Number
- CN202510945433.2
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-07-09
- Publication Date
- 2025-10-28
AI Technical Summary
In embedded systems, the Zynq platform has different peripheral extensions and underlying implementations across different vendor hardware platforms, which leads to driver compatibility problems and a lack of dynamic adaptation capabilities. Traditional solutions cannot achieve seamless operation across vendor hardware platforms.
Build a compatible driver middleware across hardware platforms. By storing the vendor ID code at power-on startup and using a dynamic adaptation engine to identify and map the corresponding underlying driver, a unified driver interface and dynamic adaptation are achieved.
It enables a single product library software to run seamlessly on different vendor hardware platforms, reducing system development, usage, and maintenance costs, improving software code reusability, and supporting rapid integration with new platforms.
Smart Images
Figure CN120848847A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of embedded system development technology, and more specifically to a method and apparatus for a cross-vendor hardware platform compatible driver middleware. Background Technology
[0002] With the rapid development of edge computing, Xilinx Zynq series heterogeneous computing platforms, leveraging the synergistic advantages of their ARM processors (PS side) and programmable logic (PL side), have been widely adopted in embedded systems. Due to the implementation of dual-vendor or multi-vendor vendor strategies, even hardware platforms using the same Zynq chip model inevitably exhibit significant differences in peripheral expansion and underlying implementation. In this context, for bare-metal upper-layer system applications without an embedded real-time operating system, different bare-metal application software entities often need to be formed based on different underlying drivers provided by different vendors, resulting in low efficiency in application software development and maintenance, and enormous complexity in software version state management.
[0003] Currently, development based on the Zynq platform mainly faces the following technical challenges:
[0004] Differences in peripheral expansion and underlying implementation: There are significant differences in peripheral expansion on the PS side and the underlying implementation of custom IP cores on the PL side among Zynq platforms provided by different vendors.
[0005] Driver compatibility issues: Due to the differences mentioned above, different vendors develop drivers with different implementations, resulting in incompatible driver code.
[0006] Lack of dynamic adaptation capability: Traditional BSP (Board Support Package) solutions cannot automatically identify hardware vendors and load matching driver strategies at runtime.
[0007] In existing technologies, driver compatibility solutions for supplier hardware platforms mainly have the following limitations:
[0008] 1. Supplier-specific BSP solution: Each supplier provides a customized driver library, which binds the underlying driver software and the upper-level application software, making it impossible to reuse across supplier hardware platforms.
[0009] 2. Device Tree Solution: Although it can describe the hardware topology, it cannot solve the problem of dynamic adaptation of IP cores on the PL side, and it requires recompilation for different vendor hardware, making it impossible to achieve seamless operation of a single product library code on different vendor hardware platforms.
[0010] 3. Traditional Hardware Abstraction Layer (HAL): Solutions such as the ARM Cortex Microcontroller Software Interface Standard (CMSIS) can only abstract the functions of the ARM processor on the PS side, and lack unified management capabilities for the supplier-defined logic on the PL side and mixed-signal peripherals.
[0011] To achieve seamless operation of a single product library codebase across multiple vendor hardware platforms, there is an urgent need for a method to implement a compatible and unified driver middleware across heterogeneous Zynq hardware platforms from different vendors. This implementation needs to have the following characteristics:
[0012] 1. Hardware difference shielding capability: It can shield the underlying differences between hardware from different vendors and provide a unified driver interface.
[0013] 2. Dynamic adaptation capability: Supports runtime hardware recognition and automatic driver loading.
[0014] 3. Performance optimization: Without introducing additional performance overhead while ensuring compatibility.
[0015] Based on this technical background, the present invention proposes a method and apparatus for a compatible driver middleware across vendor hardware platforms. Summary of the Invention
[0016] To address the shortcomings of existing technologies, this invention proposes a method and apparatus for cross-vendor hardware platform compatible driver middleware. This method, by constructing middleware, decouples different underlying driver software from different vendors from the same upper-level application software with the same system requirements, enabling a single set of product library application software to run seamlessly across vendor hardware platforms. This significantly reduces the costs of system development, use, maintenance, and state management, and improves software code reusability.
[0017] To achieve the above objectives, a first aspect of the present invention provides a cross-vendor hardware platform compatible driver middleware method, comprising:
[0018] Power on and start the Zynq SoC, executing the BootROM;
[0019] During the execution of FSBL, the PS terminal is initialized, the PL terminal is configured using the PS terminal, the supplier ID codes are stored, and the bare-metal application is loaded into DDR.
[0020] The bare-metal application is executed, and the middleware is used to read the ID codes of each supplier. The middleware's dynamic adaptation engine is used to identify and map the underlying driver of the corresponding supplier.
[0021] The middleware is used to call the corresponding vendor's driver to perform system initialization and low-level hardware operations.
[0022] A second aspect of the present invention provides an apparatus for a cross-vendor hardware platform compatible driver middleware, comprising:
[0023] The power-on startup module is used to power on the Zynq SoC and execute the BootROM.
[0024] The FSBL module is used to initialize the PS terminal during the FSBL execution process, configure the PL terminal using the PS terminal, store the ID codes of each supplier, and load the bare-metal application into the DDR.
[0025] The dynamic adaptation module is used to execute the bare-metal application, read the ID codes of each supplier using middleware, and identify and map the underlying drivers of the corresponding suppliers through the dynamic adaptation engine of the middleware.
[0026] The calling module is used to invoke the corresponding vendor's driver using the middleware to perform system initialization and low-level hardware operations.
[0027] The technical effects of this invention include:
[0028] (1) The cross-vendor hardware platform compatible driver middleware method proposed in this invention, by constructing middleware, decouples the different underlying driver software of different vendors and the same upper-level application software with the same system requirements, and realizes the seamless operation of a set of product library application software across vendor hardware platforms, thereby significantly reducing the cost of system development, use, maintenance and status management, and improving the software code reuse rate.
[0029] (2) The cross-vendor hardware platform compatible driver middleware method proposed in this invention also has significant advantages in terms of system scalability, supports the rapid access of new vendor hardware platforms, and only requires driver layer adaptation according to the specification to complete the integration.
[0030] Other features and advantages of the present invention will be described in detail in the following detailed description section. Attached Figure Description
[0031] The above and other objects, features and advantages of the present invention will become more apparent from the more detailed description of exemplary embodiments of the invention in conjunction with the accompanying drawings, wherein the same reference numerals generally represent the same components in the exemplary embodiments of the invention.
[0032] Figure 1 This is a flowchart illustrating the cross-vendor hardware platform compatible driver middleware method proposed in this invention.
[0033] Figure 2 This is a flowchart illustrating a specific implementation of the cross-vendor hardware platform compatible driver middleware method proposed in this invention.
[0034] Figure 3 This is a schematic diagram of FSBL code, which implements the vendor ID encoding memory storage in a specific embodiment of the cross-vendor hardware platform compatible driver middleware method proposed in this invention.
[0035] Figure 4 This is a schematic diagram illustrating the implementation of middleware reading vendor ID encoding code in a specific embodiment of the cross-vendor hardware platform compatible driver middleware method proposed in this invention.
[0036] Figure 5 This is a schematic diagram of the middleware platform initialization unified driver interface function code, which is a specific implementation of the cross-vendor hardware platform compatible driver middleware method proposed in this invention.
[0037] Figure 6 This is a schematic diagram of the code for conflict handling in the middleware during the optimization and merging process of the dedicated board-level support package, which is a specific implementation of the cross-vendor hardware platform compatible driver middleware method proposed in this invention. Detailed Implementation
[0038] Preferred embodiments of the invention will now be described in more detail. While preferred embodiments of the invention are described below, it should be understood that the invention can be implemented in various forms and should not be limited to the embodiments set forth herein.
[0039] In this invention, unless otherwise stated, directional terms such as "upper" and "lower" generally refer to the upper and lower positions of the device in its normal operating state, while "inner" and "outer" refer to their position relative to the device's outline. Furthermore, the terms "first," "second," and "third" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of indicated technical features. Thus, a feature defined as "first," "second," or "third" may explicitly or implicitly include one or more of that feature. In the description of this invention, "a plurality of" means two or more, unless otherwise explicitly specified.
[0040] This invention provides a cross-vendor hardware platform compatible driver middleware method, such as... Figure 1 Shown, including:
[0041] Power on and start the Zynq SoC, executing the BootROM;
[0042] During the execution of FSBL, the PS terminal is initialized, the PL terminal is configured using the PS terminal, the ID codes of each vendor are stored, and the bare-metal application is loaded into DDR.
[0043] Execute the bare-metal application, use middleware to read the ID codes of each vendor, and use the middleware's dynamic adaptation engine to identify and map the underlying drivers of the corresponding vendors;
[0044] The middleware is used to call the corresponding vendor's driver to perform system initialization and low-level hardware operations.
[0045] In this invention, by constructing middleware, the binding between different underlying driver software from different vendors and the same upper-level application software with the same system requirements is removed, enabling a set of product library application software to run seamlessly across vendor hardware platforms, thereby significantly reducing the costs of system development, use, maintenance, and status management, and improving the software code reusability rate.
[0046] According to the present invention, powering on and starting the Zynq SoC to execute the BootROM includes:
[0047] After the Zynq SoC is powered on, the BootROM code searches for header files in the off-chip non-volatile memory of the Zynq SoC and uses the boot information defined in the header files to configure the execution of the BootROM.
[0048] The startup information includes the offset address of the FSBL and whether it is booting in safe mode.
[0049] According to the present invention, the PS terminal is an ARM processor and the PL terminal is programmable logic;
[0050] The software code for the Zynq SoC and the BIT file for configuring the FPGA are stored in memory connected to the PS.
[0051] According to the present invention, storing the supplier ID codes includes:
[0052] Through FSBL, each supplier stores its own ID code according to the agreed vendor ID coding system, the agreed storage scheme and storage space;
[0053] The encoding system adopts a 3-byte vendor ID encoding standard, where byte 1 is the vendor identification number, byte 2 is the hardware version number, and byte 3 is a spare code.
[0054] According to the present invention, the storage scheme is to store each supplier ID code in a fixed storage space according to a memory allocation strategy;
[0055] The storage space is implemented by adding code to FSBL to store the supplier ID encoding in memory, so that when the middleware reads the supplier ID encoding, it can dynamically adapt and call the underlying driver of each supplier. Its address is 0x1FFFFFF0~0x1FFFFFFF.
[0056] According to the present invention, executing a bare-metal application, reading the ID codes of each vendor using middleware, and identifying and mapping the underlying drivers of the corresponding vendors through the middleware's dynamic adaptation engine includes:
[0057] Define a read function in the middleware to read the ID codes of each supplier;
[0058] By using a dynamic adaptation engine to read the ID codes of each supplier through a reading function, dynamic adaptation of the driver interface is achieved.
[0059] According to the present invention, executing a bare-metal application, reading the vendor ID codes using middleware, and identifying and mapping the underlying drivers of the corresponding vendors through the middleware's dynamic adaptation engine further includes:
[0060] Define standardized driver interface functions in the middleware;
[0061] Add the corresponding underlying driver interface function identification number of each vendor to the end of the standardized driver interface function name;
[0062] The standardized driver interface function calls the corresponding driver interface function of the supplier based on the obtained supplier ID code to realize the dynamic adaptation engine function.
[0063] According to the present invention, executing a bare-metal application, reading the vendor ID codes using middleware, and identifying and mapping the underlying drivers of the corresponding vendors through the middleware's dynamic adaptation engine further includes:
[0064] A collection is built based on the dedicated board-level support packages of each vendor;
[0065] Conflicting functions, variables, and macro definitions in the collection are handled by standardizing the driver interface functions and separated by vendor ID encoding;
[0066] When using conflicting functions, variables, or macro definitions, identification is performed based on the obtained vendor ID code.
[0067] This invention also has significant advantages in terms of system scalability, supporting rapid access to new vendor hardware platforms, and integration can be completed simply by implementing driver layer adaptation according to the specifications.
[0068] The present invention also provides an apparatus for a cross-vendor hardware platform compatible driver middleware, comprising:
[0069] The power-on startup module is used to power on the Zynq SoC and execute the BootROM.
[0070] The FSBL module is used to initialize the PS end, configure the PL end using the PS end, store the ID codes of each vendor, and load the bare-metal application into DDR during the execution of FSBL.
[0071] The dynamic adaptation module is used to execute bare-metal applications. It uses middleware to read the ID codes of each vendor and identifies and maps the underlying drivers of the corresponding vendors through the middleware's dynamic adaptation engine.
[0072] The calling module is used to invoke the corresponding vendor's driver using middleware to perform system initialization and low-level hardware operations.
[0073] According to the present invention, executing a bare-metal application, reading the ID codes of each vendor using middleware, and identifying and mapping the underlying drivers of the corresponding vendors through the middleware's dynamic adaptation engine includes:
[0074] Define a read function in the middleware to read the ID codes of each supplier;
[0075] By using a dynamic adaptation engine to read the ID codes of each supplier through a reading function, dynamic adaptation of the driver interface is achieved.
[0076] Define standardized driver interface functions in the middleware;
[0077] Add the corresponding underlying driver interface function identification number of each vendor to the end of the standardized driver interface function name;
[0078] The standardized driver interface function calls the corresponding driver interface function of the supplier based on the obtained supplier ID code to realize the dynamic adaptation engine function;
[0079] A collection is built based on the dedicated board-level support packages of each vendor;
[0080] Conflicting functions, variables, and macro definitions in the collection are handled by standardizing the driver interface functions and separated by vendor ID encoding;
[0081] When using conflicting functions, variables, or macro definitions, identification is performed based on the obtained vendor ID code.
[0082] The present invention will now be described in more detail through specific embodiments.
[0083] Example 1
[0084] This embodiment provides a method for a cross-vendor hardware platform compatible driver middleware. The overall implementation process is as follows: Figure 2 Shown, including:
[0085] In Zynq, the PS is the master device, and the PL can be regarded as a peripheral of the PS. Therefore, the PS needs to configure the PL.
[0086] Software code and FPGA configuration BIT files can be stored in configuration memory connected to the PS, which supports various off-chip non-volatile memories;
[0087] The boot process of a Zynq SoC begins with the on-chip BootROM. The code in the BootROM first looks for a header file in off-chip non-volatile memory. The header file defines some boot information to configure the operation of the BootROM.
[0088] This boot information includes the offset address of the FSBL and whether it is in safe mode, etc. The presence of the header file ensures that the BootROM can operate in the way that the device is configured after it has been formatted.
[0089] After the BootROM executes, the next configuration stage is called FSBL, which is created by the designer. In the FSBL code, each hardware manufacturer stores the manufacturer ID encoding information according to the agreed manufacturer ID encoding system, the agreed storage scheme and storage space. FSBL first initializes PS and configures PL. After the bare metal application is loaded into DDR and starts executing the bare metal application, the first step of the bare metal application is to read the vendor ID encoding. Based on the read vendor ID encoding, the corresponding vendor's driver can be called through the Unified Driver Interface (UDI) and Dynamic Adaptor Engine (DAE) to perform system initialization and low-level hardware operations.
[0090] In this embodiment, the supplier ID coding system includes:
[0091] Define the 3-byte supplier ID encoding standard:
[0092] Byte 1: Supplier Identifier (0x01: Supplier 1, 0x02: Supplier 2, ...);
[0093] Byte 2: Hardware version number (0x01: version 01, 0x02: version 02, ...);
[0094] Byte 3: Alternate code (0x00: Alternate code 00, 0x01: Alternate code 01, ...);
[0095] Supplier ID storage solutions include:
[0096] The supplier ID can be stored in Flash or memory, the principle is the same; memory read and write is more efficient and simpler to operate than Flash read and write, this embodiment adopts the memory storage solution;
[0097] According to the memory allocation strategy, a fixed memory address space of 0x1FFFFFF0~0x1FFFFFFF is allocated for the storage of supplier ID codes. This memory address space is used only for storing supplier ID codes.
[0098] like Figure 3 As shown, the FSBL code for supplier ID encoding memory storage includes:
[0099] Add code to FSBL to implement in-memory storage of vendor IDs so that middleware can read vendor IDs and dynamically adapt and call the underlying drivers of each vendor.
[0100] like Figure 4 As shown, the middleware implementation for reading the supplier ID encoding includes:
[0101] The middleware reads the vendor ID code by defining a function void Get_Vendor_ID(u8 Vendor_ID[]), which is written into the agreed memory space by each vendor in the FSBL code; the Dynamic Adaptation Engine (DAE) uses the vendor ID code read by this function to achieve dynamic adaptation of the interface;
[0102] like Figure 5 As shown, the Unified Driver Interface (UDI) includes:
[0103] A unified driver interface is also a consideration in middleware design. Standardized driver interface functions are defined in the middleware; the underlying driver interface functions of each vendor are appended with the vendor identification number (e.g., _01 or _02) to the end of the standardized driver interface function name; the middleware driver interface functions call the corresponding vendor's driver interface function based on the obtained vendor ID code to achieve dynamic engine adaptation.
[0104] Taking the platform initialization function as an example, the standardized platform initialization function defined by the middleware is voidPlatform_Init(), the platform initialization function for vendor 01 is void Platform_Init_01(), the platform initialization function for vendor 02 is void Platform_Init_02(), and so on, with more vendor initialization functions possible; the standardized platform initialization function defined by the middleware will call the corresponding vendor's platform initialization function according to the read vendor ID;
[0105] like Figure 6 As shown, the optimizations and improvements to the dedicated board support package (BSP) include:
[0106] Each vendor's underlying driver library has vendor-specific BSP support. A unified driver interface also requires a unified BSP. Therefore, the vendor-specific BSPs need to be optimized, improved and merged to form a unified BSP. This is also a consideration in middleware design.
[0107] First, a collection of BSP files for each vendor is built. For any conflicts in the collection, a design method similar to a unified driver interface is needed to handle them. Conflicting functions, variables, macro definitions, etc. are separated by vendor ID. When using these functions, variables, macro definitions, etc., the obtained vendor ID is used for identification.
[0108] Example 2
[0109] This embodiment provides an apparatus for a cross-vendor hardware platform compatible driver middleware, comprising:
[0110] The power-on startup module is used to power on the Zynq SoC and execute the BootROM.
[0111] The FSBL module is used to initialize the PS end, configure the PL end using the PS end, store the ID codes of each vendor, and load the bare-metal application into DDR during the execution of FSBL.
[0112] The dynamic adaptation module is used to execute bare-metal applications. It uses middleware to read the ID codes of each vendor and identifies and maps the underlying drivers of the corresponding vendors through the middleware's dynamic adaptation engine.
[0113] The calling module is used to call the corresponding vendor's driver using middleware to perform system initialization and low-level hardware operations;
[0114] In this embodiment, powering on and starting the Zynq SoC to execute the BootROM includes:
[0115] After the Zynq SoC is powered on, the BootROM code searches for header files in the off-chip non-volatile memory of the Zynq SoC and uses the boot information defined in the header files to configure the execution of the BootROM.
[0116] The startup information includes the offset address of the FSBL and whether it is booting in safe mode.
[0117] The PS side is an ARM processor, and the PL side is programmable logic;
[0118] The software code of the Zynq SoC and the BIT file for configuring the FPGA are stored in the memory configured connected to the PS.
[0119] The storage of each supplier's ID code includes:
[0120] Through FSBL, each supplier stores its own ID code according to the agreed vendor ID coding system, the agreed storage scheme and storage space;
[0121] The encoding system adopts a 3-byte vendor ID encoding standard, where byte 1 is the vendor identification number, byte 2 is the hardware version number, and byte 3 is a spare code;
[0122] The storage solution involves storing each vendor's ID code in a fixed storage space according to a memory allocation strategy.
[0123] The storage space is implemented by adding code to FSBL to store the supplier ID encoding in memory, so that when the middleware reads the supplier ID encoding, it can dynamically adapt and call the underlying driver of each supplier. Its address is 0x1FFFFFF0~0x1FFFFFFF;
[0124] The bare-metal application executes, uses middleware to read the ID codes of each vendor, and identifies and maps the underlying drivers of the corresponding vendors through the middleware's dynamic adaptation engine, including:
[0125] Define a read function in the middleware to read the ID codes of each supplier;
[0126] By using a dynamic adaptation engine to read the ID codes of each supplier through a reading function, dynamic adaptation of the driver interface is achieved.
[0127] Define standardized driver interface functions in the middleware;
[0128] Add the corresponding underlying driver interface function identification number of each vendor to the end of the standardized driver interface function name;
[0129] The standardized driver interface function calls the corresponding driver interface function of the supplier based on the obtained supplier ID code to realize the dynamic adaptation engine function;
[0130] A collection is built based on the dedicated board-level support packages of each vendor;
[0131] Conflicting functions, variables, and macro definitions in the collection are handled by standardizing the driver interface functions and separated by vendor ID encoding;
[0132] When using conflicting functions, variables, or macro definitions, identification is performed based on the obtained vendor ID code.
[0133] The method for cross-vendor hardware platform compatible driver middleware proposed in the embodiments of the present invention decouples the different underlying driver software from different vendors and the same upper-level application software with the same system requirements by constructing middleware. This enables a set of product library application software to run seamlessly across vendor hardware platforms, thereby significantly reducing the costs of system development, use, maintenance and status management, and improving the software code reusability rate.
[0134] The various embodiments of the present invention have been described above. These descriptions are exemplary and not exhaustive, nor are they limited to the disclosed embodiments. Many modifications and variations will be apparent to those skilled in the art without departing from the scope and spirit of the described embodiments.
Claims
1. A method for a cross-vendor hardware platform compatible driver middleware, characterized in that, include: Power on and start the Zynq SoC, executing the BootROM; During the execution of FSBL, the PS terminal is initialized, the PL terminal is configured using the PS terminal, the supplier ID codes are stored, and the bare-metal application is loaded into DDR. The bare-metal application is executed, and the middleware is used to read the ID codes of each supplier. The middleware's dynamic adaptation engine is used to identify and map the underlying driver of the corresponding supplier. The middleware is used to call the corresponding vendor's driver to perform system initialization and low-level hardware operations.
2. The method according to claim 1, characterized in that, Upon power-on and booting the Zynq SoC, the BootROM execution includes: After the Zynq SoC is powered on, the code in the BootROM searches for header files in the off-chip non-volatile memory of the Zynq SoC, and uses the boot information defined in the header files to configure the execution of the BootROM; The startup information includes the offset address of the FSBL and whether it is a safe mode startup.
3. The method according to claim 1, characterized in that, The PS terminal is an ARM processor, and the PL terminal is programmable logic. The software code of the Zynq SoC and the BIT file for configuring the FPGA are stored in a memory connected to the PS terminal.
4. The method according to claim 1, characterized in that, The storage of each supplier's ID code includes: Through the FSBL, each supplier stores its own ID code according to the agreed vendor ID coding system, the agreed storage scheme, and the storage space; The encoding system adopts a 3-byte manufacturer ID encoding standard, where byte 1 is the manufacturer identification number, byte 2 is the hardware version number, and byte 3 is a spare code.
5. The method according to claim 4, characterized in that, The storage scheme involves storing each supplier's ID code in a fixed storage space according to a memory allocation strategy. The storage space is implemented by adding code to the FSBL to store the supplier ID encoding in memory, so that when the middleware reads the supplier ID encoding, it can dynamically adapt and call the underlying driver of each supplier. Its address is 0x1FFFFFF0~0x1FFFFFFF.
6. The method according to claim 1, characterized in that, Executing the bare-metal application involves using middleware to read the ID codes of each vendor and identifying the underlying driver of the corresponding vendor through the middleware's dynamic adaptation engine. The middleware defines a read function to read the ID codes of each supplier; The dynamic adaptation engine uses the reading function to read the supplier ID codes, thereby achieving dynamic adaptation of the driver interface.
7. The method according to claim 6, characterized in that, Executing the bare-metal application, using middleware to read the ID codes of each vendor, and identifying the underlying driver of the corresponding vendor through the middleware's dynamic adaptation engine, further includes: Define standardized driver interface functions in the middleware; Add the corresponding underlying driver interface function identification number of each vendor to the end of the standardized driver interface function name; The standardized driver interface function calls the corresponding supplier's driver interface function based on the obtained supplier ID code to realize the dynamic adaptation engine function.
8. The method according to claim 7, characterized in that, Executing the bare-metal application, using middleware to read the ID codes of each vendor, and identifying the underlying driver of the corresponding vendor through the middleware's dynamic adaptation engine, further includes: A collection is built based on the dedicated board-level support packages of each vendor; The standardized driver interface function handles conflicting functions, variables, and macro definitions in the collection and separates them according to the supplier ID code. When using the conflicting functions, variables, or macros, identification is performed based on the obtained supplier ID code.
9. An apparatus for a cross-vendor hardware platform compatible driver middleware, characterized in that, include: The power-on startup module is used to power on the Zynq SoC and execute the BootROM. The FSBL module is used to initialize the PS terminal during the FSBL execution process, configure the PL terminal using the PS terminal, store the ID codes of each supplier, and load the bare-metal application into the DDR. The dynamic adaptation module is used to execute the bare-metal application, read the ID codes of each supplier using middleware, and identify and map the underlying drivers of the corresponding suppliers through the dynamic adaptation engine of the middleware. The calling module is used to invoke the corresponding vendor's driver using the middleware to perform system initialization and low-level hardware operations.
10. The method according to claim 9, characterized in that, Executing the bare-metal application involves using middleware to read the ID codes of each vendor and identifying the underlying driver of the corresponding vendor through the middleware's dynamic adaptation engine. The middleware defines a read function to read the ID codes of each supplier; The dynamic adaptation engine is used to read the supplier ID codes through the reading function to achieve dynamic adaptation of the driver interface; Define standardized driver interface functions in the middleware; Add the corresponding underlying driver interface function identification number of each vendor to the end of the standardized driver interface function name; The standardized driver interface function calls the corresponding supplier's driver interface function based on the obtained supplier ID code to realize the dynamic adaptation engine function. A collection is built based on the dedicated board-level support packages of each vendor; The standardized driver interface function handles conflicting functions, variables, and macro definitions in the collection and separates them according to the supplier ID code. When using the conflicting functions, variables, or macros, identification is performed based on the obtained supplier ID code.