TE803 + TEBF0808 MAC address

[TimN]

Hi

I'm using a TE803 and TEBF0808 with the StarterKit petalinux project and am trying to understand how the MAC address gets assigned to the Zynq ethernet interface. As I understand it, the FSBL sets the I2C mux at 0x73 to allow EEPROM access, then u-boot reads the MAC at initialisation from one of the Microchip EEPROM devices. The platform-top.h file in my project indicates this is the device at I2C address 0x50, offset 0xFA. However u-boot and petalinux both report a MAC address different from the one I can see in any of the three EEPROMS:

U-boot:

Code: [Select]

ZynqMP> printenv
...
ethaddr=80:1f:12:02:10:24
...

OS:

Code: [Select]

root@petalinux:~# ifconfig eth0
eth0      Link encap:Ethernet  HWaddr 80:1F:12:02:10:24

EEPROMS:

Code: [Select]

root@petalinux:~# i2cdump -y 6 0x50
No size specified (using byte-data access)
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f    0123456789abcdef
00: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
...<snip>...
f0: ff ff ff ff ff ff ff ff ff ff 80 1f 12 c2 18 b5    ..........??????
root@petalinux:~# i2cdump -y 6 0x51
No size specified (using byte-data access)
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f    0123456789abcdef
00: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
...<snip>...
f0: ff ff ff ff ff ff ff ff ff ff 80 1f 12 c2 4b ef    ..........????K?
root@petalinux:~# i2cdump -y 6 0x52
No size specified (using byte-data access)
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f    0123456789abcdef
00: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
...<snip>...
f0: ff ff ff ff ff ff ff ff ff ff 80 1f 12 c2 07 1c    ..........??????

I can see that the MAC reported is a Microchip OUI, but the bottom three octets don't match any of the three EEPROMS.

What am I missing?

Thanks

Tim

[JH]

Hi,
did you use the 18.3 reference design or older one or own one?

We have implement EEPROM read with 18.3 there was 3 changes needed
1. set I2C mux with FSBL to EEPROM before uboot starts
2. enable and modify Xilinx example in platform-top.h
3. remove random MAC in petalinux config

See also https://wiki.trenz-electronic.de/display/PD/TE0803+StarterKit#TE0803StarterKit-SoftwareDesign-PetaLinux

On boot process uboot should tell you that it used EEPROM MAC, as long as this output does not appear, it use random MAC.

br
John

[TimN]

Hi John

I'm using the 2018.3 StarterKit reference design. It appears to be performing all the steps you describe. Here's the FSBL/u-boot output on the console:

Code: [Select]

--------------------------------------------------------------------------------
TE0803 TE_XFsbl_HookPsuInit_Custom
Configure Carrier I2C Switch 0x77
Configure TE0808 SI5338
Si5338 Init Registers Write.
Si5338 Init Complete
USB Reset Complete
PCIe Reset Complete

--------------------------------------------------------------------------------

--------------------------------------------------------------------------------
Xilinx Zynq MP First Stage Boot Loader (TE modified)
Release 2018.3   Sep 18 2019  -  13:31:26
Device Name: XCZU4CG

--------------------------------------------------------------------------------
TE0803 TE_XFsbl_BoardInit_Custom
Configure Carrier I2C Switch 0x73 for EEPROM access

--------------------------------------------------------------------------------
NOTICE:  ATF running on XCZU4CG/silicon v4/RTL5.1 at 0xfffea000
NOTICE:  BL31: Secure code at 0x0
NOTICE:  BL31: Non secure code at 0x8000000
NOTICE:  BL31: v1.5(release):xilinx-v2018.2-919-g08560c36
NOTICE:  BL31: Built : 15:15:19, Aug  9 2019
PMUFW:  v1.1


U-Boot 2018.01 (Aug 09 2019 - 15:15:56 +0000) Xilinx ZynqMP ZCU102 rev1.0

I2C:   ready
DRAM:  2 GiB
EL Level:       EL2
Chip ID:        zu4cg
MMC:   mmc@ff160000: 0 (eMMC), mmc@ff170000: 1 (SD)
Using default environment

In:    serial@ff000000
Out:   serial@ff000000
Err:   serial@ff000000
Board: Xilinx ZynqMP
Bootmode: SD_MODE1
Net:   ZYNQ GEM: ff0e0000, phyaddr 1, interface rgmii-id

Warning: ethernet@ff0e0000 using MAC address from ROM
eth0: ethernet@ff0e0000
U-BOOT for petalinux

ethernet@ff0e0000 Waiting for PHY auto negotiation to complete......................................... TIMEOUT !
Hit any key to stop autoboot:  3
ZynqMP> printenv ethaddr
ethaddr=80:1f:12:02:10:24

In an earlier test I mistakenly used the FSBL built by petalinux, which doesn't set the I2C max so I got a random MAC, but in this case I'm using an FSBL built in SDK as per the wiki instructions. The MAC is also not fully random - it has the Microchip OUI in first 3 bytes of the MAC (80:1f:12), but the last three don't match any of the 3 EEPROMs.

platform-top.h appears to set up correctly also:

Code: [Select]

/*Define CONFIG_ZYNQMP_EEPROM here and its necessaries in u-boot menuconfig if you had EEPROM memory. */
#define CONFIG_ZYNQMP_EEPROM
#ifdef CONFIG_ZYNQMP_EEPROM
#define CONFIG_SYS_I2C_EEPROM_ADDR_LEN  1
#define CONFIG_CMD_EEPROM
#define CONFIG_ZYNQ_EEPROM_BUS          0
#define CONFIG_ZYNQ_GEM_EEPROM_ADDR     0x50
#define CONFIG_ZYNQ_GEM_I2C_MAC_OFFSET  0xFA
#endif

Thanks

Tim

[JH]

Hi,
I can reproduce this issue here.
But Uboot say it read some EEPROM MAC.

Warning: ethernet@ff0e0000 using MAC address from ROM

this procedure is available since two or three vivado/petalinux versions and I've updated designs from time to time. I did not checked again on every series if it's still the correct one as long as Uboot tell me he reads from eeprom.
The question is what's going wrong.

I found this AR from Xilinx for ZCU102 and 19.1:

• https://www.xilinx.com/support/answers/72401.html

I didn't test 19.1 until now, it's on my todo. either Xilinx has change procedure to read eeprom mac or such a patch is also need when you has this entry on u-boot.
PS: the part that shown in the AR also  EEPROM MAC and environment MAC should also appears, when you add again the mac on the petalinux config.
Maybe you add this again to see what he read. and maybe use one time an invalid EMMC address to see if uboot still say it use the eeproom address or if it will print an error.

I will check this also during the next week. Maybe I will also install 19.1 to check what Xilinx has changed in this procedure to read eeprom mac.

br
John

[JH]

Hi,
I've test again with an TE0808(-04-09EG-2IB) and with another TE0803(-01-04CG-1EA) module. On both the mac was the same like on the eeprom. I've put linux and uboot screenshot from TE0803 on the attachment.

On Friday I was using a wrong setup on an module carrier combination where I must test some other things where I can't guarantee this functionality. It was also different to your behaviour, on this setup it got an totally different mac .

Can you tell me which TE0803 assembly variant you use?


br
John

[TimN]

Hi John

That's interesting. I've got a TE0803-02-04CG-1EA (with the TE0BF0808-04A carrier).

I'm about to try your suggestion from Friday: fixing the MAC address in petalinux-config to see what u-boot reports for the mismatch between the two.

Thanks

Tim

[JH]

Hi,
Okay, please give me feedback when you've tested it. Also when you set and address which is not accessible

PS: Did you test also with the prebuilt Boot.bin and image.ub for your assembly version from this ZIP: TE0803-StarterKit-vivado_2018.3-build_05_20190507093424.zip

br
John

[TimN]

Hi John

OK, results of the three tests:

1. Using the prebuilt images from the StarterKit download results in the same false MAC address (80:1F:12:02:10:24) being picked up and used by u-boot and Linux.

2. Configuring an explicit MAC address in petalinux-config results in the following output from u-boot:

Code: [Select]

Warning: ethernet@ff0e0000 MAC addresses don't match:
Address in ROM is          80:1f:12:02:10:24
Address in environment is  00:0a:35:00:d0:0f
eth0: ethernet@ff0e0000
U-BOOT for petalinux
i.e. u-boot still reads the false MAC from EEPROM but then uses the environment MAC when the OS boots.

3. Modifying project-spec/meta-user/recipes-bsp/u-boot/files/platform-top.h to use a false I2C device address (0x53 instead of 0x50) results in u-boot complaining the read fails and then using a random MAC:

Code: [Select]

Net:   ZYNQ GEM: ff0e0000, phyaddr 1, interface rgmii-id
I2C EEPROM MAC address read failed

Warning: ethernet@ff0e0000 (eth0) using random MAC address - 56:79:41:43:6f:ef
eth0: ethernet@ff0e0000
U-BOOT for petalinux

I also tried another experiment, which was to write a similar MAC address into the bottom R/W 6 bytes of the EEPROM at address 0x50 and changing platform-top.h to #define CONFIG_ZYNQ_GEM_I2C_MAC_OFFSET 0x0. u-boot then reads and uses this MAC correctly:

Code: [Select]

Warning: ethernet@ff0e0000 using MAC address from ROM
eth0: ethernet@ff0e0000
U-BOOT for petalinux

ethernet@ff0e0000 Waiting for PHY auto negotiation to complete......................................... TIMEOUT !
Hit any key to stop autoboot:  0
ZynqMP> printenv ethaddr
ethaddr=80:1f:12:c2:18:b6
ZynqMP>
So it appears it is something to do with u-boot reading from the upper R/O part of the EEPROM perhaps?

Tim

[JH]

Hi,

So it appears it is something to do with u-boot reading from the upper R/O part of the EEPROM perhaps?

The question is why it works with my board.
There are 2 other EEPROMs with MAC on the TEBF0808, can you read the upper part of the EEPROM on this devices with Uboot?  There is also an eeprom on te0803 on the same bus like SI5338(in this case you must remove last I2C mux changes on FSBL)

At first try manually with uboot?
--> i2c md 0x50 0xFA
--> i2c md 0x51 0xFA
--> i2c md 0x52 0xFA
And than change use one of the other for uboot mac read.
br
John

[TimN]

Hi John,

At first try manually with uboot?
--> i2c md 0x50 0xFA
--> i2c md 0x51 0xFA
--> i2c md 0x52 0xFA

All three are readable, although 0x50 unsurprisingly shows the 'fake' address that gets used by u-boot/petalinux:

Code: [Select]

ZynqMP> i2c md 0x50 0xfa
00fa: 80 1f 12 02 10 24 80 1f 12 c2 18 b6 ff ff ff ff    .....$..........
ZynqMP> i2c md 0x51 0xfa
00fa: 80 1f 12 c2 4b ef ff ff ff ff ff ff ff ff ff ff    ....K...........
ZynqMP> i2c md 0x52 0xfa
00fa: 80 1f 12 c2 07 1c ff ff ff ff ff ff ff ff ff ff    ................
NB The adjacent MAC (c2:18:b6) shown for 0x50 is where the address wraps back to 0 to the test one I used yesterday.

Booting with the MAC read from 0x51 or 0x52 correctly returns the expected addresses (c2:4b:ef and c2:07:1c respectively). As suggested I also tried the te0803 EEPROM at 0x50, disabling the I2C mux setup in the FSBL. That boots correctly with the expected MAC. By the way, I couldn't find any reference to this device in the te0803 TRM, I had to look at the schematic.

Faulty EEPROM on the carrier? Marginal timing? Does the I2C bus get clocked at a different speed for FSBL/u-boot vs petalinux?

Thanks again for your continued help with this.

Tim

[JH]

Hi,

. By the way, I couldn't find any reference to this device in the te0803 TRM, I had to look at the schematic.

https://wiki.trenz-electronic.de/display/PD/TE0803+TRM#TE0803TRM-ConfigurationEEPROM

Did you use TRM as PDF? maybe an older version additional EEPROM was add with REV01 update.
https://wiki.trenz-electronic.de/display/PD/PCN-20180817+TE0803-01+to+TE0803-02+Hardware+Revision+Change

Faulty EEPROM on the carrier? Marginal timing? Does the I2C bus get clocked at a different speed for FSBL/u-boot vs petalinux?

At the moment I've no idea, why this happens only on your board. Maybe a few very unfavourable conditions with the tolerances between all devices.

And yes, I2C can be handle different on barmetal, Uboot and linux, depending on the drivers.
https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/18841822/I2C-PS+standalone+driver
https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/18842029/U-Boot+I2C+Driver
https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/18841974/Linux+I2C+Driver

I've compared one time the read values:
hex:
80 1f 12 02 10 24
80 1f 12 c2 18 b5
binary:
‭100000000001111100010010 0000 0010 0001 0000 0010 0100‬
‭100000000001111100010010 1100 0010 0001 1000 1011 0101‬
But I can't see a system there.
Do you have an second carrier and/or an second module to test other combinations?

br
John

[TimN]

Hi,

Did you use TRM as PDF? maybe an older version additional EEPROM was add with REV01 update.

Ah yes, I did. Thanks, I see the difference now.

Do you have an second carrier and/or an second module to test other combinations?

Currently I only have one module/carrier system although we have plans to purchase more soon. For now I'm happy that we have narrowed down the problem somewhat and I know that my workflow is basically correct. For now, I'll probably stick with an FSBL/u-boot combination that uses the te0803 on-board EEPROM since that may suit our longer-term plans.

So I'm happy to leave this investigation where it is now. Thanks very much for your support and feedback - I've learned a lot in the process!

Cheers

Tim