KSZ8873 switch on AM1808 custom board

Hi, Manuel!

Can you give me your experience how was modified u-boot code?

Thank you.

Hello.

Well. I have exactly the same problem with the same chip KSZ8873 on OMAPL138.. Strange.. Did you find any solution to the problem?

Best regards,

Andreas

Hello,

Does anyone from TI knows what type of switch chip you are using on da830evm board?

There some code of activating a 3-port switch on for the board on da830evm  in the u-boot, but no idea the type of the chip. See below:

From - u-boot/boards/davinci/da8xxevm/da830evm.c

#if defined(CONFIG_DRIVER_TI_EMAC)

#define PHY_SW_I2C_ADDR    0x5f /* Address of PHY on i2c bus */

/*
 * Initializes on-board ethernet controllers.
 */
int board_eth_init(bd_t *bis)
{
    u_int8_t mac_addr[6];
    u_int8_t switch_start_cmd[2] = { 0x01, 0x23 };
    struct eth_device *dev;

    /* Read Ethernet MAC address from EEPROM */
    if (dvevm_read_mac_address(mac_addr))
        /* set address env if not already set */
        davinci_sync_env_enetaddr(mac_addr);

    /* read the address back from env */
    if (!eth_getenv_enetaddr("ethaddr", mac_addr))
        return -1;

    /* enable the Ethernet switch in the 3 port PHY */
    if (i2c_write(PHY_SW_I2C_ADDR, 0, 0,
            switch_start_cmd, sizeof(switch_start_cmd))) {
        printf("Ethernet switch start failed!\n");
        return -1;
    }

    /* finally, initialise the driver */
    if (!davinci_emac_initialize()) {
        printf("Error: Ethernet init failed!\n");
        return -1;
    }

    dev = eth_get_dev();

    /* provide the resulting addr to the driver */
    memcpy(dev->enetaddr, mac_addr, 6);
    dev->write_hwaddr(dev);

    return 0;
}
#endif /* CONFIG_DRIVER_TI_EMAC */

I wonder if something similar is required for KSZ8873MLL. I have checked the datasheet of KSZ8873MLL, there is a register at the same location 0x01 with a bit to switch on the phy switch, but says is "on" after the power up...

Thanks

Andreas

Hello Idle,

Sorry for the late response. I hope is not too late.

What I did was to use the drivers/net/davinci_emac.c driver as a base driver and modify it to fit my platform. The changes that I did was to replace the functions that call the MDIO bus by my own functions which use the I2C interface. I was able to get the ping responses and use the TFTP protocol for loading the Kernel image after I fixed a problem in the hardware design with the pin28 (SMTXER3) in the KSZ8873 chip. This pin was connected to a GPIO to the processor which was set to high, this indicated to the switch that the port3 link was down, so nothing was forwarded to this port.

Then I thought that I could do the same in the Linux Kernel, but it wasn't so easy to work with the PHY libraries using as communication interface the I2C bus. We had to do some hardware redesign for other reasons and at the same time we change the switch's control interfafe to use MII (MDIO). When we had the new hardware I could use the Uboot and Linux kernel drivers from TI. I needed to add a new PHY indentifier to the PHY level.

Andreas, check the pin28 on the KSZ8873 if it is high or low. If it is high, you are telling to the switch that the port3 link is down, so nothing will be forwarded to this port.

I hope some of the information was useful for you.

Best regards,

Manuel.

Hello Manuel!

Thank you for you answer!

We have board with two DM8168 placed on it. MDIO lines connected only to CPU0. I solved problem with KSZ8873 in u-boot for CPU1: replace functions that working with MDIO to my own functions. In CPU0 they stay the same as in original u-boot source code. In linux side I set PHYID in "", as mentioned in linux/include/linux/davinci_emac.h and phy start working properly with two CPUs.

Hi,

Thank you very much for your response. Do you mean Pin27? SMTXER3 is pin27. It is wired to the ground with a resistor. I don't see a problem with that. I am using MDIO BitBang and I can access all the phy resisters. I am doing a bit more investigation and I will update the list with my findings soon.

Best regards,

Andreas

Hi Andreas,

You are right, the pin is the number 27 (SMTXER3). I think it is ok that you have it grounded with a resistor. In our design we have it with a pull-up and I have to set it low before I can receive any frames.

Have you set the MAC addresses of the ports 1 and 2?

When I was debugging my problem, I went through all the port counters in order to find out what was my problem. I know that it is quite tedious task, but if you have all the settings correctly done, it is the only way to find out why you cannot receive data.

Thank you for the MDIO BitBang idea, I think this is a good solution for me also which I need to check, because right now I can access only MDIO "standard" registers and I cannot access the ones defined by Micrel.

Best regards,

Manuel.

Hi,

When I am done, I will post the bitbang MDIO code to access from the u-boot all KSZ8873 registers.

The situation is a bit awkward here. There is a redboot working with the board, but there is no source code available for that. When I use the redboot, I can do tftp without problem and download images. However, with the u-boot I can see only ARP packets going out but the responses seem not getting to the EMAC. The u-boot, starts from NOR parallel flash the same as the redboot, without the use of the AIS header.

When booting from the flash and not using AIS header, you need to initialise all the PLLs, DDR, GPIOs , etc.  It is possible to run the u-boot after the redboot has started. Simply, I download the u-boot into  RAM, and ask the redboot to "go"  there. Then the u-boot starts properly, initialises everything,  PLLs, DDRs,GPIOs etc, and the tftp works properly from the u-boot! I used the MDIO bitBang from the u-boot, and I observe that the PHY registers have the same values as when I start with u-boot only.  Also, on every open EMAC  operation from the u-boot,  the davinci_emac open function resets the whole EMAC controller,  and all the registers are getting their initial values. As it stands at the moment, I have compared the following registers between the working redboot  and the u-boot with net not working, checked  SYSCFG0, SYSCFG1, PLL0, PLL1, Power Module control registers PSC0, and PSC1, all have the same values.

I am still investigating the cause of the problem...If you have any ideas where to loot at, please let me know.

Best regards

Andreas

Hello Andreas,

Please, try to use the mii tool in u-boot console in order to see if the EMAC driver detects your MII device, in this case is the KSZ8873 as PHY device.

I get:

> mii device
MII devices: 'KSZ8873 @ 0x01' 'KSZ8873 @ 0x02' 'KSZ8873 @ 0x03'
Current device: 'KSZ8873 @ 0x01'

Do you get any errors when u-boot initializes EMAC?

I get:

Net:   DaVinci-EMAC
Hit any key to stop autoboot:  0

Regards,

Manuel.

Hello Manuel,

There is no error when detecting the PHY, it comes up and I get

>mii device
MII devices: 'KSZ8873 @ 0x01' 'KSZ8873 @ 0x02' 'KSZ8873 @ 0x03'
Current device: 'KSZ8873 @ 0x01'

It seems ok.

I have programmed the phy and make the port 3 (MII) sniffer port with port 1,2 enabled to forward to the sniffer port, but not frames going to the host.

Regards,

Andreas