Re: Fwd: DA850-evm MAC Address is random

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wednesday 30 August 2017 06:19 AM, Adam Ford wrote:
> On Tue, Aug 29, 2017 at 10:20 AM, Adam Ford <aford173@xxxxxxxxx> wrote:
>> On Tue, Aug 29, 2017 at 10:16 AM, Sekhar Nori <nsekhar@xxxxxx> wrote:
>>> On Tuesday 29 August 2017 05:32 PM, Adam Ford wrote:
>>>> On Tue, Aug 29, 2017 at 6:42 AM, Sekhar Nori <nsekhar@xxxxxx> wrote:
>>>>> On Tuesday 29 August 2017 03:53 PM, Adam Ford wrote:
>>>>>> On Tue, Aug 29, 2017 at 3:23 AM, Sekhar Nori <nsekhar@xxxxxx> wrote:
>>>>>>> On Tuesday 29 August 2017 02:42 AM, Tony Lindgren wrote:
>>>>>>>> * Adam Ford <aford173@xxxxxxxxx> [170828 13:33]:
>>>>>>>>> On Mon, Aug 28, 2017 at 1:54 PM, Grygorii Strashko
>>>>>>>>> <grygorii.strashko@xxxxxx> wrote:
>>>>>>>>>> Cc: Sekhar
>>>>>>>>>>
>>>>>>>>>> On 08/28/2017 10:32 AM, Adam Ford wrote:
>>>>>>>>>>>
>>>>>>>>>>> The davinvi_emac MAC address seems to attempt a call to
>>>>>>>>>>> ti_cm_get_macid in cpsw-common.c but it returns the message
>>>>>>>>>>> 'davinci_emac davinci_emac.1: incompatible machine/device type for
>>>>>>>>>>> reading mac address ' and then generates a random MAC address.
>>>>>>>>>>>
>>>>>>>>>>> The function appears to lookup varions boards using
>>>>>>>>>>> 'of_machine_is_compaible' and supports dm8148, am33xx, am3517, dm816,
>>>>>>>>>>> am4372 and dra7.  I don't see the ti,davinci-dm6467-emac which is
>>>>>>>>>>> what's shown in the da850 device tree.
>>>>>>>>>>>
>>>>>>>>>>> Is there a patch somewhere for supporting the da850-evm?
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Not sure if MAC address can be read from Control module.
>>>>>>>>>> May be Sekhar can say more?
>>>>>>>>>
>>>>>>>>> My understanding is that the MAC address is programmed by Logic PD
>>>>>>>>> into the SPI flash.  The Bootloader reads this from either SPI or its
>>>>>>>>> env variables.  Looking at the partition info listed in the
>>>>>>>>> da850-evm.dts file, it appears as if they've reserved space for it.
>>>>>>>>> Unfortunately, I don't see any code that reads it out.  I was hoping
>>>>>>>
>>>>>>> This code is present in U-Boot sources at
>>>>>>> board/davinci/da8xxevm/da850evm.c. See the function get_mac_addr() and
>>>>>>> its usage in misc_init_r().
>>>>>>>
>>>>>>>>> there might be a way to just pass cmdline parameter from the
>>>>>>>>> bootloader to the kernel to accept the MAC address.
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> If not, is there a way to pass the MAC address from U-Boot to the
>>>>>>>>>>> driver so it doesn't generate a random MAC?
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> "local-mac-address" dt porp
>>>>>>>>>
>>>>>>>>> The downside here, is that we'd have to have the Bootloader modify the
>>>>>>>>> device tree.
>>>>>>>>
>>>>>>>> That piece of code exists somewhere in u-boot already. Note how
>>>>>>>
>>>>>>> Yes, it is fdt_fixup_ethernet() and its usage is in common/image-fdt.c.
>>>>>>>
>>>>>>>> we are populating the mac address for USB Ethernet drivers in
>>>>>>>> u-boot and then the Ethernet driver code parses it. See commit
>>>>>>>> 055d31de7158 ("ARM: omap3: beagleboard-xm: dt: Add ethernet to
>>>>>>>> the device tree") for some more information.
>>>>>>>>
>>>>>>>> I think u-boot needs the ethernet alias for finding the interface.
>>>>>>>
>>>>>>> That's exactly what was missing. I have sent a patch for fixing that and
>>>>>>> copied you there.
>>>>>>
>>>>>> Thanks for doing that.
>>>>>>
>>>>>>>
>>>>>>> Adam, if I can get your Tested-by, I will make an attempt to send it for
>>>>>>> v4.13 itself.
>>>>>>
>>>>>> I will test it.  Do need to run some instruction or do something
>>>>>> special in U-Boot to pass this in the proper place for the kernel to
>>>>>> pull it?  Tony's patch reference showed
>>>>>> command for fdt set, but I am not sure I fully understand the
>>>>>> parameters that went along with that.
>>>>>
>>>>> Nope, just applying the patch and booting the with the new dtb should
>>>>> result in the random mac address going away.
>>>>
>>>> Unfortunately, I am not seeing any change with the patch (at least
>>>> with Kernel 4.12.9 from stable).
>>>>
>>>> netconsole: network logging started
>>>> davinci_emac davinci_emac.1: incompatible machine/device type for
>>>> reading mac address
>>>> davinci_emac davinci_emac.1: using random MAC addr: ee:74:c3:3a:15:be
>>>>
>>>> Looking at the source for cpsw-common.c function ti_cm_get_macid()
>>>> doesn't have a case for the  ti,davinci-dm6467-emac so I wonder if
>>>> there might be more to it.
>>>
>>> Hmm, it did solve the issue for me when I tried latest -next. And
>>> reverting the patch brought back the random mac address usage. Could you
>>> try latest mainline or -next?
>>>
>>> Meanwhile let me see whats going on with the observations you have.
>>
>> I will try again with -next this afternoon and see what I can find.
>> Can you tell me which U-Boot version you're using? I want to match
>> your setup. I want to see if something is missing during the hand-off
>> between the Bootloader and Linux.
>>
> 
> I wonder if U-Boot isn't pushing something to Linux because it doesn't
> appear to be running some of the da850 specific code even when I run
> linux-next.  Can you tell me what verision of U-Boot you're using?
> Other than using davinci_all_defconfig, did you change the
> configuration at all?

I am using U-Boot 2017.01. Yes, the kernel was built using
davinci_all_defconfig and no other config change. Before booting kernel,
can you confirm that ethaddr is set in U-Boot environment? This is what
fdt_fixup_ethernet() reads to fixup the FDT before boot.

Here is my complete boot log with environment variable dump.

http://pastebin.ubuntu.com/25430265/

Thanks,
Sekhar
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Linux Arm (vger)]     [ARM Kernel]     [ARM MSM]     [Linux Tegra]     [Linux WPAN Networking]     [Linux Wireless Networking]     [Maemo Users]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux