From: Grant Edwards <grant.b.edwards@gmail.com>
To: buildroot@busybox.net
Subject: [Buildroot] endian issue
Date: Sat, 15 May 2010 14:09:11 +0000 (UTC) [thread overview]
Message-ID: <hsm9u7$759$1@dough.gmane.org> (raw)
In-Reply-To: 201005151547.02656.korgull@home.nl
On 2010-05-15, Marcel <korgull@home.nl> wrote:
> I'm using an Atmel sam9g45 using buildroot with linux 2.6.33.
>
> I currently have most of my things working but run into an issue
> which is endian related.
>
> My driver outputs it's data in big-endian mode (ADC data).
Oops. The 9g45 is a little-endian part.
> This is fine with me.
Apparently not, since you're complaining about how it breaks things. ;)
> I added a package to buildroot with my own software that talks to the
> driver. This package than transfers the results either over ethernet,
> usb or rs232. This all works great as long as I don't perform any
> calculations in the package that I added.
That's because your processor is running in little-endian mode. Doing
calculations on big-endian data using a little-endian part (or vice
versa) doesn't work.
> When I do so, all data will be messed up and I'm sure it's related to
> endiannes.
n
Indeed it is.
> I think my package is compiled in little-endian mode
I would hope so, since you're running it on a little-endian part.
> and I'm quite sure this is the issue.
The issue is your driver. Change your driver to return data in the
format expected by your processor (that's little-endian in the case of
the 9g45). Then use standard macros (hton(), htons(), htonl()) to
convert data to "network order" before you ship it out via Ethernet or
USB.
[Don't ask me why Atmel chose little-endian when they designed the
AT91 peripherals. For anything with a network interface, big-endian
makes a lot more sense to me. But that debate has been going on for
40 years...]
> I did some byte swapping to proof it's the issue and this byte
> swapping makes things fine.
>
> Is there any way to compile my package in big-endian mode from
> buildroot ?
Yes.
But doing so will result in object files that don't work. In fact
you won't even be able to link them.
> Or is there another way I should force this ?
No, you shouldn't force this. You should fix your driver. Really.
--
Grant
next prev parent reply other threads:[~2010-05-15 14:09 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-05-15 13:47 [Buildroot] endian issue Marcel
2010-05-15 14:09 ` Grant Edwards [this message]
2010-05-15 14:19 ` Lionel Landwerlin
2010-05-15 14:43 ` Grant Edwards
2010-05-15 15:26 ` Marcel
2010-05-15 16:33 ` Thomas Petazzoni
2010-05-15 16:37 ` Lionel Landwerlin
2010-05-15 16:45 ` Grant Edwards
2010-05-15 17:53 ` Marcel
2010-05-15 15:18 ` Marcel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='hsm9u7$759$1@dough.gmane.org' \
--to=grant.b.edwards@gmail.com \
--cc=buildroot@busybox.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.