TE0720 vs TE0745 Ethernet PHY configurations

[PeVa]

Hello, I'm hoping I can gain some insight into the differences between these two boards to figure out an issue I am having.

• I started off with a TE0720 running micrium (a real time OS with a built in TPC/IP). The Zynq PS is configured with UART0 & Ethernet0 mapped to the MIO pins. As a basic test I can ping the TE0720 and get a response.
• I upgraded to the TE0745 and configured the Zynp PS exactly the same (UART0 & Ethernet0 mapped to MIO pins). When I loaded my software the board stopped responding to ping.
• The Zynq PS's/software is exactly the same, so I am convinced there must be some subtle difference between the two boards. I noticed the following:

• The Marvell 88E1512 pin 15 CONFIG is connected high on the TE0745 (causes 2-bit config address 11, PHY ADDR[0] = 1), while on the TE0720 it's connected to the CPLD and mapped to logic low (causes 2-bit config address 00, PHY ADDR[0] = 0). The Marvell documentation doesn't have a lot of detail on this. What's the reason this change was made and what affect does it have?
• The Marvell 88E1512 pin 16 nReset pin is connected to MIO9 on the TE0745 vs CPLD on TE0720 and mapped to an internal reset. What's the reason the CPLD was used vs the MIO pins? Do I really need a reset - vs just pulling the line high after power up?

One other data point. While testing the TE0720, I reloaded to software without reloading the bitstream/resetting the FPGA and ping stopped responding. This got me thinking about the differences on how the two boards are reset. Hope this is enough for someone to give me some leads and thanks so much!

[JH]

Hi,

The Marvell 88E1512 pin 16 nReset pin is connected to MIO9 on the TE0745 vs CPLD on TE0720 and mapped to an internal reset. What's the reason the CPLD was used vs the MIO pins? Do I really need a reset - vs just pulling the line high after power up?

depending on the interfaces not always are MIOs left and we use CPLD more or less as extender in this case.
And yes, you should reset phy on power up. Sometimes it doesn't work without...with reset you has a known state, without it can happens that drivers expected some state which isn't set and than it fails...

I upgraded to the TE0745 and configured the Zynp PS exactly the same (UART0 & Ethernet0 mapped to MIO pins). When I loaded my software the board stopped responding to ping.

We have an reference design online:
https://wiki.trenz-electronic.de/display/PD/TE0745+Test+Board
--> here we have activated ETH Reset over GPIO --> see Xilinx IP, so  driver can reset phy
Also prebuilt binaries are included. Do you have the same problems there?
Did you use custom board or our carrier?
br
John

[PeVa]

Hi John,

Thanks for responding to my post. Regarding the hardware: I see the same behavior on both my custom board and the TEB0745. I also tried the 2018.2 reference design (since I'm using Vivado 2018.3) - same result. No response to ping. 

• Regarding the  Marvell 88E1512 pin 15 CONFIG, what's the difference between the 2-big config address 11 on the TE0745 vs 00 on the TE0720?
• This may be more of a xilinx question, but perhaps you have some insight. When an MIO pin is used to reset the 88E1512 PHY chip, when is that reset asserted? Doing a search in the ps7_init.c (which is created by Vivado as part of the .hdf compressed file) I found the code/comment which seems like it is calling a reset as part of the PS configuration?

Code: [Select]

EMIT_MASKWRITE(0XE000A000, 0xFFFFFFFFU ,0xFF7F0080U),
// .. .. START: ENET RESET
// .. .. .. START: ENET0 RESET
// .. .. .. .. START: DIR MODE BANK 0
// .. .. .. .. DIRECTION_0 = 0x280
// .. .. .. .. ==> 0XE000A204[31:0] = 0x00000280U
// .. .. .. ..     ==> MASK : 0xFFFFFFFFU    VAL : 0x00000280U


• Last, still convinced this has something to do with the 88E1512 PHY chip reset. The post here: https://support.xilinx.com/s/article/66552?language=en_US seems to describe what I am seeing, except I can't initially ping either.

 

[JH]

I also tried the 2018.2 reference design (since I'm using Vivado 2018.3) - same result.

You has use prebuilt binaries? Can you send me the whole boot log please. Can you try out 19.2 prebuilt please. In case it also didn't work, I think something is damaged on your HW. Ethernet should work with these binaries.

Regarding the  Marvell 88E1512 pin 15 CONFIG, what's the difference between the 2-big config address 11 on the TE0745 vs 00 on the TE0720?

it's only different address for MDIO interface, Marvel support 2 different addresses. On board use zero and the other one. --> Different Developer of the modules :-)

This may be more of a xilinx question, but perhaps you have some insight. When an MIO pin is used to reset the 88E1512 PHY chip, when is that reset asserted? Doing a search in the ps7_init.c (which is created by Vivado as part of the .hdf compressed file) I found the code/comment which seems like it is calling a reset as part of the PS configuration?

I never checked where is used, I would expect FSBL like you but also uboot or linux drivers is possible, but this always depends on the drivers.

Last, still convinced this has something to do with the 88E1512 PHY chip reset. The post here: https://support.xilinx.com/s/article/66552?language=en_US seems to describe what I am seeing, except I can't initially ping either.

Do you mean it works partially? But I didn't thinks that's the same. You didn't control the reset pin.
br
John

[PeVa]

You has use prebuilt binaries? Can you send me the whole boot log please. Can you try out 19.2 prebuilt please. In case it also didn't work, I think something is damaged on your HW. Ethernet should work with these binaries.

Sorry, I misspoke. I used the TE0745 2018.2 test board .cmd scripts to create a block diagram and compiled it. I then loaded my software (micrium RTOS which supports TCP/IP) onto the TE0745 and tried to ping it. The TE0745 did not respond. The same RTOS software when loaded onto a TE0720 works.

As a sanity check, I compiled the example Xilinx LWIP (Light Weight Internet Protocol) echo server project that comes with the SDK and loaded it onto the TE0745. Ping worked with this software, so I think this proves the hardware is working. That's why I am looking at the MIO9 reset now, since that is a difference. The TE0720 ethernet reset was handled externally by the CPLD. The TE0745 reset is some how asserted by the MIO, but I'm not clear where that occurs.

If it helps, I can load the 2019.2 prebuilt. Are you suggesting the hello_te0745 or u-boot BOOT.bin files? Or do you mean petalinux?

[JH]

Hi,


Boot.bin( with Uboot) and linux image.ub --> Linux use dhcp
https://wiki.trenz-electronic.de/display/PD/TE0745+Test+Board#TE0745TestBoard-Launch

but you must not check again, if you get it running with LWIP.

For your RTOS, do you know if communication to phy works? Do you get Link up and Ping fails or both? Maybe your design use wrong phy address (--> it's 1 instead of 0 from TE0720) or your RTOS hold the PHY into reset (rather unlikely but possible).
br
John

[PeVa]

For your RTOS, do you know if communication to phy works? Do you get Link up and Ping fails or both? Maybe your design use wrong phy address (--> it's 1 instead of 0 from TE0720)

As a test: If I disconnect the ethernet cable and reboot, I get an error during initialization. Also as a test, I temporarily disconnected the MDC/MDIO lines today which also caused an error during initialization.
When the ethernet cable/MDC/MDIO pins are connected, my RTOS is able to communicate with the PHY and link is occurring. Just no ping.

Regarding the PHY Address being 1 vs 0: I never changed anything in my original RTOS net config when using the TE0720. Perhaps it worked simply because it defaults to 0. For the TE0745, I will look how to configure for address 1. For the Marvell 88E1512 what is the difference when the config pin is set high (PHY Addr == 1) vs low (PHY Addr == 0)? The Marvell datasheet doesn't give me a lot to go on.

or your RTOS hold the PHY into reset (rather unlikely but possible)

I traced the ethernet reset and it looks like the FSBL initializes the PS/performs all peripheral resets by calling the function: ps7_init() --> ps7_config() --> ps7_peripherals_init_data[]. The array is a series of registers writes. Since my RTOS never calls the ps7_init(), I don't think it has the ability to reset the ethernet which is ok because the FSBL will have already configured the PS.

[JH]

Hi,
when you get a link up, than PHY address is correct. Marvel has 2 possible addresses to connect max 2 PHY to the same MIO bus. So it's only to select correct phy. In case address is wrong, you get mostly an error that phy was not detected. I'm not familiar with RTOS but I would expect similar behaviour like on other os.

I had similar behaviour one time on TE0720 with TE0706 and second eth phy (over PL and RGMII), in this case CONFIG_XILINX_GMII2RGMII was missing on kernel config. But I'm not sure if this information helps you...

Regarding ps7_init. This is for FSBL only. Depending on device tree and drivers also  uboot and linux can control everything and on the most interfaces the initialised everything (depending on the drivers also setting from previous stage are used, so FSBL, Uboot and linux configuration depends from each other but can still change everything like they want).

br
John