Ethernet Firmware
|
The applications that are part of this demo show Jacinto 7 integrated switch differentiating features like interVLAN routing in hardware, firewall, packet header based classification and rate limiting along with Layer-2 switching with VLAN, multicast and software-based interVLAN routing among the ports. The traffic forwarding process among the ports don't require CPU involvement or DMA bandwidth as everything is completely handled by CPSW hardware.
The intention behind this demo which encompasses multiple sub-demos is to show the switching capabilities of the J721E/J7200 integrated Ethernet Switch (CPSW9G or CPSW5G) as well as the software developed which includes Enet low-level driver (Enet LLD), lwIP TCP/IP integration and Ethernet Switch Firmware (EthFw) application.
Below are top-level features demonstrated:
The Ethernet Firmware demo application is in charge of:
This application runs with the GESI (Gateway/Ethernet Switch/Industrial Expansion Board) board on J721E EVM and with the QPENet (Quad Port Eth Expansion Board) board on J7200 EVM. The demo requires two PCs running Ubuntu connected to the GESI or QPEnet board in order to demonstrate the L2 switching capabilities as well as to generate and monitor Ethernet traffic at different stages of the demo. The connection diagrams for the respective EVMs are shown below.
Note: The IP addresses shown in above diagram are only for example and can change based on your network configuration.
A GUI-based control interface to enable/disable/configure features like VLAN, multicast, rate limiting, interVLAN routing and also to show the load of the CPU is added in the release.
A video streaming application, like Plex or VLC, can be used to demonstrate Ethernet packet switching functionality between multiple PCs. The media server will run on one PC and the client(s) will run on other PC(s), all connected to the switch via GESI board.
This demo uses Plex media system for video streaming. Plex clients can access media content via web interface, so any PC connected to the switch can easily access it.
Note: Please check licensing information and terms of usage of Plex TV media server and make sure it adheres to your organization's policy before using and configuring it.
A Remote Client application for the Main R5F core 1 is also available as part of this demo. This application runs a local lwIP stack on a virtual network device which demonstrates the RTOS switch remote core integration.
This application depends on multiple components and are detailed in sections below:
Not applicable.
Note: Plex server is required only in PC 1.
Note: packETH tool is required only in PC 1.
Install packETH packet generator tool on the Linux PC. The Ubuntu installation instructions can be found in their website.
The packEth configurations used in this demo are included in the Ethernet Firmware package at <ETHFW_PATH>/docs/packeth_configurations/
Note: Please check licensing information and terms of usage of packETH tool and make sure it adheres to your organization's policy before using and configuring it.
The CPSW Remote Configuration GUI tool is developed using Python3 and PyQt. Pip3 can be used to install additional Python modules required by the GUI tool.
Note: The GUI tool can be executed from either PC 1 or PC 2, so Python and its dependencies must be installed only on the selected PC.
Install Python3, PyQt, pip3 and other dependencies:
sudo apt install python3-pip pip3 install --user pyqt5 sudo apt-get install python3-pyqt5 sudo apt-get install pyqt5-dev-tools sudo apt-get install qttools5-dev-tools pip3 install jsonschema pyserial serial xmodem
Note: Wireshark packet analyzer tool is required in both PC 1 and PC 2.
Refer to the Wireshark installation instructions on Ubuntu in this website.
Note: iperf network performance measurement tool is required on either PC 1 or PC 2.
Install iperf in the selected Ubuntu PC(s):
sudo apt-get install iperf
Note: bmon is required only on PC 2.
bmon is a network bandwidth monitoring tool that will be used in this demo to monitor the traffic received on PC 2 during the interVLAN tests.
Install bmon in the Ubuntu PC as follows:
sudo apt-get install bmon
After installing bmon, enable promiscuous mode on the network interface using,
sudo ifconfig eth0 promisc
This is required to capture VLAN tagged packets in the PC. Since fixed VLAN tags, IP & MAC addresses are used in the demo, PC's network interface will drop these packets as they are not addressed to it. To avoid this, promiscuous mode should be enabled on the network interface.
Note: DHCP server is required only in PC 1.
A DHCP server is required to assign IPs dynamically to all internal cores (A72, Main R5F core0, Main R5F core1) or external devices (PC 1, PC 2) in this demo.
subnet 192.168.1.0 netmask 255.255.255.0 { range 192.168.1.200 192.168.1.210; ... }
192.168.1.<pc1>
and the restart the DHCP server.If dynamic IP configuration is not possible, static IPs can be setup as follows:
For Ethernet Firmware server, set below flag in ethfw/apps/app_remoteswitchcfg_server/mcu_2_0/main.c
to disable DHCP and use static IP instead:
#define ETHAPP_LWIP_USE_DHCP (0)
The static IP address, gateway and netmask can be set also in the same file.
#define ETHFW_CLIENT_IPADDR(addr) IP4_ADDR((addr), 192,168,1,201) #define ETHFW_CLIENT_GW(addr) IP4_ADDR((addr), 192,168,1,1) #define ETHFW_CLIENT_NETMASK(addr) IP4_ADDR((addr), 255,255,255,0)
For RTOS client application, set below flag in ethfw/apps/app_remoteswitchcfg_client/mcu_2_1/main.c
:
#define ETHAPP_LWIP_USE_DHCP (0)
The static IP address, gateway and netmask can be set also in the same file.
sudo ifconfig <ethDeviceName> 192.168.1.x netmask 255.255.255.0 up
Device | IP address |
---|---|
PC 1 (Plex server) | 192.168.1.202 |
J721E/J7200/J784S4 Main R5F core (running EthFw) | 192.168.1.203 |
PC 2 (Plex client) | 192.168.1.204 |
J721E/J7200/J784S4 A72 core (virtual net driver) | 192.168.1.205 |
Default Gateway | 192.168.1.1 |
Subnet Mask | 255.255.255.0 |
Note: Make sure that all IPs assigned manually are in the same subnet as the Ethernet Firmware.
Note: PTP stack is required only on PC 2.
Note: PC 2 should be connected to MAC port 3 in J721E. Refer to J721E GESI Expansion Board for MAC port numbers in J721E EVM. CPTS event lookup errors will be seen if connected to a different MAC port.
Note: PC 2 should be connected to MAC port 3 in J7200. Refer to J7200 Quad-Port Eth Expansion Board for MAC port numbers in J7200 EVM. CPTS event lookup errors will be seen if connected to a different MAC port.
Note: PC 2 should be connected to MAC port 3 in J784S4. Refer to J784S4 Quad-Port Eth Expansion Board for MAC port numbers in J784S4 EVM. CPTS event lookup errors will be seen if connected to a different MAC port.
PTP stack is required to run master clock and synchronize with the slave running on EVM.
~]# ethtool -T eth3 Time stamping parameters for eth3: Capabilities: hardware-transmit (SOF_TIMESTAMPING_TX_HARDWARE) software-transmit (SOF_TIMESTAMPING_TX_SOFTWARE) hardware-receive (SOF_TIMESTAMPING_RX_HARDWARE) software-receive (SOF_TIMESTAMPING_RX_SOFTWARE) software-system-clock (SOF_TIMESTAMPING_SOFTWARE) hardware-raw-clock (SOF_TIMESTAMPING_RAW_HARDWARE) PTP Hardware Clock: 0 Hardware Transmit Timestamp Modes: off (HWTSTAMP_TX_OFF) on (HWTSTAMP_TX_ON) Hardware Receive Filter Modes: none (HWTSTAMP_FILTER_NONE) all (HWTSTAMP_FILTER_ALL)where eth3 is the interface you want to check.
SOF_TIMESTAMPING_SOFTWARE SOF_TIMESTAMPING_TX_SOFTWARE SOF_TIMESTAMPING_RX_SOFTWARE
SOF_TIMESTAMPING_RAW_HARDWARE SOF_TIMESTAMPING_TX_HARDWARE SOF_TIMESTAMPING_RX_HARDWARE
sudo apt install linuxptp
Start PTP master:
sudo ptp4l -P -2 -S -i eth3 -m -q -p -l 7 /dev/ptp0
Replace -S
with -H
if your NIC supports hardware timestamping.
ptp
in Wireshark's display filter. The timestamp sent from the J721E/J7200/J784S4 EVM should be updated to current time, i.e. responseOriginTimestamp in TI EVM's Path_Delay_Resp_Follow_Up message. The value from this field can be converted to a human-readable date using epochconverter.com or other tools.Install Code Composer Studio and setup a Target Configuration for use with J721E, J7200 or J784S4 EVM. Refer to IDE (CCS).
XDS110
. Alternatively, XDS560v2 debugger can be connected to the JTAG connected labeled JTAG MIPI
.UART
.SW8
and SW9
for no-boot mode:Open up a serial terminal for UART2 communication. This terminal will show logs from MCU2_0 core where the demo application runs.
Note: Linux running on A72 core is not compatible with CCS boot mode.
Copy the demo application to the ethfw
directory of Linux filesystem in SD card.
For J721E using FREERTOS:
cp <SDK_INSTALL_PATH>/ethfw/out/J721E/R5Ft/FREERTOS/debug/app_remoteswitchcfg_server_strip.xer5f <MOUNT>/rootfs/lib/firmware/ethfw/
For J7200 using FREERTOS:
cp <SDK_INSTALL_PATH>/ethfw/out/J7200/R5Ft/FREERTOS/debug/app_remoteswitchcfg_server_strip.xer5f <MOUNT>/rootfs/lib/firmware/ethfw/
If needed, update the soft-link j7-main-r5f0_0-fw
or j7200-main-r5f0_0-fw
to point to the demo application copied to SD card in the previous step.
For J721E:
cd <MOUNT>/rootfs/lib/firmware/ ln -sf ethfw/app_remoteswitchcfg_server_strip.xer5f j7-main-r5f0_0-fw
For J7200:
cd <MOUNT>/rootfs/lib/firmware/ ln -sf ethfw/app_remoteswitchcfg_server_strip.xer5f j7200-main-r5f0_0-fw
Optional: Copy the remote client application to the firmware
directory of Linux filesystem in SD card and update soft-link:
For J721E using FREERTOS:
cp <SDK_INSTALL_PATH>/ethfw/out/J721E/R5Ft/FREERTOS/debug/app_remoteswitchcfg_client.xer5f <MOUNT>/rootfs/lib/firmware/ cd <MOUNT>/rootfs/lib/firmware/ ln -sf app_remoteswitchcfg_client.xer5f j7-main-r5f0_1-fw
For J7200 using FREERTOS:
cp <SDK_INSTALL_PATH>/ethfw/out/J7200/R5Ft/FREERTOS/debug/app_remoteswitchcfg_client.xer5f <MOUNT>/rootfs/lib/firmware/ cd <MOUNT>/rootfs/lib/firmware/ ln -sf app_remoteswitchcfg_client.xer5f j7200-main-r5f0_1-fw
UART
.SW8
and SW9
for SD card boot:Open up a serial terminal for UART2 communication. This terminal will show logs from MCU2_0 core where the demo application runs.
MICRO SD
and power on the J721E/J7200/J784S4 EVM board.Note: The demo application in this release assumes that external devices, PC 1 and PC 2, are connected prior to starting the demo. It's a mandatory step.
The IPs assigned dynamically to Main R5F cores 0 and 1 will be printed in the UART2 serial terminal.
Plex TV server running on PC 1 requires an initial setup covered in the Prerequisites section. Note that Plex server may required to be explicitly launched after PC has been booted.
Run Plex client from PC 2 by accessing the following address using your favorite web browser: http://192.168.1.<pc1>:32400/web/index.html
Once the EVM is booted along with Linux on A72, the virtual net driver module should be loaded and the eth1
network device corresponding to CPSW9G should be added.
ifconfig -a
on Linux terminal console of the EVM.sudo ifconfig eth1 up
ping 192.168.1.<pc1> ping 192.168.1.<pc2>
ping 192.168.1.<a72>
The CPSW switch is capable of steering network traffic without CPU intervention by classifying it based on its characteristics. This can be demonstrated by running iperf server on Linux running on the A72 core and iperf client on any of the external devices, PC 1 or PC 2.
iperf -s
-t
option as needed. iperf -c 192.168.1.<a72> -t 20 -i 1
After getting the IP address printed on the console, launch the GUI tool:
cd <SDK_INSTALL_PATH>/pdk_jacinto_xx_yy_zz/packages/ti/drv/enet/tools/cpsw_configclient sudo python3 switchconfig_client.py
You should be able to see a window opening up as shown below.
Select the SETTINGS tab and enter the target IP 192.168.1.<r5f_0>
as shown below.
Once the IP is set, the Main R5 Load progress bar will get updated periodically.
sw_intervlan_routing_config.txt
file present in the <SDK_INSTALL_PATH>/pdk_jacinto_xx_yy_zz/packages/ti/drv/enet/tools/cpsw_configclient/config_files
directory.schemas.py
file in the cpsw_configclient/inc
directory.ing_portNum
and egr_portNum
accordingly if using different MAC port numbers than those in the config file. This can be done in the CONFIG
panel of the CONFIGURATION FILE tab. The port numbers are 0-based, i.e. if packets are submitted via MAC port 1, then "ing_portNum":0
.In the packETH tool on the PC 1, which has IP address 192.168.1.<pc1>
, load the swintervlanrouting
configuration file from <ETHFW_PATH>/docs/packeth_configurations/
directory.
The loaded configuration should match with the below picture.
packETH configuration for software interVLAN routing:
02:00:00:00:00:02
00:11:01:00:00:01
192.168.1.202
192.168.1.204
Note that source and destination IP address don't have to match either PC 1 or PC 2 address. They match the IP address in the sw_intervlan_routing_config.txt
config file, so they must not be changed.
192.168.1.<pc2>
and the VLAN ID will be changed to 0xC8 (200 in decimal). This can be verified using tools like Wireshark on the receiver PC.00:11:02:00:00:01
02:00:00:00:00:02
192.168.1.202
192.168.1.204
hw_intervlan_routing_config.txt
file present in the <SDK_INSTALL_PATH>/pdk_jacinto_xx_yy_zz/packages/ti/drv/enet/tools/cpsw_configclient/config_files
directory.ing_portNum
and egr_portNum
accordingly if using different MAC port numbers than those in the config file. This can be done in the CONFIG
panel of the CONFIGURATION FILE tab. The port numbers are 0-based, i.e. if packets are submitted via MAC port 1, then "ing_portNum":0
.Load the hwintervlanrouting
configuration file from <ETHFW_PATH>/docs/packeth_configurations/
directory.
The loaded configuration should match with the below picture.
packETH configuration for hardware interVLAN routing:
02:00:00:00:00:02
00:11:01:00:00:01
192.168.1.201
192.168.1.204
Note that source and destination IP address don't have to match either PC 1 or PC 2 address. They match the IP address in the hw_intervlan_routing_config.txt
config file, so they must not be changed.
192.168.1.<pc2>
and the VLAN ID will be changed to 0xC8 (200 in decimal). This can be verified using tools like Wireshark on the receiver PC.00:11:02:00:00:01
02:00:00:00:00:02
192.168.1.201
192.168.1.204
CPSW9G supports whitelisting of up to four different IP protocols for a VLAN group. This demo white-lists TCP and UDP protocols and hence blocking packets of other protocols in the VLAN network.
vlanId: 0x2BC (700 in decimal)
with host port, MAC ports 2 and 3 as members of the VLAN group.ip_nxt_hdr_whitelisting_config.txt
file present in the <SDK_INSTALL_PATH>/pdk_jacinto_xx_yy_zz/packages/ti/drv/enet/tools/cpsw_configclient/config_files
directory.ipnxthdr_tcp
configuration file from <ETHFW_PATH>/docs/packeth_configurations/
directory to the packEth tool and start sending packets.ip.addr eq 192.168.1.202 && vlan
filter.ipnxthdr_udp
packETH configuration can be used to verify UDP.ipnxthdr_icmp_echorequest
from packETH won't be received at PC 2.rate_limiting_config.txt
file present in the <SDK_INSTALL_PATH>/pdk_jacinto_xx_yy_zz/packages/ti/drv/enet/tools/cpsw_configclient/config_files
directory.ratelimiting
configuration file from <ETHFW_PATH>/docs/packeth_configurations/
directory to the packETH tool and stat sending packets at a rate more than 200 Mbps.bmon
or System Monitor
in PC 2.Inter-core virtual Ethernet is enabled by default on RTOS cores (unless disabled using build flags). As such it is always used for incoming and outgoing broadcast messages, as well as unicast messages between cores.
Examples of broadcast data flows exercised in this demo are given below.
RTOS remote client DHCP procedure: Main R5F core1 starts DHCP procedure by sending a DHCP discover broadcast packet, which is forwarded by the main R5F core1 bridge to main R5F core0 bridge over inter-core interface. The main R5F core0 bridge also broadcasts this packet thus sending it out to the external DHCP server via the Enet LLD interface. Outgoing broadcast packets follow this data path:
Main R5F core1 network stack → Main R5F core1 bridge → Main R5F core0 bridge (over intercore) → Main R5F core0 Enet LLD netif → Linux PC (DHCP server)
Incoming ARP broadcast from PC: Ping Main R5F core1 remote client from Linux PC. This results in the PC sending an ARP broadcast to resolve the MAC address of the remote core. Incoming broadcast packets follow this data path:
Broadcast form PC → Main R5F core0 Enet LLD netif → Main R5F core0 bridge → Main R5F core1 bridge (over intercore) → Main R5F core1 network stack
The tap
user-space application serves as a medium to facilitate the exchange of Ethernet frames between the A72 Linux and R5_0 (MCU2_0) master cores. To achieve this, a TAP device is used to read from and write to the Linux network stack. Ethernet frames are copied from/to the shared memory region to allow other cores to access it.
The TAP application is provided as part of the Ethernet Firmware software component in the Processor SDK, it can be found at ethfw/apps/tap
. The TAP application needs to be cross-compiled using Linux toolchain and then installed to the Linux filesystem. The steps listed below assume that an SD card is used for Linux booting of the TI EVM.
setuptools.sh
helper script. $ ./setuptools.sh
Cross-compile the TAP application and install in SD card. Here,<aarch64-none-linux-gnu install dir>
is the absolute path where the ARM64 A72 Linux compiler was installed using setuptools.sh
in previous step.
$ make CROSS_COMPILE=<aarch64-none-linux-gnu install dir>/bin/aarch64-none-linux-gnu- install DESTDIR=<Path to the root file system on SD card>
For example, if the ARM64 A72 Linux compiler was installed in <PSDK_RTOS_PATH>/ethfw/apps/tap/gcc-arm-9.2-2019.12-x86_64-aarch64-none-linux-gnu
, and the SD card is mounted at /media/username
and the file system is at /media/username/root
, then the make command should be:
$ make CROSS_COMPILE=<PSDK_RTOS_PATH>/ethfw/apps/tap/gcc-arm-9.2-2019.12-x86_64-aarch64-none-linux-gnu/bin/aarch64-none-linux-gnu- install DESTDIR=/media/username/root
launch_tap.service
starts up automatically on boot. With this, on the next boot, the user-space application should be running automatically in the background. $ systemctl enable launch_tap.service
tap0
will be created and it will get an IP address assigned using DHCP. The network interface tap0
should also show up in the list of available network interfaces using the ifconfig
command: $ ifconfig tap0 tap0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 metric 1 inet 192.168.1.220 netmask 255.255.255.0 broadcast 192.168.1.255 inet6 fe80::201:2ff:fe04:506 prefixlen 64 scopeid 0x20<link> ether 00:01:02:04:05:06 txqueuelen 1000 (Ethernet) RX packets 82 bytes 6932 (6.7 KiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 44 bytes 5534 (5.4 KiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
By default, the systemd service launch_tap.service
will run the shell script tapif.sh
during boot up. However, it is possible to manually relaunch the application either for testing purposes or in case of errors during automatic startup:
tapif.sh
file and the tapif
executable (typically /usr/bin).tapif.sh
which shall initialize the TAP device and launch the user-space application. $ cd /usr/bin $ ls -la tap* -rwxr-xr-x 1 root root 29216 Feb 27 05:08 tapif -rwxr-xr-x 1 root root 9846 Feb 27 05:07 tapif.sh $ $ bash tapif.sh& [1] 2615 Discovered Bufpool Base Address at 0xfb800000 from device tree And the Bufpool region length is 0x01800000 Discovered Queue Base Address at 0xfb000000 from device tree And the Queue region length is 0x00800000 ------------------------------------------------ Selected Configuration: ------------------------------------------------ TAP Device name tap0 RX Queue Id 2 TX Queue Id 3 Maximum number of queues 4 Queue Base 0xfb000000 Queue Len 0x00[ 385.548282] IPv6: ADDRCONF(NETDEV_CHANGE): tap0: link becomes ready 800000 Polling interval 1000 Maximum number of bufpools 4 Bufpool base 0xfb800000 Bufpool len 0x01800000 TX Bufpool ID 2 TAP IP TAP MAC 00:01:02:04:05:06 MAX TX 64 MAX RX 64 ------------------------------------------------ Opened TAP Device successfully Queue Mapping Succeeded Bufpool Mapping Succeeded Assigned Queue Handles Queues have been initialized Assigned Bufpool Handle Bufpool Init: Values Initialized Bufpool Init: Cleared Buffers Initialized Bufpool Initialization complete ------------------------------------------------------------------------- Starting TX and RX Tasks Started TX Task Started RX Task Fetching IP address from DHCP server udhcpc: started, v1.31.1 udhcpc: sending discover udhcpc: sending select for 192.168.1.220 udhcpc: lease of 192.168.1.220 obtained, lease time 534
tapif
user-space application can be shutdown if needed by executing the script cleantapif.sh
which is provided in the same directory. $ cd /usr/bin $ bash ./cleantapif.sh
The broadcast data flows shown in RTOS client test apply to the Linux remote client as well with a few minor differences:
In addition to the broadcast data flows listed above, users can also run network utilities such as ping and iperf from the Linux client to run network tests with Main R5F core0 master and/or Main R5F core1 client cores as the destination. For instance, the A72 shell log below shows an iperf test originated from the A72 remote client with main R5F core0 master as the server. The IP address assignments are listed below:
A72 client: 192.168.1.201
Main R5F core0 server: 192.168.1.200
Below is a sample log from the execution of this demo application.
Revision | Date | Author | Description |
---|---|---|---|
0.1 | 01 Apr 2019 | Prasad J, Misael Lopez | Created for v.0.08.00 |
0.2 | 12 Jun 2019 | Prasad J | Updates for EVM demo (.85 release) |
0.3 | 17 Jul 2019 | Misael Lopez | Updates for v.0.09.00 |
0.4 | 14 Oct 2019 | Santhana Bharathi N | Updates for v.1.00.00 |
0.5 | 03 Jun 2020 | Santhana Bharathi N | Updates for v.7.00.00 (Updated logs and added instructions for TimeSync) |
1.0 | 31 Aug 2020 | Misael Lopez | Added J7200 support for SDK 7.01 EA |
1.1 | 10 Nov 2020 | Misael Lopez | Updates for v.7.01.00 |
1.2 | 08 Jul 2021 | Misael Lopez | Updates for v.8.00.00 |
1.3 | 03 Dec 2021 | Nitin Sakhuja | Updates for v.8.01.00 |
1.4 | 27 Feb 2022 | Misael Lopez | Updates for v.8.02.00 (Updated logs) |
1.5 | 01 Jul 2022 | Misael Lopez | Updates for v.8.02.01 (J784S4 support) |
1.6 | 15 Aug 2022 | Misael Lopez | Updates for v.8.04.00 |