ST Nucleo F767ZI Ethernet Auto Negotiation problem

[bwasim]

Describe the bug
I have been testing out the Zephyr support for STM32F767 Nucleo board and see a problem that originates from the STM32 Cube library implementation of the Ethernet Auto-Negotiation routine. From the users perspective, the board fails to correctly negotiate parameters with the network. In my specific example, I connected the STM32 board directly to my machine's Rj45 jack which supports 1G and had auto-negotiation enabled. Because the Nucleo board has a 100M PHY, I should've negotiated to 100M / Full Duplex but we negotiate to 100M / Half Duplex. Even if I change to a network which supports only 10M / Half Duplex, the STM32 controller still negotiates to 100M / Half duplex.

This problem primarily occurs because the STM32 Cube library ties the MAC-PHY layers too closely which is incorrect especially when your PHY is external to the SoC - In this case, you can have thousands of boards with the same SoC but different PHYs and we will run into the same problem. In the ST Nucleo F767ZI board, we have an external 100 / 10M LAN8742 PHY (https://www.microchip.com/wwwproducts/en/LAN8742) which is interfaced over RMII to the STM32 SoC (and internally the Ethernet MAC controller). In the HAL_ETH_Init function, the controller tries to perform auto-negotiation which it does correctly but looks at the PHY_SR register for negotiated parameters but LAN8742 keeps the negotiated parameters in a "Vendor Specific" PHY Special Control/Status Register register (0x31).

I have updated the HAL layer and added code for this specific PHY by reading register 0x31 and making decisions based on the register contents and it works - The only major problem is that the solution is too lan8742-centric and would fail if someone tries to use this with another board (which has a different phy). Hence, I've reported this issue instead of filing a PR to fix the problem.

To Reproduce
Steps to reproduce the behavior:

1. mkdir build; cd build
2. cmake -DBOARD=nucleo_f767zi\defconfig+networking
3. make
4. See error

Expected behavior
Ethernet able to auto-negotiate correctly with the network.

Impact
Ethernet communication fails in my case.

Environment (please complete the following information):

• Windows
• GNU Arm
• 073ec8d

[erwango]

@bwasim This looks interesting, though it looks like this issue is rather HAL related and would be better to integrate this directly in HAL. Can you try to discuss this directly in the following repo:
https://github.com/STMicroelectronics/STM32CubeF7
(You can even now push directly PRs in these repo)

[bwasim]

Correct - This issue has more to do with the HAL library instead of the Zephyr OS, but I opened it here since it impacted my Zephyr development.

Regarding pushing a fix, the changes I made weren't scalable enough because they were specific to the LAN PHY. If someone comes with the a Custom board with the STM32F767 SoC but a different PHY, my solution will fail. Hence, I decided to leave it up-to the maintainers to come up with a more scalable fix.

[erwango]

@bwasim ok, I get your point. Can you share you test configuration as well as your proposed fix. It will be a good start for the seek of a better solution

[bwasim]

@erwango , please find zephyr.txt which is my kernel configuration. Note that this configuration disables optimizations and therefore has to increase stack sizes of various threads because I get a stack overflow otherwise. I can confirm that the problem is reproducible even if the compiler optimizations are enabled.

Also find stmf7-autoneg.txt which is a "patched" stm32f7xx_hal_eth.c file (github doesn't allow me to attach .diff / .patch files)..

[FRASTM]

STMicroelectronics Internal defect submitted (#85185)

[bwasim]

Thanks.. I have also observed some problems in the driver TX path after getting over this auto-neg bug.. Basically the driver writes data correctly on the dma descriptor but it never seems to go out on the wire.. I'm investigating this currently..

[erwango]

@bwasim following our exchange about the initial subject of this topic, do you have more questions or can we close the point ?

[bwasim]

No questions from my side. I haven't been able to get back to this, but there is a problem in the TX path.. RX works fine..

I will keep on investigating this, and may get back to you guys if I'm unable to get TX working.. Thanks..

[bwasim]

This can be closed..

[erwango]

Txs for feedback, I'm closing