i.MX Processors中的主题 Re: Two mac address in fuse

Two mac address in fuse

ambroisealgrin — Fri, 29 Jan 2016 08:11:38 GMT

Hi,

I'm working on an imx6 solo X and i need two 48bits mac addresses.

The solo x has three fuse register for mac address : OCOTP_MAC0, OCOTP_MAC1 and OCOTP_MAC2.

Is it right doing this :

MAC address 1 = OCOTP_MAC0 + OCOTP_MAC1[31:16]

MAC address 2 = OCOTP_MAC1[15:0] + OCOTP_MAC2

with MSB in OCOTP_MAC0 and OCOTP_MAC1[15:0] ?

Re: Two mac address in fuse

BiyongSUN — Fri, 29 Jan 2016 09:54:02 GMT

=> fuse read 4 2 1
Reading bank 4:

Word 0x00000002: 9f037d3b
=> fuse read 4 3 1
Reading bank 4:

Word 0x00000003: 7d3c0004
=> fuse read 4 4 1
Reading bank 4:

Word 0x00000004: 00049f03

root@imx6sxsabresd:~# ifconfig
eth0      Link encap:Ethernet HWaddr 00:04:9F:03:7D:3B
          UP BROADCAST MULTICAST MTU:1500 Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)

eth1      Link encap:Ethernet HWaddr 00:04:9F:03:7D:3C
          UP BROADCAST MULTICAST MTU:1500 Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)

Re: Two mac address in fuse

ambroisealgrin — Fri, 29 Jan 2016 10:00:15 GMT

Perfect ! Thank you !

Re: Two mac address in fuse

art — Wed, 03 Feb 2016 09:23:11 GMT

The OCOTP_MAC0, OCOTP_MAC1 and OCOTP_MAC2 fuse registers are actualy just a non-volatile OTP storage, and software can treat it in any desired way. The current Linux driver uses it as follows.

OCOTP_MAC0[31:0] - lower 32 bits of ENET0 MAC address

OCOTP_MAC1[15:0] - upper 16 bits of ENET0 MAC address

OCOTP_MAC1[31:16] - lower 16 bits of ENET1 MAC address

OCOTP_MAC2[31:0] - upper 32 bits of ENET1 MAC address

Have a great day,
Artur

Re: Two mac address in fuse

anthony-loiseau-act — Fri, 04 Mar 2016 15:39:28 GMT

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