UPGRADE YOUR BROWSER

We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Participant ericcapella
Participant
1,001 Views
Registered: ‎12-05-2017

Petalinux 2018.1 10G Ethernet and DMA reset timeout!

Jump to solution

I'm trying to get petalinux driver to configure the Xilinx 10G/25G kernel. After lots of poking around, I found that I had to manually add

&xxv_ethernet_0{
local-mac-address = [00 0a 35 01 22 11];
phy-mode = "10gbase-r";
};

to the system-user.dtsi driver.  Now that that's in place, I'm getting a kernel panic on boot-up:

xilinx_axienet a0040000.ethernet eth0: __axienet_device_reset: DMA reset timeout!^M
[ 4.359653] xilinx_axienet a0040000.ethernet eth0: __axienet_device_reset: DMA reset timeout!^M
[ 4.368652] Synchronous External Abort: synchronous external abort (0x96000210) at 0xffffff800c39040c^

 

0 Kudos
1 Solution

Accepted Solutions
Moderator
Moderator
964 Views
Registered: ‎12-04-2016

Re: Petalinux 2018.1 10G Ethernet and DMA reset timeout!

Jump to solution

Hi @ericcapella

 

You can refer to xapp1305 2018.1 release and we have PL 10G ref design and bsp there. 

https://www.xilinx.com/support/documentation/application_notes/xapp1305-ps-pl-based-ethernet-solution.pdf

 

As far as DMA reset timeout issue is concerned, we have seen while upgrading the designs to higher versions and to fix this, you have to short txoutclksel_in_0[2:0] and rxoutclksel_in_0[2:0] pins should be connected to a constant and driven with a value of 3’b101. This has to solve the DMA reset timeout error and is expected to boot properly

 

Best Regards

Shabbir

 

Best Regards

Shabbir

 

 

0 Kudos
6 Replies
Moderator
Moderator
965 Views
Registered: ‎12-04-2016

Re: Petalinux 2018.1 10G Ethernet and DMA reset timeout!

Jump to solution

Hi @ericcapella

 

You can refer to xapp1305 2018.1 release and we have PL 10G ref design and bsp there. 

https://www.xilinx.com/support/documentation/application_notes/xapp1305-ps-pl-based-ethernet-solution.pdf

 

As far as DMA reset timeout issue is concerned, we have seen while upgrading the designs to higher versions and to fix this, you have to short txoutclksel_in_0[2:0] and rxoutclksel_in_0[2:0] pins should be connected to a constant and driven with a value of 3’b101. This has to solve the DMA reset timeout error and is expected to boot properly

 

Best Regards

Shabbir

 

Best Regards

Shabbir

 

 

0 Kudos
Participant ericcapella
Participant
949 Views
Registered: ‎12-05-2017

Re: Petalinux 2018.1 10G Ethernet and DMA reset timeout!

Jump to solution

Thanks. It turns out my 10G ethernet clock wasn't active. I had been relying on booting up to program the PLL to generate the clock. I added programming in the FSBL and that resolved it.

0 Kudos
Moderator
Moderator
923 Views
Registered: ‎12-04-2016

Re: Petalinux 2018.1 10G Ethernet and DMA reset timeout!

Jump to solution

Hi @ericcapella

May I know what changes you did to the FSBL as part of clock configurations?

 

0 Kudos
Xilinx Employee
Xilinx Employee
914 Views
Registered: ‎02-20-2014

Re: Petalinux 2018.1 10G Ethernet and DMA reset timeout!

Jump to solution

I assume it's GT reference clock source programming in FSBL. It also can be done in linux.

0 Kudos
Participant ericcapella
Participant
886 Views
Registered: ‎12-05-2017

Re: Petalinux 2018.1 10G Ethernet and DMA reset timeout!

Jump to solution

We added code to program the PLL as part of the FSBL. That then generated the clock so it could be used.

 

0 Kudos
Participant ericcapella
Participant
883 Views
Registered: ‎12-05-2017

Re: Petalinux 2018.1 10G Ethernet and DMA reset timeout!

Jump to solution

For the linux ethernet device driver to properly recognize the device, the GT reference clock must already be programmed prior to linux booting up. It could work to program the PLL and then reprogram the FPGA, but we had some problems that prohibited that from being thoroughly tested.

0 Kudos