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.
Best regards, Benoît