[meta-xilinx] Ethetnet kernel driver depends on U-boot
Oleg K Dzhimiev
oleg at elphel.com
Wed Oct 16 15:46:38 PDT 2013
Hi,
Figured it out. That is my mistake.
The network in u-boot is enabled with these lines:
> #define CONFIG_ZYNQ_GEM0
> #define CONFIG_ZYNQ_GEM_PHY_ADDR0 0
When enabled - the MAC address is fixed in linux,
when disabled - linux boots with a random MAC address.
The problem was that sometimes with random MACs the board couldn't ping
anything on the network.
This is solved with:
> ifconfig eth0 down
> ifconfig eth0 up
So, the kernel driver does not depend on u-boot hardware initialization.
Thanks,
Oleg
On 15 October 2013 23:45, Mike Looijmans <mike.looijmans at topic.nl> wrote:
> My guess would be the MAC address. The address that u-boot writes to the
> emac gets to be used in the kernel too. Probably without that, the kernel
> driver doesn't set a (random) MAC address and thus fails to properly
> initialize the network.
>
> Kudos to Andry by the way, I will try to sneak in an item in my next Zynq
> project to add SPL to his loader so that a "full" u-boot can be built
> without the need for proprietary tools and obscure licensing.
>
> Mike.
>
>
> On 10/15/2013 10:57 PM, Sipke Vriend wrote:
>
>> Hi Andrey,
>>
>> Xilinx common Linux boot flow is fsbl, u-boot, kernel, so I guess you
>> might be seeing a side-effect of reliance on that order.
>> If you can pin point in more detail what you have done, or if you
>> find a patch to address the issue, you may be could send it or ask on
>> git at xilinx.com.
>>
>> Regards
>> Sipke
>>
>> From: meta-xilinx-bounces@**yoctoproject.org<meta-xilinx-bounces at yoctoproject.org>
>>> [mailto:meta-xilinx-bounces@**yoctoproject.org<meta-xilinx-bounces at yoctoproject.org>]
>>> On Behalf Of andrey
>>> Sent: Saturday, 12 October 2013 7:16 AM
>>> To: meta-xilinx at yoctoproject.org
>>> Subject: [meta-xilinx] Ethetnet kernel driver depends on U-boot
>>>
>>> While troubleshooting FSBL-less booting (network did not work initially)
>>> we noticed that when we re-enabled network support in U-boot (we
>>> removed it to save room in 192KB OCM) - problem was gone and network
>>>
>> >in Linux works now. Is the kernel driver really supposed to depend on
>> some U-boot initialization of the hardware (why?) or is this just a bug?
>>
>>>
>>> Andrey
>>>
>>
>>
>>
>>
> Met vriendelijke groet / kind regards,
>
> Mike Looijmans
>
> TOPIC Embedded Systems
> Eindhovenseweg 32-C, NL-5683 KH Best
> Postbus 440, NL-5680 AK Best
> Telefoon: (+31) – (0)499 - 33.69.79
> Telefax: (+31) - (0)499 - 33.69.70
> E-mail: mike.looijmans at topic.nl
> Website: www.topic.nl
>
> Dit e-mail bericht en de eventueel daarbij behorende bijlagen zijn
> uitsluitend bestemd voor de geadresseerde, zoals die blijkt uit het e-mail
> bericht en/of de bijlagen. Er kunnen gegevens met betrekking tot een derde
> instaan. Indien u als niet-geadresseerde dit bericht en de bijlagen
> ontvangt, terwijl u niet bevoegd of gemachtigd bent om dit bericht namens
> de geadresseerde te ontvangen, wordt u verzocht de afzender hierover direct
> te informeren en het e-mail bericht met de bijlagen te vernietigen. Ieder
> gebruik van de inhoud van het e-mail bericht, waaronder de daarbij
> behorende bijlagen, door een ander dan de geadresseerde is onrechtmatig
> jegens ons dan wel de eventueel in het e-mail bericht of de bijlagen
> voorkomende andere personen. TOPIC Embedded Systems is niet aansprakelijk
> voor enigerlei schade voortvloeiend uit het gebruik en/of acceptatie van
> dit e-mail bericht of de daarbij behorende bijlagen.
>
> The contents of this message, as well as any enclosures, are addressed
> personally to, and thus solely intended for the addressee. They may contain
> information regarding a third party. A recipient who is neither the
> addressee, nor empowered to receive this message on behalf of the
> addressee, is kindly requested to immediately inform the sender of receipt,
> and to destroy the message and the enclosures. Any use of the contents of
> this message and/or the enclosures by any other person than the addressee
> or person who is empowered to receive this message, is illegal towards the
> sender and/or the aforementioned third party. TOPIC Embedded Systems is not
> liable for any damage as a result of the use and/or acceptance of this
> message and as well as any enclosures.
>
> ______________________________**_________________
>
>> meta-xilinx mailing list
>> meta-xilinx at yoctoproject.org
>> https://lists.yoctoproject.**org/listinfo/meta-xilinx<https://lists.yoctoproject.org/listinfo/meta-xilinx>
>>
>>
> ______________________________**_________________
> meta-xilinx mailing list
> meta-xilinx at yoctoproject.org
> https://lists.yoctoproject.**org/listinfo/meta-xilinx<https://lists.yoctoproject.org/listinfo/meta-xilinx>
>
--
Best regards,
Oleg Dzhimiev
Electronics Engineer
phone: +1 801 783 5555 x124
Elphel, Inc.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/meta-xilinx/attachments/20131016/349353e1/attachment.html>
More information about the meta-xilinx
mailing list