Second PHY (KSZ8081) not working on i.MX6ULL/i.MX6UL

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Second PHY (KSZ8081) not working on i.MX6ULL/i.MX6UL

1,163 Views
ayoubbenkhoris
Contributor I

Hi all,

We are trying to enable both ethernet ports on a i.MX6 ULL EVK board. After applying the following fix, we were able to use ethernet1, but ethernet0 is still down.

> +	} else if (dev && dev->interface == PHY_INTERFACE_MODE_RMII) {
> +		phy_write(dev, 0x1f, 0x8190);
> +		phy_write(dev, 0x16, 0x202);
> +	}

(see https://patchwork.kernel.org/project/linux-arm-kernel/patch/1437122304-20598-3-git-send-email-b38611...)

We are using U-Boot 2017.03-imx_v2017.03_4.9.88_2.0.0_ga

We retrieved the following PHY registers values in uboot:

imx6ull

ethernet0 (fec1) 0x02188000 0x4000 rmii ethphy0 @2
ethernet1 (fec2) 0x020b4000 0x4000 rmii ethphy1 @1 MDIO

 

PHY at address 1 (ethernet1):
0 - 0x1100
1 - 0x786d
2 - 0x22
3 - 0x1561
4 - 0x81e1
5 - 0xc1e1
6 - 0xf
7 - 0x2001
8 - 0x4fd5
PHY at address 2 (ethernet0): 0 - 0x500 => bit 10 = Electrical isolation of PHY from MII/RMII 1 - 0x7849 2 - 0x22 3 - 0x1561 4 - 0x8061 5 - 0x0 6 - 0x4 7 - 0x2001 8 - 0x0

The control register (0) for PHY at address 2 indicates that the PHY is electrically isolated. This register is supposed to be readable/writable but clearing bit 10 of register 0 directly does not work.

It looks like the bit is set by the ISO strapping pin (see https://ww1.microchip.com/downloads/aemDocuments/documents/OTH/ProductDocuments/DataSheets/00002202C... ) and locked, how can we avoid that?

Is the problem fixed in more recent u-boot versions? If yes, can you provide the version to use?

Thanks,

Ayoub

0 Kudos
Reply
3 Replies

1,052 Views
ZeeFrench
NXP Employee
NXP Employee

Hi Ayoub,

Have tried latest 2022 u-boot you can download from https://www.nxp.com/design/software/embedded-software/i-mx-software/embedded-linux-for-i-mx-applicat...

U-Boot 2022.04-lf_v2022.04+g1c881f4da8 (Jun 07 2022 - 05:16:02 +0000)

CPU: i.MX6ULL rev1.0 at 396MHz
...
Net: eth1: ethernet@20b4000 [PRIME]Get shared mii bus on ethernet@2188000
, eth0: ethernet@2188000

=> dhcp
ethernet@20b4000 Waiting for PHY auto negotiation to complete......................................... TIMEOUT !
Could not initialize PHY ethernet@20b4000

U-boot can only manage a single ethernet connection (and there is no need for more on a bootloader, I also checked more network oriented https://github.com/real-time-edge-sw/real-time-edge-uboot), the "PRIME" is configured with ethprime :

=> setenv ethprime eth0

=> saveenv

reboot
...
Net: Get shared mii bus on ethernet@2188000
eth1: ethernet@20b4000, eth0: ethernet@2188000 [PRIME]
...
=> dhcp
ethernet@2188000 Waiting for PHY auto negotiation to complete.... done

Both ethernet are working on my evk but you need to choose which one will be configured at boot.

Best regards, Philippe.

0 Kudos
Reply

1,044 Views
ayoubbenkhoris
Contributor I

Hi Philippe,

Thanks for the answer. On the logs you shared it looks like the PHY auto negotiation for ethernet 20b4000 timed out. Is it expected?

Also in our current configuration, we do not need to support both ethernet ports in u-boot but we would like to support them both at the same time in our own operating system.

We tried installing a Linux image and it looks like both ethernet ports are working. But then on our OS, the first ethernet is working fine, but for the second one we do not have access to bit 10 of the control register.

Do you know of any linux patch related to this issue?

Thanks,

Ayoub

0 Kudos
Reply

1,007 Views
ZeeFrench
NXP Employee
NXP Employee

Hi Ayoub,

Yes, timeout is expected if the negociation fail.

The original issue is that the siliconID of the phy has evolved over time :

https://community.nxp.com/t5/i-MX-Processors-Knowledge-Base/Patch-to-support-Ethernet-PHY-KSZ8081-Re...

Looks like the RMII clock is setup depending of this ID :

https://source.codeaurora.org/external/imx/linux-imx/tree/drivers/net/phy/micrel.c?h=lf-5.10.y&id=c7...

The patch you pointed has been removed in latest 5.15 kernel because it was not working with version RND :

https://source.codeaurora.org/external/imx/linux-imx/commit/arch/arm/mach-imx/mach-imx6ul.c?h=lf-5.1...

 The clock is now fixed in device tree instead :

https://source.codeaurora.org/external/imx/linux-imx/tree/arch/arm/boot/dts/imx6ul-14x14-evk.dtsi?id...

Best regards, Philippe.

0 Kudos
Reply