• State
  • Locked Locked
  • Replies 6 replies
  • Subscribers 98 subscribers
  • Views 435 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Should EMAC be enabled through bootcmds for it to be fully working once the boot process ends??

Sergi Creus
Intellectual 305 points

 

I recently updated the default DVSDK to the new version (dvsdk_2_00_00_22) and I built a new kernel (MTV 5.0) using the default options. BTW, I'm using the DM6467 develpment platform.

Since I was testing my applications, I used TFTP and NFS to provide EVM with kernel and filesystem. Everything worked fine.

When my testing phase finished I flashed the kernel and updated the default filesystem in hda1. I changed bootcmds to boot from flash and use hda1 as the new filesystem. Everything works fine, except for the ethernet connection. That is, the kernel image is retrieved from flash and the boot process starts,  hda1 is mounted and the ethernet interface (eth0) is configured, or at least so it seems, and finally the login promt shows up in the screeen. I'm able to perform anything I want but the ethernet connection doesn't work.

I use a ping command to test it. Whenever I run ifconfig, figures in Tx packets and Rx packets change. So it looks like some packets are being transmitted and received, but I'm still unable to connect to any host in my lan.

After some tests I came up with something that can apparently sort out the problem. I noticed that if I entered U-boot interface and executed a PING command and then a reset command, the ethernet interface was available when the boot process ended. So I changed my bootcmds:

Former commands: bootcmd=nboot 80700000 0 a0000;bootm -------------------------------> Ethernet  doesn't work after boot process.

New commands: bootcmd=ping 192.168.0.25;nboot 80700000 0 a0000;bootm --------->Ethernet  works fine after boot process.

I used the ping command since it is an innocuous command. But it works with all commands requiring  the ethernet interface (tftp, dhcp, ping, ...).

I dont' know how to make the ethernet connection work without adding the ping command in the bootcmd variable.

The best part of it is that if I configure the interface to use DHCP,  a new IP is always given to the EVM, regardless of the bootcmd variable.

I hope someone can help me.

Thanks in advance.

 

 

  • 0
    TI__Mastermind 37340 points

    Sergi,

    Is this happening with the original DM6467 kernel on our EVM?  That is, you are not using custom hardware or enabled/disabled kernel drivers on your own?  I am trying to eliminate variables to see if we can reproduce this internally. 

    I think your findings are very interesting and have already passed this along to our software team, but just wanted to preempt and ask some questions they may need to know.

  • 0 in reply to Juan Gonzales
    Intellectual 305 points

    Hi Juan,

    Firstly, I used the default uImage found in \dvsdk_2_00_00_22\PSP_02_00_00_140\bin\dm6467\

    But it happens with other kernels I built afterwards.

  • 0 in reply to Sergi Creus
    Intellectual 305 points

    Hi Juan,

    I gathered some information regarding my problem. I hope it may be useful for you to guess what is happening since I've run out of ideas.

    I used an sniffer to capture all ethernet packets sent between the EVM and a host when a ping command is executed.

    I captured all packets in both scenarios

    DATA:

    EVM IP: 192.168.0.183*  Mac:  00:0E:99:02:B4:89 (Spectrum_02:b4:89)

    (*) The ip given by the DHCP server when kernel boots turns out to be always the same.

    Host IP : 192.168.0.25 Mac: 00:19:DB:6E:60:29 (Micro-St_6e:60:29 )

    Command executed after logging in in both scenarios : #EVM ping 192.168.0.25

    Captured frames:

    Scenario #1: Ping added in the bootcmd variable ( ping , nboot , bootm)

    No.     Time        Source                Destination           Protocol Info
          1 0.000000    Spectrum_02:b4:89     Broadcast             ARP      Who has 192.168.0.25?  Tell 192.168.0.183
          2 0.000013    Micro-St_6e:60:29     Spectrum_02:b4:89     ARP      192.168.0.25 is at 00:19:db:6e:60:29
          3 0.000146    192.168.0.183         192.168.0.25          ICMP     Echo (ping) request
          4 0.000175    192.168.0.25          192.168.0.183         ICMP     Echo (ping) reply
          5 0.990115    192.168.0.183         192.168.0.25          ICMP     Echo (ping) request
          6 0.990156    192.168.0.25          192.168.0.183         ICMP     Echo (ping) reply
          7 1.990094    192.168.0.183         192.168.0.25          ICMP     Echo (ping) request
          8 1.990130    192.168.0.25          192.168.0.183         ICMP     Echo (ping) reply

    ............................

    In this scenario everything is fine. First an ARP request and its reply, and then ICMP request and their replies.

    Scenario #2: No ping added in the bootcmd variable (just  nboot and bootm)

    No.     Time        Source                Destination           Protocol Info
          1 0.000000    Spectrum_02:b4:89     Broadcast             ARP      Who has 192.168.0.25?  Tell 192.168.0.183
          2 0.000013    Micro-St_6e:60:29     Spectrum_02:b4:89     ARP      192.168.0.25 is at 00:19:db:6e:60:29
          3 0.999963    Spectrum_02:b4:89     Broadcast             ARP      Who has 192.168.0.25?  Tell 192.168.0.183
          4 0.999975    Micro-St_6e:60:29     Spectrum_02:b4:89     ARP      192.168.0.25 is at 00:19:db:6e:60:29
          5 1.999905    Spectrum_02:b4:89     Broadcast             ARP      Who has 192.168.0.25?  Tell 192.168.0.183
          6 1.999917    Micro-St_6e:60:29     Spectrum_02:b4:89     ARP      192.168.0.25 is at 00:19:db:6e:60:29
          7 3.009922    Spectrum_02:b4:89     Broadcast             ARP      Who has 192.168.0.25?  Tell 192.168.0.183
          8 3.009934    Micro-St_6e:60:29     Spectrum_02:b4:89     ARP      192.168.0.25 is at 00:19:db:6e:60:29

    ...........................................

    In both cases I verified the ARP table. It has the new entry:

    #EVM-> arp -a -n
    ? (192.168.0.25) at 00:19:DB:6E:60:29 [ether] on eth0

    So everything seems to be fine, but in scenario #2, EVM keeps on sending ARP requests, despite having a correct entry in the ARP table.

    Why ?

    Thank you in advance for your time.

  • 0 in reply to Sergi Creus
    Expert 1240 points

    I have exactly the same problem with the DM6467 EVM.

  • 0 in reply to Sergi Creus
    Expert 1240 points

    Meanwhile, there is a workaround for this issue, although it adds some seconds to the boot process:

    On U-boot, add 'ping 127.0.0.1' to bootcmd environment variable

  • 0 in reply to Nir Aloni
    Intellectual 305 points

    Yes. That's the only solution I came up with.