Hello Martin Thomas,

first I want thank you for your work on the WinARM toolchain.
It work's fine.

But now I've a little problem (I hope!).

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?
Is it not enough to add the option -mbig-endian to the compiler/linker 
call?

Karsten

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

Hello Karsten,

Can you please describe what you did to port your program on to the 
Board? Can you please post the contents of the makefile? Through which 
medium are you flashing the  board? ULINK? JLINK? or something else?

Regards

Vikas.