Re: eqos on Panther X2 RK3566

On Thu, 20 Nov 2025 08:15:24 +0000
qroxana <[email protected]> wrote:

> On Thursday, November 20th, 2025 at 7:14 AM, Milan Obuch
> <[email protected]> wrote:
> 
> > On Thu, 20 Nov 2025 07:01:26 +0000
> > qroxana [email protected] wrote:
> >   
> > > Hi,
> > > 
> > > I'm trying to running FreeBSD on Panther X2, the eqos0 is up
> > > however it's not able to send or receive any packets. Any help
> > > would be appreciated!
> > > 
> > > root@generic:~ # ifconfig eqos0
> > > eqos0:
> > > flags=1008843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,LOWER_UP>
> > > metric 0 mtu 1500 options=80008<VLAN_MTU,LINKSTATE> ether
> > > f2:00:2f:a2:cc:66 inet 10.10.30.90 netmask 0xff000000 broadcast
> > > 10.255.255.255  
> > 
> > 
> > Where does this IP address come from? How is it being set?  
> 
> I set the IP address manually, the DHCP was not working.
> I ran tcpdump on the DHCP server, it didn't receive any packets from
> the RK3566 box.
> 
> root@generic:~ # dhclient eqos0
> DHCPDISCOVER on eqos0 to 255.255.255.255 port 67 interval 6
> DHCPDISCOVER on eqos0 to 255.255.255.255 port 67 interval 10
> DHCPDISCOVER on eqos0 to 255.255.255.255 port 67 interval 10
> DHCPDISCOVER on eqos0 to 255.255.255.255 port 67 interval 7
> DHCPDISCOVER on eqos0 to 255.255.255.255 port 67 interval 7
> DHCPDISCOVER on eqos0 to 255.255.255.255 port 67 interval 8
> DHCPDISCOVER on eqos0 to 255.255.255.255 port 67 interval 8
> DHCPDISCOVER on eqos0 to 255.255.255.255 port 67 interval 5
> No DHCPOFFERS received.
> No working leases in persistent database - sleeping.

[ snip ]

> > Are you able to use tcpdump to see ethernet communication? In my
> > past experience, it's possible to have just one-way communication
> > working caused by wrong clock setup.
> > 
> > Regards,
> > Milan  
> 
> Thanks for the helpful tips. It seems it can receive the ARP packets
> but it was not able to send out the response.
> 
> root@generic:~ # tcpdump -n -i eqos0
> tcpdump: verbose output suppressed, use -v[v]... for full protocol
> decode listening on eqos0, link-type EN10MB (Ethernet), snapshot
> length 262144 bytes 08:06:10.020437 ARP, Request who-has 10.10.30.90
> tell 10.10.10.1, length 46 08:06:10.020535 ARP, Reply 10.10.30.90
> is-at f2:00:2f:a2:cc:66, length 28 08:06:11.018951 ARP, Request
> who-has 10.10.30.90 tell 10.10.10.1, length 46 08:06:11.019019 ARP,
> Reply 10.10.30.90 is-at f2:00:2f:a2:cc:66, length 28 08:06:12.018954
> ARP, Request who-has 10.10.30.90 tell 10.10.10.1, length 46
> 08:06:12.019001 ARP, Reply 10.10.30.90 is-at f2:00:2f:a2:cc:66,
> length 28

Generally, it matches my experience with eqos interface on Star64
board. If interested, you can look the discussion on freebsd-riscv
mailing list:

https://lists.freebsd.org/archives/freebsd-riscv/2025-May/000537.html

but no solution there as well.
 
> Here is the rk3566-panther-x2.dts I'm loading on FreeBSD, it was
> copied from Linux and the ethernet was working with the same cable.
> 
> https://pastebin.com/raw/ZysCLR7R

Well, sorry, I can't help at the moment - nothing obvious in DTS you
use. It would be good to check whether clock for PHY chip on board is
supplied with the right frequency, but I have no device to check it in
my case.

In past, I managed to diagnose something similar caused by wrong
crystal being used on board (failure in board manufacturing), and the
symptoms were exactly the same - TX path did not work. As soon as the
crystal was replaced with correct compoment it started to work - thus I
think it would be good to check this possibility, the big question is
whether you have the possibility to do so.

Regards,
Milan