Working on this too (workmate of thread author): we finally choosen a fast Linux userland workaround. A custom sysvinit script read EEPROM /sys/fsl_otp/* registers and reset eth{0,1} mac addresses from them and this mapping:
# __________________________ ________________________
# | (MSB) MAC-ETH1 (LSB)|(MSB) MAC-ETH0 (LSB) | (6 + 6 bytes)
# -------------------------- -------------------------
# |HW_OCOTP_HDCP_KSV0 | HW_OCOTP_MAC1 | HW_OCOTP_MAC0| (4 + 4 + 4 bytes)
# ----------------------------------------------------
For information (I may be wrong somewhere), bug appears to be on UBoot side.
The device tree given to Linux kernel contains the same MAC address for both ethernets ("local-mac-address" property on their node, read by Linux fsl fec driver in fec_main.c:fec_get_mac). This property appears to be set by UBoot but I have not digged into it to locate the root bug. Big lines appears to be as follow:
- UBoot > fdt_support.c > fdt_fixup_ethernet()
- alters device-tree by creating fdt property /alias/ethernet%d/local-mac-address with the value of envvar ethaddr for ethernet0, and envvar eth%daddr for next ethernets.
- UBoot > sys_eeprom.c > mac_read_from_eeprom()
- Appears to auto-create envvars ethaddr and eth%daddr from eeprom.
- But strangely I only seen ethaddr envar, not eth1addr this function should have created.
- And the algorithm appears to read n*6 consecutive bytes (in our case dual fec =12 bytes EQU 3 registers of 4 bytes each) beeing eth0 then eth1 from their MSB to their LSB which does not match the mapping I finally used (I read mac-eth1 then mac-eth0 in my script).
