• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Subscribers 99 subscribers
  • Views 573 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.

Look for documentation on boot utilities

Victor Kazmirenko
Guru 13202 points

Hello!

I am working on C6670. We are planning Ethernet boot as primary boot option for our system. So far I have tried simple application from mcsdk_2_01_02_06\tools\boot_loader\examples\ethernet. As I picked up from the example, the process consists of several steps:

  1. Build .out executable using CCS.
  2. Convert .out executable to boot table using hex6x HEX conversion utility.
  3. As boot table likely to be in little endian format, convert it to big endian using bconvert64x utility.
  4. Next take boot table in big endian format and slice in packets using bootpacket utility.
  5. Load packets to DSP using pcsendpkt utility.

Easy to guess, we don't like step 4, which stores packets in text format. We'd rather store binary files on host's filesystem. Please advise,where to read about that.

Peeping at TI's utilities source code, I am trying to make our custom solution and need more information about TI utilities internals. When I look inside pcsendpkt, it just reads packet payloads from text file and sends them to net through the socket. There is a code for skipping Ethernet, IP, and UDP headers. In other words, whole Ethernet fame is available to us after bootpacket, though probably malformed. I'd ilke to know intention behind this. I can guess, we want to write on UDP socket, rather then on RAW Ethernet. However, I already prepared application which catches Ethernet ready frame and extracts DSP's MAC address. So I don't mind sending RAW Ethernet directly to DSP's hardware address.

Next, there is ugly delay code in pcsendpkt. Needless to say that useless loops may get optimized away and produce non-consistent delays on different platforms. I'd like to know, what is requirement for delays between frames in Ethernet boot process in time units.

According to Table 3-10 of SPRUGY5B KeyStone Architecture Bootloader User Guide,

Boot Table Frame Payload (min 4 bytes, max limited by max Ethernet frame - previous headers)

Ethernet frame could be up to 1514 bytes long, deduct 14 for Ethernet, 20 for IP, 8 for UDP headers, 4 for FCS - that would allow at least 1468 bytes of payload. However, I've noticed, that bootpacket utility produces much shorter frames with UDP payload of just 244 bytes. What is a reason for that? Where I could read about that?

Thanks in advance

  • 0
    TI__Genius 9065 points

    Hello,

    about text format: you can use any format you like.

    about skipping the header: please check the sendto() API.

    about delay:  the key is not to burst the packets.

    about packet size:

    In bootpacket.h file, you can switch the definition of MAX_PAYLOAD_LEN to 1176 or higher. Please note, depends on your computer settings, in some computer if you configure your packet size to 1514 bytes , then the packet will get fragmented. Bootloader does not support fragmented packets. But I found < =1200 bytes, it is OK for most computers with default configuration.

    #define MAX_PAYLOAD_LEN    244
    //#define MAX_PAYLOAD_LEN    1176

    regards,

    David

  • 0 in reply to dzhou
    Guru 13202 points

    Hello, David,

    First of all, thank you for taking attention to this thread. However, please do not be offended by not accepting the answer as it does not fully clarify my doubts.

    The only thing clear is that frames should not get fragmented. Ethernet itself does not make fragmentation, so one have to care about that only if uses sockets stack to produce frames. I work with raw Ethernet, so all is under my control, I do make sure I do not exceed allowed size.

    As engineer, I understand, what your are saying about interframe spacing, though some measurable value would be preferred. May I suggest to update documentation, as it mentions nothing about this issue.

    Could you please clarify, that bootpacket utility produces fully formatted frames? The reason why pcsendpkt skips their headers is to replace them with other headers, but generally is not required? I mean, that in example the headers made by bootpacket were not well considered, thus get replaced.

    Could you please refer another thread at http://e2e.ti.com/support/dsp/c6000_multi-core_dsps/f/639/t/278275.aspx and clarify. I think that bconvert64x and bootpacket utilities are making endian conversion two times.

    Could you please clarify, whether I can make boot table with hex6x alone? Is there any restriction which I did not meet in example?

    Thank you.

  • 0 in reply to Victor Kazmirenko
    TI__Genius 9065 points

    Hello,

     

    1) dealy: not measured and not documented. In your case, please try with a delay to got it working first, then try to shorten it to see if works or not.

    2) header skippeing: simply those was not needed for sendto() function. Please check API definition for sendto() function. Yes, bootpacket produces the fully formatted frame. You can try to not skipping the header and do a test to see what happens by capturing the packets going out and compare them.

    3) I will check the other thread.

    regards,

    David