TMS320C6678: Dose anyone have any validated big endian TFTP boot examples for C6678EVM?

j-breeze

Part Number: TMS320C6678

Hi Champs,

One of my customer is trying the big endian TFTP boot on C6678EVM, but he can not. He has already done the little endian boot w/o any problems.
So, dose anyone have any validated examples for the boot for the EVM?

Regards,
j-breeze

over 7 years ago

0 Yordan Kovachev over 7 years ago

TI__Guru**** 161600 points

Hi,

Have they compiled the bootloader as described in the bellow wiki:
processors.wiki.ti.com/.../Processor_SDK_RTOS_BOOT_C66x

Best Regards,
Yordan

0 j-breeze over 7 years ago in reply to Yordan Kovachev

Mastermind 7560 points

Hi Yordan,

Yes. My customer has compiled the IBL using a command below in MinGW environment.

make evm_c6678_i2c ENDIAN=big I2C_BUS_ADDR=0x51

Could you please let me know what I should check next?

Regards,
j-breeze

0 j-breeze over 7 years ago in reply to j-breeze

Mastermind 7560 points

Hi Yordan,

My customer is trying to use BOOTP. So, dose the TFTP boot support BOOTP? Can I enable it like below?

replace
ibl.bootModes[2].u.ethBoot.doBootp = FALSE;
with
ibl.bootModes[2].u.ethBoot.doBootp = TRUE;

Regards,
j-breeze

0 j-breeze over 7 years ago in reply to j-breeze

Mastermind 7560 points

Hi,

I'm waiting for reply.
Can I do a big endian TFTP boot using DHCP by setting doBootp to TRUE?

Regards,
j-breeze

0 j-breeze over 7 years ago in reply to j-breeze

Mastermind 7560 points

0 j-breeze over 7 years ago in reply to j-breeze

Mastermind 7560 points

Hi Yordan,

Should I start a new thread on this matter?

Regards,
j-breeze

0 Yordan Kovachev over 7 years ago in reply to j-breeze

TI__Guru**** 161600 points

Hi,

Sorry for the delay. If you've built the ibl correctly with big endian, this should be possible.
I've notified the team to elaborate. Feedback will be posted here.

Best Regards,
Yordan

0 j-breeze over 6 years ago in reply to Yordan Kovachev

Mastermind 7560 points

Hi,

Any feedback?

Regards,
j-breeze

0 j-breeze over 6 years ago in reply to j-breeze

Mastermind 7560 points

Hi,

The below is my latest result. I attached the Wireshark logs.

o Little Endian & BOOTP Enabled (file name: TFTP_BOOT_LE_BOOTP_ENA.pcapng)

- 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!

o Big Endian & BOOTP Enabled (file name: TFTP_BOOT_BE_BOOTP_ENA.pcapng)

- 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!

What is the reason for not working with Big Endian?
Any comment would be appreciated.

TFTP_BOOT_BOOTP_ENA_Wireshark_Logs.zip

Regards,
j-breeze

0 j-breeze over 6 years ago in reply to j-breeze

Mastermind 7560 points

HI,

I found that ARP was issued from PC(TFTP server), not the EVM when BOOTP was enabled in BE mode.
So, could you please let me know what part of the example code I should modify to issue ARP from the EVM?

Regards,
j-breeze

0 j-breeze over 6 years ago in reply to j-breeze

Mastermind 7560 points

Hi,

Dose anyone help me?

Regards,
j-breeze

0 Rahul Prabhu over 6 years ago in reply to j-breeze

TI__Guru** 114410 points

j-breeze,

Please check my responses here:

ALso refer to the attached document to run TFTP boot in BE mode. This was validated using MCSDK baseline. With Processor SDK RTOS, we have tested this in little endian mode only.

8637.How to test BOOTP C6678 EVM in BE mode.pdf

Regards,

Rahul

0 j-breeze over 6 years ago in reply to Rahul Prabhu

Mastermind 7560 points

Hi Rahul,

Thank you for your support.

I think the document you attached is for ROM Ethernet Boot, not IBL TFTP Boot. Because the DEVSTAT value is 0x00001C84 and it shows ROM Ethernet Boot mode. Could you please check it out again?

And, could you please refer my Wireshark logs I attached in my previous post and let me clarify why ARP is issued from PC which I use for DHCP/TFTP server, not the EVM, when BOOTP is enabled in BE mode?

Regards,
j-breeze

0 Rahul Prabhu over 6 years ago in reply to j-breeze

TI__Guru** 114410 points

J-breeze,

When the boot fails, can you run the debug GEL file we provide here and provide the log:
processors.wiki.ti.com/.../Keystone_Device_Architecture

This will help us understand, how your clock, boot and SGMII is configured. As per the secondary boot expert, all you need to do is build the IBL in big endian mode flash the binary and boot the EVM with the big endian IBL TFTP boot switch settings

Regards,
Rahul

0 j-breeze over 6 years ago in reply to Rahul Prabhu

Mastermind 7560 points

Hi Rahul,

My customer has already built the IBL in BE mode as following. I think there is no problem.

make evm_c6678_i2c ENDIAN=big I2C_BUS_ADDR=0x51

Can I ask you to verify the boot and give me the Wireshark log?

Regards,
j-breeze

0 Rahul Prabhu over 6 years ago in reply to j-breeze

TI__Guru** 114410 points

J-Breeze,

I have provided the Wireshark log from what I am seeing from the TFTP BOOTP based BE boot.

IBL_TFTP_BE_WireShark_log.pcapng

I definitely see a response and the image transfer happening in big endian mode.

Regards,

Rahul

0 j-breeze over 6 years ago in reply to Rahul Prabhu

Mastermind 7560 points

Hi Rahul,

Thank you so much for sharing your Wireshark log. Could you please tell me the following?

Q1) What type of data in a SDK did you use, pre-build or rebuild?

Q2) What tool did you use for servers for the verification on your PC?

Q3) What are settings of the tool?

Regards,
j-breeze

0 Rahul Prabhu over 6 years ago in reply to j-breeze

TI__Guru** 114410 points

J-breeze,

I used the MCSDK images for this effort and used prebuilt binaries as I didn`t make any changes in the source.

I configured the boot parameter table using the i2cConfig.gel as described here:

Modified the GEL to enable BOOTP and ran the .out to flash the parameter table.

2. On the host I used a tool called TFTP32 which is described here:

I have attached the snapshot of the tool settings.:

To test this I used a switch that was not on my office network and the configured the machine LAN with static IP and connected it to the switch.

Hope this helps.

Regards,

Rahul

0 j-breeze over 6 years ago in reply to Rahul Prabhu

Mastermind 7560 points

Hi Raul,

I really appreciate your support.
I have already use the tool and configured the table using the GEL file as you told me, but the boot dose not work yet in my environment.
I connect my PC to C6678EVM directly using cross cable. Is it wrong?

And, I found a difference b/w our Wireshark logs.
In your log, BOOTP/Boot Reply(No.2) is issued after BOOTP/Boot Request(No.1), and ARPs(No. 3 & 4) are issued, and then TFTP transfer starts.
On the other hand, DHCP/DHCP Offer(No.104) is issued after BOOTP/Boot Request(No.102), and ARPs(No. 105 & 106) are issued, and then TFTP transfer starts in my log(for little endian mode in which the boot work).

I'm not familier with the protocol. Could you please let me crarify the difference, if you have any?

Regards,
j-breeze

0 j-breeze over 6 years ago in reply to j-breeze

Mastermind 7560 points

Hi Rahul,

I'd like to ask you one more thing.
Can I share your Wireshark log with my customer?

Regards,
j-breeze

0 Rahul Prabhu over 6 years ago in reply to j-breeze

TI__Guru** 114410 points

J-Breeze,

I have posted the logs in a public forum so there is no issues sharing the log with the customer.

In my setup, the connection is not directly from EVM to PC using a cross cable connection. I have created a local network using a 1G ethernet switch. I am not sure if this has been tested with direct connection between EVM And PC using cross cable but if your little endian boots ok with the setup then you should be able to use the same for big endian mode.

Regards,
Rahul

0 j-breeze over 6 years ago in reply to Rahul Prabhu

Mastermind 7560 points

Rahul,

I'm looking at the IBL code, but I'm not sure why the boot dose not work.

Could you please advice me what are the possible causes for not issuing ARP in the BE mode in my configration?
Any comment would be really appreciated.

Regards,
j-breeze

0 Rahul Prabhu over 6 years ago in reply to j-breeze

TI__Guru** 114410 points

J-Breeze,

Big endian mode is not very widely supported so I haven`t done a lot of debugging in this endian. Did you try to create a local connection using a switch as I mentioned or are you still connecting the PC directly to the EVM.

Regards,

Rahul

0 j-breeze over 6 years ago in reply to Rahul Prabhu

Mastermind 7560 points

Hi Rahul,

I'm still connecting my PC directly to the EVM.

By the way, I'd like to ask you another question. I want to debug the IBL, especially bootp.c file.
So, could you please let me know how I can see mprintf() outputs below?
I'm not sure, but I guess that the Boot Reply/DHCP Offer packet is not interpreted correctly in the BE mode.

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

    - Line 312~320

      /* DEBUG Message: */
      mprintf ("*****************************\n");
mprintf ("BOOTP Complete\n");
      mprintf ("    IP Address    : 0x%x\n", ntohl(netmcb.net_device.ip_address));
      mprintf ("    Net Mask      : 0x%x\n", subnetmask);
      mprintf ("    Default Router: 0x%x\n", defaultRouter);
      mprintf ("    Server IP     : 0x%x\n", ntohl(serverIP));
      mprintf ("    File Name     : %s\n",   ptr_bootphdr->file);
      mprintf ("*****************************\n");

Regards,
j-breeze

0 Rahul Prabhu over 6 years ago in reply to j-breeze

TI__Guru** 114410 points

J-Breeze,

My understanding is the mprintfs are used to suppress or mute the printf statements that may be inserted in the IBL code during the emulator based debugging. Usually these prints go to the CCS console and mprintfs is a way to suppress these prints. The mprintf is defined in the file iblmain.c as a function macro and you can see files like dlw_client.c includes a define as shown below

/* Eat printfs. */
#define printf mprintf

I recommend that for the mprintf that you want to see as debug outputs. you change this to uart_write_string so that you can see them on the UART when the device boots up the IBL.

Regards,
Rahul

0 j-breeze over 6 years ago in reply to Rahul Prabhu

Mastermind 7560 points

Hi Rahul,

I'd like to ask your advice about the IBL code.

I'm trying to debug the code and I found that it does not reach a bootp_receive() function after executing a bootp_tmr_expiry() function in bootp.c in the BE mode. Because of this, I can not see mprintf() outputs I mentioned in my previous post in the bootp_receive().

So, could you please give me some advice on the possible causes?

Regards,
j-breeze

0 j-breeze over 6 years ago in reply to j-breeze

Mastermind 7560 points

Hi,

The below is my Tftpd64 log. I hope It would be useful information.

o LE

    Rcvd BootP Msg for IP 0.0.0.0, Mac 40:5F:C2:B8:FC:9A [08/06 15:50:43.155]
    BOOTP: proposed address 192.168.2.201 [08/06 15:50:43.155]
    Connection received from 192.168.2.201 on port 1234 [08/06 15:50:43.171]
    Read request for file <app.out>. Mode octet [08/06 15:50:43.171]
    Using local port 49175 [08/06 15:50:43.171]
    <app.out>: sent 994 blks, 508780 bytes in 0 s. 0 blk resent [08/06 15:50:43.405]
    Warning : received duplicated request from : [08/06 15:50:43.405]
    Connection received from 192.168.2.201 on port 1234 [08/06 15:50:43.663]
    Read request for file <app.out>. Mode octet [08/06 15:50:43.663]
    Using local port 50022 [08/06 15:50:43.663]
    <app.out>: sent 994 blks, 508780 bytes in 0 s. 0 blk resent [08/06 15:50:43.881]

o BE

    Rcvd BootP Msg for IP 0.0.0.0, Mac 40:5F:C2:B8:FC:9A [08/06 15:57:01.839]
    BOOTP: proposed address 192.168.2.201 [08/06 15:57:01.839]
    Rcvd BootP Msg for IP 0.0.0.0, Mac 40:5F:C2:B8:FC:9A [08/06 15:57:09.808]
    BOOTP: proposed address 192.168.2.201 [08/06 15:57:09.808]
    Rcvd BootP Msg for IP 0.0.0.0, Mac 40:5F:C2:B8:FC:9A [08/06 15:57:21.764]
    BOOTP: proposed address 192.168.2.201 [08/06 15:57:21.764]
      .
      .
      .

Regards,
j-breeze

0 j-breeze over 6 years ago in reply to j-breeze

Mastermind 7560 points

Hi Champs,

Dose anyone help me? I have not been solved yet.

The IBL in BE mode repeats a if statement in arp_resplve() below and then excutes another if statement that shows an error "BOOTP Failure: Max Retransmissions exceeded". What could be wrong with it? What should I check next?

Any comment would be appreciated.

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

- Line 127~142

    /* Special Case: Are we sending the packet to 255.255.255.255? */
    if (dst_ip == (IPN)0xFFFFFFFF)
    {
/* YES. This implies that the destination MAC Address in the packet is the Broadcast address
   * We dont need to lookup the cache. */
    ptr_ethhdr = net_create_eth_header ((Uint8 *)ptr_iphdr, (void *)&BroadcastMac[0], 0x800);
    if (ptr_ethhdr == NULL)
return;

        /* We now have a completed Ethernet packet; send it across. */
          net_send_packet (ptr_ethhdr, sizeof(ETHHDR) + l3_pkt_size);

    /* The packet has been transmitted and we can clean it up now. */
    net_free_tx_packet ((Uint8 *)ptr_iphdr);
    return;
    }

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

- Line 141~149

    /* Check if we have exceeded the max. permissible? *
    if (bootpmcb.num_request > BOOTP_MAX_RETRIES)
    {
/* Error: Maximum retransmissions have been exceeded; indicate error. */
    mprintf ("BOOTP Failure: Max Retransmissions exceeded\n");
    net_set_error ();
    udp_sock_close(bootpmcb.sock);
    return;
    }

Regards,
j-breeze

0 Rahul Prabhu over 6 years ago in reply to j-breeze

TI__Guru** 114410 points

J-breeze,

Sorry for the delay in getting back to you.

I looked at your little endian and big endian wireshark logs and compared it with my logs along with a colleague to get additonal set of eyes on it. The big difference in the working and non-working cases is that the Read request goes out after the IP address is received.

Can you confirm that the code reaches ip_receive, udp_recieve, arp_receive, tftp_receive, bootp_receive in the failing case. Eventually, we need to find out why tftp_get_file is not being reached.

Regards,
Rahul

0 Rahul Prabhu over 6 years ago in reply to Rahul Prabhu

TI__Guru** 114410 points

You may have provided this info before but can you indicate how you changed the default server ip from 192.168.2.101 to 192.168.2.201?

I noticed in one of you earlier threads you LE log indicated the ARP response to be :
No.105: ARP Who has 192.168.2.3? Tell 192.168.2.201

and BE ARP response was :
No. 85 ARP Who has 192.168.2.101? Tell 192.168.2.3

0 j-breeze over 6 years ago in reply to Rahul Prabhu

Mastermind 7560 points

Hi Rahul,

My customer solved this issue with their own efforts and told me their tentative workaround as follows(highlighted in red). So, I'd like to close this thread.
I appreciated your support so much.

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

Regards,
j-breeze

0 Rahul Prabhu over 6 years ago in reply to j-breeze

TI__Guru** 114410 points

J-breeze,

Thank you for posting the update here and your patience when working through this issue. I am glad the issue is resolved.

I can confirm that this a bug due to inconsistent BIGENDIAN Macro definition. The C6000 Compiler defines this macro as _BIG_ENDIAN so that macro is incorrectly defined in the IBL code.I will report the bug and ask the development team to fix the bug. If you want the code to work in both little and big endian mode, you can replace BIGENDIAN with _BIG_ENDIAN.

Regards,

Rahul

Processors

Processors forum

TMS320C6678: Dose anyone have any validated big endian TFTP boot examples for C6678EVM?