Cross-system debugging method based on high-pass 8295 platform

Abstract

The invention relates to a cross-system debugging method based on a high-pass 8295 platform, and the method comprises the steps: dividing a system into a QNX host and an Android guest on the high-pass 8295 platform, and dividing different resources to the QNX host or the Android guest according to demands; starting a network protocol stack, providing a virtualized rear end, sending a specified instruction and running the specified instruction, and generating a specified network card through a QNX host; and the appointed USB resource is allocated to the Android guest device in a transparent transmission mode. Related content of a virtual network card is added in a virtual machine configuration file, the Android guest generates the virtual network card, and the virtual network card exchanges data with the vpla of the QNX host through a memory; a USB interface is connected with a PC end, an Ethernet card of the type of RNDIS is formed at the PC end, and an IP address is distributed to the Ethernet card. According to the method, automatic data forwarding between a PC end and a QNX host is achieved through an iptable tool, at the moment, a data link between the PC end and the QNX host is broken through, the QNX host end is accessed through an ssh / ftp tool, debugging of the QNX host end is achieved, or an Android guest is debugged through a USB adb tool.

Description

Technical Field

[0001] The invention belongs to the technical field of cross-system debugging, and in particular relates to a cross-system debugging method based on Qualcomm 8295 platform. Background Art

[0002] Based on the Qualcomm 8295 platform, using QNX's hypervisor technology, multiple systems can be deployed on one chip. QNX host is used as an instrument system to ensure its stability. Android guset is used as an infotainment system to meet its application richness. Before the device is installed in the vehicle, you can use tools such as Ethernet and serial ports for debugging. However, these interfaces will not be visible after the device is installed. Once there is a need for debugging, the device needs to be disassembled, which is very inefficient. In the infotainment system, due to the needs of charging and interconnection, several USB interfaces will be provided to users. These interfaces can be used directly for Andorid debugging. However, the USB interface is a high-speed device. In order to ensure its performance, it is usually allocated to the guest in a transparent manner. In this way, the QNX host cannot directly access these devices and cannot use the USB interface to interact with external data.

[0003] Therefore, how to improve the existing system debugging method on the Qualcomm 8295 platform to achieve system debugging without disassembling the machine during actual vehicle debugging, reduce the complexity of the debugging process, and improve the efficiency of system debugging is a technical problem that needs to be solved urgently. Summary of the invention

[0004] The purpose of the present invention is to provide a cross-system debugging method based on the Qualcomm 8295 platform, to improve the existing system debugging method on the Qualcomm 8295 platform, so as to realize the system debugging without disassembling the machine in the current system actual vehicle debugging, reduce the complexity of the debugging process, and improve the system debugging efficiency.

[0005] In order to solve the above technical problems, the technical solution adopted by the present invention is as follows:

[0006] A cross-system debugging method based on Qualcomm 8295 platform, comprising the following steps:

[0007] S1: Divide the system into QNX host and Android guest on the Qualcomm 8295 platform, wherein the QNX host is used for the real vehicle LCD instrument panel, and the Android guest is used for the real vehicle entertainment system, and divide different resources into the QNX host or Android guest according to requirements;

[0008] S2: Start the network protocol stack through the io-pkt tool provided by the QNX host, provide a virtio-io-net virtualized backend, send and run the specified instructions, and after running the specified instructions, generate a specified network card named vp_la through the QNX host, and set the specified IP address of the specified network card;

[0009] S3: Allocate the specified USB resources to the Android guest by passthrough, and perform relevant configurations, so that the Android guest can securely access the resources of USB0 through the relevant configurations;

[0010] S4: Add relevant content of the virtual network card to the virtual machine configuration file, the Android guest generates a virtual network card, and sets an IP address for the virtual network card, and the virtual network card exchanges data with the vp_la of the QNX host through the memory;

[0011] S5: Connect the USB interface to the PC, form an RNDIS Ethernet card on the PC, and assign an IP address to the Ethernet card. At this time, data interaction can be achieved between the PC and the Android guest, and between the Android guest and the QNX host, but data interaction cannot be achieved between the PC and the QNX host.

[0012] S6: Perform the following configuration on the Android guest:

[0013] Enable IP forwarding function;

[0014] Clear all chain rules of iptable;

[0015] Delete all chain rules of iptable;

[0016] Clear the NAT chain rules in iptable;

[0017] Delete the NAT chain rules of iptable;

[0018] Allows reception of established and initiated links;

[0019] Allow forwarding of established and initiated links;

[0020] Replace the data packet with source address 92.168.1.2 with source address 10.10.10.3;

[0021] Replace the data packet with the destination address 10.10.10.3 with the destination address 192.168.1.2.

[0022] Automatic data forwarding between the PC and the QNX host is achieved through the iptable tool. At this time, the data link between the PC and the QNX host is opened. The QNX host can be accessed through the ssh / ftp tool to debug the QNX host or debug the Android guest through the USB adb tool.

[0023] Preferably, the framework of the io-pkt tool provided by the QNX host in step S2 has four layers, specifically including an application layer, a network protocol stack layer, a driver layer and a network interface layer, wherein the application layer initiates a request to the network based on a socket API, the network protocol stack layer is used to parse and process the network protocol, the driver layer controls the network interface and transmits data packets, and the network interface layer includes a network interface card and a network interface card driver, which is responsible for transmitting data packets from the physical layer to the data link layer, and from the data link layer to the network layer.

[0024] Preferably, the relevant instructions in step S2 are io-pkt-v6-hc-uSvDp tcpip-d / ifs / lib64 / dll / devnp-vdevpeer-net.sopeer= / dev / qvm / lv / la_to_host,bind= / dev / vdevpeer / vp_la,name=vp_la,mode=0660,mac=aaaaaaaaaaaaa.

[0025] Preferably, at the same time as step S3, in the Android guest, the system configures the USB0 as an RNDIS device, generates a USB network card in the system, and sets the IP address of the USB network card.

[0026] Preferably, the IP address of the USB network card is set to 10.10.10.3.

[0027] Preferably, the relevant configurations performed in step S3 are as follows:

[0028] Transmit the address of the USB0 controller from the host to the client;

[0029] Transmit the master device address of the USB0 controller from the host to the client;

[0030] Transmit the slave device address of the USB0 controller from the host to the client;

[0031] Transparently transmit interrupt 526 of USB0 controller to the client;

[0032] Transparently transmit interrupt 836 of USB0 controller to the client;

[0033] Transparently transmit interrupt 655 of USB0 controller to the client;

[0034] Transparently transmit interrupt 527 of USB0 controller to the client;

[0035] Transparently transmit interrupt 835 of the USB0 controller to the client.

[0036] Preferably, the specific process of allocating the specified USB resource by passthrough in step S3 is as follows:

[0037] S31: Entering the passthrough mode working state based on the specified command;

[0038] S32: Defines the specified operating parameters of the passthrough mode, so that the devices can communicate on the network without any hardware or software modifications to the devices;

[0039] S33: Allocate USB resources to designated locations based on the passthrough method.

[0040] Preferably, in step S2, the designated IP address of the designated network card is set to 192.168.1.2, in step S4, the IP address of the virtual network card is set to 192.168.1.3, and in step S5, the IP address of the Ethernet card is set to 10.10.10.2.

[0041] The beneficial effects of the present invention include:

[0042] The cross-system debugging method based on Qualcomm 8295 platform provided by the present invention divides the system into QNX host and Android guest on the Qualcomm 8295 platform, and divides different resources into QNX host or Android guest according to requirements; starts the network protocol stack, provides a virtualized backend, sends and runs a specified instruction, generates a specified network card through the QNX host; and allocates the specified USB resource to the Android guest through a transparent transmission mode. Add the relevant content of the virtual network card in the virtual machine configuration file, the Android guest generates the virtual network card, and the virtual network card exchanges data with the vp_la of the QNX host through the memory; connects the USB interface to the PC end, forms an Ethernet card of the RNDIS type on the PC end, and allocates an IP address to the Ethernet card. Automatic data forwarding between the PC end and the QNX host is realized by the iptable tool, at which time the data link between the PC end and the QNX host is opened, and the QNX host end is accessed by the ssh / ftp tool to realize the debugging of the QNX host end or debug the Android guest by the USB adb tool.

[0043] By connecting the USB interface to the PC, an Ethernet card of type RNDIS is formed on the PC, and an IP address is assigned to the Ethernet card, so that data interaction can be achieved between the PC and the Android guest, and between the Android guest and the QNX host. Then, the iptable tool is used to realize automatic data forwarding between the PC and the QNX host, and the data link between the PC and the QNX host is opened. The QNX host is accessed through the ssh / ftp tool to realize the debugging of the QNX host or the debugging of the Android guest through the USB adb tool. Therefore, it is no longer necessary to disassemble the machine during the actual vehicle debugging process, which simplifies the debugging process, reduces the complexity and difficulty of the debugging process and the debugging cost, and improves the system debugging efficiency. BRIEF DESCRIPTION OF THE DRAWINGS

[0044] Figure 1 The figure is a flow chart of the cross-system debugging method based on Qualcomm 8295 platform of the present invention.

[0045] Figure 2 It is a schematic diagram of the architecture of the cross-system debugging system based on Qualcomm 8295 platform of the present invention.

[0046] Figure 3 The present invention is a flow chart of allocating designated USB resources by way of passthrough. DETAILED DESCRIPTION

[0047] The following is combined with Figure 1 to Figure 3 The present invention is further described in detail:

[0048] The corresponding English definitions in the embodiments are as follows:

[0049] QNX: A microkernel operating system widely used in automotive applications.

[0050] Android: is a free and open source mobile operating system based on the Linux kernel. Mainly used in mobile devices;

[0051] Hypervisior: virtualization technology;

[0052] Host: A system that acts as a physical host in virtualization and is responsible for resource allocation and management;

[0053] Guest: The operating system used as an application in virtualization;

[0054] USB:Universal Serial Bus;

[0055] PC:Personal Computer;

[0056] RNDIS: Remote Network Driver Interface Specification is the remote network driver interface specification;

[0057] FTP: File Transfer Protocol (FTP);

[0058] SSH: Secure Shell (SSH for short);

[0059] IP: refers to Internet Protocol, the abbreviation of Internet Protocol;

[0060] Iptable: IPTABLE is a network firewall used under LINUX

[0061] ADB: Android Debug Bridge, Android Debug Bridge;

[0062] IO-PKT:Network protocol stack in QNX system;

[0063] Virtio-io-net - an Ethernet driver based on the virtio-io specification.

[0064] Passthrough: A method of allocating resources to guests in virtualization, which completely allocates resources to guests.

[0065] Example 1

[0066] See attached Figure 1-Figure 3 As shown, a cross-system debugging method based on Qualcomm 8295 platform includes the following steps:

[0067] S1: On the Qualcomm 8295 platform, the system is divided into QNX host and Android guest, the QNX host is used for the real car LCD instrument panel, and the Android guest is used for the real car entertainment system, and different resources are allocated to the QNX host or Android guest according to the needs. QNX is a microkernel, embedded, non-open source, secure real-time operating system, which complies with the POSIX specification of Unix-like real-time operating system, with a microkernel architecture, and the kernel is only tens of KB. Its drivers, protocol stacks, file systems, applications, etc. are all run in a memory-protected space outside the microkernel.

[0068] Using the QNX host as the instrument system can effectively ensure the stability of the instrument system and ensure that the content displayed on the instrument is stable and accurate. The Android guest used for the real-car entertainment system is allowed to run on the vehicle system, providing a safe and isolated environment so that multiple users or applications can use the resources of the vehicle system at the same time without interfering with each other. In the vehicle Android Guest system, guest users are given certain permissions to use system resources, but these permissions are restricted to ensure that the data and settings of the main system or primary users are not interfered with. For example, guest users can install and run third-party applications, but the installation and operation of these applications will not affect the core functions and data of the host system. This model not only improves the flexibility and convenience of the system, but also ensures the security and stability of the vehicle infotainment system.

[0069] S2: Start the network protocol stack through the io-pkt tool provided by the QNX host, provide a virtio-io-net virtualized backend, send the specified instruction and run it, after running the specified instruction, generate a specified network card named vp_la through the QNX host, and set the specified IP address of the specified network card. The io-pkt tool is the network protocol stack in the QNX operating system. It is the core component of the QNX operating system for processing network I / O operations, responsible for managing data transmission between the underlying network driver and the upper-level application. The workflow of io-pkt involves the application sending a network I / O request to the kernel through the socket API, the kernel passing the request to the io-pkt subsystem, and the io-pkt subsystem sending or receiving data packets to or from the network interface according to the request type (send or receive).

[0070] In addition, the io-pkt subsystem can also pre-process data packets, such as filtering invalid data packets or fragmenting and reassembling data packets. Throughout the process, the io-pkt subsystem plays the role of an intermediate layer for network I / O operations. The io-pkt executable file is a packet redirector / multiplexer that is responsible for loading protocol and driver modules according to the configuration given on the command line. It uses a zero-copy architecture to dynamically load multiple network protocols or driver modules, which are shared objects installed into io-pkt. In the QNX operating system, the performance of io-pkt can be optimized by adjusting its parameters, such as adjusting the mclbytes parameter to specify the maximum size of a single data packet, thereby improving network performance.

[0071] S3: Allocate the specified USB resources to the Android guest through passthrough, and perform relevant configurations. The Android guest securely accesses the resources of USB0 through the relevant configurations. The passthrough method refers to the process in which the intermediate node does not process the data in any way during the transmission of USB resources, but simply forwards the data from one interface to another. The purpose is to maintain the originality and integrity of the USB resources and ensure that the USB resources will not be tampered with or damaged during the transmission process. During the passthrough process, the intermediate node will not parse, modify or identify the data, but only transmit the USB resources as a transparent bit stream. This transmission method allows USB resources to be seamlessly transmitted between different network protocols and devices without any special processing or conversion.

[0072] S4: Add the relevant content of the virtual network card in the virtual machine configuration file, the Android guest generates a virtual network card, and sets its IP address for the virtual network card, and the virtual network card exchanges data with the vp_la of the QNX host through the memory. The main purpose of adding the virtual network card here is to simulate the network environment, establish a local area network, and enhance network performance, improve data security and management convenience. The network adapter simulated by the software allows the creation of a virtual network interface at the software level.

[0073] S5: Connect the USB interface to the PC, form an RNDIS type Ethernet card on the PC, and assign an IP address to the Ethernet card. At this time, data interaction can be achieved between the PC and the Android guest, and between the Android guest and the QNX host, but data interaction cannot be achieved between the PC and the QNX host.

[0074] S6: Perform the following configuration on the Android guest:

[0075] Enable IP forwarding function;

[0076] Clear all chain rules of iptable;

[0077] Delete all chain rules of iptable;

[0078] Clear the NAT chain rules in iptable;

[0079] Delete the NAT chain rules of iptable;

[0080] Allows reception of established and initiated links;

[0081] Allow forwarding of established and initiated links;

[0082] Replace the data packet with source address 92.168.1.2 with source address 10.10.10.3;

[0083] Replace the data packet with the destination address 10.10.10.3 with the destination address 192.168.1.2.

[0084] Automatic data forwarding between the PC and the QNX host is achieved through the iptable tool. At this time, the data link between the PC and the QNX host is opened. The QNX host can be accessed through the ssh / ftp tool to debug the QNX host or debug the Android guest through the USB adb tool.

[0085] Therefore, by connecting the USB interface to the PC, an Ethernet card of type RNDIS is formed on the PC, and an IP address is assigned to the Ethernet card, data interaction can be achieved between the PC and the Android guest, and between the Android guest and the QNX host, and then the iptable tool is used to realize automatic data forwarding between the PC and the QNX host, open up the data link between the PC and the QNX host, access the QNX host through the ssh / ftp tool, realize the debugging of the QNX host, or debug the Android guest through the USB adb tool. Therefore, it is realized that there is no need to disassemble the machine during the actual vehicle debugging process, simplifying the debugging process, reducing the complexity and difficulty of the debugging process and the debugging cost, and improving the system debugging efficiency.

[0086] Example 2

[0087] On the basis of Example 1, the framework of the io-pkt tool provided by the QNX host in step S2 has four layers, specifically including an application layer, a network protocol stack layer, a driver layer and a network interface layer, the application layer initiates a request to the network based on a socket API, the network protocol stack layer is used to parse and process the network protocol, the driver layer controls the network interface and transmits data packets, the network interface layer includes a network interface card and a network interface card driver, which is responsible for transmitting data packets from the physical layer to the data link layer, and from the data link layer to the network layer.

[0088] The relevant instructions in step S2 are io-pkt-v6-hc-uSvDp tcpip-d / ifs / lib64 / dll / devnp-vdevpeer-net.sopeer= / dev / qvm / lv / la_to_host,bind= / dev / vdevpeer / vp_la,name=vp_la,mode=0660,mac=aaaaaaaaaaaaa.

[0089] At the same time as step S3, in the Android guest, the system configures the USB0 as an RNDIS device, generates a USB network card in the system, and sets the IP address of the USB network card, setting the IP address of the USB network card to 10.10.10.3.

[0090] Example 3

[0091] Based on Example 1, the relevant configurations performed in step S3 are as follows:

[0092] Transmit the address of the USB0 controller from the host to the client;

[0093] Transmit the master device address of the USB0 controller from the host to the client;

[0094] Transmit the slave device address of the USB0 controller from the host to the client;

[0095] Transparently transmit interrupt 526 of USB0 controller to the client;

[0096] Transparently transmit interrupt 836 of USB0 controller to the client;

[0097] Transparently transmit interrupt 655 of USB0 controller to the client;

[0098] Transparently transmit interrupt 527 of USB0 controller to the client;

[0099] Transparently transmit interrupt 835 of the USB0 controller to the client.

[0100] In step S2, the designated IP address of the designated network card is set to 192.168.1.2, in step S4, the IP address of the virtual network card is set to 192.168.1.3, and in step S5, the IP address of the Ethernet card is set to 10.10.10.2.

[0101] In this embodiment, the specific process of allocating the specified USB resource by passthrough in step S3 is as follows:

[0102] S31: Entering the passthrough mode working state based on the specified command;

[0103] S32: Defines the specified operating parameters of the passthrough mode, so that the devices can communicate on the network without any hardware or software modifications to the devices;

[0104] S33: Allocate USB resources to designated locations based on the passthrough method.

[0105] In transparent transmission mode, data is directly transferred from one port to another without any processing or modification. In this mode, data transmission is transparent, meaning that data is directly transferred between the sender and the receiver without any intermediate processing or conversion. The main purpose of transparent transmission mode is to enable devices that do not need to make any changes to achieve network communication. In transparent transmission mode, the device implements the properties required for network connection by defining a series of related operating parameters. The definition of these parameters enables the device to communicate on the network without any hardware or software modifications to the device. Before the data transmission between the device and the network begins, the transparent transmission mode enters the working state through a specific command, at which time the device focuses on processing the data of the local device serial port and transmits it transparently. This means that data is sent directly to the network end after being received from the serial port, and vice versa, ensuring the originality and integrity of the data. The establishment and termination of transparent transmission mode are carried out through specific commands. For example, the transparent transmission mode is entered through a specific AT+I command, and the transparent transmission mode can be exited and the command mode can be re-entered by entering a specific character combination or monitoring the data flow through a physical jumper. In this mode, the device can work as a client or server mode, flexibly switching roles according to communication requirements. The originality and integrity of the data are effectively guaranteed through the above process.

[0106] In summary, the cross-system debugging method based on the Qualcomm 8295 platform provided by the present invention divides the system into QNX host and Android guest on the Qualcomm 8295 platform, and divides different resources into the QNX host or Android guest according to the needs; starts the network protocol stack, provides a virtualized backend, sends and runs the specified instructions, and generates the specified network card through the QNX host; allocates the specified USB resources to the Android guest through transparent transmission. Add the relevant content of the virtual network card in the virtual machine configuration file, the Android guest generates the virtual network card, and the virtual network card exchanges data with the vp_la of the QNXhost through the memory; connects the USB interface to the PC end, forms an Ethernet card of the RNDIS type on the PC end, and allocates an IP address to the Ethernet card. Automatic data forwarding between the PC end and the QNX host is realized by the iptable tool. At this time, the data link between the PC end and the QNX host is opened, and the QNX host end is accessed by the ssh / ftp tool to realize the debugging of the QNX host end or debug the Android guest by the USB adb tool.

[0107] By connecting the USB interface to the PC, an Ethernet card of type RNDIS is formed on the PC, and an IP address is assigned to the Ethernet card, so that data interaction can be achieved between the PC and the Android guest, and between the Android guest and the QNX host. Then, the iptable tool is used to realize automatic data forwarding between the PC and the QNX host, and the data link between the PC and the QNX host is opened. The QNX host is accessed through the ssh / ftp tool to realize the debugging of the QNX host or the debugging of the Android guest through the USB adb tool. Therefore, it is no longer necessary to disassemble the machine during the actual vehicle debugging process, which simplifies the debugging process, reduces the complexity and difficulty of the debugging process and the debugging cost, and improves the system debugging efficiency.

Claims

1. A cross-system debugging method based on Qualcomm 8295 platform, characterized in that: The following steps are involved: S1: Divide the system into QNX host and Android guest on the Qualcomm 8295 platform, wherein the QNX host is used for the real vehicle LCD instrument panel, and the Android guest is used for the real vehicle entertainment system, and divide different resources into the QNX host or Android guest according to requirements; S2: Start the network protocol stack through the io-pkt tool provided by the QNX host, provide a virtio-io-net virtualized backend, send and run the specified instructions, and after running the specified instructions, generate a specified network card; S3: Allocate the specified USB resources to the Android guest and perform relevant configurations, so that the Android guest can securely access the resources of USB0 through the relevant configurations; S4: Add relevant content of the virtual network card to the virtual machine configuration file, the Android guest generates a virtual network card, and sets an IP address for the virtual network card, and the virtual network card exchanges data with the vp_la of the QNX host through the memory; S5: Connect the USB interface to the PC, form an RNDIS Ethernet card on the PC, and assign an IP address to the Ethernet card. At this time, data interaction can be achieved between the PC and the Android guest, and between the Android guest and the QNX host, but data interaction cannot be achieved between the PC and the QNX host. S6: Perform specified configuration on the Android guest and use the iptable tool to implement automatic data forwarding between the PC and the QNX host. At this time, the data link between the PC and the QNX host is opened. Use the ssh / ftp tool to access the QNX host to implement debugging of the QNX host or use the USB adb tool to debug the Android guest.

2. A cross-system debugging method based on Qualcomm 8295 platform according to claim 1, characterized in that: The framework of the io-pkt tool provided by the QNX host in step S2 has four layers, including an application layer, a network protocol stack layer, a driver layer and a network interface layer. The application layer initiates a request to the network based on the socket API, the network protocol stack layer is used to parse and process the network protocol, the driver layer controls the network interface and transmits data packets, and the network interface layer includes a network interface card and a network interface card driver, which is responsible for transmitting data packets from the physical layer to the data link layer, and from the data link layer to the network layer.

3. A cross-system debugging method based on Qualcomm 8295 platform according to claim 1, characterized in that: In step S2, after running the specified command, the QNX side will generate a network card named vp_la and set its IP to 192.168.1.

2.

4. A cross-system debugging method based on Qualcomm 8295 platform according to claim 1, characterized in that: At the same time as step S3, in the Android guest, the system configures the USB0 as an RNDIS device, generates a USB network card in the system, and sets the IP address of the USB network card.

5. A cross-system debugging method based on Qualcomm 8295 platform according to claim 4, characterized in that: Set the IP address of the USB network card to 10.10.10.

3.

6. A cross-system debugging method based on Qualcomm 8295 platform according to claim 4, characterized in that: The relevant configurations performed in step S3 are as follows: Transmit the address of the USB0 controller from the host to the client; Transmit the master device address of the USB0 controller from the host to the client; Transmit the slave device address of the USB0 controller from the host to the client; Transparently transmit interrupt 526 of USB0 controller to the client; Transparently transmit interrupt 836 of USB0 controller to the client; Transparently transmit interrupt 655 of USB0 controller to the client; Transparently transmit interrupt 527 of USB0 controller to the client; Transparently transmit interrupt 835 of the USB0 controller to the client.

7. A cross-system debugging method based on Qualcomm 8295 platform according to claim 4, characterized in that: In step S3, the specified USB resource is allocated to the Android guest by passthrough.

8. A cross-system debugging method based on Qualcomm 8295 platform according to claim 5, characterized in that: The specific process of allocating the specified USB resource by passthrough in step S3 is as follows: S31: Entering the passthrough mode working state based on the specified command; S32: Defines the specified operating parameters of the passthrough mode, so that the devices can communicate on the network without any hardware or software modifications to the devices; S33: Allocate USB resources to designated locations based on the passthrough method.

9. A cross-system debugging method based on Qualcomm 8295 platform according to claim 1, characterized in that: In step S4, the IP address of the virtual network card is set to 192.168.1.3, and in step S5, the IP address of the Ethernet card is set to 10.10.10.

2.

10. A cross-system debugging method based on Qualcomm 8295 platform according to claim 1, characterized in that: In step S6, performing the specified configuration on the Android guest includes: Enable IP forwarding function; Clear all chain rules of iptable; Delete all chain rules of iptable; Clear the NAT chain rules in iptable; Delete the NAT chain rules of iptable; Allows reception of established and initiated links; Allow forwarding of established and initiated links; Replace the data packet with source address 92.168.1.2 with source address 10.10.10.3; Replace the data packet with the destination address 10.10.10.3 with the destination address 192.168.1.2.

Images