Reputation: 498
I am attempting to run the FreeRTOS+TCP demo (release 10.1.1):
The code is written for the Windows Simulator, but I am attempting to target the Xilinx Zynq, emulated by QEMU (version 4.2.0). The host machine is Ubuntu 16.04. There exists a Network Interface port for the TCP part of FreeRTOS+TCP, so this should be possible.
One of the obvious modifications to the demo is changing the way messages are printed, and removing calls to the Windows Sleep
function. Also, I am using ARM semihosting to view the output of the print statements.
Besides these changes, what changes will I need to make to the command line call? The demo creates a TCP echo server and client. If these are tied together, then no traffic should need to go to the host, right? Is there anything special I would need to do to get this to work? I don't have a ton of experience with networking.
Since this is technically a baremetal application, CLI options like -nic user,hostfwd=tcp::5022-:22
give the warning qemu-system-arm: warning: nic cadence_gem.1 has no peer.
(Found at How to replace `qemu-system -redir` command argument?).
If I ever did want to send traffic between the host and guest (like having a ncat
echo server, instead of in FreeRTOS), how would I go about doing that?
Here is a related problem, with no solution: Running LWIP TCP/IP Stack with QEMU
Current command line arguments:
qemu-system-arm -semihosting --semihosting-config enable=on,target=native -nographic -serial mon:stdio -machine xilinx-zynq-a9 -m 512M -cpu cortex-a9 -nic user,hostfwd=tcp::12346-:7 -kernel build/rtos_demo_tcp/rtos_demo_tcp.elf
Current output (I enabled extra debug messages):
qemu-system-arm: warning: nic cadence_gem.1 has no peer
Seed for randomiser: 1591112953
Random numbers: 00001294 00001925 000022D0 00005CC3
FreeRTOS_IPInit
vTaskStartScheduler
prvIPTask started
Network buffers: 30 lowest 30
IP Address: 10.2.118.223
Subnet Mask: 255.255.255.0
Gateway Address: 10.2.118.1
DNS Server Address: 208.67.222.222
Socket 7 -> 0ip:0 State eCLOSED->eTCP_LISTEN
Then this next bit repeats indefinitely, with a different socket number each time:
FreeRTOS_connect: 14207 to a0276dfip:7
Socket 14207 -> a0276dfip:7 State eCLOSED->eCONNECT_SYN
ARP for a0276dfip (using a0276dfip): rc=0 00:00:00 00:00:00
Network buffers: 30 lowest 29
Connect[a0276dfip:7]: next timeout 1: 500 ms
ARP for a0276dfip (using a0276dfip): rc=0 00:00:00 00:00:00
Connect[a0276dfip:7]: next timeout 2: 500 ms
ARP for a0276dfip (using a0276dfip): rc=0 00:00:00 00:00:00
Connect[a0276dfip:7]: next timeout 3: 500 ms
Connect: giving up a0276dfip:7
Socket 14207 -> a0276dfip:7 State eCONNECT_SYN->eCLOSE_WAIT
FreeRTOS_closesocket[14207 to a0276dfip:7]: buffers 30 socks 1
Summary: How do I change the way I am calling QEMU so that the TCP client and server can connect to each other?
Upvotes: 3
Views: 4554
Reputation: 1290
I would recommend trying out all of the options enumerated in the qemu networking guide:
- SLIRP: -netdev user,id=mynet0,net=192.168.76.0/24,dhcpstart=192.168.76.9
- TAP: -netdev tap,id=mynet0
- SOCKET: -netdev socket,id=mynet0,listen=:1234
and -netdev socket,id=mynet0,connect=:1234
And there is much more in the guide. Something you might also consider is that it might be difficult for you to port-forward directly from the VM you care about to the host, and it might be easier to connect that VM to another VM and port-forward from that second VM to your host.
Sounds a bit odd, but that's something I've needed to do before. To talk between two VM's I find sockets to be the best method. They work sort of like a "virtual crossover cable".
This VM to VM method would allow you to simply have to set up corresponding static IP's and subnets on each VM and then ncat
's would work between them. Do away with all of the complexity of a DHCP server and any sort of port-forwarding.
Upvotes: 3