U-Boot ethXaddr environment variables are not propagating to Linux

[Maxim Sloyko]

On Fri, Sep 30, 2016 at 12:10 PM, Milton Miller II <miltonm at us.ibm.com>
wrote:

>
>
> -----"openbmc" <openbmc-bounces+miltonm=us.ibm.com at lists.ozlabs.org>
> wrote: -----
>
> >To: OpenBMC Maillist <openbmc at lists.ozlabs.org>
> >From: Maxim Sloyko
> >Sent by: "openbmc"
> >Date: 09/30/2016 01:09PM
> >Subject: U-Boot ethXaddr environment variables are not propagating to
> >Linux
> >
> >Hi all,
> >
> >This worked before, when I first tried it ~2 months ago on the eval
> >board: set ethaddr & eth1addr in U-Boot, boot Linux and it will use
> >the same MAC addresses. I tried it again yesterday and it does not
> >work any more.
>
> I think ethaddr made a difference.  Not sure eth1addr ever did, unless
> you have two direct interfaces on your board?


I'm using eval board. It does have two network ports, but I'm mostly
interested in the one that is "attached" to ethaddr.


>
>
> >
> >I tried it with openbmc/u-boot, to make sure my changes do not
> >interfere. I verified, by reading MAC08 MAC0C registers, that MAC
> >addresses are properly configured by U-Boot from env. However, when I
> >booted Linux, it still generated random MAC address, rather then
> >reusing whatever was passed up from U-Boot.
> >
> >Any ideas on what change might have affected this?
>
>
> You have likely hit the same issue as
> https://github.com/openbmc/u-boot/issues/13
> https://github.com/openbmc/openbmc/issues/578
>
> Basically u-boot was over optimized and does not write the mac unless it
> tries to use the network.
>

I verified by reading MAC registers MAC08 & MAC0C that for both macs the
addresses are properly configured.
I tried running dhcp and I saw dhcp requests on the network from the
correct MAC address.

Booting linux still results in it generating random MAC addresses.


>
> You could add a ping (static addressing) or dhcp request (dhcp address) in
> your bootcmd as a workaround, or address the bug more directly.
>
> Note: even with NCSI this should not require 2 seconds, only the 10ms
> sleep to wait for the clock stabilization.  The 2 second delay likely
> comes
> from the NCSI spec as the maximum time for packages to initialize.
>
> milton
>
>
>


-- 
*M*axim *S*loyko
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20160930/0b926eed/attachment.html>