Hi, Benoit,
-----Original Message----- From: Benoît Thébaudeau [mailto:benoit.thebaudeau@advansee.com] Sent: Thursday, June 06, 2013 5:46 AM To: Fabio Estevam Cc: Andy Voltz; u-boot@lists.denx.de; Stefano Babic; Wang Huan-B18965 Subject: Re: [U-Boot] imx: Vybrid VF610 mac address issue
On Wednesday, June 5, 2013 11:16:17 PM, Benoît Thébaudeau wrote:
Hi Andy, Fabio,
On Wednesday, June 5, 2013 11:13:52 PM, Fabio Estevam wrote:
Hi Andy,
On Wed, Jun 5, 2013 at 5:54 PM, Andy Voltz andy.voltz@timesys.com
wrote:
I recently tried booting the VF610 support on the Tower board,
but
the mac address is reversed in Linux userspace. DHCP/BOOTP seems to work properly in u-boot.
I'm booting this kernel: https://github.com/Timesys/linux-timesys/ ref: 2c4ead2dd6da019f5052a69b12c8f5b6b71f8dca
I haven't yet seen how the address is passed to the kernel, but our previous u-boot support does not have this issue with the
same
kernel. That u-boot branch is also on our github.
The MAC address is read in the imx_get_mac_from_fuse() function in arch/arm/cpu/armv7/vf610/generic.c
Try printing all the elements of mac[] array in this function and check if the logic is correct there.
You probably had programmed the fuses with a MAC address on your board, and then replaced the existing U-Boot with the mainline version. These 2 U-Boot-s may interpret the MAC fuses in a different way. Especially, note that VF610 interprets the MAC fuses with reversed endianness compared to i.MX6 in mainline U-Boot. This is documented in doc/README.<SoC>. There may be the same difference between VF610 in mainline U-Boot and the other version of U-Boot that you used first.
But if there is such a difference between U-Boot editions, it might be worth considering to make mainline U-Boot more consistent with Freescale's or others' before it is too much widespread. It is especially important if people change the U-Boot edition on their board.
Stefano, Alison, what do you think?
Alison, have you checked if your implementation in mainline is consistent with Freescale's? There may be a difference both for which fuse word is used for high/low parts of the MAC address (i.e. word- level endianness that I was talking about above), and for the byte- level endianness inside each fuse word.
[Alison Wang] Thanks for your comments. In Vybrid's RM, there is no specific descriptions about how to program the mac address in the OTP Bank4 Word2(OCOTP_MAC0) and OTP Bank4 Word3(OCOTP_MAC1). So I think it is not formulary which fuse word is used for high/low parts of the MAC address (i.e. word-level endianness), and for the byte-level endianness inside each fuse word. Through reading the doc/README.vf610, I think the user could program the fuses correctly.
Best Regards, Alison Wang