Unified NDK drive architecture with DSP supporting multiple PHYs and implementation method

Abstract

The invention relates to a unified NDK (Named Data Keying) driving architecture with a DSP (Digital Signal Processor) supporting multiple PHYs (Physical Layers) and an implementation method, and the driving architecture realizes flexible adaptation of PHY driving through a three-layer architecture comprising a basic driving layer, an extended driving library and an external driving interface; a three-level elastic framework is used, automatic identification and layered loading are achieved, all IEEE 802.3 Ethernet PHY chips are supported, and compared with a monomer solidification framework and full-manual programming adaptation in the prior art, development is simpler and more flexible, and efficiency is higher. According to the method, a DSP user can directly use the NDK library without recompiling, so that the development difficulty is reduced, and the development time and energy are saved.

Description

Technical Field

[0001] This invention belongs to the field of embedded network communication technology, and relates to a unified NDK driver architecture and implementation method for DSP supporting multiple PHYs. Background Technology

[0002] The NDK (Network Developer's Kit) is a network development toolkit for DSPs. Its core function is to provide lightweight TCP / IP protocol stack support, helping developers efficiently implement network communication on resource-constrained hardware. It provides a complete TCP / IP protocol stack, covering the link layer (such as Ethernet driver) to the application layer (HTTP, DHCP, Telnet, etc.). It supports standard Socket programming interfaces, simplifying network application development.

[0003] Ethernet PHY (Physical Layer) is a key hardware component at the lowest level (physical layer) of the OSI / RM model in computer networks. It is responsible for handling physical signal conversion, encoding, and link establishment in Ethernet communication, and is the foundation for network device connections.

[0004] The Ethernet PHY registers conform to the IEEE 802.3 standard framework, which is mandatory in IEEE 802.3. 0x00-0x0F Standard Registers, 0x10-0x1F Manufacturer Extension Registers, and 0x20 onwards is the paging extension space.

[0005] The NDK's HAL (Hardware Abstraction Layer) is responsible for managing underlying hardware resources, including access to and control of the Ethernet PHY (Physical Layer Chip). Because Ethernet PHYs come from a wide variety of manufacturers and models (such as various product lines from major manufacturers like Marvell, TI, and Realtek), and because the layout and functional definitions of extended registers differ significantly between manufacturers, serious compatibility challenges arise during development.

[0006] In actual network initialization and maintenance, key functions such as obtaining the current auto-negotiation rate and duplex mode, setting RX and TX Delays to match timing requirements, and switching paging registers all need to be implemented by accessing vendor-defined extended registers. These operations not only have different register addresses, but their bit definitions and access methods also often differ.

[0007] The most similar implementation currently is the approach of writing custom driver code for different PHY chips to meet specific project needs. In actual projects, developers may need to use multiple PHY chips such as 88E1111, RTL8211, XL52101, and YT8511, depending on different hardware platforms and network requirements. Each time a new project is developed, facing different combinations of DSP and PHY chips, developers must rewrite or modify the PHY driver code in the HAL layer of the NDK, and then rewrite the NDK itself. This highly customized development model not only greatly increases repetitive workload but also significantly increases the maintenance cost of the NDK library, severely impacting development efficiency. Every change in hardware platform or PHY chip means a large amount of driver adaptation work, leading to extended project development cycles and a waste of human resources. Summary of the Invention

[0008] To address the problems existing in the traditional methods mentioned above, this invention proposes a unified NDK driver architecture and implementation method for DSP to support multiple PHYs. This method focuses on the design of the Hardware Abstraction Layer (HAL) and the compatibility handling of PHYs from multiple manufacturers. Through a scalable driver architecture, it achieves unified support for different PHY chips, significantly improving the development efficiency and system maintainability of embedded network devices.

[0009] To achieve the above objectives, the embodiments of the present invention adopt the following technical solutions: On the one hand, a unified NDK driver architecture supporting multiple PHYs for DSPs is provided, the method including the following steps: The driver mode selection module is used to select the driver mode based on user-configured variables; the driver modes include: basic driver mode, extended driver mode, and external extended driver mode.

[0010] The basic driver module is used to reset the Ethernet PHY, read the PHYID, and set the PHY rate when the driver mode is basic driver mode, so as to realize Ethernet PHY configuration communication.

[0011] The extended driver module is used to put several extended register drivers for different PHY chips from different manufacturers into the NDK when the driver mode is extended driver mode. It automatically matches the required driver based on the Ethernet PHY chip ID. If the match is successful, it calls the preset extended driver, performs auto-negotiation, configures the delay parameters, and performs user extension. If the match fails, it sets the driver mode to the basic driver mode.

[0012] The external extension driver module is used to initialize the Ethernet PHY and complete the customized configuration when the driver mode is external extension driver mode.

[0013] A unified NDK driver implementation method for DSP supporting multiple PHYs, the method includes the following steps: Step 1: Obtain user configuration variables and determine the driver mode based on the parsing results of user configuration variables; driver modes include: basic driver mode, extended driver mode, and external extended driver mode.

[0014] Step 2: When the driver mode is the basic driver mode, reset the Ethernet PHY, read the PHY ID, set the PHY rate, and realize Ethernet PHY configuration communication.

[0015] Step 3: When the driver mode is extended driver mode, put the extended register drivers of several different PHY chips from different manufacturers into the NDK. The driver to be used is automatically matched according to the Ethernet PHY chip ID. If the match is successful, the preset extended driver is called, auto-negotiation is performed, the delay parameters are configured, and the user extension is performed. If the match fails, the driver mode is set to basic driver mode.

[0016] Step 4: When the driver mode is external extended driver mode, the NDK runs a callback function to initialize the Ethernet PHY and complete the customized configuration.

[0017] One of the above technical solutions has the following advantages and beneficial effects: The aforementioned DSP supports a unified NDK driver architecture and implementation method for multiple PHYs. This driver architecture utilizes a three-layer structure—a basic driver layer, an extended driver library, and an external driver interface—to achieve flexible PHY driver adaptation. Using a three-level flexible architecture, it automatically identifies and loads layers, supporting all IEEE 802.3 Ethernet PHY chips. Compared to existing monolithic, fixed architectures requiring entirely manual programming adaptation, development is simpler, more flexible, and more efficient. This application allows DSP users to directly use the NDK library without recompilation, reducing development difficulty and saving development time and effort. Attached Figure Description

[0018] To more clearly illustrate the technical solutions in the embodiments of this application or the conventional technology, the drawings used in the description of the embodiments or the conventional technology 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.

[0019] Figure 1 This is a schematic diagram of the technical solution for a unified NDK driver architecture that supports multiple PHYs in one embodiment. Figure 2 This is a schematic diagram of drive mode selection in one embodiment; Figure 3 Here is an extended driver flowchart in one embodiment; Figure 4 This is a schematic diagram of a unified NDK driver process for DSP supporting multiple PHYs in one embodiment. Detailed Implementation

[0020] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0021] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. The terminology used in this specification is for the purpose of describing particular embodiments only and is not intended to be limiting of the application.

[0022] It should be noted that, in this document, the reference to "embodiment" means that a particular feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment of the invention. The presentation of this phrase in various places throughout the specification does not necessarily refer to the same embodiment, nor is it a separate or alternative embodiment mutually exclusive with other embodiments. Those skilled in the art will understand that the embodiments described herein can be combined with other embodiments. The term "and / or" as used herein refers to any combination of one or more of the associated listed items, and all possible combinations, including such combinations.

[0023] This application addresses the technical problem of increased repetitive work and reduced development efficiency when developing networks using DSPs. This is due to the wide variety of selectable GMAC PHY chips and the lack of a unified standard, requiring developers to write or modify GMAC PHY configuration programs in the NDK (Network Developer's Kit) for different PHY chips. This application proposes a unified NDK driver architecture for DSPs supporting multiple PHYs. This architecture involves network driver development on the DSP platform, physical layer chip (PHY) adaptation, and lightweight protocol stack optimization techniques.

[0024] The embodiments of the present invention will now be described in detail with reference to the accompanying drawings.

[0025] In one embodiment, a unified NDK driver architecture supporting multiple PHYs for DSPs is provided, the method comprising the steps of: The driver mode selection module is used to select the driver mode based on user-configured variables; the driver modes include: basic driver mode, extended driver mode, and external extended driver mode.

[0026] Specifically, user configuration variables include the use_external flag and the use_extended flag.

[0027] When the use_external flag is enabled, the external extended driver mode is selected; when the use_extended flag is enabled, the extended driver mode is used; when neither the use_external nor the use_extended flag is enabled, the basic driver mode is used by default.

[0028] Currently, the NDK HAL layer needs to be modified each time a different Ethernet PHY chip is used, requiring either assistance in writing or custom writing of the NDK HAL layer, which significantly increases the workload. The reason for this is that there are numerous manufacturers and models of Ethernet PHYs, and the layout of their extended registers also differs. During Ethernet initialization, operations such as obtaining the currently negotiated speed and duplex mode, RX Delay, TX Delay, and paging are all contained in the manufacturer's extended registers, necessitating time and effort to match different Ethernet PHYs.

[0029] This application achieves configuration that takes effect instantly with zero compilation. Its innovation lies in variable-driven hot configuration. Specifically, it allows for real-time switching of the working mode by modifying configuration variable values ​​(without recompiling the NDK).

[0030] The unified NDK driver architecture for DSPs supporting multiple PHYs proposed in this application uses a three-layer architecture consisting of a basic driver layer (IEEE standard registers), an extended driver library (pre-built vendor drivers), and an external driver interface (callbacks). This architecture supports any PHY model without requiring development, enabling flexible PHY driver adaptation. Using a three-level flexible architecture, it automatically identifies and loads layer by layer, supporting all IEEE 802.3 Ethernet PHY chips. Compared to existing monolithic, fixed architectures requiring fully manual programming adaptation, development is simpler, more flexible, and more efficient.

[0031] The basic driver module is used to reset the Ethernet PHY, read the PHYID, and set the PHY rate when the driver mode is basic driver mode, so as to realize Ethernet PHY configuration communication.

[0032] The extended driver module is used to put several extended register drivers for different PHY chips from different manufacturers into the NDK when the driver mode is extended driver mode. It automatically matches the required driver based on the Ethernet PHY chip ID. If the match is successful, it calls the preset extended driver, performs auto-negotiation, configures the delay parameters, and performs user extension. If the match fails, it sets the driver mode to the basic driver mode.

[0033] Specifically, based on the Ethernet PHY chips used and those commonly found on the market, vendor-specific extended register drivers are written and placed in the NDK library. The required driver is automatically identified based on the Ethernet PHY chip ID. User configuration variables are defined and passed to the NDK library. When manual control of the Ethernet PHY negotiation rate is insufficient, the extended function variable is enabled, thus enabling the extended register driver and achieving automatic negotiation. The RX / TX delay variable is set to enable RX / TX delay operations. Extended configuration variables for the extended register driver are set to add more configurations (such as interrupt control, energy-saving Ethernet mode, driver strength adjustment, etc.).

[0034] The external extension driver module is used to initialize the Ethernet PHY and complete the customized configuration when the driver mode is external extension driver mode.

[0035] Specifically, when the Ethernet PHY being used does not have an extended register driver implemented in the library, a setting variable is defined and passed to the NDK library to set the use of an external driver variable. When the Ethernet PHY is initialized, the callback function implemented in the program is called to initialize it, thus achieving flexible use.

[0036] Atomized driver encapsulation is adopted to save driver development time. Specifically, there is a function pointer "int(*init)(uint8_t phy_addr)" in the user configuration variable. This function pointer accesses the corresponding PHY initialization function according to the configuration in the user configuration variable. When in use, only the init function pointer needs to be called.

[0037] The technical solution process for a unified NDK driver architecture supporting multiple PHYs in DSPs is as follows: Figure 1 As shown.

[0038] The aforementioned DSP supports a unified NDK driver architecture for multiple PHYs. This driver architecture, employing a three-layer structure—a basic driver layer, an extended driver library, and an external driver interface—achieves flexible PHY driver adaptation. Utilizing a three-level flexible architecture, it automatically identifies and loads layer by layer, supporting all IEEE 802.3 Ethernet PHY chips. Compared to existing monolithic, fixed architectures requiring entirely manual programming adaptation, development is simpler, more flexible, and more efficient. This application allows DSP users to directly use the NDK library without recompilation, reducing development difficulty and saving development time and effort.

[0039] In one embodiment, the driver mode selection module is further configured to obtain user configuration variables, parse the user configuration variables, and if the use_external flag is enabled, the driver mode is the external extended driver mode; if the use_external flag is not enabled, the enable_extended flag is parsed; if the enable_extended flag is enabled, the driver mode is the extended driver mode; if the enable_extended flag is not enabled, the driver mode is the basic driver mode.

[0040] Specifically, the drive mode selection process is as follows: Figure 2 As shown, the use_external flag determines whether an external driver is used. If an external driver is used, the Ethernet PHY initialization in the NDK library will no longer be called, and the NDK will run a callback function to initialize the Ethernet PHY. If the Ethernet PHY is initialized using the NDK library, the enable_extended flag determines whether an extended driver is used. If the base driver is used, the Ethernet PHY can be reset, the PHY ID can be read, and the PHY rate can be set.

[0041] In one embodiment, the basic driver module is also used to enforce the definition of the 0x00-0x0F standard registers using the IEEE 802.3 protocol, and to realize Ethernet PHY configuration communication by manually configuring the Ethernet negotiation rate and the MAC controller rate, obtaining the link status, resetting the PHY, and obtaining the PHY ID.

[0042] Specifically, by fully utilizing the IEEE 802.3-mandated 0x00-0x0F standard registers (basic control, status, PHY ID, etc.), the Ethernet negotiation rate and MAC controller rate can be manually configured, the link status can be obtained, the PHY can be reset, and the PHY ID can be obtained, thus enabling Ethernet PHY configuration communication. This can be applied to any IEEE 802.3 compatible PHY on the market, allowing a single program to be adapted to all PHYs. However, the drawback is that the Ethernet PHY negotiation rate can only be manually set and cannot be auto-negotiated. Auto-negotiating requires the use of manufacturer-extended registers to obtain the Ethernet negotiation rate, thereby configuring the MAC controller rate.

[0043] In one embodiment, the extended driver module is further configured to, when the driver mode is extended driver mode: check whether it is auto-negotiation; if it is not auto-negotiation, manually set the Ethernet PHY rate; if it is auto-negotiation, wait for automatic negotiation to complete; if negotiation fails, switch to manually setting the Ethernet PHY rate; if negotiation succeeds, obtain the actual Ethernet PHY rate and configure the RX / TX delay variables; configure the MAC controller according to the manually set Ethernet PHY rate or the actual Ethernet PHY rate; enable the TX / RX delay operation according to the TX / RX delay variables, set the extended register driver extended configuration variables, enable ext_params if advanced configuration needs to be added, complete the extended parameter callback function, and perform advanced configuration.

[0044] Specifically, the extended driver process is as follows: Figure 3 As shown, if using an extended driver, first check if auto-negotiation is enabled. If not, use manual setting. If auto-negotiation is enabled, wait for it to complete. If negotiation fails, switch to manual setting of the Ethernet PHY rate. After auto-negotiation or manual setting of the rate, configure the MAC rate and set the TX / RX delay based on the TX / RX delay variables. If advanced configuration is required, enable ext_params, complete the extended parameter callback function, and perform advanced configuration.

[0045] Non-intrusive extensions are achieved through ext_params, eliminating the need to recompile the NDK, and the failure of the extension will not affect the underlying driver.

[0046] No need to rewrite the NDK; simple addition, deletion, and customization of extended code; no need to modify the NDK source code with existing technologies; and no need to debug and test the NDK, which greatly reduces development time.

[0047] In one embodiment, the extended driver module is further configured to set extended register driver extended configuration variables to add interrupt control, energy-saving Ethernet mode, and drive strength adjustment configurations.

[0048] In one embodiment, such as Figure 4 As shown, a unified NDK driver implementation method for DSP supporting multiple PHYs is provided, which includes the following steps: Step 1: Obtain user configuration variables and determine the driver mode based on the parsing results of user configuration variables; driver modes include: basic driver mode, extended driver mode, and external extended driver mode.

[0049] Step 2: When the driver mode is the basic driver mode, reset the Ethernet PHY, read the PHY ID, set the PHY rate, and realize Ethernet PHY configuration communication.

[0050] Step 3: When the driver mode is extended driver mode, put the extended register drivers of several different PHY chips from different manufacturers into the NDK. The driver to be used is automatically matched according to the Ethernet PHY chip ID. If the match is successful, the preset extended driver is called, auto-negotiation is performed, the delay parameters are configured, and the user extension is performed. If the match fails, the driver mode is set to basic driver mode.

[0051] Step 4: When the driver mode is external extended driver mode, the NDK runs a callback function to initialize the Ethernet PHY and complete the customized configuration.

[0052] In one embodiment, step 1 specifically includes: obtaining user configuration variables and parsing the user configuration variables; if the use_external flag is enabled, the driving mode is the external extended driving mode. If the use_external flag is not enabled, the enable_extended flag is resolved. If the enable_extended flag is enabled, the driver mode is extended driver mode; if the enable_extended flag is not enabled, the driver mode is basic driver mode.

[0053] In one embodiment, step 2 specifically includes: when the driving mode is the basic driving mode, the IEEE 802.3 protocol is used to forcibly define the 0x00-0x0F standard registers, and Ethernet PHY configuration communication is realized by manually configuring the Ethernet negotiation rate and the MAC controller rate, obtaining the link status, resetting the PHY, and obtaining the PHY ID.

[0054] In one embodiment, step 3 specifically includes: when the driver mode is extended driver mode: checking whether it is auto-negotiation; if it is not auto-negotiation, manually setting the Ethernet PHY rate; if it is auto-negotiation, waiting for automatic negotiation to complete; if negotiation fails, switching to manually setting the Ethernet PHY rate; if negotiation succeeds, obtaining the actual Ethernet PHY rate and configuring the RX / TX delay variables; configuring the MAC controller according to the manually set Ethernet PHY rate or the actual Ethernet PHY rate; enabling the TX / RX delay operation according to the TX / RX delay variables, setting the extended register driver extended configuration variables; if advanced configuration needs to be added, enabling ext_params, completing the extended parameter callback function, and performing advanced configuration.

[0055] In one embodiment, an extended register driver extended configuration variable is set to add interrupt control, power-saving Ethernet mode, and drive strength adjustment configuration.

[0056] It should be understood that, although the above process Figure 4The steps are shown sequentially as indicated by the arrows, but these steps are not necessarily executed in the order indicated by the arrows. Unless otherwise explicitly stated in this document, there is no strict order in which these steps are executed; they can be performed in other orders. Furthermore, the above... Figure 4 At least some of the steps may include multiple sub-steps or multiple stages. These sub-steps or stages are not necessarily executed at the same time, but can be executed at different times. The execution order of these sub-steps or stages is not necessarily sequential, but can be executed in turn or alternately with other steps or at least some of the sub-steps or stages of other steps.

[0057] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0058] The above embodiments are merely illustrative of several implementation methods of this application, and their descriptions are relatively specific and detailed. However, they should not be construed as limiting the scope of protection of this application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and all such modifications and improvements fall within the scope of protection of this application.

Claims

1. A unified NDK driver architecture for DSP supporting multiple PHYs, characterized in that, Including the following steps: The driver mode selection module is used to select the driver mode according to user configuration variables; the driver modes include: basic driver mode, extended driver mode, and external extended driver mode. The basic driver module is used to reset the Ethernet PHY, read the PHY ID, and set the PHY rate to realize Ethernet PHY configuration communication when the driver mode is basic driver mode. The extended driver module is used to put several extended register drivers for different PHY chips from different manufacturers into the NDK when the driver mode is extended driver mode. It automatically matches the required driver based on the Ethernet PHY chip ID. If the match is successful, it calls the preset extended driver, performs auto-negotiation, configures the delay parameters, and performs user extension. If the match fails, it sets the driver mode to the basic driver mode. The external extension driver module is used to initialize the Ethernet PHY and complete the customized configuration when the driver mode is external extension driver mode.

2. The unified NDK driver architecture for DSP supporting multiple PHYs according to claim 1, characterized in that, The driver mode selection module is further configured to obtain user configuration variables, parse the user configuration variables, and if the use_external flag is enabled, the driver mode is the external extended driver mode; if the use_external flag is not enabled, the enable_extended flag is parsed; if the enable_extended flag is enabled, the driver mode is the extended driver mode; if the enable_extended flag is not enabled, the driver mode is the basic driver mode.

3. The unified NDK driver architecture for DSP supporting multiple PHYs according to claim 1, characterized in that, The basic driver module is also used to force the definition of the 0x00-0x0F standard registers using the IEEE 802.3 protocol, and to realize Ethernet PHY configuration communication by manually configuring the Ethernet negotiation rate and the MAC controller rate, obtaining the link status, resetting the PHY, and obtaining the PHY ID.

4. The unified NDK driver architecture for DSP supporting multiple PHYs according to claim 1, characterized in that, The extended driver module is also used to: check whether it is auto-negotiation when the driver mode is extended driver mode; if it is not auto-negotiation, manually set the Ethernet PHY rate; if it is auto-negotiation, wait for automatic negotiation to complete; if negotiation fails, switch to manually setting the Ethernet PHY rate; if negotiation succeeds, obtain the actual Ethernet PHY rate and configure the RX / TX delay variables; configure the MAC controller according to the manually set Ethernet PHY rate or the actual Ethernet PHY rate; enable TX / RX delay operation according to the TX / RX delay variables; set the extended register driver extended configuration variables; if advanced configuration needs to be added, enable ext_params, complete the extended parameter callback function, and perform advanced configuration.

5. The unified NDK driver architecture for DSP supporting multiple PHYs according to claim 1, characterized in that, The extended driver module is also used to set extended register driver extended configuration variables, which are used to add interrupt control, energy-saving Ethernet mode and drive strength adjustment configuration.

6. A unified NDK driver implementation method for DSP supporting multiple PHYs, characterized in that, Including the following steps: Step 1: Obtain user configuration variables and determine the driving mode based on the parsing results of the user configuration variables; the driving mode includes: basic driving mode, extended driving mode, and external extended driving mode. Step 2: When the driver mode is the basic driver mode, reset the Ethernet PHY, read the PHY ID, set the PHY rate, and realize Ethernet PHY configuration communication; Step 3: When the driver mode is extended driver mode, put the extended register drivers of several different PHY chips written into the NDK. The driver to be used is automatically matched according to the Ethernet PHY chip ID. If the match is successful, the preset extended driver is called, auto-negotiation is performed, the delay parameters are configured, and the user extension is performed. If the match fails, the driver mode is set to basic driver mode. Step 4: When the driver mode is external extended driver mode, the NDK runs a callback function to initialize the Ethernet PHY and complete the customized configuration.

7. The unified NDK driver implementation method for DSP supporting multiple PHYs according to claim 6, characterized in that, Step 1 specifically includes: Obtain user configuration variables and parse the user configuration variables; If the use_external flag is enabled, the driving mode is external extended driving mode; If the use_external flag is not enabled, the enable_extended flag is resolved. If the enable_extended flag is enabled, the driver mode is extended driver mode; if the enable_extended flag is not enabled, the driver mode is basic driver mode.

8. The unified NDK driver architecture for DSP supporting multiple PHYs according to claim 6, characterized in that, Step 2 specifically includes: When the driver mode is the basic driver mode, the IEEE 802.3 protocol is used to forcibly define the 0x00-0x0F standard registers. Ethernet PHY configuration communication is achieved by manually configuring the Ethernet negotiation rate and the MAC controller rate, obtaining the link status, resetting the PHY, and obtaining the PHYID.

9. The unified NDK driver architecture for DSP supporting multiple PHYs according to claim 6, characterized in that, Step 3 specifically includes: When the driver mode is extended driver mode: Check if it is a self-negotiation; If it is not auto-negotiation, then manually set the Ethernet PHY rate; If it is auto-negotiation, wait for the auto-negotiation to complete. If the negotiation fails, switch to manually setting the Ethernet PHY rate. If the negotiation succeeds, obtain the actual Ethernet PHY rate and configure the RX / TX delay variables. Configure the MAC controller based on the manually set Ethernet PHY rate or the actual Ethernet PHY rate; enable TX / RX delay operation based on TX / RX delay variables, set extended register driver extended configuration variables, and enable ext_params to add advanced configuration if needed, complete the extended parameter callback function, and perform advanced configuration.

10. The unified NDK driver architecture for DSP supporting multiple PHYs according to claim 6, characterized in that, Configure extended register driver extended configuration variables to add interrupt control, power-saving Ethernet mode, and drive strength adjustment configurations.

Images