• State
  • Locked Locked
  • Replies 4 replies
  • Subscribers 99 subscribers
  • Views 394 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.

tftp works on DM355 IPNC but not on DM368 IPNC

tek4
Intellectual 700 points

Hi,

with older versions of u-boot on DM355 IPNC it was easy to download new firmware with tftp. All we needed to do was set serverip, ethaddr, and either ipaddr or dhcp

Now with DM368 IPNC and u-boot 1.3.4 it doesn't work any more, regardless of whether we use DHCP or a manually assigned ipaddr. Adding gatewayip and netmask doesn't seem to help. Connectivity is fine as DHCP can get an address, and TFTP server is ok too as verified by using exact same commands on DM355 IPNC.

I can provide more detail if needed

  • 0
    TI__Prodigy 480 points

    What tftp server untility are you using?

    -phil

  • 0 in reply to Philip Baltz
    Intellectual 700 points

    Same result with both Winagents tftp server on Windows and tftpd on Ubuntu 9.10.

  • 0 in reply to tek4
    TI__Mastermind 19985 points

    Hi,

    I think the following post might be of some help for your problem.

    http://e2e.ti.com/support/embedded/f/354/p/43146/167343.aspx#167343

    BTW, can you please provide the dump of /sbin/ifconfig on your linux host machine where you are running TFTP server?

    I suspect that MTU size might be less than 1468 and linux host machine might be sending out fragmented TFTP datagrams, which our uBoot does not understand. So if MTU size is set to less than 1500, please use the following command to set it back to 1500.

    # /sbin/ifconfig eth0 mtu 1500

    Regards,

    Anshuman

    PS: Please mark this post as verified, if you think it has answered your question. Thanks.

  • 0 in reply to Anshuman Saxena
    Intellectual 700 points

    Looking further into this, it appears not be related to block sizes or checksums, but appears to be some kind of ARP failure that happens on the DM368 but did not happen on the DM355.

    If we place a DM355 IPNC on the same network jack and configure its ethaddr as 00:01:02:03:04:05 and get a tftp transfer going, then unplug the DM355 and do the same with the DM368 including same ethaddr, then it works.

    When the DM368 is using its own ethaddr, a wireshark trace shows that the DM368 keeps asking "who has <serverip> tell <ipaddr>" and even though it gets a reply with the proper MAC address then it does not initiate the TFTP transfer but instead send another ARP message.

    After downloading uImage and cramfs by UART, the IPNC works fine. So everything points to some kind of ARP or initialization failure in uBoot 1.0 for DM368, where this problem did not appear on the earlier uBoot for DM355.