search

zephyrproject-rtos / zephyr

Primary Git Repository for the Zephyr Project. Zephyr is a new generation, scalable, optimized, secure RTOS for multiple hardware architectures.
https://docs.zephyrproject.org
Apache License 2.0
10.92k stars 6.65k forks source link

STM32 Ethernet initialization sequence #80432

Open robi251 opened 3 weeks ago

robi251 commented 3 weeks ago

Describe the bug

Initialization sequence seams to be incorrect in case of STM32 F4 MCU and external MAC PHY unit

The problem I encounter is about the peripheral initialization sequence. In my case, the MCU which is STM32 F4X series is cooperating with external MAC PHY (DM8806) connected via MDIO bus. And in this case, the initialization sequence which will bring up the Ethernet link should be: MDIO_init ---> MAC_PHY_init ---> eth_stm32_hal_init In current situation, the eth_initialize() in et_stm32_hal.c is trying to talk with the PHY, but the MDIO is not ready yet.

To Reproduce

  1. Integrate DM8806 driver from PR: https://github.com/zephyrproject-rtos/zephyr/pull/77812
  2. Switch on MDIO in the project
  3. Run on the hardware (which is the most difficult part, since I don't expect somebody has similar hardware)

Expected behavior Initialization sequence which will bring-up devices one by one in below order:

  1. GPIO
  2. MDIO
  3. PHY
  4. Ethernet

Impact In original form I'm not able to bring-up the Ethernet link, but the solution is to split the eth_initialize(). This function is running partially, then the mdio_stm32_init() is called to initialize MDIO bus, next the MAC PHY initialization function is called to initialize external PHY DM8806 (phy_dm8806_init()) and next the boot-up process is come back to the rest part of the eth_initialize() which is operating on the MDIO and was extracted as separate function wit system initialization priority: SYS_INIT(hal_init, POST_KERNEL, 89); This of course is just the workaround to deal with this situation. I'm wondering what will be the best way to make the initialization process correct. Extracting the MDIO completely from the mac node seams to be not the best option for me.

Logs and console output

Environment (please complete the following information):

Additional context In my case, the device tree looks similar to this:

&mac {
    status = "okay";
    pinctrl-0 = <&eth_crs_dv_px...
             &eth_ref_clk_px...
             &eth_tx_en_px...
             &eth_txd1_px...
             &eth_txd0_px...
             &eth_rxd1_px...
             &eth_rxd0_px...>;
                 pinctrl-names = "default";

    mdio {
        compatible = "st,stm32-mdio";
        status = "okay";
        pinctrl-0 = <&eth_mdio_px... &eth_mdc_px...>;
        #address-cells = <1>;
        #size-cells = <0>;
        pinctrl-names = "default";

        dm8806_phy0: ethernet-phy@0 {
            reg = <2>;
            reg-switch = <8>;
erwango commented 3 weeks ago

Enhancement as does not impact already upstream code. This is rather a change required to support new feature/hardware.

robi251 commented 3 weeks ago

Should it be rather RFC / Proposal ?

robi251 commented 1 week ago

OK, so if not RFC, maybe PR will be better place to discuss it?: https://github.com/zephyrproject-rtos/zephyr/pull/81272