MIIM / SMI "ETH Connected" check on eth-switch

[maxhil]

Hi,

I am trying to integrate an ethernet Switch (Microsemi KSZ8864 series with four Ports, of which two PHYs and two RMII) with an ESP32.
MIIM connection and access to the standard registers works.
The Issue I have is, that I can only check one PHY of the Switch for a valid connection at a time.

So for example, when I set define ETH_PHY_ADDR to 0x2, I only get "ETH Connected" for PHY1 of the switch,
and when I set ETH_PHY_ADDR to 0x3,I only get "ETH Connected" for PHY2 of the switch.

Both PHY´s of the KSZ8864 switch 100baseT fine, just the ESP32 only begins receiving packets when it sees "ETH Connected" on one particular port.

Is there a way to check for a connection on both PHYs of the switch? i guess I am missing something obvious...

[ESP_morris]

Hi,

I am trying to integrate an ethernet Switch (Microsemi KSZ8864 series with four Ports, of which two PHYs and two RMII) with an ESP32.
MIIM connection and access to the standard registers works.
The Issue I have is, that I can only check one PHY of the Switch for a valid connection at a time.

So for example, when I set define ETH_PHY_ADDR to 0x2, I only get "ETH Connected" for PHY1 of the switch,
and when I set ETH_PHY_ADDR to 0x3,I only get "ETH Connected" for PHY2 of the switch.

Both PHY´s of the KSZ8864 switch 100baseT fine, just the ESP32 only begins receiving packets when it sees "ETH Connected" on one particular port.

Is there a way to check for a connection on both PHYs of the switch? i guess I am missing something obvious...

Yes I think so. The Ethernet driver didn't take the switch into account so it will be a little for your application. For example, during driver initialization, it will set the PHY address into ESP32's some register and this address won't be updated later any more. Theoretically, the SMI APIs should take a parameter called **phy_addr**, but for now, we only have void esp_eth_smi_write(uint32_t reg_num, uint16_t value);, so you can only access only one PHY after driver initialization.

Sorry about that, but the good news is, we're refactoring Ethernet driver now (4.0 feature), this time, Ethernet driver will be much flexible.

[maxhil]

Hello Morris, thanks for the answer. Yes it would be great if the SMI functions would be able to take an PHY_ADR argument in addition to the register number. This would also enable access to some of the non-standard SMI registers in my case (KSZ8864CNX-datasheet page 37 paragraph 3.6 if you are interested).

[Nishi_D]

Hello Team,

We are using “KSZ8895" 5 port internet switch , which has SMI (MDIO/MDC) interface .

I am using , KSZ8863 code ( Two Port Mode) as reference design.


Fortunately , I am able to read the Port5/Host configuration ( in case KSZ8863 -Port 3 Host configuration port ) using SMI configuration ( I have bypass SPI/I2C call by setting NULL )

.read_phy_reg = NULL, \
.write_phy_reg = NULL, \


For for next two ports p1 & p2 port , I am not able to divert calls to SMI & getting exception
e.g for configuration
emac_esp32_write_phy_reg


I have noticed KSZ8863 has unimplemented SMI handing switch case in the code “ksz8863_ctrl.c”.

Could you please suggest, How I can divert P1& P2 phy read/write calls to SMI interface .

[ESP_ondrej]

If I remember correctly, it is not possible to access all registers via SMI => you can manage only host port and you cannot mange the other ports or switch configuration. That was the reason why SMI is not implemented because it didn't worth. Please consult with switch chip documentation for more info.

[ESP_ondrej]

I double checked and I was kind of wrong. SMI is non standard version of MII so it was not implemented due to lack of time. You can access all registers via SMI. Try the following:
* remove `ksz8863_ctrl_intf_init` from `ksz8863_board_specific_init` so the I2C/SPI is not going to be initialized
* update `ETH_KSZ8863_DEFAULT_CONFIG` by removing `ksz8863_phy_reg_read/write` so the EMAC SMI interface will be used.
* Then you need to properly update `eth->phy_reg_read/write`calls in `esp_eth_phy_ksz8863.c` to make sure that it properly constructs SMI frame as defined by datasheet (PHY address/reg. address).

[ESP_ondrej]

Once I have time I'll have a look at it in more details. I created https://github.com/espressif/esp-eth-drivers/issues/20

[Nishi_D]

Thanks for the suggestion ,

I have tried as suggested by you & it's working fine with host port ( I am able to read chip ID and other register ).

Unfortunately, Port 1 & Port 2 calls are not routing through SMI phy read and phy write

Do I need to map SMI Calles to following functions ?


pmac->parent.write_phy_reg = ??
pmac->parent.read_phy_reg = ??

or suggest how I can Port 1 And port 2 call to SMI interfaces

[ESP_ondrej]

Fuu, it was very long day today but I now fully recall why I didn't implement the SMI in KSZ8863 driver. It is not possible on ESP32! It's not fault of the ESP32 though. I'll try to explain.

In terms of KSZ8863 terminology, SMI is non-standard version of IEEE 802.3 MII Management Interface (MIIM), see section 3.3.10 and 3.3.11 of KSZ8863 datasheet. The main differences between these two are "OP code" numbering and address format. MIIM's read OP code is 10b and write OP code is 01b. While SMI read and write have both OP code 00b. Since the ESP32 EMAC follows the IEEE 802.3 MII Management Interface standard, we are not able to set OP code to 00b, see ESP32 EMACMIIADDR_REG register. There is no such option.

Luckily for you, it seems that Micrel/Microchip realized it and KSZ8895 SMI format is different. Read OP code is 10b and Write OP code is 01b - the same as for MIIM, see TABLE 3-13, Section 3.7 of https://ww1.microchip.com/downloads/aem ... 002246.pdf.

Therefore, you can use `emac_esp32_read/write_phy_reg` functions. As I've already said, update `ETH_KSZ8863_DEFAULT_CONFIG` by removing custom PHY read/write functions `ksz8863_phy_reg_read/write`, i.e. set those to NULL to use internal `emac_esp32_read/write_phy_reg` functions. And most importantly, update `eth->phy_reg_read/write`calls in `esp_eth_phy_ksz8863.c` with appropriate address format as defined in TABLE 3-13, Section 3.7.