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

Endianness of TI's kernel

ranchu
Guru 20755 points
Other Parts Discussed in Thread: OMAP-L138

Hello, I am using TI's PSP kernel with OMAP-L138, and I get something strange: ntohs and htons returns the same value, which makes me conclude that the host is Big endiann (same as net ordering), but the datasheet say the OMAP-L138 is little endiann. I hope you can solve this little confusion, Thank you, Ran
  • 0
    Genius 3510 points

    Hello Ran!

    You can simple check this:

    #include <stdio.h>
    unsigned short x = 1; /* 0x0001 */
    int main(void)
    {
      printf("%s\n", *((unsigned char *) &x) == 0 ? "big-endian" : "little-endian");
      return 0;
    }

     

  • 0 in reply to Kirill Brilliantov
    TI__Expert 5290 points

    Hi,

    The cpu and hence the kernel should be little-endian. I think what you are seeing is due to some eccentricity of the networking layer. I'll check if someone can shed more light on this.

    Regards,

    Vaibhav

  • 0 in reply to Vaibhav Bedia
    TI__Expert 4245 points

    One more check to do, is to run the same code for ntoh and hton on your PC which is little endian. That may help with any code issues.

  • 0 in reply to Siddharth Heroor
    Guru 20755 points

    Hello,

    Thanks for all the suggestions.

    It seems to me that maybe I confused myself and others too :


    Checking with the suggested simple program does verify that the kernel "thinks" we're little-endiann.

    If ntohs equals hsons it still does not mean that it is big-endiann architecture: if for example unsigned short temp = 0x0001, and we're using little endian architecture, then both ntohs and htons we'll result in the same value (0x0100) becuase they both replace the bytes order. it seemed to me strange at first that I get the same value and I thought that something is wrong here, but actually it does what it supposed to do.

     Regards,

    Ran