Second ethernet MAC address

We need to have a second Ethernet port on our VF61 carrier. Can the MAC address for this second Ethernet device be stored on the module itself?

Our current plan is to have a MAC ID chip on the carrier board connected through an I2C port, but if there’s a way to do this on the module itself, it might be preferable.

Also, if we end up doing this on our carrier, how/when do we read this MACID through I2C and get it into the OS?

@haydin
Please let us know which OS you plan to use. Windows CE or Linux?

@roman.schnarwiler : We’re planning to use Linux

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

@bhuvanchandra.dv

Note that I am not asking how to use the second ethernet controller. I am talking about how to assign a second MAC address.

Moreover, because of pin constraints, we will not be able to use the second RMII interface, rather, we will have to use an SPI-based ethernet controller.

The secondary MAC address may be allocated from block 0x100000 higher then the first MAC address. In U-Boot this can be achieved by the CONFIG_TRDX_CFG_BLOCK_2ND_ETHADDR configuration option:

http://git.toradex.com/cgit/u-boot-toradex.git/tree/board/toradex/common/common.c?h=2015.04-toradex#n100

More information about our MAC address/serial number handling can be found in the following article:

@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.

@stefan.agner : We’re planning to use Micrel KSZ8851SNLI part number as the SPI ethernet controller. Datasheet link: ww1.microchip.com/downloads/en/DeviceDoc/ksz8851snl_ds.pdf

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.