[U-Boot] imx: Vybrid VF610 mac address issue

[U-Boot] imx: Vybrid VF610 mac address issue

[Andy Voltz]

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.

Any ideas?

Thanks
-- 
Andy Voltz
Timesys Corporation

[U-Boot] imx: Vybrid VF610 mac address issue

[Fabio Estevam]

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.

Regards,

Fabio Estevam

[U-Boot] imx: Vybrid VF610 mac address issue

[Benoît Thébaudeau]

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.

Best regards,
Beno?t

[U-Boot] imx: Vybrid VF610 mac address issue

[Benoît Thébaudeau]

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

[U-Boot] Vybrid VF610 mac address issue

[Wang Huan-B18965]

Hi, Andy, Fabio, Beno?t,

> -----Original Message-----
> From: u-boot-bounces at lists.denx.de [mailto:u-boot-bounces at lists.denx.de]
> On Behalf Of Beno?t Th?baudeau
> Sent: Thursday, June 06, 2013 5:16 AM
> To: Fabio Estevam
> Cc: u-boot at lists.denx.de
> Subject: Re: [U-Boot] imx: Vybrid VF610 mac address issue
> 
> 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.
> 
[Alison Wang] First of all, the mac address is set in include/configs/vybrid.h as below in Andy's previous u-boot version.
#define CONFIG_ETHADDR		00:e0:0c:bc:e5:60
#define CONFIG_IPADDR		10.81.67.175
Because no hardcoded IP addresses/MAC addresses should be set there, I change the codes. As Fabio said, the mac address is read in the imx_get_mac_from_fuse() function in arch/arm/cpu/armv7/vf610/generic.c now.

I think Andy may not program the mac address correctly in fuses on his board with the mainline version. On my board, the fuses are programmed like this,
The value of OTP fuse Bank4 Word2 is 0x000000e0
The value of OTP fuse Bank4 Word3 is 0x0cbce560

So the mac address can be read from imx_get_mac_from_fuse() function in u-boot. Then we can get "ethaddr=00:e0:0c:bc:e5:60" in u-boot environment variables as below.
Vybrid U-Boot > pri
baudrate=115200
bootdelay=3
ethact=FEC
ethaddr=00:e0:0c:bc:e5:60
stderr=serial
stdin=serial
stdout=serial

Environment size: 121/8188 bytes

Andy, did you program the fuses as above? How about the result after programming the fuses as above?

Best Regards,
Alison Wang

[U-Boot] imx: Vybrid VF610 mac address issue

[Wang Huan-B18965]

Hi, Benoit,

> -----Original Message-----
> From: Beno?t Th?baudeau [mailto:benoit.thebaudeau at advansee.com]
> Sent: Thursday, June 06, 2013 5:46 AM
> To: Fabio Estevam
> Cc: Andy Voltz; u-boot at 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

[U-Boot] imx: Vybrid VF610 mac address issue

[Benoît Thébaudeau]

Hi Alison,

On Thursday, June 6, 2013 5:36:23 AM, Wang Huan-B18965 wrote:
> Hi, Benoit,
> 
> > -----Original Message-----
> > From: Beno?t Th?baudeau [mailto:benoit.thebaudeau at advansee.com]
> > Sent: Thursday, June 06, 2013 5:46 AM
> > To: Fabio Estevam
> > Cc: Andy Voltz; u-boot at 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.

I agree. I only had a concern if Freescale had released a VF610 BSP requiring
the MAC fuses to be programmed in a different way. According to what you said in
your previous e-mail, this is not the case, so everything is fine in mainline.

Best regards,
Beno?t