All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jakub Kicinski <kuba@kernel.org>
To: "Álvaro \"G. M.\"" <alvaro.gamez@hazent.com>
Cc: netdev@vger.kernel.org,
	Radhey Shyam Pandey <radhey.shyam.pandey@amd.com>
Subject: Re: Issue with AMD Xilinx AXI Ethernet (xilinx_axienet) on MicroBlaze: Packets only received after some buffer is full
Date: Wed, 2 Apr 2025 10:00:39 -0700	[thread overview]
Message-ID: <20250402100039.4cae8073@kernel.org> (raw)
In-Reply-To: <9a6e59fcc08cb1ada36aa01de6987ad9f6aaeaa4.camel@hazent.com>

+CC Radhey, maintainer of axienet

On Tue, 01 Apr 2025 12:52:15 +0200 Álvaro "G. M." wrote:
> Hello,
> 
> I have a custom PCB board fitting a AMD/Xilinx Artix 7 FPGA with a Microblaze design
> inside that uses Xilinx' AXI 1G/2.5G Ethernet Subsystem connected via DMA.
> 
> This board and HDL design have been tested and in production since 2016 using
> kernel 4.4.43 without any issue. The hardware part of the ethernet is DP83620
> running in 100base-FX mode, which back in the day required a small patch to
> dp83848.c from myself that has been in the kernel since.
> 
> I am now trying to upgrade to a recent kernel (v6.13) and I'm facing some strange
> behavior of the ethernet system. The most probable cause is a misconfiguration
> on my part of the device tree, since things have changed since then and I've found
> the device tree documentation confusing, but I can't discard some kind of bug,
> for I have never seem something similar to this.
> 
> Relevant boot messages:
> 
> xilinx_axienet 40c00000.ethernet eth0: PHY [axienet-40c00000:01] driver [TI DP83620 10/100 Mbps PHY] (irq=POLL)
> xilinx_axienet 40c00000.ethernet eth0: configuring for phy/mii link mode
> xilinx_axienet 40c00000.ethernet eth0: Link is Up - 100Mbps/Half - flow control off
> 
> Now, transmission from the Microblaze seems to work fine, but reception however does not.
> I run tcpdump on the Microblaze and I can see that there's some kind of buffering occuring,
> as a single ARP packet sent from my directly connected computer won't reach tcpdump unless
> I send also a big chunk of data via, for example, multicast, or after enough time of ping flooding.
> 
> It's not however a matter of sending a big chunk of data at the beginning, it seems like the
> buffer empties once full and the process starts back again, so a single ping packet won't be
> received after the buffer has emptied.
> 
> I can see that interrupts increase, but not as fast as they occur when using old kernel.
> For example, in the ping case, kernel 4.43 will notify that there was an interrupt
> for each single ping packet received with ping -c 1 (so no coalescing shenanigans can occur),
> but the new kernel won't show any increase in the number of interrupts, so it means
> that the DMA core is either not generating the irq for some reason or isn't even
> executing the DMA transfer at all.
> 
> Output packets, however, do seem to be sent expeditely and received in my working computer
> as soon as I sent them from the Microblaze.
> 
> I guess I may have made some mistake in upgrading the DTS to the new format, although
> I've tried the two available methods (either setting node "dmas" or using "axistream-connected"
> property) and both methods result in the same boot messages and behavior.
> 
> By crafting properly sized UDP multicast packets (so I don't have to rely on ARP which isn't
> working due to timeouts), I've been able to determine I need to send 131072 bytes before
> reception can truly occur, although it somehow seems like sending multicast UDP
> packets won't trigger receiving IRQ unless I have a specific UDP listener program running on
> the Microblaze. I'm quite confused about that too.
> 
> So please, if anyone could inspect the DTS for me and/or guide me on how to debug this, I'd be grateful.
> 
> These are the relevant parts of the DTS for kernel 6.13, which I've hand crafted with help
> from Documentation/devicetree/bindings and peeking at xilinx_axienet_main.c:
> 
> 
> axi_ethernet_0_dma: dma@41e00000 {
> 	compatible = "xlnx,axi-dma-1.00.a";
> 	#dma-cells = <1>;
> 	reg = <0x41e00000 0x10000>;
> 	interrupt-parent = <&microblaze_0_axi_intc>;
> 	interrupts = <7 1 8 1>;
> 	xlnx,addrwidth = <32>;
> 	xlnx,datawidth = <32>;
> 	xlnx,include-sg;
> 	xlnx,sg-length-width = <16>;
> 	xlnx,include-dre = <1>;
> 	xlnx,axistream-connected = <1>;
> 	xlnx,irq-delay = <1>;
> 	dma-channels = <2>;
> 	clock-names = "s_axi_lite_aclk", "m_axi_mm2s_aclk", "m_axi_s2mm_aclk", "m_axi_sg_aclk";
> 	clocks = <&clk_bus_0>, <&clk_bus_0>, <&clk_bus_0>, <&clk_bus_0>;
> 	dma-channel@41e00000 {
> 		compatible = "xlnx,axi-dma-mm2s-channel";
> 		xlnx,include-dre = <1>;
> 		interrupts = <7 1>;
> 		xlnx,datawidth = <32>;
> 	};
> 	dma-channel@41e00030 {
> 		compatible = "xlnx,axi-dma-s2mm-channel";
> 		xlnx,include-dre = <1>;
> 		interrupts = <8 1>;
> 		xlnx,datawidth = <32>;
> 	};
> };
> axi_ethernet_eth: ethernet@40c00000 {
> 	compatible = "xlnx,axi-ethernet-1.00.a";
> 	reg = <0x40c00000 0x40000>, <0x41e00000 0x10000>;
> 	phy-handle = <&phy1>;
> 	xlnx,rxmem = <0x1000>;
> 	phy-mode = "mii";
> 	xlnx,txcsum = <0x2>;
> 	xlnx,rxcsum = <0x2>;
> 	clock-names = "s_axi_lite_clk", "axis_clk", "ref_clk", "mgt_clk";
> 	clocks = <&clk_bus_0>, <&clk_bus_0>, <&clk_bus_0>, <&clk_bus_0>;
> /*	axistream-connected = <&axi_ethernet_0_dma>; */
> 	dmas = <&axi_ethernet_0_dma 0>, <&axi_ethernet_0_dma 1>;
> 	dma-names = "tx_chan0", "rx_chan0";
> 	mdio {
> 		#address-cells = <1>;
> 		#size-cells = <0>;
> 		phy1: ethernet-phy@1 {
> 			device_type = "ethernet-phy";
> 			reg = <1>;
> 		};
> 	};
> };
> 
> 
> And these are same parts of the DTS for kernel 4.43 which worked fine.
> These were created with help from Xilinx tools.
> 
> axi_ethernet_0_dma: dma@41e00000 {
> 	#dma-cells = <1>;
> 	compatible = "xlnx,axi-dma-1.00.a";
> 	interrupt-parent = <&microblaze_0_axi_intc>;
> 	interrupts = <7 1 8 1>;
> 	reg = <0x41e00000 0x10000>;
> 	xlnx,include-sg ;
> 	dma-channel@41e00000 {
> 		compatible = "xlnx,axi-dma-mm2s-channel";
> 		dma-channels = <0x1>;
> 		interrupts = <7 1>;
> 		xlnx,datawidth = <0x8>;
> 		xlnx,device-id = <0x0>;
> 	};
> 	dma-channel@41e00030 {
> 		compatible = "xlnx,axi-dma-s2mm-channel";
> 		dma-channels = <0x1>;
> 		interrupts = <8 1>;
> 		xlnx,datawidth = <0x8>;
> 		xlnx,device-id = <0x0>;
> 	};
> };
> axi_ethernet_eth: ethernet@40c00000 {
> 	axistream-connected = <&axi_ethernet_0_dma>;
> 	axistream-control-connected = <&axi_ethernet_0_dma>;
> 	clock-frequency = <83250000>;
> 	clocks = <&clk_bus_0>;
> 	compatible = "xlnx,axi-ethernet-1.00.a";
> 	device_type = "network";
> 	interrupt-parent = <&microblaze_0_axi_intc>;
> 	interrupts = <3 0>;
> 	phy-mode = "mii";
> 	reg = <0x40c00000 0x40000>;
> 	xlnx = <0x0>;
> 	xlnx,axiliteclkrate = <0x0>;
> 	xlnx,axisclkrate = <0x0>;
> 	xlnx,gt-type = <0x0>;
> 	xlnx,gtinex = <0x0>;
> 	xlnx,phy-type = <0x0>;
> 	xlnx,phyaddr = <0x1>;
> 	xlnx,rable = <0x0>;
> 	xlnx,rxcsum = <0x2>;
> 	xlnx,rxlane0-placement = <0x0>;
> 	xlnx,rxlane1-placement = <0x0>;
> 	xlnx,rxmem = <0x1000>;
> 	xlnx,rxnibblebitslice0used = <0x1>;
> 	xlnx,tx-in-upper-nibble = <0x1>;
> 	xlnx,txcsum = <0x2>;
> 	xlnx,txlane0-placement = <0x0>;
> 	xlnx,txlane1-placement = <0x0>;
> 	phy-handle = <&phy0>;
> 	axi_ethernetlite_0_mdio: mdio {
> 		#address-cells = <1>;
> 		#size-cells = <0>;
> 		phy0: phy@1 {
> 			device_type = "ethernet-phy";
> 			reg = <1>;
> 			ti,rx-internal-delay = <7>;
> 			ti,tx-internal-delay = <7>;
> 			ti,fifo-depth = <1>;
> 		};
> 	};
> };
> 
> 
> 
> Best regards,
> 


  reply	other threads:[~2025-04-02 17:00 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-04-01 10:52 Issue with AMD Xilinx AXI Ethernet (xilinx_axienet) on MicroBlaze: Packets only received after some buffer is full Álvaro G. M.
2025-04-02 17:00 ` Jakub Kicinski [this message]
2025-04-03  5:44   ` Álvaro G. M.
2025-04-03  5:54     ` Pandey, Radhey Shyam
2025-04-03  6:10       ` Álvaro G. M.
2025-04-09 11:00       ` Álvaro G. M.
2025-04-09 11:14         ` Pandey, Radhey Shyam
2025-04-09 13:09           ` Álvaro G. M.
2025-04-10  6:25             ` Gupta, Suraj
2025-04-10  6:54               ` Álvaro G. M.
2025-04-10  7:10                 ` Gupta, Suraj
2025-04-21 11:12                   ` Álvaro G. M.
2025-04-10  7:14                 ` Álvaro G. M.
2025-04-10  9:06                   ` Álvaro G. M.
2025-04-17 16:12             ` Sean Anderson
2025-04-03 13:58     ` Gupta, Suraj

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20250402100039.4cae8073@kernel.org \
    --to=kuba@kernel.org \
    --cc=alvaro.gamez@hazent.com \
    --cc=netdev@vger.kernel.org \
    --cc=radhey.shyam.pandey@amd.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.