On Tuesday 08 December 2015 09:55 PM, Tony Lindgren wrote: > * kernel@xxxxxxxx <kernel@xxxxxxxx> [151207 09:17]: >> Hi Tony, >> >> there are two ethernet interfaces ( dual-emac-configuration ) used. >> One is connected to another 100mbit switch-ic ( refclk should come from >> switch ic ) via rmii, the other one is connected to a 1gbit fpga rgmii >> interface ( where the clock is served from the fpga ). This means you have both the interfaces with MAC-to-MAC interface. Is MDIO is active or did you disabled it as it is not needed (because of no phy present in the system)? >> >> On both interfaces it may happen that the clock isn't present while the >> mac-address is set (fpga may not have been inited, switch chip could be >> held in reset), but this was the same behaviour with previous kernel >> (3.14 with cpsw patched from ti tree) where this configuration worked. >> As the hardware is in field now there is no chance to change hardware. >> >> On the other hand: when not setting the mac of the interface that early, >> the cpsw seems to init proberly but a ping to the outer world does not >> work either, so something else may be different on the new kernel. > > Maybe Mugunthan has some ideas what's going on here. > If MDIO is disabled and CPSW is not brought up then CPSW clocks are gated and when you try to set the mac address the system will crash as the driver try to access CPSW registers with CPSW clocks gated. Can you try below options and see what happens * Instead of setting the mac address using *ip link set address*, try to use u-boot env variable (ethaddr/ath1addr) to set the mac address. * You must be storing the MAC address in EEPROM or somewhere, just try to implement the mac address reading mechanism in drivers/net/ethernet/ti/cpsw-common.c file to avoid setting of mac address from userspace. Regards Mugunthan V N -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html