• State Resolved
  • Locked Locked
  • Replies 7 replies
  • Answers 2 answers
  • Subscribers 99 subscribers
  • Views 2452 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.

TMS320C6678: IBL TFTP with BOOTP in BE failed with TMDSEVM6678LE

Hitoshi Sugawara
Mastermind 20330 points
Part Number: TMS320C6678


Hi Folks,

Our customer mentioned that IBL TFTP with BOOTP condition as follows:

1) in LE / TFTP / BOOTP inactive  --> TFTP BOOT OK
2) in LE / TFTP / BOOTP active --> TFTP BOOT OK
3) in BE / TFTP / BOOTP inactive --> TFTP BOOT OK
4) in BE / TFTP / BOOTP active -->  TFTP BOOT NG!  It does NOT work!

Info: 
2) in LE / TFTP / BOOTP active --> Works OK.
   - No.102:  BOOTP  Boot Request from 40:5f:c2:b8:fc:9a (TexasIns_b8:fc:9a)
   - No.104:  DHCP   DHCP Offer    - Transaction ID 0x1
   - No.105:  ARP    Who has 192;168;2;3? Tell 192;168;2;201
   - No.107:  TFTP   Read Request, File: app.out, Transfer type: octet
   - No.109:  TFTP   Data Packet, Block: 1
   - No.110:  TFTP   Acknowledgement, Block: 1
    * TFTP BOOT OK

4) in BE / TFTP / BOOTP active -->  Does not work!
   - No. 82:  BOOTP  Boot Request from 40:5f:c2:b8:fc:9a (TexasIns_b8:fc:9a)
   - No. 83:  DHCP   DHCP Offer    - Transaction ID 0x1
   - No. 85   ARP    Who has 192;168;2;101? Tell 192;168;2;3
   - No.122:  BOOTP  Boot Request from 40:5f:c2:b8:fc:9a (TexasIns_b8:fc:9a)
   - No.123:  DHCP   DHCP Offer    - Transaction ID 0x1
   - No.124   ARP    Who has 192;168;2;101? Tell 192;168;2;3
   - No.171:  BOOTP  Boot Request from 40:5f:c2:b8:fc:9a (TexasIns_b8:fc:9a)
   - No.172:  DHCP   DHCP Offer    - Transaction ID 0x1
   - No.174   ARP    Who has 192;168;2;101? Tell 192;168;2;3
   * TFTP BOOT NG!

It seems that ARP is issued however, the IP address seems wrong in BE / TFTP / BOOTP active.
Could you please check the condition and let us know any suggestions to resolve it.

Thank you in advance for your quick support.
Best regards,
Hitoshi Sugawara



  • 0
    TI__Guru**** 161600 points
    Hi,

    I've notified the RTOS team. Their feedback will be posted here.

    Best Regards,
    Yordan
  • 0
    TI__Guru** 116770 points

    Sugarawa-san,

    Sorry for the delayed response. Is the customer still using MCSDK baseline for this effort or have the migrated to Processor SDK RTOS software.

    How are they booting in big endian mode? Have they set the boot switch Pin1 for big endian as described here:
    processors.wiki.ti.com/.../TMDXEVM6678L_EVM_Hardware_Setup

    by default, the switch is set to little endian. TFTP boot for us worked on the EVM using the following instruction with MCSDK:

    How to test BOOTP C6678 EVM in BE mode.pdf

    Also, look at similar issue reported here:
     

    Why is the customer trying to boot in big endian mode, is their application using big endian? Normally we test all of the SDK software in little endian mode. This functionality was tested in MCSDK but we will need to check if there is system test data for Processor SDK. If possible please provide the result from debug GEL file when reporting boot errors.

     

    Regards,
    Rahul

  • 0 in reply to Rahul Prabhu
    TI__Mastermind 20330 points
    Hi Rahul,
    Thank you very much for your kind attention and support.
    According to the customer, it is mandatory that their application must work in BE with BOOTP enable.
    They have been testing with MCSDK for this with our EVM.

    Again, only the combination of BE with BOOTP does not work.
    1) in LE / TFTP / BOOTP inactive --> TFTP BOOT OK
    2) in LE / TFTP / BOOTP active --> TFTP BOOT OK
    3) in BE / TFTP / BOOTP inactive --> TFTP BOOT OK
    4) in BE / TFTP / BOOTP active --> TFTP BOOT NG! It does NOT work!

    It seems that boot in BE might be OK.
    But if BOOTP is enable in BE, it has a problem.

    Our observations are as follows:
    a) ARP is not issued properly when application is in BE with BOOTP enable.
    b) ARP is issued with the IP Address 192.168.2.3 which might be the address for TFTP server.
    If so, ARP is sent out from the TFTP sever not from the EVM.
    c) We have been looking for the source code where is related to BOOTP and Endian.
    Unfortunately, we still do not know where they are located in.
    3) in BE / TFTP / BOOTP disable --> TFTP BOOT is OK, therefore, BE with BOOTP might have a problem.

    Could you please check from a) to c) and let us know your observation.
    Thank you very much for your kind help.
    Best regards,
    Hitoshi Sugawara
  • 0 in reply to Hitoshi Sugawara
    TI__Guru** 116770 points

    Hitoshi-san,

    I tried this  on the EVM as there was a similar question posted on the E2E here:

    Attached WireShark log from BE IBL TFTP boot:

    https://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/791/7674.IBL_5F00_TFTP_5F00_BE_5F00_WireShark_5F00_log.pcapng

    I have provided the Wireshark logs for reference. while testing I created a local network that was disconnected from rest of the network and do see the correct BOOTP response from the EVM and the file transfer happening in the wireshark logs.

    • TFTP, ARP, BOOTP implementation is in the folder   mcsdk_2_01_02_06\tools\boot_loader\ibl\src\driver\eth
    • IBL configuration for TFTP boot and endian detect is done in iblmain.c and iblinit.c under directory path mcsdk_2_01_02_06\tools\boot_loader\ibl\src\main
    • If they are modifying ibl parameter table by changing IBLConfig, then also look at settings in device.c found under mcsdk_2_01_02_06\tools\boot_loader\ibl\src\util\iblConfig\src. If they are using GEL then they should look at the configuration in iblConfig.gel provided at mcsdk_2_01_02_06\tools\boot_loader\ibl\src\make\bin
    • Endian interpreter helper functions are implemented here: mcsdk_2_01_02_06\tools\boot_loader\ibl\src\interp

    Modifying parameters using GEL or iblConfig is described here:

    Regards,

    Rahul

  • 0 in reply to Rahul Prabhu
    TI__Mastermind 20330 points
    Hi Rahul,
    Thank you so much for your kind support on this technical question.
    As you mentioned, a specialist in our team has posted it onto another sled.
    He has already informed our answers to the customer.
    I would very appreciate if you could kindly reply onto the sled.

    Will keep you updated.
    Best regards,
    Hitoshi Sugawara
  • 0 in reply to Hitoshi Sugawara
    TI__Mastermind 20330 points
    Hi Rahul,
    Finally, we might have found the root cause why BOOTP in BE does not work.
    After we made the modification onto two files icmp.c and udp.c, BOOTP in BE worked correctly.

    o icmp.c
    (C:\ti\pdk_c667x_2_0_5\packages\ti\boot\ibl\src\driver\eth)

    - Line 77~82

    //#ifdef BIGENDIAN
    if( tmp1 )
    TSum += (Uint32)(*pw & 0xFF00);
    //#else
    // if( tmp1 )
    // TSum += (Uint32)(*pw & 0x00FF);
    //#endif

    o udp.c
    (C:\ti\pdk_c667x_2_0_5\packages\ti\boot\ibl\src\driver\eth)

    - Line 96~102

    //#ifdef BIGENDIAN
    if( tmp1 )
    TSum += (Uint32)(*pw & 0xFF00);
    //#else
    // if( tmp1 )
    // TSum += (Uint32)(*pw & 0x00FF);
    //#endif

    This means that there should be a typo of the definition of 'BIGENDIAN'. might be no '_'?
    I would very appreciate if you could kindly check it and fix our sample code accordingly.

    Best regards,
    Hitoshi
  • 0 in reply to Hitoshi Sugawara
    TI__Guru** 116770 points

    Thank you for updating the thread with the solution. I will pass the finding to the development team.

    I have filed an issue with the development team that can be tracked using the bug ID PRSDK-2669

    The MACRO should be defined as _BIG_ENDIAN 

    Regards,

    Rahul