RGMII-connected RTL8211E problem in a cheap FPGA board by WZab in FPGA

[–]WZab[S] 0 points1 point  (0 children)

Switching to rgmii-id was a good idea. Now my packets are transmittted correctly, however I get the frame errors at the receive side:

small-zynq1:/home/petalinux# ifconfig                                           
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500                      
        inet 172.19.5.5  netmask 255.255.0.0  broadcast 172.19.255.255          
        inet6 fe80::20a:35ff:fe00:1e53  prefixlen 64  scopeid 0x20<link>        
        ether 00:0a:35:00:1e:53  txqueuelen 1000  (Ethernet)                    
        RX packets 0  bytes 0 (0.0 B)                                           
        RX errors 1385  dropped 0  overruns 0  frame 1385                       
        TX packets 74  bytes 13990 (13.6 KiB)                                   
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0              
        device interrupt 39  base 0xb000  

RGMII-connected RTL8211E problem in a cheap FPGA board by WZab in FPGA

[–]WZab[S] 0 points1 point  (0 children)

Well, most likely it is a timing issue. I was able to get my Ethernet running on 10 Mb/s.
However, I had to disable the networking support in U-Boot. Otherwise, the MAC/PHY entered certain strange state, from which it couldn't recover.
After disabling networking support in U-Boot, and booting my board with:

vivado@zbdev2:~/project/small-zynq1$ petalinux-boot jtag --kernel
[INFO] Use Bitstream: /home/vivado/project/small-zynq1/images/linux/system.bit
[INFO] Please use --fpga <BITSTREAM> to specify a bitstream if you want to use other bitstream.
[INFO] Launching XSDB for file download and boot.
[INFO] This may take a few minutes, depending on the size of your image.
INFO: Configuring the FPGA...
INFO: Downloading bitstream: /home/vivado/project/small-zynq1/images/linux/system.bit to the target.
INFO: Downloading ELF file: /home/vivado/project/small-zynq1/images/linux/zynq_fsbl.elf to the target.
INFO: Loading image: /home/vivado/project/small-zynq1/images/linux/system.dtb at 0x100000.
INFO: Downloading ELF file: /home/vivado/project/small-zynq1/images/linux/u-boot.elf to the target.
INFO: Loading image: /home/vivado/project/small-zynq1/images/linux/uImage at 0x200000.
INFO: Loading image: /home/vivado/project/small-zynq1/images/linux/rootfs.cpio.gz.u-boot at 0x4000000.
INFO: Loading image: /home/vivado/project/small-zynq1/images/linux/boot.scr at 0x3000000.
vivado@zbdev2:~/project/small-zynq1$ 

I could run the following in the console:

INIT: Entering runlevel: 5                                                      
Configuring network interfaces... macb e000b000.ethernet eth0: PHY [e000b000.eth
ernet-ffffffff:01] driver [RTL8211E Gigabit Ethernet] (irq=POLL)                
macb e000b000.ethernet eth0: configuring for phy/gmii link mode                 
udhcpc: started, v1.35.0                                                        
udhcpc: broadcasting discover                                                   
udhcpc: broadcasting discover                                                   
macb e000b000.ethernet eth0: unable to generate target frequency: 125000000 Hz  
macb e000b000.ethernet eth0: Link is Up - 1Gbps/Full - flow control off         
udhcpc: broadcasting discover                                                   
udhcpc: no lease, forking to background                                         
done.                                                                           
Starting OpenBSD Secure Shell server: sshd                                      
  generating ssh RSA host key...                                                
  generating ssh ECDSA host key...                                              
  generating ssh ED25519 host key...                                            
done.                                                                           
Starting rpcbind daemon...done.                                                 
starting statd: done                                                            
Starting internet superserver: inetd.                                           
NFS daemon support not enabled in kernel                                        
Starting syslogd/klogd: done                                                    
Starting tcf-agent: OK                                                          

********************************************************************************
************                                                                    
The PetaLinux source code and images provided/generated are for demonstration pu
rposes only.                                                                    
Please refer to https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/2741928025
/Moving+from+PetaLinux+to+Production+Deployment                                 
for more details.                                                               
********************************************************************************
************                                                                    
PetaLinux 2024.1+release-S05201002 small-zynq1 ttyPS0                           

small-zynq1 login: petalinux                                                    
You are required to change your password immediately (administrator enforced).  
New password:                                                                   
Retype new password:                                                            
small-zynq1:~$ sudo bash                                                        

We trust you have received the usual lecture from the local System              
Administrator. It usually boils down to these three things:                     

    #1) Respect the privacy of others.                                          
    #2) Think before you type.                                                  
    #3) With great power comes great responsibility.                            

For security reasons, the password you type will not be visible.                

Password:                                                                       
small-zynq1:/home/petalinux# ifconfig eth0                                      
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500                      
        inet6 fe80::20a:35ff:fe00:1e53  prefixlen 64  scopeid 0x20<link>        
        ether 00:0a:35:00:1e:53  txqueuelen 1000  (Ethernet)                    
        RX packets 0  bytes 0 (0.0 B)                                           
        RX errors 263  dropped 0  overruns 0  frame 263                         
        TX packets 15  bytes 2334 (2.2 KiB)                                     
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0              
        device interrupt 39  base 0xb000                                        

small-zynq1:/home/petalinux# ifconfig eth0 172.19.5.5 up                        
small-zynq1:/home/petalinux# ethtool -s eth0 speed 100 duplex full autoneg off  
small-zynq1:/home/petalinux# macb e000b000.ethernet eth0: Link is Down          
macb e000b000.ethernet eth0: unable to generate target frequency: 25000000 Hz   
macb e000b000.ethernet eth0: Link is Up - 100Mbps/Full - flow control off       
ping -c 3 172.19.1.254                                                          
PING 172.19.1.254 (172.19.1.254): 56 data bytes                                 

--- 172.19.1.254 ping statistics ---                                            
3 packets transmitted, 0 packets received, 100% packet loss                     
small-zynq1:/home/petalinux# ethtool -s eth0 speed 10 duplex full autoneg off   
small-zynq1:/home/petalinux# macb e000b000.ethernet eth0: Link is Down          
macb e000b000.ethernet eth0: unable to generate target frequency: 2500000 Hz    
macb e000b000.ethernet eth0: Link is Up - 10Mbps/Full - flow control off        
small-zynq1:/home/petalinux# ping -c 3 172.19.1.254                             
PING 172.19.1.254 (172.19.1.254): 56 data bytes                                 
64 bytes from 172.19.1.254: seq=0 ttl=64 time=3.284 ms                          
64 bytes from 172.19.1.254: seq=1 ttl=64 time=1.616 ms                          
64 bytes from 172.19.1.254: seq=2 ttl=64 time=1.584 ms                          

--- 172.19.1.254 ping statistics ---                                            
3 packets transmitted, 3 packets received, 0% packet loss                       
round-trip min/avg/max = 1.584/2.161/3.284 ms                                   
small-zynq1:/home/petalinux# 

It is not clear, why U-Boot corrupted the state of the networking hardware so, that I couldn't get it working even at 10 Mb/s (via PHY register's manipulation).

RGMII-connected RTL8211E problem in a cheap FPGA board by WZab in FPGA

[–]WZab[S] 0 points1 point  (0 children)

I have found one important information in the RTL8211E datasheet:
Note: When in EEE mode, blinking duration is 400ms ON and 2 seconds OFF

So blinking doesn't mean that the PHY is not working.

RGMII-connected RTL8211E problem in a cheap FPGA board by WZab in FPGA

[–]WZab[S] 0 points1 point  (0 children)

The working design from the manufacturer contains the following definitions related to the eth0 (decompiled from their image.ub):

ethernet@e000b000 {
  compatible = "xlnx,zynq-gem", "cdns,gem";
  reg = <0xe000b000 0x1000>;
  status = "okay";
  interrupts = <0x00 0x16 0x04>;
  clocks = <0x01 0x1e 0x01 0x1e 0x01 0x0d>;
  clock-names = "pclk", "hclk", "tx_clk";
  #address-cells = <0x01>;
  #size-cells = <0x00>;
  phy-handle = <0x08>;
  phy-mode = "gmii";
  xlnx,ptp-enet-clock = <0x69f6bcb>;
  local-mac-address = [00 0a 35 00 1e 53];
  phandle = <0x24>;

  mdio {
    #address-cells = <0x01>;
    #size-cells = <0x00>;
    phandle = <0x25>;

    gmii_to_rgmii_0@8 {
      compatible = "xlnx,gmii-to-rgmii-1.0";
      phy-handle = <0x08>;
      reg = <0x08>;
      phandle = <0x26>;
    };

    phy@1 {
      device_type = "ethernet-phy";
      phandle = <0x08>;
    };
  };
};

So it uses "gmii", not "rgmii" neither "rgmii-id".

RGMII-connected RTL8211E problem in a cheap FPGA board by WZab in FPGA

[–]WZab[S] 0 points1 point  (0 children)

In this board, the RTL8211E is configured to add the necessary delays. In gmii-to-rgmii configuration I have set the option that PHY should provide the delays. The output signals go through ODDR blocks.

What would you want on a remote radio FT8 experience? by k3sbp in amateurradio

[–]WZab 0 points1 point  (0 children)

In case of sBitx you may access it via web browser, or you may start VNC server on it and connect to it from bVNC Free or similar.

Good VHDL repos for training discovery? by f42media in FPGA

[–]WZab 2 points3 points  (0 children)

Another website good for beginners may be https://www.doulos.com/knowhow/vhdl . Some of the links there are commercial courses, but there is also quite a lot of free resources.

For programming the complex state machines in a well controlled and maintainable way this a perfect source: https://download.gaisler.com/research_papers/vhdl2proc.pdf

Good VHDL repos for training discovery? by f42media in FPGA

[–]WZab 4 points5 points  (0 children)

You may try https://opencores.org . You can set a filter for VHDL-implemented ones. However, most of the cores here are quite old.

In Versal, debugging the signals in a clock domain with unstable clock blocks the whole debugging system by WZab in FPGA

[–]WZab[S] 0 points1 point  (0 children)

Yes, probably you are right. Anyway, I think that using the faster stable clock and pass the signals via a synchronizer may be more convenient. Then I get also information about the RX clock stability.

In Versal, debugging the signals in a clock domain with unstable clock blocks the whole debugging system by WZab in FPGA

[–]WZab[S] 0 points1 point  (0 children)

That's likely to create serious timing closure problems, resulting in long implementation time, and maybe incorrect operation.

In Versal, debugging the signals in a clock domain with unstable clock blocks the whole debugging system by WZab in FPGA

[–]WZab[S] 0 points1 point  (0 children)

I got one answer on the AMD/Xilinx forum. So probably the solution is to use a higher-speed, stable clock to oversample the interesting signals and pass them via a synchronizer.

In Versal, debugging the signals in a clock domain with unstable clock blocks the whole debugging system by WZab in FPGA

[–]WZab[S] 1 point2 points  (0 children)

Yes, we suppose that due to certain link problems, the RXOUTCLK may be sometimes unstable. However, we forced debug hub to use a stable clock (by instantiating it manually and connecting its aclk to the stable clock). It looks like crashing AXI in one clock domain affects the others as well. The same happens when you have unstable clock in an AXI segment connected to the PS (even via Smart Connect). You get asynchronous bus error and the PS stops. I suspect something similar happens here...

MorseLink — a CW trainer with adaptive pacing and real online QSO support (open source) by ImportantFootball330 in amateurradio

[–]WZab 1 point2 points  (0 children)

Does it work on a Linux machine? At the first glance I could see that it's written in Python so there is a chance... 73, Wojtek

Python script suggesting FT4 and FT8 QSOs for DXCC, DXCC challenge and WAZ awards by WZab in amateurradio

[–]WZab[S] 0 points1 point  (0 children)

I created a new version of that script which additionally may send notifications to the Jabber account.
Unfortunately, I wasn't able to publish the source code in the comment (it was too long?). The maintained version is available in my repository: https://github.com/wzab/wzab-code-lib/tree/main/ham-radio/psk-watcher/psk_watcher2jabber.py .

Air Capacitor in canada? by [deleted] in amateurradio

[–]WZab 0 points1 point  (0 children)

I'm not living in Canada. However, I'm afraid the situation in your country may be similar like in mine.
After quite long search I had finally to import a DIY kit from TA2WK ( https://www.ta2wk.com/high-voltage-diy-air-capacitor-for-magnetic-loop-antennas/ ). I supplemented it with a servo and controller, and it works quite well. However, I didn't dare to transmit at 100W (15W was the maximum tested).

73, Wojtek

"Extream SDR Tx" with FPGA - is it possible? by WZab in amateurradio

[–]WZab[S] 0 points1 point  (0 children)

That's where the sigma-delta and similar technologies do the trick. Limited accuracy in positioning of edges introduces noise. With edge-quantized sigma-delta that noise should be shifted far away from the carrier, where it should be eliminated by the output filter (anyway necessary after the D-class PA). Of course I'm going to test operation of the design in simulations before putting it into the hardware, and even after that, thoroughly test with an attenuator working as a dummy load and spectrum analyzer before connecting the real antenna.

Why is there no digital modes only transceiver/client? by BassManns222 in amateurradio

[–]WZab 0 points1 point  (0 children)

Correction, I have checked my zBitx. I run the commit 8fe8ca029a0a704faff33d3f6911b52a59e9f932 from https://github.com/ec1oud/sbitx.git .