Vybrid has two on-chip Ethernet controllers available via two independent RMII interfaces. One controller is connected to the on-module PHY which is used according to the standard Colibri Ethernet pin-out. To use the second on-chip Ethernet controller an external PHY (on the carrier board) needs to be connected to the RMII interface. Refer to the datasheet and the Dual Ethernet Carrier Board example schematic for Colibri VF50/VF61.
To enable software support for the second Ethernet controller, a custom device tree is required. Our Kernel tree contains a custom device tree for the dual Ethernet Colibri Carrier Board: Device trees for dual Ethernet Board
@haydin, @bhuvanchandra.dv, mac address assignment is Ethernet device specific, hence all depends what kind of SPI based ethernet device you plan to use…
The FEC driver, which is used for the on-board ethernet controller, is able to read the MAC address from the device tree as well as adopt the value from the FEC registers already set by the boot loader (for the exact details examine the fec_get_mac function in drivers/net/ethernet/freescale/fec_main.c).
Toradex assigns two MAC addresses from our OUI 00:14:2d (Organizationally Unique Identifier). Those two MAC addresses are ment to be assigned for the two available Ethernet controller, however I don’t see any problem to use it for another Ethernet device.
Those two MAC addresses are generated from the serial number and are available as environment variables in U-Boot ( ethaddr and eth1addr). U-Boot assigns this environment variables to the Ethernet device(s) specified in the device tree aliases section (our dual-eth device tree has this section specified).
For the SPI device: I would make sure the device driver is able to retrieve the MAC address from the device tree. If this is the case, an alias entry which links to your second Ethernet device (the SPI slave node) should be enough to assign our second MAC address to your device.
On a quick glance, the code of the driver ks8851.c (which is probably handling that chip) says this:
* ks8851_init_mac - initialise the mac address
* @ks: The device structure
* Get or create the initial mac address for the device and then set that
* into the station address register. If there is an EEPROM present, then
* we try that. If no valid mac address is found we use eth_random_addr()
* to create a new one.
So it seems that is an option to use a external EEPROM. If you are not using that, the driver seems to generate a random address. If you want to use our MAC, add the DT data and lift the device tree code from fec_get_mac in fec_main.c.