TE0720 second ETH not running when starting from QSPI

[DG]

Hi,


I have a setup, with a TE0706 and TE0720 for a development prototype.
I used this for months to receive two ethernet streams with LwIP.
Everything works fine, as long as I program the Zynq-FPGA using the SDK.

Recently, I wanted to start the same setup, while booting from QSPI-Flash.
Here, the second ethernet interface (using the external PHY on the TE0706) gets stuck at the auto-negotiation process and never comes up. I first thought, that it has anything to do, with the power-up-sequence, for example, if the processor would start before the hardware is entirely ready. But after adding a few wait seconds before starting the LwIP software, the issue still remains.

In the TE0720-wiki there is a specific Trenz FSBL where the Marvell PHY seems to be configured. Is this mandatory for this setup? Why should there be any initialisation of the PHY (in the FSBL) before starting the main software (custom application)?

Thank you very much in advance for the discussion!

Kind regards,
DG

[JH]

Hi,
we have an older project available where we used also the second eth phy:
https://shop.trenz-electronic.de/en/Download/?path=Trenz_Electronic/Modules_and_Module_Carriers/4x5/TE0720/Reference_Design/2016.2/carrier_te0706_eth


That you has problem, can be different reason and also depends on the vivado/SDK/petalinux version.

At first check your design an, if everything is connected correctly and also all timing constrains are set --> see user guide from xilinx IP.
Xilinx baremetal apps also seldom run out of the box. We use in the most cases linux to check eth.

Check also that you use correct MDIO PHY address, otherwise driver can not configure phy for communication.

In case you use linux, start at first with the second eth(PL) only --> disable MIO ETH in PS IP  and generate new hdf. (I would recommend this also when you still want to test all with xilinx barmetal app). Automatically  setup will in the most cases done correctly only for one ETH, when you use a second one, you must do much more by yourself. --> Sometimes there exists also patches from xilinx for different vivado/petalinux versions and depending how you connect the phys.


br
John

[DG]

Dear John,


thank you very much for your assistance!
I don't think, it's a constraints problem, because the design works while loading it from SDK. This way, the communication over MDIO should already been established successfully.

The only thing that has changed, is the booting from QSPI. Should I try to check with the Trenz FSBL? Is it mandatory to initialize the PHY already in the FSBL? Unfortunately I am working with 2019.1 or can I still use your 2018.3 FSBL?

Kind regards,
DG

[JH]

Hi,
do not mix on board eth with the second one on the te0706....
and it can be still an timing problem or reset sequencing...

And you can not use the prebuilt FSBL, in this case the PS has the configuration from our reference design and not from your design with second eth!

So did you generate your FSBL with the same hdf like your sdk test? --> maybe your fsbl has other(older) configuration, where you use other ps-pl clks or ps-pl interfaces configuration...

What you can also try--> put your application elf as debug into the boot.bin. and before you reboot from QSPI(-->SD Boot is also possible on TE0720), connect JTAG debugger and start your application with SDK and set break point at the beginning. Than reboot --> fsbl loads your elf from qspi and debugger stops on the break point again --> you can jump step by step through to code to check what's exactly the problem.
br
John

[DG]

Hi John,

sorry for the delay.
In the meantime I found out, that this issue doesn't especially arise while booting from QSPI, as I thought before.

The issue also happens while booting from SDK, if the hardware is turned off and on again (coldstart). Then, the first loading from SDK leads to the software getting stuck while auto-negotiation. Afterwards, every new loading from SDK leads to a correctly running system.

If I scope the signals MDC, MDIO and /Rst of the PHY, I see that prior to loading from SDK, these signals have a 1.2V level (even if we are in a 1.8V system). After the first loading, MDC und /Rst go to 0V and MDIO has 1V (undefined). And later: MDIO and MDC toggle endlessly but with 1.8V levels. This first start leads to auto-neg being unsuccessful. Now I stop the execution of the software and MDIO shifts to 1.8V then (defined level). The next loading leads to expected behaviour.

What do you think could be the root of this issue. Is there anything not being initialized correctly? I don't understand why the second loading makes a difference. If I just halt the software and resume, it stills gets stuck in auto-eg. If I restart, it works, even if there is no new code being executed. If it was any initialization which is done by the software, why does the second loading make a difference then?

Kind regards,
Dino

[JH]

Hi,

you mean you load bitstream and sw again or only bitstream or only sw?
maybe some bug if sdk or reset problem. Try to delay reset in the PL part (Reset IP) or add some sleep into your app before it starts. Or both.

br
John

[DG]

Hi John,

thank you very much for your help.

you mean you load bitstream and sw again or only bitstream or only sw?

In this setup, I always load the FPGA and used the run settings for resetting all the system (all checks active) from SDK.

Try to delay reset in the PL part (Reset IP) or add some sleep into your app before it starts. Or both.

I already added a delay at the start of the app but it makes no difference.

You mentioned, that you would initialize the PHY already in your FSBL. Is this mandatory?

In the meantime, I found out, that the software gets stuck after having intiated a copper reset of the Marvell PHY. While waiting for this reset bit to clear (self-clearing), the application gets stuck. Do you know any circumstances under which the PHY isn't able to execute the reset successfully?

Thank you very much, in advance!

Kind regards,
DG

[JH]

Hi,

You mentioned, that you would initialize the PHY already in your FSBL. Is this mandatory?

No, I mean you add (In case you didn't) a Processor System Reset IP in your PL design which resets the gmii to rgmii block. you can configure this IP to delay resets, maybe this helps.

what's happens when you start a boot.bin from SD with fsbl, bistream and your baremetal app

br
John