WinARM and the endian setup

Hello,

Karsten Brandt wrote:
> I develop for the TMS470 controller.
> This controller need the big-endian format.
>
> As I worked with the WinARM toolchain I've seen that all memory entry's
> are "swapped" (Is this word right? I dont know.) at every 32-bit bound.
>
> After I contact an other forum I becomes the information that I use the
> wrong endian format. And that's right.
> The next information was, that WinARM was allways build for the little
> endian format, because the most ARM controllers supports this.
>
> You can find this here:
>
> http://groups.yahoo.com/group/gnuarm/message/1988?threaded=1
>
> My question is now:
>
> Is that right, that I've have to build my own toolchain for the big
> endian support?

I'm not sure. WinARM has been build with the defaults for arm-elf but
the multilib-options have been set for little and big-endian. As far as
I know the compiler and the binutils support both without a special
configuration for the build-process.

> Is it not enough to add the option -mbig-endian to the compiler/linker
> call?

Sorry, I do not know. Maybe someone else can jump in here. So far I did
not need this and I don't have a board with a big-endian controller for
testings. Maybe additional options are needed for
compiler/linker/assembler.

You may find useful information in documentation for embedded
linux-systems or RTOS for big-endian targets (redboot, u-boot etc). The
bootloader for such systems gets build with an arm-elf toolchain, so you
may find the needed options in makefiles/configuration-files.


Martin Thomas

Hello Martin,

I've tried to compile with the -mbig-endian option.

This proccess was successfully, but on my target the created binary
doesn't work.
Can you give me a little description, how do you create a toolchain for
the minGW environment.
In this case I'll try to build a big-endian toolchain. If this
successfully we can merge our experience in the future.

I'll download the following sources from gnuARM.org:

binutils-2.16.1.tar.bz2
gcc-4.1.0.tar.bz2
newlib-1.14.0.tar.gz

I hope that you can give me that needed information.

Karsten

Hello Karsten,

first of all: It's not that nice to post the same question in different
forums at the same time. Give people some time to answer before you use
another forum/mailing-list. You have also given more and different
information in the gnuarm-thread than in this forum. This is not a good
idea too.

Karsten Brandt wrote:
>
> I've tried to compile with the -mbig-endian option.
>
> This proccess was successfully, but on my target the created binary
> doesn't work.

From what I read in the gnuarm-group "doesn't work" seems to be not
quite true. The binary itself seems to work but there seems to be an
issue with the order of data-bytes. Again: If you expect an useful
answer, give complete information. Usualy nobody will spend time to
collect your pieces of information from the gnuarm-group,
mikrocontroller.net/German forum and this forum to get the complete
picture.

> Can you give me a little description, how do you create a toolchain for
> the minGW environment.
> In this case I'll try to build a big-endian toolchain.

From what I can see WinARM should also be build for big-endian
(-mbig-endian) too.

C:\Dokumente und Einstellungen\mthomas.KATJA400>arm-elf-gcc
-print-multi-lib
.;
thumb;@mthumb
be;@mbig-endian
fpu;@mhard-float
interwork;@mthumb-interwork
nofmult;@mcpu=arm7
fpu/interwork;@mhard-float@mthumb-interwork
fpu/nofmult;@mhard-float@mcpu=arm7
be/fpu;@mbig-endian@mhard-float
be/interwork;@mbig-endian@mthumb-interwork
be/nofmult;@mbig-endian@mcpu=arm7
be/fpu/interwork;@mbig-endian@mhard-float@mthumb-interwork
be/fpu/nofmult;@mbig-endian@mhard-float@mcpu=arm7
thumb/be;@mthumb@mbig-endian
thumb/interwork;@mthumb@mthumb-interwork
thumb/be/interwork;@mthumb@mbig-endian@mthumb-interwork

But maybe there is an error somewhere.

Did you try the -EB command-line-option for linker and assembler? Again:
I do not now much about this, but I have found this option in the
binutils-documentation. If you have not used the option before try this
first.

> If this
> successfully we can merge our experience in the future.
>
> I'll download the following sources from gnuARM.org:
>
> binutils-2.16.1.tar.bz2
> gcc-4.1.0.tar.bz2
> newlib-1.14.0.tar.gz
>

Try another ready-made toolchain (i.e. gnuarm or the one codesourcery)
first before you create your own toolchain. Maybe this saves some time.
I'm not using the files from gnuarm but those from the
"distribution-servers" of the different projects (the first
WinARM-versions have been build with the sources from the
mingw-project). I don't know if the gnuarm-sources are patched.

> I hope that you can give me that needed information.

Currently I have no document how WinARM is build. Building the gnu-tools
and working arount problems is only partly automated.

Good information can be found in:
- the mingw-wikki
- the mingw-patches for gcc and binutils
- the build-script and patches from devkitpro/devkitarm
- the crosstool files

If you are building your own toolchain and find a solution please send
it. Keep in mind that WinARM has to be a collection for little- and
big-endian (well, at least for little-endian). If you'd like to have
your methods included in WinARM please don't break the little-endian
build.

Martin Thomas

Hello Thomas,

sorry, the posting in more as one forums was not ok. I noticed that now.
But I'm standing under time pressure and need a very fast solution for
my problem.

In my last post I've mentioned that the build proccess finished
successfully.

I've researched the created binary mit arm-elf-objdump -d.
The result looks ok.
Therefore I believe at the moment, that I've a problem with the transfer
of binary in the controller.

I'will test this and will you inform over the result.

Sorry again,
Karsten

Hello Thomas,

the problem is solved now. When we transfer the binary into the target,
we've also to use that big endian format for the upload program. I've
solved this and now it work's.

Result: WinARM does support little and big endian by setting the
-mbig-endian gcc option.

Thank's for your help.
Karsten