Vehicle-mounted cascade network self-adaption method, device and equipment and storage medium

Abstract

The invention discloses a vehicle-mounted cascade network self-adaption method, device and equipment and a storage medium, and is applied to the field of automotive electronics, and the method comprises the steps: generating a hybrid drive based on a kernel PHY framework; the hybrid drive comprises control logics corresponding to various PHY chip identification codes; performing kernel configuration and device tree configuration on the hybrid drive; and when the kernel is started, analyzing the device tree to obtain the configuration information, calling the hybrid drive to configure the target PHY device according to the configuration information, and performing corresponding configuration on the switch. The hybrid drive created by the invention can be compatible with different PHY chips and interface modes. Based on existing drive development, the workload is small, and the difficulty is low; the method does not depend on additional hardware configuration, such as hardware version numbers, so that the number of PHY chip models is not limited, and the application range is wide; when the PHY chip is newly added or replaced, only part of codes in the hybrid drive need to be changed, kernel configuration and device tree configuration do not need to be changed, and the modification range is small.

Description

Technical Field

[0001] The present invention relates to the field of automotive electronics, and in particular to a vehicle-mounted cascade network self-adaptation method, device, equipment and storage medium. Background Art

[0002] After the product is released, the production and after-sales support cycle is very long. During this process, there may be shortages of chips or components, production suspensions, etc., which may lead to the need to replace materials. In an in-vehicle cascade network architecture such as SOC-SWITCH-PHY-gateway, the PHY chip model will change, and the interface mode between PHY and SWITCH may also change. Therefore, this requires the software to be able to support both PHY chips A and B at the same time, and also to support the SWITCH port to automatically configure the mode. At present, the compatibility of different PHY chips is generally achieved through hardware version numbers. This solution has a strong dependence on hardware design and is not suitable for all scenarios. In terms of software, there are many logical patches to the driver code, and the cost of subsequent upgrades and maintenance is relatively high.

[0003] Therefore, how to improve the versatility of PHY chip compatibility solutions, reduce hardware design dependencies, and simplify driver code maintenance to reduce upgrade costs are issues that need to be urgently addressed. Summary of the Invention

[0004] In view of this, the purpose of the present invention is to provide a vehicle-mounted cascade network adaptation method, device, equipment and storage medium, which solves the problems in the prior art of the strong dependence of PHY chip compatibility solutions on hardware design, as well as the complex and high cost of driver code maintenance.

[0005] To solve the above technical problems, the present invention provides a vehicle-mounted cascade network adaptation method, comprising:

[0006] Generate a hybrid driver based on the core PHY framework; the hybrid driver includes control logic corresponding to multiple PHY chip identification codes;

[0007] Performing kernel configuration and device tree configuration on the hybrid driver;

[0008] When the kernel starts, the device tree is parsed to obtain configuration information, and the hybrid driver is called according to the configuration information to configure the target PHY device and to configure the switch accordingly.

[0009] Optionally, generate a hybrid driver based on the kernel PHY framework, including:

[0010] defining identification codes of multiple PHY chips, and generating the control logic for each PHY chip according to the identification codes;

[0011] A device support list and a driver name for the hybrid driver are defined; the device support list includes an identification code for each of the PHY chips.

[0012] Optionally, before performing kernel configuration and device tree configuration on the hybrid driver, the method further includes:

[0013] In the compilation configuration file, the compilation order of the driver code of the hybrid driver is placed last.

[0014] Optionally, performing kernel configuration and device tree configuration on the hybrid driver includes:

[0015] Enable the compilation option of the hybrid driver in the kernel configuration file;

[0016] A PHY device node is defined under the MDIO node in the device tree; in the definition code of the device tree node, a compatibility attribute is defined as the hybrid driver, and a physical layer mode attribute is defined as the hybrid interface mode;

[0017] The physical layer mode attribute is defined as hybrid interface mode in the switch node of the device tree and associated with the PHY device node.

[0018] Optionally, when the kernel starts, parsing the device tree to obtain configuration information, calling the hybrid driver according to the configuration information to configure the target PHY device, and configuring the switch accordingly, including:

[0019] Parsing the device tree to obtain the PHY device address and physical layer mode attributes;

[0020] When the physical layer mode attribute is a hybrid interface mode, the hybrid driver is called according to the PHY device address and the hybrid interface mode attribute to configure the target PHY device, and the switch is configured accordingly.

[0021] Optionally, when the physical layer mode attribute is a hybrid interface mode, calling the hybrid driver to configure the target PHY device according to the PHY device address and the hybrid interface mode attribute, and configuring the switch accordingly, includes:

[0022] Determine the target PHY device according to the PHY device address;

[0023] Reading an identification code register of a target PHY chip associated with the target PHY device via the MDIO bus to obtain a target identification code;

[0024] Match the device support list corresponding to each driver according to the target identification code and the matching priority to determine the target driver;

[0025] When the target drive is the hybrid drive, calling the hybrid drive to execute the control logic corresponding to the target identification code;

[0026] Read the configuration pin register of the target PHY chip to obtain the actual PHY interface mode;

[0027] The interface mode of the switch is dynamically configured according to the hybrid interface mode and the PHY actual interface mode.

[0028] Optionally, dynamically configuring the interface mode of the switch according to the hybrid interface mode and the PHY actual interface mode includes:

[0029] When the actual interface mode of the PHY is RGMII mode, the interface mode of the switch is configured as RGMII mode;

[0030] If the actual interface mode of the PHY is the RMII mode, the interface mode of the switch is configured as the RMII mode.

[0031] The present invention also provides a vehicle-mounted cascade network adaptive device, comprising:

[0032] A driver creation module is used to generate a hybrid driver based on the core PHY framework; the hybrid driver includes control logic corresponding to multiple PHY chip identification codes;

[0033] A driver configuration module, configured to perform kernel configuration and device tree configuration on the hybrid driver;

[0034] The driver calling module is used to parse the device tree to obtain configuration information when the kernel starts, call the hybrid driver to configure the target PHY device according to the configuration information, and configure the target PHY device.

[0035] The present invention also provides a vehicle-mounted cascade network adaptive device, comprising:

[0036] Memory for storing computer programs;

[0037] A processor is used to implement the above-mentioned vehicle-mounted cascade network adaptation method when executing the computer program.

[0038] The present invention also provides a computer-readable storage medium, in which computer-executable instructions are stored. When the computer-executable instructions are loaded and executed by a processor, the above-mentioned vehicle-mounted cascade network adaptation method is implemented.

[0039] It can be seen that the present invention generates a hybrid driver based on the kernel PHY framework; the hybrid driver contains control logic corresponding to multiple PHY chip identification codes; the kernel configuration and device tree configuration are performed on the hybrid driver; when the kernel starts, the device tree is parsed to obtain configuration information, and the hybrid driver is called according to the configuration information to configure the target PHY device, and the switch is configured accordingly. The present invention creates a hybrid driver based on the identification codes and corresponding control logic of various PHY chips, and the hybrid driver is compatible with different PHY chips and interface modes. In addition, the hybrid driver is developed based on the existing driver, with a small workload and low difficulty; and does not rely on additional hardware configurations, such as hardware version numbers, so the hybrid driver has no restrictions on the number of compatible PHY chip models and has a wider range of applications; and when adding or replacing a PHY chip, only part of the code in the hybrid driver needs to be changed, the modification scope is small, and the subsequent maintenance cost is low.

[0040] In addition, the present invention also provides a vehicle-mounted cascade network adaptive device, equipment and storage medium, which also have the above-mentioned beneficial effects. BRIEF DESCRIPTION OF THE DRAWINGS

[0041] In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the following briefly introduces the drawings required for use in the embodiments or the description of the prior art. Obviously, the drawings described below are merely embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on the provided drawings without paying any creative work.

[0042] Figure 1 A flow chart of a vehicle-mounted cascade network adaptive method provided by an embodiment of the present invention;

[0043] Figure 2 An example diagram of an old hardware network architecture provided by an embodiment of the present invention;

[0044] Figure 3 An example diagram of a new hardware network architecture provided by an embodiment of the present invention;

[0045] Figure 4 A schematic structural diagram of a vehicle-mounted cascade network adaptive device provided by an embodiment of the present invention;

[0046] Figure 5 A schematic structural diagram of a vehicle-mounted cascade network adaptive device provided by an embodiment of the present invention. DETAILED DESCRIPTION

[0047] To make the objectives, technical solutions, and advantages of the embodiments of the present invention more clear, the technical solutions in the embodiments of the present invention will be clearly and completely described below in conjunction with the accompanying drawings in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without making creative efforts shall fall within the scope of protection of the present invention.

[0048] First, several terms involved in this invention are explained:

[0049] PHY (Physical Layer): The physical layer chip is called a PHY chip, or simply PHY. In automotive Ethernet, it acts as a signal base station, converting digital signals into signals suitable for transmission on physical media, and performing encoding and decoding.

[0050] CAN stands for Controller Area Network. In automotive applications, the CAN bus is primarily used to connect devices such as engine control units, sensors, and instrument panels, enabling low-speed data transmission. It is characterized by high reliability, strong anti-interference capabilities, and low cost.

[0051] CAN FD: CAN with Flexible Data Rate, Controller Area Network with Flexible Data Rate. It is an upgraded version of the CAN bus, designed to address the data transmission rate and bandwidth issues of the traditional CAN bus.

[0052] MOST: Media Oriented Systems Transport. It is a high-speed serial communication network designed for in-vehicle multimedia applications.

[0053] The on-board switching chip is a core component of the on-board network system. It is mainly used to realize data exchange and transmission between different devices in the vehicle. It is similar to a "traffic hub" in the network, ensuring that data flows efficiently and orderly between nodes.

[0054] OTA: Over-the-Air Technology, which is air download technology, updates the local software system from the cloud through the in-vehicle network.

[0055] A switch is a network interconnection device whose core function is to identify the destination address of data frames and efficiently forward data from the source port to the destination port, enabling high-speed communication between multiple devices within a local area network. In this example, the switch is an Ethernet switch.

[0056] SOC: System on a Chip. It refers to the integration of multiple functional modules on a single chip to form a complete system.

[0057] RGMII: Reduced Gigabit Media Independent Interface, an interface standard for high-speed Ethernet communication, mainly used to connect Ethernet physical layer (PHY) devices and data link layer (MAC) devices.

[0058] RMII: Reduced Media Independent Interface, an interface standard for high-speed Ethernet communication, mainly used to connect Ethernet physical layer (PHY) devices and data link layer (MAC) devices.

[0059] Linux kernel: The Linux kernel is the core component of the Linux operating system. It is responsible for managing hardware resources (such as CPU, memory, and peripherals), providing low-level functions such as process scheduling, file system management, network communication, and device drivers. It is the bridge connecting hardware and upper-level applications.

[0060] phylink: A mechanism that supports hot-plugging of network modules that are connected directly to the MAC without reinitializing the adapter on hot-plug events.

[0061] With the advancement of automotive technology, particularly in the ADAS (Advanced Driving Assistance System) sector, the addition of sensors such as onboard cameras, LiDAR, and millimeter-wave radar has resulted in a massive amount of data being sensed, far exceeding the carrying capacity of traditional networks such as CAN (500 kbit / s), CAN FD (2 Mbit / s), and MOST (150 Mbit / s). This has necessitated the emergence of in-vehicle Ethernet. To meet the high-bandwidth data demands of in-vehicle networks, in-vehicle switching chips are typically used to expand network interfaces. After product release, production and after-sales support cycles are lengthy. During this process, chip or component shortages and production halts may occur, necessitating material replacements. For example, a 2024 release may use PHY chip A, corresponding to software version 1.0. In 2025, PHY chip B may be replaced, corresponding to software version 2.0. Since vehicles can upgrade software version 1.0 to 2.0 via over-the-air (OTA) technology, the new software version 2.0 must support both chips A and B.

[0062] In a cascaded network architecture such as SOC-SWITCH-PHY-gateway, not only the PHY chip model will change, but also the interface mode between the PHY chip and the SWITCH may change. Figure 2 and Figure 3 As shown, Figure 2 and Figure 3 The following are example diagrams of two types of hardware network architecture, new and old. Figure 2 For example, a typical cascade network topology in a domain controller is described: the MAIN Domain of the SOC is connected to port 0 of the ethernet switch, and the interface mode is through RGMII; the MCU Domain of the system-level chip is connected to port 1 of the ethernet switch, and the interface mode is through RGMII; the PHY chip A is connected to port 2 of the ethernet switch, and the interface mode is through RMII; the AI ​​processor of the SOC is connected to port 3 of the ethernet switch, and the interface mode is through RGMII; all network data packets sent out by the SOC are first sent to the ethernet switch, and then forwarded through port 2 of the ethernet switch, and finally transmitted to the vehicle gateway through the PHY chip A, and the gateway forwards the data. Figure 2 and Figure 3 It can be seen that there are the following differences between the new and old hardware, as shown in Table 1.

[0063] Table 1 Hardware differences between new and old models

[0064]

[0065] Currently, because devices equipped with different PHY chips have different hardware version numbers, they are generally distinguished by hardware version numbers in the driver, so that different control logic is executed to achieve compatibility. This method of relying on hardware version numbers to achieve compatibility has certain defects. (1) In terms of hardware: a. If there is no version number design on the hardware when the product is first launched, the above solution is not applicable because the hardware version number cannot be read on the hardware. b. Due to the scarcity of hardware resources, the version numbers that can be reserved in the design are limited. The hardware version number is generally represented by a combination of multiple GPIO (input and output port) pins. The value of each GPIO is 0 or 1, and the combination of 3 GPIOs can represent the range of 0 to 7. If the number of hardware version changes exceeds the version number representation range, the hardware outside the range does not have the correct version number, and the version number is equivalent to failure, then the above solution is not applicable. Therefore, it has certain limitations. (2) In terms of software: a. The configuration in the Linux kernel device tree may be inconsistent with the actual configuration, which can easily mislead development and maintenance personnel. For example, the switch port mode is specified as phy-mode="rmii" in the device tree, but when running on hardware version HW2.0, the driver actually configures it to use RGMII. This is because only one switch port mode can be specified in the device tree. b. Changing the PHY chip requires multiple logic modifications in the driver code based on the hardware version. These modifications must be merged when upgrading the driver to the new version, increasing upgrade and maintenance costs. Furthermore, sometimes it's necessary to forcibly modify the driver code. For example, c. Parsing the device tree yields phy-mode="rmii", but the current hardware version is HW2.0 and includes PHY chip B, whose phy-mode should be RGMII. In this case, the driver code must forcibly change the phy-mode to RGMII based on the hardware version to initialize the switch in RGMII mode. d. Parse the phy-handle property in the device tree to obtain the corresponding phy device. The phy-handle property defines two phy devices: phy-handle=<&main_cpsw_phy0&main_cpsw_phy1>. At this time, you need to forcibly specify the phy-handle as either main_cpsw_phy0 or main_cpsw_phy1 in the driver code according to the hardware version number.

[0066] Therefore, the current solution of making different PHY chips compatible by hardware version number has a strong dependence on hardware design and is not suitable for all scenarios; the software requires many logical patches to the driver code, and the cost of subsequent upgrades and maintenance is relatively high. In order to solve the above problems, the present invention provides a vehicle-mounted cascade network adaptive method, specifically referring to Figure 1 . Figure 1 A flowchart of a vehicle-mounted cascade network adaptation method provided by an embodiment of the present invention. The method may include:

[0067] S101: Generate a hybrid driver based on the core PHY framework; the hybrid driver includes control logic corresponding to multiple PHY chip identification codes.

[0068] The execution entity of this embodiment is a terminal. This embodiment does not limit the terminal type; any terminal capable of performing the in-vehicle cascade network adaptation method is sufficient. The PHY chip identification code, or PHY ID, is the unique identifier (ID) of the PHY chip. Essentially, it is a set of binary data stored in the PHY chip registers, following the format defined by a specific protocol (such as IEEE 802.3). At the hardware level, the identification code is typically accessed through the MDIO (Management Data Input / Output) interface. To achieve compatibility between PHY chip A and PHY chip B, the hybrid driver code should include the identification codes for both chips, as well as control logic written based on the different identification codes. This control logic performs different processing based on the different identification codes. Specifically, if the identification code is for PHY chip A, the detection logic for PHY chip A in the existing driver is invoked; if the identification code is for PHY chip B, the detection logic for PHY chip B in the existing driver is invoked.

[0069] This embodiment is based on the Linux kernel's PHY framework (drivers / net / phy / directory), and writes hybrid driver code based on the existing chip driver to generate a new driver. The newly generated driver in this embodiment is used to uniformly provide support for different types of PHY chips.

[0070] Furthermore, the above-mentioned generation of hybrid drivers based on the kernel PHY framework may specifically include: defining identification codes of multiple PHY chips, and generating control logic for each PHY chip according to the identification code; defining a device support list and driver name for the hybrid driver; and including the identification code of each PHY chip in the device support list.

[0071] It should be noted that each driver will have a corresponding device support list. The device support list of the hybrid driver in this embodiment contains identification codes of multiple different types of PHY chips to match the hybrid driver. The hybrid driver also includes operations such as detection, initialization, and removal, and can call existing driver code based on the PHY identification code. Of course, the hybrid driver can also include some other callback functions. The specific code of the hybrid driver phy_mixed is as follows:

[0072] #define PHY_ID_A 0x12345678 / / PHY chip A identification code;

[0073] #define PHY_ID_B 0x87654321 / / Identification code of PHY chip B;

[0074] static int phy_mixed_probe(struct phy_device *phydev)

[0075] {

[0076] switch (phydev->phy_id) { / / Do different processing according to the PHY identification code;

[0077] case PHY_ID_A: / / If it is the identification code of PHY chip A;

[0078] / / Call the detection logic of PHY chip A in the existing driver;

[0079] Break;

[0080] case PHY_ID_B: / / If it is the identification code of PHY chip B;

[0081] / / Call the detection logic of PHY chip B in the existing driver;

[0082] Break;

[0083] default: / / If it is not the above identification code;

[0084] return –ENODEV; / / return error;

[0085] }

[0086] return 0; / / Return success.

[0087] }

[0088] / / The following defines various properties of the mixed driver phy_mixed;

[0089] static struct phy_driver phy_mixed_driver = {

[0090] .phy_id = PHY_ID_A | PHY_ID_B, / / Device support list;

[0091] .phy_id_mask = 0xFFFFFFFF, / / phy identification code mask. Assuming the read PHY identification code is C, perform an AND operation on C and 0xFFFFFFFF, which is equivalent to taking only the lower 32 bits of the number C, and then matching it with the device support list;

[0092] .name = "phy-mixed", / / Driver name;

[0093] .probe =phy_mixed_probe, / / Default probe (detection) interface, allocates and requests the required system resources for the device, performs hardware initialization, etc.;

[0094] / / You can add other callback functions as needed, such as remove, suspend, resume, etc.;

[0095] };

[0096] module_phy_driver(phy_mixed_driver); / / Register the mixed driver into the kernel.

[0097] Furthermore, before performing kernel configuration and device tree configuration on the hybrid driver, the process may further include placing the compilation order of the driver code corresponding to the hybrid driver at the end in the compilation configuration file.

[0098] It should be noted that when there are multiple drivers, this embodiment gives the highest priority to the hybrid driver. The specific operation is: in the makefile (compilation file), add compilation support for the corresponding code of the hybrid driver. Put phy-mixed at the end and register phy-mixed later, so that the priority of the hybrid driver is set to the highest priority, so that the hybrid driver can be matched first in the chip matching target driver stage. The principle is: putting phy-mixed at the end of the Makefile will make it compiled later in the linking order, resulting in it being executed after the initialization function and finally registered with the kernel. Since the kernel matches drivers in reverse order of registration, phy-mixed will be detected first, thereby achieving the effect of "priority matching". This mechanism is designed by the Linux kernel to support dynamic expansion of drivers, and the indirect association with the compilation order is the key to achieving this goal.

[0099] The specific code is as follows:

[0100] obj-$(CONFIG_CHIPA_PHY)+=CHIPA.o / / If CONFIG_CHIPA_PHY is enabled in the Linux kernel config, compile the chip Ac code and enable support for chip A at the code level;

[0101] obj-$(CONFIG_chipB_PHY)+=chipBo / / If chip B_PHY is enabled in the Linux kernel config, compile the chip Bc code and enable chip B support at the code level;

[0102] obj-$(CONFIG_MIXED_PHY)+= phy-mixed.o / / If CONFIG_MIXED_PHY is enabled in the Linux kernel config, compile the phy-mixed.c code to enable phy-mixed support at the code level.

[0103] S102: Perform kernel configuration and device tree configuration on the hybrid driver.

[0104] After generating a new driver (i.e., a hybrid driver), you need to compile it into the kernel through Linux Kernel Config (i.e., kernel configuration, configuring kernel compilation options), thereby enabling the hybrid driver. During kernel configuration, configuration items are modified, which affect device tree parsing and driver initialization parameters. Furthermore, the kernel configuration also requires device tree support (CONFIG_OF), so device tree configuration is also required.

[0105] Furthermore, the hybrid driver is configured in the kernel and the device tree, which may specifically include: enabling the compilation option of the hybrid driver in the kernel configuration file; defining the PHY device node under the MDIO node in the device tree; defining the compatibility attribute as a hybrid driver and the physical layer mode attribute as a hybrid interface mode in the definition code of the device tree node; defining the physical layer mode attribute as a hybrid interface mode in the switch node of the device tree and associating the PHY device node.

[0106] Specifically, modify the .config file to add or enable the hybrid driver configuration option. Once this configuration option is enabled, the hybrid driver code in step S101 is compiled into the kernel, and the driver takes effect. Generally, system software accesses the PHY chip through MDIO (Management Data Input / Output). Therefore, define a PHY device node under the MDIO node in the device tree. In the definition code for the device tree node, define the compatibility attribute as a hybrid driver and the physical layer mode attribute as a hybrid interface mode. The specific code is as follows:

[0107] &main_cpsw_mdio { / / reference the existing MDIO bus node;

[0108] main_cpsw_phy0:ethernet-phy@1{ / / Node label, used to be referenced by other phy-handles; node name, @1 indicates that the address of the PHY device on the MDIO bus is 1;

[0109] compatible="dummy,phy-mixed","ethernet-phy-ieee802.3-c22"; / / The custom compatible string is for mixed driver, which is just for description and has no practical effect;

[0110] reg= <1> ; / / The address of the PHY device on the MDIO bus. The MDIO driver communicates with the PHY through this address.

[0111] phy-mode="mii-mixed"; / / Customize the PHY interface mode to mixed mode;

[0112] };

[0113] }.

[0114] In the device tree, define the physical layer mode property as hybrid interface mode and associate it with the above PHY device node. The specific code for the switch device tree configuration is as follows:

[0115] ports{ / / Switch port collection node;

[0116] port@2{ / / Port 2 of the switch;

[0117] label="phy"; / / Port label, used to identify the port connected to the PHY device;

[0118] phy-mode="mii-mixed"; / / Customize the PHY interface mode to mixed mode;

[0119] phy-handle=<&main_cpsw_phy0>; / / Bind this port to the PHY device main_cpsw_phy0 (i.e., the PHY at MDIO address 1). The driver associates the switch port with the configuration of the PHY device through this binding relationship.

[0120] reg= <2> ;

[0121] }.

[0122] S103: When the kernel starts, the device tree is parsed to obtain configuration information, and the hybrid driver is called according to the configuration information to configure the target PHY device and to configure the switch accordingly.

[0123] When the kernel starts, it parses the device tree to obtain the configuration information of the PHY chip and switch. This configuration information will be used by the Linux kernel to correctly initialize and configure the PHY device (i.e., PHY device).

[0124] Furthermore, when the kernel starts, the device tree is parsed to obtain configuration information, and the hybrid driver is called according to the configuration information to configure the target PHY device, and the switch is configured accordingly. The following steps may be included: parsing the device tree to obtain the PHY device address and physical layer mode attributes; when the physical layer mode attribute is a hybrid interface mode, the hybrid driver is called according to the PHY device address and the hybrid interface mode attribute to configure the target PHY device, and the switch is configured accordingly.

[0125] Specifically, the phy-mode attribute (i.e., the physical layer mode attribute) in the device tree is parsed to obtain the interface mode. If the physical layer mode attribute is mii-mixed (mixed interface mode), it indicates that the PHY interface mode is not clearly defined. The phy-handle attribute in the device tree (used to associate the PHY device with the switch) is parsed to obtain the corresponding PHYdevice. Further parsing determines the PHY device address. Based on the PHY device address and the mixed interface mode attribute, the hybrid driver is called to configure the PHY device.

[0126] Furthermore, when the physical layer mode attribute is the hybrid interface mode, the hybrid driver is called according to the PHY device address and the hybrid interface mode attribute to configure the target PHY device and configure the switch accordingly, which may specifically include:

[0127] Determine the target PHY device based on the PHY device address; read the identification code register of the target PHY chip associated with the target PHY device through the MDIO bus to obtain the target identification code; match the device support list corresponding to each driver based on the target identification code and matching priority to determine the target driver; when the target driver is a hybrid driver, call the hybrid driver to execute the control logic corresponding to the target identification code; read the configuration pin register of the target PHY chip to obtain the actual PHY interface mode; dynamically configure the interface mode of the switch based on the hybrid interface mode and the actual PHY interface mode.

[0128] It should be noted that the target PHY device and the target PHY chip are different expressions of the same object, and they are in a corresponding relationship. The PHY chip is a physical entity, the PHY device is a software abstraction, and the device tree node is the configuration bridge between the two.

[0129] Specifically, based on the configuration of main_cpsw_mdio in the device tree, the ID register (i.e., identification code register) of the PHY chip at phy address 1 is accessed via the MDIO bus to obtain the PHY chip's identification code (i.e., target identification code). If multiple drivers exist, all registered drivers can be traversed based on the target identification code, and the read target identification code can be used to match the device support list in each driver. Matching can be performed based on matching priority. Specifically, this embodiment sets the matching priority of the hybrid driver to the highest priority. Therefore, a match is performed first with the hybrid driver's device support list. Because the hybrid driver contains the identification codes of each PHY chip, a successful match is guaranteed. That is, whether the hardware chip is PHY chip A or PHY chip B, it can match the hybrid driver phy-mixed. The hybrid driver is then associated with the PHY chip, and a corresponding PHY device is created. If a match is successful, the driver code of the hybrid driver can be called. The hybrid driver contains the control logic corresponding to each PHY identification code. Therefore, the control logic of the corresponding PHY chip in the hybrid driver can be executed based on the target identification code. In other words, this embodiment determines the driving PHY chip based on the identification code.

[0130] Furthermore, this embodiment also obtains the actual configuration mode of the current hardware PHY interface by reading the target PHY chip's strap pin register (configuration pin register) and storing it in the mode variable of the PHY device structure. Based on the actual configuration mode of the PHY interface, the corresponding switch driver dynamically sets the interface mode of the switch port. Specifically, the switch initializes its own port according to the mode specified by the phy-mode attribute (i.e., the actual configuration mode of the PHY interface) and configures and manages the PHY device specified by the phy-handle attribute through the phylink mechanism. It should be noted that the strap pin is set during hardware design and varies across different PHY chips and modes.

[0131] Furthermore, dynamically configuring the interface mode of the switch according to the hybrid interface mode and the actual PHY interface mode may specifically include: when the actual PHY interface mode is RGMII mode, configuring the interface mode of the switch to RGMII mode; if the actual PHY interface mode is RMII mode, configuring the interface mode of the switch to RMII mode.

[0132] For example, if the actual interface mode of the PHY chip is RGMII, the switch port must be configured as RGMII accordingly; if the actual interface mode of the PHY chip is RMII, the switch port must be configured as RMII accordingly; if the actual interface mode of the PHY chip is RGMII-rxid, the switch port must be configured as RGMII-rxid accordingly.

[0133] The vehicle-mounted cascade network adaptation method provided by the embodiment of the present invention is applied to generate a hybrid driver based on the kernel PHY framework; the hybrid driver contains control logic corresponding to multiple PHY chip identification codes; the kernel configuration and device tree configuration are performed on the hybrid driver; when the kernel starts, the device tree is parsed to obtain configuration information, and the hybrid driver is called according to the configuration information to configure the target PHY device, and the switch is configured accordingly. The hybrid driver created by the present invention is compatible with different PHY chips and interface modes. It is developed based on existing drivers, with low workload and low difficulty; and it does not rely on additional hardware configurations, such as hardware version numbers, so there is no limit on the number of PHY chip models, and the application range is wide; when adding or replacing a PHY chip, only part of the code in the hybrid driver needs to be changed, and the kernel configuration and device tree configuration do not need to be changed, so the scope of modification is small.

[0134] The following introduces a vehicle-mounted cascade network adaptive device provided by an embodiment of the present invention. The vehicle-mounted cascade network adaptive device described below and the vehicle-mounted cascade network adaptive method described above can refer to each other.

[0135] Please refer to Figure 4 , Figure 4 A schematic structural diagram of a vehicle-mounted cascade network adaptive device provided in an embodiment of the present invention may include:

[0136] The driver creation module 100 is used to generate a hybrid driver based on the core PHY framework; the hybrid driver includes control logic corresponding to multiple PHY chip identification codes;

[0137] A driver configuration module 200 is used to perform kernel configuration and device tree configuration on the hybrid driver;

[0138] The driver calling module 300 is used to parse the device tree to obtain configuration information when the kernel starts, and call the hybrid driver according to the configuration information to configure the target PHY device and configure the switch accordingly.

[0139] Based on the above embodiment, the driver creation module 100 may include:

[0140] a first defining unit, configured to define identification codes of multiple PHY chips and generate the control logic for each PHY chip according to the identification codes;

[0141] The second definition unit is used to define a device support list and a driver name for the hybrid driver; the device support list includes an identification code of each of the PHY chips.

[0142] Based on the above embodiment, the vehicle-mounted cascade network adaptive device may further include:

[0143] The sequence determination module is used to place the compilation sequence of the driver code of the hybrid driver at the end in the compilation configuration file.

[0144] Based on the above embodiment, the drive configuration module 200 may include:

[0145] A configuration unit, configured to enable a compilation option of the hybrid driver in a kernel configuration file;

[0146] A third definition unit is configured to define a PHY device node under the MDIO node in the device tree; in the definition code of the device tree node, define the compatibility attribute as the hybrid driver and define the physical layer mode attribute as the hybrid interface mode;

[0147] The fourth defining unit is configured to define a physical layer mode attribute as a hybrid interface mode in the device tree switch node and associate the physical layer mode attribute with the PHY device node.

[0148] Based on the above embodiment, the driver calling module 300 may include:

[0149] A parsing unit, configured to parse the device tree to obtain a PHY device address and a physical layer mode attribute;

[0150] The calling unit is configured to call the hybrid driver to configure the target PHY device according to the PHY device address and the hybrid interface mode attribute when the physical layer mode attribute is the hybrid interface mode, and to configure the switch accordingly.

[0151] Based on the above embodiment, the calling unit may include:

[0152] a target device determining subunit, configured to determine the target PHY device according to the PHY device address;

[0153] a target identification code determination subunit, configured to read an identification code register of a target PHY chip associated with the target PHY device via an MDIO bus to obtain a target identification code;

[0154] a target driver determination subunit, configured to match the device support list corresponding to each driver according to the target identification code and the matching priority, and determine the target driver;

[0155] a calling subunit, configured to, when the target drive is the hybrid drive, call the hybrid drive to execute the control logic corresponding to the target identification code;

[0156] The actual interface mode acquisition subunit is used to read the configuration pin register of the target PHY chip to obtain the actual interface mode of the PHY;

[0157] The switch interface configuration subunit is configured to dynamically configure the interface mode of the switch according to the hybrid interface mode and the PHY actual interface mode.

[0158] Based on the above embodiment, the switch interface configuration subunit may include:

[0159] A first configuration subunit, configured to configure the interface mode of the switch to RGMII mode when the actual interface mode of the PHY is RGMII mode;

[0160] The second configuration subunit is configured to configure the interface mode of the switch to the RMII mode if the actual interface mode of the PHY is the RMII mode.

[0161] It should be noted that the order of the modules and units in the above-mentioned vehicle-mounted cascade network adaptive device can be changed without affecting the logic.

[0162] The vehicle-mounted cascade network adaptive device provided by the embodiment of the present invention is used to generate a hybrid driver based on the kernel PHY framework through a driver creation module 100; the hybrid driver contains control logic corresponding to multiple PHY chip identification codes; the driver configuration module 200 is used to perform kernel configuration and device tree configuration on the hybrid driver; the driver call module 300 is used to parse the device tree to obtain configuration information when the kernel starts, and call the hybrid driver according to the configuration information to configure the target PHY device, and configure the switch accordingly. The hybrid driver created by this device is compatible with different PHY chips and interface modes. Based on the existing driver development, the workload is small and the difficulty is low; and it does not rely on additional hardware configuration, such as hardware version number, so there is no limit on the number of PHY chip models, and the application range is wide; when adding or replacing a PHY chip, only part of the code in the hybrid driver needs to be changed, and the kernel configuration and device tree configuration do not need to be changed, and the modification scope is small.

[0163] The following introduces a vehicle-mounted cascade network adaptive device provided by an embodiment of the present invention. The vehicle-mounted cascade network adaptive device described below and the vehicle-mounted cascade network adaptive method described above can refer to each other.

[0164] Please refer to Figure 5 , Figure 5 A schematic structural diagram of a vehicle-mounted cascade network adaptive device provided in an embodiment of the present invention may include:

[0165] Memory 10, for storing computer programs;

[0166] The processor 20 is configured to execute a computer program to implement the above-mentioned vehicle-mounted cascade network adaptation method.

[0167] The memory 10 , the processor 20 , and the communication interface 31 all communicate with each other via the communication bus 32 .

[0168] In the embodiment of the present invention, the memory 10 is used to store one or more programs. The program may include program code, and the program code includes computer operation instructions. In the embodiment of the present invention, the memory 10 may store programs for implementing the following functions:

[0169] Generates hybrid drivers based on the core PHY framework; the hybrid drivers contain control logic corresponding to multiple PHY chip identification codes;

[0170] Perform kernel configuration and device tree configuration for hybrid drivers;

[0171] When the kernel starts, it parses the device tree to obtain configuration information, calls the hybrid driver according to the configuration information to configure the target PHY device, and configures the switch accordingly.

[0172] In one possible implementation, the memory 10 may include a program storage area and a data storage area, wherein the program storage area may store an operating system and applications required for at least one function, etc.; the data storage area may store data created during use.

[0173] In addition, the memory 10 may include a read-only memory and a random access memory, and provides instructions and data to the processor. A portion of the memory may also include NVRAM. The memory stores an operating system and operating instructions, executable modules or data structures, or a subset or an extended set thereof. The operating instructions may include various operating instructions for implementing various operations. The operating system may include various system programs for implementing various basic tasks and processing hardware-based tasks.

[0174] The processor 20 may be a central processing unit (CPU), an application-specific integrated circuit, a digital signal processor, a field programmable gate array, or other programmable logic device. The processor 20 may be a microprocessor or any conventional processor. The processor 20 may call a program stored in the memory 10 .

[0175] The communication interface 31 may be an interface of a communication module, used for connecting to other devices or systems.

[0176] Of course, it needs to be explained that Figure 5 The structure shown does not constitute a limitation on the vehicle-mounted cascade network adaptive device in the embodiment of the present invention. In actual applications, the vehicle-mounted cascade network adaptive device may include Figure 5 More or fewer components than shown, or combinations of certain components.

[0177] The computer-readable storage medium provided by an embodiment of the present invention is introduced below. The computer-readable storage medium described below and the vehicle-mounted cascade network adaptation method described above can be referenced to each other.

[0178] The present invention also provides a computer-readable storage medium having a computer program stored thereon. When the computer program is executed by a processor, the steps of the above-mentioned vehicle-mounted cascade network self-adaptation method are implemented.

[0179] The computer-readable storage medium may include: a USB flash drive, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk, etc., which can store program codes.

[0180] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on its differences from the other embodiments. Reference can be made to the descriptions of the identical or similar parts between the various embodiments. For the devices disclosed in the embodiments, since they correspond to the methods disclosed in the embodiments, the descriptions are relatively simple, and the relevant parts can be referred to the descriptions of the methods.

[0181] Professionals may further appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of the two. In order to clearly illustrate the interchangeability of hardware and software, the above description has generally described the components and steps of each example according to their functions. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professionals and technicians may use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of the present invention.

[0182] Finally, it should be noted that, in this document, relationships such as first and second, etc., are used solely to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any actual relationship or order between these entities or operations. Moreover, the terms "comprises," "comprising," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that includes a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article, or apparatus.

[0183] The above is a detailed introduction to the vehicle-mounted cascade network adaptation method, device, equipment and computer-readable storage medium provided by the present invention. Specific examples are used herein to illustrate the principles and implementation methods of the present invention. The description of the above embodiments is only used to help understand the method of the present invention and its core ideas. At the same time, for those skilled in the art, according to the ideas of the present invention, there may be changes in the specific implementation methods and application scopes. In summary, the content of this specification should not be understood as limiting the present invention.

Claims

1. A vehicle-mounted cascade network adaptive method, characterized in that: include: Generate a hybrid driver based on the core PHY framework; the hybrid driver includes control logic corresponding to multiple PHY chip identification codes; Performing kernel configuration and device tree configuration on the hybrid driver; When the kernel starts, the device tree is parsed to obtain configuration information, and the hybrid driver is called according to the configuration information to configure the target PHY device and to configure the switch accordingly.

2. The vehicle-mounted cascade network adaptive method according to claim 1, characterized in that: Generate hybrid drivers based on the kernel PHY framework, including: defining identification codes of multiple PHY chips, and generating the control logic for each PHY chip according to the identification codes; A device support list and a driver name for the hybrid driver are defined; the device support list includes an identification code for each of the PHY chips.

3. The vehicle-mounted cascade network adaptive method according to claim 1, characterized in that: Before performing kernel configuration and device tree configuration on the hybrid driver, the following steps are also included: In the compilation configuration file, the compilation order of the driver code of the hybrid driver is placed last.

4. The vehicle-mounted cascade network adaptive method according to claim 1, characterized in that: Perform kernel configuration and device tree configuration on the hybrid driver, including: Enable the compilation option of the hybrid driver in the kernel configuration file; A PHY device node is defined under the MDIO node in the device tree; in the definition code of the device tree node, a compatibility attribute is defined as the hybrid driver, and a physical layer mode attribute is defined as the hybrid interface mode; The physical layer mode attribute is defined as hybrid interface mode in the switch node of the device tree and associated with the PHY device node.

5. The vehicle-mounted cascade network adaptive method according to claim 1, characterized in that: When the kernel starts, the device tree is parsed to obtain configuration information, and the hybrid driver is called according to the configuration information to configure the target PHY device and the switch, including: Parsing the device tree to obtain the PHY device address and physical layer mode attributes; When the physical layer mode attribute is a hybrid interface mode, the hybrid driver is called according to the PHY device address and the hybrid interface mode attribute to configure the target PHY device, and the switch is configured accordingly.

6. The vehicle-mounted cascade network adaptive method according to claim 5, characterized in that: When the physical layer mode attribute is a hybrid interface mode, calling the hybrid driver to configure the target PHY device according to the PHY device address and the hybrid interface mode attribute, and configuring the switch accordingly, including: Determine the target PHY device according to the PHY device address; Reading an identification code register of a target PHY chip associated with the target PHY device via the MDIO bus to obtain a target identification code; Match the device support list corresponding to each driver according to the target identification code and the matching priority to determine the target driver; When the target drive is the hybrid drive, calling the hybrid drive to execute the control logic corresponding to the target identification code; Read the configuration pin register of the target PHY chip to obtain the actual PHY interface mode; The interface mode of the switch is dynamically configured according to the hybrid interface mode and the PHY actual interface mode.

7. The vehicle-mounted cascade network adaptive method according to claim 6, characterized in that: Dynamically configuring the interface mode of the switch according to the hybrid interface mode and the PHY actual interface mode includes: When the actual interface mode of the PHY is RGMII mode, the interface mode of the switch is configured as RGMII mode; If the actual interface mode of the PHY is the RMII mode, the interface mode of the switch is configured as the RMII mode.

8. A vehicle-mounted cascade network adaptive device, characterized in that: include: A driver creation module is used to generate a hybrid driver based on the core PHY framework; the hybrid driver includes control logic corresponding to multiple PHY chip identification codes; A driver configuration module, configured to perform kernel configuration and device tree configuration on the hybrid driver; The driver calling module is used to parse the device tree to obtain configuration information when the kernel starts, call the hybrid driver according to the configuration information to configure the target PHY device, and configure the switch accordingly.

9. A vehicle-mounted cascade network adaptive device, characterized in that: include: Memory for storing computer programs; A processor, configured to implement the vehicle-mounted cascade network adaptation method according to any one of claims 1 to 7 when executing the computer program.

10. A computer-readable storage medium, characterized in that The computer-readable storage medium stores computer-executable instructions, and when the computer-executable instructions are loaded and executed by the processor, the vehicle-mounted cascade network adaptation method according to any one of claims 1 to 7 is implemented.

Images