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.
Please log in before posting. Registration is free and takes only a minute.
Existing account
Do you have a Google/GoogleMail account? No registration required!
Log in with Google account
Log in with Google account
No account? Register here.