i.MX6UL with KSZ8895 switch not working

[xavierdouville]

Hello

We designed a board using Digi's connect core 6UL (using the i.MX6UL).

We tried to follow the reference design (connect core 6UL starter kit) as much as possible but we replaced the Fast Ethernet PHY by a Micrel KSZ8895RQXI 5 ports switch. The connection used is RMII. With RXER tied low.

We modified the Linux device tree to use a fixed phy (fixed 100 Mbps full duplex, see attached file). We are not using MDIO or any other bus to configure the switch since default values are enough.

On the dev kit, we even cut the MDIO and MDC traces in order to confirm our modified kernel (and the Ethernet port) is working without MDIO.

However, on our board, we get a "no such device" error on boot and every time we issue a "ifconfig eth0 up" command.

I dug into the code a little and it seems the function fec_enet_mii_probe() is calling of_phy_connect() which returns NULL.

Problem has been reproduced using two BSPs:

Yocto 2.2 / Linux 4.1 and Yocto 2.4 / Linux 4.9

So the question is, how does the i.MX6UL and Linux detect whether there is a chip on the other end of the RMII connection? How can it work on the dev kit but not on our own board? Any hint on what we could be doing wrong?

Even when turning off the power of the PHY on the dev kit we can't reproduce the problem. Is there any bootstrap configuration related to Ethernet 1 we could be missing?

The KSZ8895 switch is working fine (well, the 4 other ports at least).

thanks

Xavier

[emintolgasivri]

Hi Xavier

I am using imx7 and ksz8895.Imx7 have 2 ethernet port.One of them goes to SW port.One of them goes to p5 port.Which one ethernet port should be fixed phy.

[xavierdouville · Accepted solution]

We found out the solution. It turned out the wrong device tree file was being loaded because the board_id was not set (unlike on the starter board). So nothing wrong with the hardware.

The "not found" phy is really not possible when the fixed phy is configured properly.

[wuweile]

我也遇到了这个问题，请问你们是怎么解决的？

[wuweile]

我也遇到了这个问题，请问你们是怎么解决的。

[igorpadykov]

Hi Xavier

one can check signals with oscilloscope and look on similar issue on

configure the ksz8765 5 port Ethernet switch 

NXP BSPs described below, do not support switches

i.MX Software|NXP 

Also may be useful :

KSZ8895 PHY Driver Porting Guide v1.0 

GitHub - downwith/linux-ksz8895: Mirror of https://git.alt-teknik.com/nathan/linux-ksz8895 

http://www.microchip.com/SWLibraryWeb/producttc.aspx?product=KSZ8895%20Software%20Linux%203.18 

[net-next,1/1] net: dsa: microchip: Add Microchip KSZ8895 DSA driver - Patchwork 

Best regards
igor

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[xavierdouville]

Hi Igor, thanks for replying

We do not need to configure the switch, as the default configuration suits our need (no VLAN or any other managed switch feature). We provisioned for SPI bus configuration, but don't plan on using it. We therefore shouldn't need any KSZ8895 specific driver. We are using the dumb, generic, fixed, phy driver. There is no link speed/duplex negotiation going on. Therefore we don't need any switch support from the BSP.

We checked the signals with an oscilloscope. RXD0, RXD1 and RXEN seems fine. We see data being sent from the switch to the i.MX6UL when sending broadcast packets on any of the other 4 switch ports.

The RMII clock is fine too, at 50 MHz. The switch wouldn't work without that clock.

What we haven't been able to test are the TX signals (TXEN, TXD0, TXD1) since Linux refuses to send any data in this "no such device" state.

[xavierdouville]

Hello Igor,

We may explore this driver (included as of Linux 4.13, but we are using 4.1 or 4.9) if we need some extra features. However, we shouldn't. It should work without a specific phy driver and without any management bus (SPI, SMI/MDIO) just like it does on our starter kit.

Xavier

[bernhardfink]

Hi Xavier,

I have seen something like this before. Can you please check how you configured the ethernet reference clock in your software. There are two things to consider:

• The clock going from the i.MX to the Switch/PHY. This is obviously used for the data sent from the i.MX to the Switch/PHY. Let's call this the TX path. Easy to check with an oscilloscope.
• In the other direction, the RX path, you need to understand that the RX block is asynchronous to the TX block, therefore it needs its own clock. It is derived from the TX clock, or let's say it's taken from the TX clock, but for this you need to set the so called SION bit in the respective IOMUXC_SW_MUX_CTL register. This configures the ref clock pin as an input for the RX block even if it is in principle a clock output for the TX block.

Regards,

Bernhard.

[Jacob_bai]

Hi Bernhard,

Our team got some issues with the imx8mm and ksz9893. We have had imx8qxp working with ksz9893 on enet2. Currently, all RX packages will be count as CRC error if we setup the fixed link to 1GB speed. But if we setup up to 100MB speed, the packages will be half-half (half working, half error), and I can ping the device with a chance of losing connection. Both imx8qxp and imx8mm using almost the same PCB design. Any idea for this?

Please email me if need more information, j.bai@optergy.com

Many thanks in advance,

Jacob