Repeater equipment test method and device, electronic device and storage medium

Abstract

The invention relates to a repeater equipment testing method and device, an electronic device and a storage medium, and the method comprises the steps: starting a loading program, reading the equipment information of to-be-tested repeater equipment, and determining a target equipment tree file in a preset storage area according to the equipment information; the target device tree file is arranged in system firmware; the target device tree file is used for describing hardware configuration of the embedded system; analyzing the target device tree file to obtain compatibility attributes of the to-be-tested repeater device; and starting the embedded system, and loading an equipment driving function corresponding to the compatibility attribute so as to test the to-be-tested repeater equipment. According to the invention, the problem that the compatibility of product systems of different items corresponding to the same SOC system needs to be improved when equipment testing is carried out on the repeater equipment is solved.

Description

Technical Field

[0001] The present application relates to the field of electronic equipment testing, and in particular to a repeater equipment testing method, device, electronic device and storage medium. Background Art

[0002] At present, the equipment of the repeater system includes many models. Different models need to invest time to develop the underlying firmware of the equipment. Due to the different requirements of different equipment models and the different underlying firmware required by the projects, the testing resources also need to be invested in the corresponding projects, resulting in serious duplication of tests for the same SOC system (System on Chip), which leads to a waste of resources. Therefore, the compatibility of the same SOC product system of different projects needs to be improved when testing the repeater equipment.

[0003] With regard to the problem in the related art that the compatibility of product systems of different projects of the same SOC system needs to be improved when testing repeater equipment, no effective solution has been proposed yet. Summary of the invention

[0004] In this embodiment, a method, device, electronic device and storage medium for testing a repeater device are provided to solve the problem in the related art that the compatibility of product systems of different projects corresponding to the same SOC system needs to be improved when testing repeater devices.

[0005] In a first aspect, a repeater device testing method is provided in this embodiment, which is applied to an embedded system, and the method includes:

[0006] Start the loader and read the device information of the repeater device to be tested, and determine the target device tree file in the preset storage area according to the device information; the target device tree file is set in the system firmware; the target device tree file is used to describe the hardware configuration of the embedded system;

[0007] Parsing the target device tree file to obtain the compatibility attribute of the repeater device to be tested;

[0008] The embedded system is started, and the device driver function corresponding to the compatibility attribute is loaded to implement the test of the repeater device to be tested.

[0009] In some of the embodiments, before the startup loader and reading the device information of the repeater device to be tested, the method further includes:

[0010] In response to multiple device function requirements of different projects, determining driver information according to the device function requirements, and storing the driver information in the device tree file;

[0011] According to a preset package format, the device tree file, the preset root file system and the kernel image file are packaged according to a preset system startup format to obtain the system firmware;

[0012] The system firmware is stored in the preset storage area.

[0013] In some embodiments, storing the driver information in a device tree file includes:

[0014] According to a preset verification algorithm, detecting whether the driving information is complete;

[0015] If the driver information is complete, storing the driver information in the device tree file;

[0016] If the driver information is incomplete, the backup data corresponding to the driver information is obtained, and the backup data is stored in the device tree file.

[0017] In some embodiments, determining a target device tree file in a preset storage area according to the device information includes:

[0018] Read the system firmware to obtain the device model in the device information;

[0019] Matching device node data corresponding to the device model in the storage area;

[0020] Determine device tree data according to the device node data, and perform format verification on the device tree data;

[0021] When the device tree data passes the format check, a target device tree file including the device tree data is loaded.

[0022] In some embodiments, parsing the target device tree file includes:

[0023] Parsing the target device tree file to determine the clock information corresponding to the repeater device to be tested; the clock information includes clock accuracy and clock frequency;

[0024] According to the clock accuracy and the clock frequency, a clock profile is matched; and the compatibility attribute includes different clock profiles.

[0025] In some embodiments, parsing the target device tree file to obtain the compatibility attribute of the repeater device to be tested further includes:

[0026] Parsing the target device tree file to obtain custom hard core information;

[0027] Determining a target initialization logic according to the custom hard core information; the compatibility attributes include different target initialization logics;

[0028] According to the target initialization logic, the device of the customized hard core information is registered.

[0029] In some embodiments, the method further comprises:

[0030] Obtaining a device type of a device to be detected; the target device tree file includes multiple physical network cards;

[0031] A target physical network card among the multiple physical network cards is enabled according to the device type.

[0032] In a second aspect, a repeater equipment testing device is provided in this embodiment, the device comprising: a loading module, a parsing module and a testing module;

[0033] The loading module is used to start the loading program and read the device information of the repeater device to be tested, and determine the target device tree file in the preset storage area according to the device information; the target device tree file is set in the system firmware; the target device tree file is used to describe the hardware configuration of the embedded system;

[0034] The parsing module is used to parse the target device tree file to obtain the compatibility attribute of the repeater device to be tested;

[0035] The test module is used to start the embedded system and load the device driver function corresponding to the compatibility attribute to implement the test of the repeater device to be tested.

[0036] In a third aspect, an electronic device is provided in this embodiment, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor implements the repeater equipment testing method described in the first aspect when executing the computer program.

[0037] In a fourth aspect, a storage medium is provided in this embodiment, on which a computer program is stored, and when the program is executed by a processor, the method for testing the repeater equipment described in the first aspect is implemented.

[0038] Compared with the related art, a repeater equipment testing method, device, electronic device and storage medium provided in this embodiment reads the repeater equipment model information, loads the corresponding device tree file, starts the kernel to parse the device tree, and finally performs device driving to achieve compatibility testing of different repeater equipment to be tested based on the same SOC system, thereby meeting the different functional requirements of different models of equipment.

[0039] Details of one or more embodiments of the present application are set forth in the following drawings and description to make other features, objects, and advantages of the present application more readily apparent. BRIEF DESCRIPTION OF THE DRAWINGS

[0040] The drawings described herein are used to provide a further understanding of the present application and constitute a part of the present application. The illustrative embodiments of the present application and their descriptions are used to explain the present application and do not constitute an improper limitation on the present application. In the drawings:

[0041] Figure 1 It is a hardware structure block diagram of a terminal of the repeater equipment testing method provided in an embodiment of the present application;

[0042] Figure 2 It is a schematic diagram of the composition of the system firmware of the repeater equipment in the prior art;

[0043] Figure 3 is a flow chart of a repeater equipment testing method provided in an embodiment of the present application;

[0044] Figure 4 is a schematic diagram of the system firmware provided in this specific embodiment;

[0045] Figure 5 is a flowchart of system startup provided by this specific embodiment;

[0046] Figure 6 It is a structural block diagram of the repeater equipment testing device provided in the embodiment of the present application. DETAILED DESCRIPTION

[0047] In order to more clearly understand the purpose, technical solutions and advantages of the present application, the present application is described and illustrated below in conjunction with the accompanying drawings and embodiments.

[0048] Unless otherwise defined, the technical terms or scientific terms involved in this application shall have the general meaning understood by people with ordinary skills in the technical field to which this application belongs. The words "one", "a", "a", "the", "these" and the like in this application do not represent quantitative restrictions, and they can be singular or plural. The terms "include", "comprise", "have" and any variants thereof involved in this application are intended to cover non-exclusive inclusions; for example, a process, method and system, product or device comprising a series of steps or modules (units) is not limited to the listed steps or modules (units), but may include unlisted steps or modules (units), or may include other steps or modules (units) inherent to these processes, methods, products or devices. The words "connect", "connected", "coupled" and the like involved in this application are not limited to physical or mechanical connections, but may include electrical connections, whether directly or indirectly. The "multiple" involved in this application refers to two or more. "And / or" describes the association relationship of associated objects, indicating that there can be three relationships. For example, "A and / or B" can mean: A exists alone, A and B exist at the same time, and B exists alone. Usually, the character " / " indicates that the objects associated with each other are in an "or" relationship. The terms "first", "second", "third", etc. involved in this application are only used to distinguish similar objects and do not represent a specific ordering of the objects.

[0049] The method embodiment provided in this embodiment can be executed in a terminal, a computer or a similar computing device. For example, running on a terminal, Figure 1 1 is a hardware structure diagram of a terminal of a repeater device testing method provided in an embodiment of the present application. Figure 1 As shown, the terminal may include one or more ( Figure 1 Only one is shown in the figure) processor 102 and memory 104 for storing data, wherein processor 102 may include but is not limited to a processing device such as a microprocessor MCU or a programmable logic device FPGA. The above terminal may also include a transmission device 106 and an input and output device 108 for communication functions. It can be understood by those skilled in the art that Figure 1 The structure shown is only for illustration and does not limit the structure of the above terminal. Figure 1 More or fewer components as shown, or with Figure 1 Different configurations shown.

[0050] The memory 104 can be used to store computer programs, for example, software programs and modules of application software, such as the computer program corresponding to the repeater equipment testing method in this embodiment. The processor 102 executes various functional applications and data processing by running the computer program stored in the memory 104, that is, to implement the above method. The memory 104 may include a high-speed random access memory, and may also include a non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some examples, the memory 104 may further include a memory remotely arranged relative to the processor 102, and these remote memories may be connected to the terminal via a network. Examples of the above network include, but are not limited to, the Internet, an intranet, a local area network, a mobile communication network, and combinations thereof.

[0051] The transmission device 106 is used to receive or send data via a network. The above network includes a wireless network provided by the communication provider of the terminal. In one example, the transmission device 106 includes a network adapter (Network Interface Controller, referred to as NIC), which can be connected to other network devices through a base station so as to communicate with the Internet. In one example, the transmission device 106 can be a radio frequency (Radio Frequency, referred to as RF) module, which is used to communicate with the Internet wirelessly.

[0052] Therefore, when two-way communication is carried out between the base station and different mobile stations, different repeater equipment is required for communication. The repeater is composed of antenna, RF duplexer, low noise amplifier, mixer, electrically adjustable attenuator, filter, power amplifier and other components or modules, including uplink and downlink amplification links. The basic principle of its operation is: the downlink signal of the base station is received into the repeater by the forward antenna (donor antenna), the useful signal is amplified by the low noise amplifier, the noise signal in the signal is suppressed, and the signal-to-noise ratio (S / N) is improved; then it is down-converted to the intermediate frequency signal, filtered by the filter, amplified by the intermediate frequency, and then up-converted to the radio frequency by frequency shifting, amplified by the power amplifier, and transmitted to the mobile station by the backward antenna (retransmission antenna); at the same time, the uplink signal of the mobile station is received by the backward antenna, and processed by the uplink amplification link along the opposite path: that is, it is transmitted to the base station through the low noise amplifier, down converter, filter, intermediate amplifier, up converter, power amplifier. Thus, two-way communication between the base station and the mobile station is achieved.

[0053] However, different types of repeater equipment need to invest the same amount of time to develop the underlying firmware, and testing resources need to be invested in the corresponding projects, resulting in low management efficiency for different types of repeater equipment. The same SOC system has a serious waste of resources due to repeated testing. Moreover, often due to material replacement and the addition of safety mechanisms, each model needs to be modified and then tested repeatedly, which consumes a lot of R&D and testing resources. Figure 2 This is a schematic diagram of the system firmware of a repeater device in the prior art. Figure 2 , the system firmware-image.ub of the existing repeater equipment includes: device tree-system.dtb, root system file roofts.cpio.gz and kernel image-image.gz. However, due to the different project requirements of different types of equipment, the required Linux bottom layer is also different, that is, the system firmware is not universal. Furthermore, different system firmware will affect the version management of external devices, and will greatly increase the project development cycle and personnel efficiency, resulting in a waste of resources. At the same time, once platform issues are involved, all projects need to update the underlying firmware version. Often the same iterative product baseline is based on the same SOC, such as the ZU67 core. Therefore, it is necessary to solve the problem of product system compatibility of different projects based on the same SOC system.

[0054] In this embodiment, a test method for a repeater device is provided, which solves the compatibility problem of product systems of the same SOC in different projects and provides a unified external system firmware version. Figure 3 Flow chart of the repeater equipment testing method provided in the embodiment of the present application. Figure 3 As shown, the process includes the following steps:

[0055] Step S310, start the loader and read the device information of the repeater device to be tested, and determine the target device tree file in the preset storage area according to the device information; the target device tree file is set in the system firmware; the target device tree file is used to describe the hardware configuration of the embedded system.

[0056] In this step, after starting the loader, the repeater device to be tested is run, and the device information of the repeater device to be tested is obtained at this time. The device information here includes the device model of the repeater device and the test task information of the device; the device information is stored in the end partition of the flash storage corresponding to the repeater device. Thereafter, the target device tree file is determined in the preset storage area according to the device information of the repeater device to be tested. It can be understood that the preset storage area has a plurality of device tree files corresponding to the device information pre-stored, and the repeater device to be tested determines the target device tree file in the system firmware required for the test according to its own device information. Further, the device tree is a mechanism for describing hardware devices and system configurations, and the function of the device tree is to describe the hardware resources of a hardware platform. By determining the target device tree file according to different repeater devices to be tested, it is beneficial to improve the compatibility and flexibility of the system.

[0057] Furthermore, before starting the loader and reading the device information of the repeater device to be tested, it is necessary to: respond to multiple device function requirements of different projects, determine the driver information according to the device function requirements, and store the driver information in the device tree file; according to the preset package format, package the device tree file, the preset root file system and the kernel image file according to the preset system startup format to obtain the system firmware; store the system firmware in the preset storage area.

[0058] In some embodiments, storing the driver information in the device tree file includes: detecting whether the driver information is complete according to a preset verification algorithm; if the driver information is complete, storing the driver information in the device tree file; if the driver information is incomplete, obtaining backup data corresponding to the driver information, and storing the backup data in the device tree file. Exemplarily, the verification algorithms preset here include: cyclic redundancy check algorithm, hash algorithm, Hamming code, etc.

[0059] Specifically, according to the device function requirements of different repeater devices for different projects, and according to the device function requirements, the driver information relied on is determined, and the driver information is stored in the device tree file corresponding to the device to be tested. Thereafter, according to the preset packaging method, the description information of the device tree file corresponding to the repeater device to be tested, the corresponding dtb file information and the data type are packaged. Thereafter, the device tree file, the preset root file system and the kernel image file are packaged according to the preset system startup format to obtain the system firmware, and the system firmware is stored in the preset storage area, so as to determine the corresponding target device tree information in the preset storage area according to the device information later.

[0060] Step S320, parsing the target device tree file to obtain the compatibility attributes of the repeater device to be tested.

[0061] In this embodiment, after obtaining the target device tree file, the target device tree file is loaded and parsed. The loading of the target device tree file specifically includes: reading the system firmware to obtain the device model in the device information; matching the device node data corresponding to the device model in the storage area; determining the device tree data according to the device node data, and performing format verification on the device tree data; when the device tree data passes the format verification, loading the target device tree file including the device tree data.

[0062] Exemplarily, the format check is used to ensure that the read device tree data is usable. Once the device node data cannot be matched or the device tree data is damaged, it is regarded as system firmware damage. At this time, the system firmware backup is used to load the device tree file.

[0063] Afterwards, the kernel is started, and the device tree file is parsed from a flat structure into a structure used inside the kernel through a specific function in the kernel, such as the unflatten_device_tree function. The device tree file classifies device features by function, so that the device can load functions accordingly as required. In addition, the target device tree file is parsed to obtain the compatibility attributes of the repeater device to be tested, including hard-core devices and clock configurations.

[0064] Step S330, starting the embedded system and loading the device driver function corresponding to the compatibility attribute to implement the test of the repeater device to be tested.

[0065] In this step, after starting the corresponding embedded system, the device driver function corresponding to the compatibility attribute is determined, and then the corresponding driver module is loaded to implement the functional application corresponding to the driver module, thereby realizing the detection of the device to be detected.

[0066] Through the above steps, since different projects have different functional requirements, these functional requirements rely on different driver information, and these driver information are uniformly placed in the device tree file. After starting the repeater device to be tested, read the device information of the repeater device to be tested, and load the system firmware from the storage area, and select the corresponding target device tree file in the system firmware to be loaded according to the device information. Thereafter, load and parse the target device tree file corresponding to the repeater device to be tested, and obtain the compatibility attributes including hard core information and clock information in the device tree file, as well as the corresponding device driver function. After starting the embedded system, load the device driver function to implement the relevant functional application to complete the detection of the device to be detected. By reading the device model information, loading the corresponding device tree file, and starting the kernel to parse the device tree, and finally performing the device driver, the compatibility test of different repeater devices to be tested based on the same SOC system is realized, which meets the different functional requirements of different models of devices.

[0067] In some of the embodiments, parsing the target device tree file includes: parsing the target device tree file to determine the clock information corresponding to the repeater device to be tested; the clock information includes clock accuracy and clock frequency; matching the clock configuration file according to the clock accuracy and clock frequency; the compatibility attributes include different clock configuration files.

[0068] In this step, each model needs to output a clock configuration file specifically, and the FPGA relies on the clock when loading and running, so the clock needs to be loaded before the kernel loads the FPGA. In the prior art, a uboot startup program is separately issued for each device, which contains the clock configuration program and files required for a specific model. However, in order to achieve compatibility effects, this application divides the system clock configuration file according to clock accuracy and clock frequency, so that different device models are adapted according to different clock information in different target device tree files, which is conducive to improving the test compatibility of different devices in the same SOC system.

[0069] In some of the embodiments, parsing the target device tree file to obtain the compatibility attributes of the repeater device to be tested also includes: parsing the target device tree file to obtain custom hard core information; determining the target initialization logic based on the custom hard core information; the compatibility attributes include different target initialization logics; and registering the device with the custom hard core information based on the target initialization logic.

[0070] In this step, the custom hard core information generally includes custom FPGA hard core information. Different hard core information corresponds to different registration methods of initialization logic. Therefore, it is necessary to determine different hard core information according to the target device tree files of different repeater devices to be tested, and then register the hard core devices, so that different models can adaptively register hard core devices according to the initialization logic, which is conducive to improving the compatibility of different repeater devices based on the same SOC system.

[0071] In some of the embodiments, the repeater device testing method further includes: obtaining a device type of the device to be tested; the target device tree file includes multiple physical network cards; and enabling a target physical network card among the multiple physical network cards according to the device type.

[0072] In this step, since the device under test is a repeater device, there are currently multiple designs for the universal public radio interface of repeater devices. Therefore, different repeater devices have different physical network card enabling requirements. Therefore, different physical network cards are divided in the device tree file according to different interface functions, so that the physical network cards to be enabled are determined according to the device type of different repeater devices, which is conducive to improving the compatibility of the same SOC system with different repeater devices.

[0073] The present embodiment is described and illustrated by means of specific examples below.

[0074] Figure 4 is a schematic diagram of the system firmware provided in this specific embodiment. Figure 4 , the system firmware provided in this embodiment includes: device tree files-a.system.dtb, b.system.dtb, c.system.dtb, d.system.dtb, kernel image-image.gz, root file system-rootfs.cpio.gz. The device tree files here include multiple, namely device a, device b, device c and device d, which correspond to the device tree files of different device models respectively, and are specifically determined according to the functional requirements of different repeater devices. The composition of the system firmware is: in the configuration item configurations item in the format file Its file used to describe and configure the startup process of the embedded system, the device tree file information of each model is added in turn.

[0075] For example, the code for adding device tree information is as follows:

[0076]

[0077]

[0078] Among them, a_system.dtb indicates the retrieval key value corresponding to device a, Description indicates the information describing the device tree; data is the actual device tree dtb file, type indicates the data type; arch indicates the Linux platform on which the device tree depends; compression indicates whether it is compressed, and if compressed, it indicates the specific compression method.

[0079] Furthermore, the mkimage command is used to package the image kernel, rootfs and device tree in the Its file format to form the final system firmware. The specific implementation command is: mkimage-f kernel.itsimage.ub.

[0080] Figure 5 is a flowchart of the system startup provided in this specific embodiment, such as Figure 5As shown in FIG. 1 , the system startup process includes the following steps: First, control the FSBL (First Stage Boot Loader) to start. FSBL is a key component in the startup process of the embedded system, responsible for the initialization of the CPU and basic peripherals. One of the main tasks of FSBL is to load the second-stage boot loader (such as U-Boot) from the non-volatile memory (such as NOR / NAND flash memory, eMMC or SD card) to the RAM and hand over the control to it. Afterwards, load UBOOT to read the device model information through the Equipment partition, load the system firmware package from the flash storage, and obtain the dtb device tree file corresponding to the specified model of the repeater device to be tested from the firmware package header. Afterwards, load the device tree, start the kernel, and then parse the device tree. Load the corresponding device drivers according to the compatible in the device tree. Specifically, first perform the corresponding clock configuration according to the clock information, then parse the hard core information related to the FPGA, and register the hard core device. When the embedded system is running, the upper layer application of the corresponding model of the repeater equipment is pulled up, and the corresponding driver module is loaded to realize the corresponding functional application.

[0081] Specifically, different projects have different functional requirements. The driver information that these functional requirements rely on is uniformly placed in the DTB device tree. When the repeater device is running, choose to load the corresponding device tree file according to the model requirements. Different model information is placed in the Equipment partition at the end of the device flash storage (i.e. the repeater device location). Relevant driver information, including IIC, ETHERNET, DMA, GPIO and other drivers, are set into the kernel and loaded according to the detailed information in the device tree. The driver module can be put into the project package and brought into the repeater device. The corresponding hard core space information and control interface information of the programmable FPGA are placed in the device tree file. When the kernel starts to parse the device tree file, the corresponding function is loaded.

[0082] When reading the device model information, the Uboot program runs, reads the Equipment partition into the memory, and extracts the model information contained therein. The specific implementation is as follows: the data burned into the Equipment partition is a 64-byte structure data, including magic number, CRC (Cyclic Redundancy Check) of the structure data, model information, delivery time information, etc. Then read the data in the flash memory (or other eerom) into the memory, first check the magic number, and then check the data CRC after the check passes. When the above magic number and CRC are both successfully checked, read the device model information; if the check fails, directly read the Equipment data in the backup area to perform the above check operation.

[0083] When loading the device tree file, the Uboot program reads the data of the system firmware partition into the memory, retrieves the device tree file of the specified model through the model information, and loads it. The specific implementation is: read the system firmware stored in the flash memory into the memory; assuming that the device model is a, then the device tree of this model is a_system.dtb, and this is used as the key value to match the configurations item in the system firmware and find the a_system.dtb node; through the dtb node data, get the data, compression, type and other information; perform format verification on the data data through type to ensure that the read data data is available. Once the key value does not match or the data data is damaged, it is regarded as a damaged system firmware, and the system firmware backup is used to load the device tree with the same logic.

[0084] When the kernel is started and the device tree is parsed, the unflatten_device_tree function is used in the kernel to parse the device tree, parsing the device tree from a flat structure into a structure used inside the kernel. The device tree classifies device features according to function, so that the device can load corresponding functions according to demand.

[0085] When registering FPGA-related hard-core devices, if there is a custom FPGA hard-core in the parsed device tree (such as "xxx,filter-1.0"), the compatible device node is included in the filter initialization logic for registration processing as required. When the compatible is identified as: "xxx,demodulator-1.0", the demodulator initialization logic is used for registration processing. Since this part of the FPGA hard-core devices belongs to FPGA custom devices, the definition of each model is different. The current device solution is to customize and develop according to the actual model and FPGA design. Each new model must be initialized according to the FPGA device address and register the device node, rather than uniformly registering according to the device in the device tree.

[0086] The system clock is an indispensable part of the stable operation of the device, so each model needs to output a clock configuration file specifically. Moreover, the FPGA relies on the clock when loading and running, so the clock needs to be loaded before the kernel loads the FPGA. In the prior art, a separate uboot startup program is issued for each device, which contains the clock configuration program and files required for the specific model. However, the present application divides the system clock configuration according to the clock accuracy and frequency function, and classifies the functions in the device tree, so that different models can be adapted according to the different clock compatible types in the new device tree, such as "xxx,n850-491.25", "xxx,n850-156.25", and the unnecessary clock configuration can be directly disabled in the device tree.

[0087] Since the product is a repeater device, there are currently multiple designs for the cpric and ecpric (common public radio interface) network ports of the device. Some devices are ORAN (open radio access network), including cpric ports and ecpric ports, and there are network cards specifically for sending and receiving PTP (Precision Time Protocol, a protocol for achieving high-precision clock synchronization). However, DAS devices (Direct Attached Storage) only have cpric ports. Therefore, different devices have different network card requirements. In the prior art, system packages containing different network cards are developed according to different device types. In this embodiment, different network cards are divided in the device tree according to the functions of cpric, ecpric, ptp, Ethernet physical network card, etc., and compatible (clock type) is respectively "xxx, eth-cpric", "xxx, eth-ecpri", "xxx, eth-net", etc. The required network card functions can be enabled, and the unnecessary ones can be disabled. By analogy, in this embodiment, different module functions can be loaded and configured in the form of nodes in the device tree, making the development of repeater equipment more flexible and compatible.

[0088] Later, you can put the device function mode selection in the Equipment partition and add the function modules you want to implement. When the kernel parses the device tree, the module items in the configuration file will be enabled for the corresponding module items in the device tree, and the unenabled function nodes will not be loaded. In this way, in the future, only the configuration files are different in the case of a total device tree to meet the functional requirements of different models of repeater equipment.

[0089] In this embodiment, the test only needs to test the specific functions of the corresponding model, and there is no need to test the entire firmware system. If you switch between devices using the same PCB, you only need to modify the Equipment information. In the later stage, for all platform-specific equipment issues, you only need to send out one version of the system firmware package. When carrying out production line production, you only need to burn one version for production, and you only need to treat the device model information differently. At the same time, the research and development of the system firmware package will be relatively simple. There is no need to make functional changes to the source code. You only need to manage the modules to realize the assembly of device functions.

[0090] It should be noted that the steps shown in the above process or the flowchart in the accompanying drawings can be executed in a computer system such as a group of computer executable instructions.

[0091] In this embodiment, a repeater equipment testing device is also provided, which is used to implement the above-mentioned embodiments and preferred implementation modes, and the descriptions that have been made are not repeated here. The terms "module", "unit", "subunit" and the like used below can implement a combination of software and / or hardware of a predetermined function. Although the devices described in the following embodiments are preferably implemented in software, the implementation of hardware, or a combination of software and hardware is also possible and conceivable.

[0092] Figure 6 is a structural block diagram of a repeater equipment testing device provided in an embodiment of the present application, such as Figure 6 As shown, the device includes: a loading module 10, a parsing module 20 and a testing module 30.

[0093] The loading module 10 is used to start the loading program and read the device information of the repeater device to be tested, and determine the target device tree file in the preset storage area according to the device information; the target device tree file is set in the system firmware; the target device tree file is used to describe the hardware configuration of the embedded system.

[0094] The parsing module 20 is used to parse the target device tree file to obtain the compatibility attributes of the repeater device to be tested.

[0095] The test module 30 is used to start the embedded system and load the device driver function corresponding to the compatibility attribute to implement the test of the repeater device to be tested.

[0096] It should be noted that the above modules can be functional modules or program modules, and can be implemented by software or hardware. For modules implemented by hardware, the above modules can be located in the same processor; or the above modules can be located in different processors in any combination.

[0097] In this embodiment, an electronic device is further provided, including a memory and a processor, wherein a computer program is stored in the memory, and the processor is configured to run the computer program to execute the steps in any one of the above method embodiments.

[0098] Optionally, the electronic device may further include a transmission device and an input / output device, wherein the transmission device is connected to the processor, and the input / output device is connected to the processor.

[0099] Optionally, in this embodiment, the processor may be configured to perform the following steps through a computer program:

[0100] S1, start the loader and read the device information of the repeater device to be tested, and determine the target device tree file in the preset storage area according to the device information; the target device tree file is set in the system firmware; the target device tree file is used to describe the hardware configuration of the embedded system.

[0101] S2, parsing the target device tree file to obtain the compatibility attributes of the repeater device to be tested.

[0102] S3, starting the embedded system and loading the device driver function corresponding to the compatibility attribute to implement the test of the repeater device to be tested.

[0103] It should be noted that the specific examples in this embodiment can refer to the examples described in the above embodiments and optional implementation modes, and will not be repeated in this embodiment.

[0104] In addition, in combination with the repeater device testing method provided in the above embodiment, a storage medium can also be provided in this embodiment to implement the repeater device testing method. The storage medium stores a computer program; when the computer program is executed by a processor, any of the repeater device testing methods in the above embodiment is implemented.

[0105] It should be understood that the specific embodiments described herein are only used to explain the application, rather than to limit it. Based on the embodiments provided in this application, all other embodiments obtained by ordinary technicians in this field without creative work are within the protection scope of this application.

[0106] Obviously, the drawings are only some examples or embodiments of the present application. For ordinary technicians in the field, the present application can also be applied to other similar situations based on these drawings without creative work. In addition, it is understandable that although the work done in this development process may be complicated and lengthy, for ordinary technicians in the field, certain changes in design, manufacturing or production based on the technical content disclosed in this application are only conventional technical means and should not be regarded as insufficient content disclosed in this application.

[0107] The term "embodiment" in this application refers to a specific feature, structure or characteristic described in conjunction with the embodiment that can be included in at least one embodiment of the present application. The appearance of this phrase in various locations in the specification does not necessarily mean the same embodiment, nor does it mean that it is mutually exclusive with other embodiments and is independent or optional. It is clearly or implicitly understood by those of ordinary skill in the art that the embodiments described in this application can be combined with other embodiments without conflict.

[0108] The above-mentioned embodiments only express several implementation methods of the present application, and the descriptions thereof are relatively specific and detailed, but they cannot be understood as limiting the scope of patent protection. It should be pointed out that, for a person of ordinary skill in the art, several variations and improvements can be made without departing from the concept of the present application, and these all belong to the scope of protection of the present application. Therefore, the scope of protection of the present application shall be subject to the attached claims.

Claims

1. A repeater equipment testing method, characterized in that: Applied to an embedded system, the method comprises: Start the loader and read the device information of the repeater device to be tested, and determine the target device tree file in the preset storage area according to the device information; the target device tree file is set in the system firmware; the target device tree file is used to describe the hardware configuration of the embedded system; Parsing the target device tree file to obtain the compatibility attribute of the repeater device to be tested; The embedded system is started, and the device driver function corresponding to the compatibility attribute is loaded to implement the test of the repeater device to be tested.

2. The repeater equipment testing method according to claim 1, characterized in that: Before the startup loader and reading the device information of the repeater device to be tested, the method further includes: In response to multiple device function requirements of different projects, determining driver information according to the device function requirements, and storing the driver information in the device tree file; According to a preset package format, the device tree file, the preset root file system and the kernel image file are packaged according to a preset system startup format to obtain the system firmware; The system firmware is stored in the preset storage area.

3. The repeater equipment testing method according to claim 2, characterized in that: The storing of the driver information into the device tree file includes: According to a preset verification algorithm, detecting whether the driving information is complete; If the driver information is complete, storing the driver information in the device tree file; If the driver information is incomplete, the backup data corresponding to the driver information is obtained, and the backup data is stored in the device tree file.

4. The repeater equipment testing method according to claim 1, characterized in that: The step of determining a target device tree file in a preset storage area according to the device information includes: Read the system firmware to obtain the device model in the device information; Matching device node data corresponding to the device model in the storage area; Determine device tree data according to the device node data, and perform format verification on the device tree data; When the device tree data passes the format check, a target device tree file including the device tree data is loaded.

5. The repeater equipment testing method according to claim 1, characterized in that: The parsing of the target device tree file includes: Parsing the target device tree file to determine the clock information corresponding to the repeater device to be tested; the clock information includes clock accuracy and clock frequency; According to the clock accuracy and the clock frequency, a clock profile is matched; and the compatibility attribute includes different clock profiles.

6. The repeater equipment testing method according to claim 5, characterized in that: The step of parsing the target device tree file to obtain the compatibility attribute of the repeater device to be tested further includes: Parsing the target device tree file to obtain custom hard core information; Determining a target initialization logic according to the custom hard core information; the compatibility attributes include different target initialization logics; According to the target initialization logic, the device of the customized hard core information is registered.

7. The repeater equipment testing method according to any one of claims 1 to 6, characterized in that: The method further comprises: Obtaining a device type of a device to be detected; the target device tree file includes multiple physical network cards; A target physical network card among the multiple physical network cards is enabled according to the device type.

8. A repeater equipment testing device, characterized in that: The device comprises: a loading module, a parsing module and a testing module; The loading module is used to start the loading program and read the device information of the repeater device to be tested, and determine the target device tree file in the preset storage area according to the device information; the target device tree file is set in the system firmware; the target device tree file is used to describe the hardware configuration of the embedded system; The parsing module is used to parse the target device tree file to obtain the compatibility attribute of the repeater device to be tested; The test module is used to start the embedded system and load the device driver function corresponding to the compatibility attribute to implement the test of the repeater device to be tested.

9. An electronic device comprising a memory and a processor, characterized in that: A computer program is stored in the memory, and the processor is configured to run the computer program to execute the repeater device testing method according to any one of claims 1 to 7.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the steps of the repeater equipment testing method described in any one of claims 1 to 7 are implemented.

Images