[U-Boot] Setting up MAC address for eth drivers
Michal Simek
michal.simek at xilinx.com
Tue Mar 17 17:57:11 CET 2015
Hi Joe,
On 03/17/2015 04:56 PM, Joe Hershberger wrote:
> Hi Michal,
>
> On Fri, Mar 13, 2015 at 7:25 AM, Michal Simek <michal.simek at xilinx.com>
> wrote:
>>
>> Hi,
>>
>> I have a question regarding setting mac address for drivers.
>> Drivers setting up write_hwaddr via eth_write_hwaddr via eth_initialize
>> which is called from common/board_r.c.
>
> This is because on at least ARM kernels, the MAC is passed via the MAC's
> filter registers. Because of this, we need to write hwaddr even before the
> MAC is started.
>
>> But then there are some drivers(macb, designware, altera_tse) which also
> calls
>> mac setup from dev->init which has side effect for example when you setup
> CONFIG_ENV_OVERWRITE
>> and change mac address you can directly use it.
>
> This is probably a work-around for a shortcoming of the net/eth.c not
> calling write_hwaddr() when the env MAC changes. It already updates the
> registers used by the network stack, so presumably if those MACs are
> filtering incoming traffic based on the register as expected, changing the
> MAC after boot without rewriting that register would cause all traffic to
> not be returned.
>
>> It also means if there is intention to call hwaddr from dev->init
>> that for the first packet mac address is setup twice - in eth core init
>> and then before every driver use.
>
> The design of the network stack assumes the MAC is started each time a
> network operation is requested and stopped when done.
>
> As for the setting of the hwaddr, we should check if it changed.
>
>> I am asking this question because I would like to know the right flow
>> for eth mac setup.
>> If it is
>> set ethaddr xx....
>> saveenv
>> reset
>> eth with new mac
>>
>> or if
>> set ethaddr
>> eth with new mac
>> should work
>>
>> The second approach looks reasonable when ethaddr is not set at all
>> but then at least our driver needs to be fixed to support this feature.
>
> I think the second should work ideally, but we need to add a call to
> eth_init() if the "ethaddr" in the env changes and set it again if so. We
> should also remove the calls from the drivers you identified since the
> framework will now do it.
Does it mean that you are going to write that code for it?
Thanks,
Michal
More information about the U-Boot
mailing list