AVR32 Binutils 2.22 Ready for Test

Log in or register to post comments
Go To Last Post
8 posts / 0 new
Author
Message
jasminj
jasminj's picture
Level: New Member
Joined: Mon. Mar 19, 2012
Posts: 7 View posts
Location: Vienna, Austria
#1
Posted by jasminj: Mon. Apr 9, 2012 - 10:36 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The short story :)

I just finished the build of the avr32 Version of binutils-2.22 8).

I tried the gas and ld test (make check), but this produced some errors.
The same error happened with my build of binutils 2.20.1.
I guess ATMEL didn't update the test cases for long time.

Currently I have no hardware to test the result. I hope someone else can try this version.

You can find the full statically built binaries here:
http://avr.anw.at/avr32/binaries/avr32-tools-0.1.0.tgz

And the README:
http://avr.anw.at/avr32/binaries/README

The patch(es) can be found here:
http://avr.anw.at/avr32/patches/binutils/2_22/

The binaries should run on any system newer than Debian Etch (e.g.: Lenny, Squeeze, wheezy, ...). I guess a RedHat based system will work, too.

Why I did it :shock:

I am still using a Lenny system and the tools from ATMEL will not run on Lenny. So I decided to rebuild the tools.
I used the avr32-toolchain from James Snyder, available here:
https://github.com/jsnyder/avr32-toolchain

Then I had the idea to make gdb running in this make file. The original version couldn't handle delta building of parts, which is required during patch development. I didn't want to fix all the different make steps separately. So I decided to use a new approach, where make macros are generating the rules.
At the end I started a new avr32-toolchain project, which you can get here:
http://web.anw.at/websvn/listing.php?repname=avr32-toolchain

The new make file:
http://web.anw.at/websvn/filedetails.php?repname=avr32-toolchain&path=%2Ftrunk%2FMakefile

Then I decided to use the newest sources and then I had a lot of work with binutils :oops:.

In the hope that the changes can be put into the mainline binutils in the near future, I made it as perfect as I could. I did analyze several mainline changes, before I fixed the linker. But when I am honest. I have not much knowledge of all this stuff.
The best would be, that someone from ATMEL or some other experienced person will check my changes. If the internals of binutils have changed much, I guess it will not work.

Next would be GCC 4.7. I am not sure if this is the right version to try, because the current avr32 GCC is version 4.4.3. There are a lot of changes in GCC since that version, but when we want to have the avr32 target in the mainline, we need to do it in the most recent version, I guess.

Before I start!
Has anybody else started such a project?
Are there any good reasons not to try it?
Does ATMEL already work on this subject?

Cheers,
Jasmin

Tags:

Tools, In-System Debuggers and Programmers
Top
kblomqvist
kblomqvist's picture
Level: Hangaround
Joined: Sun. Dec 11, 2011
Posts: 203 View posts
Location: Finland
Posted by kblomqvist: Wed. Jul 11, 2012 - 07:25 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hope you are still around. I would be keen to know how this would work out (building with the newer version of GCC). I don't know any reasons why not try. Don't know either if Atmel works on this.

I have built the 32-bit Toolchain with the newer version of Newlib (1.19.0) and Binutils (2.22) using the James Snyder's Makefile as well. Newlib version 1.19.0 seemed to work out very well and in all my tests the sprintf() has worked now kindly. With Newlib 1.16.0 it tended to crash the execution every now and then.

The latest Newlib version, 1.20.0, did not build though. I have reported these experiment to Atmel and they have promised to look at updating to the latest Newlib version.

Quote:
The original version couldn't handle delta building of parts, which is required during patch development. I didn't want to fix all the different make steps separately. So I decided to use a new approach, where make macros are generating the rules.
Would it be possible you to work at GitHub? This way it would be easier to see what has been changed and you may also like to send pull request to James.

Quote:
Next would be GCC 4.7. I am not sure if this is the right version to try, because the current avr32 GCC is version 4.4.3.
First, bet for the highest version. If that does not work, then try the highest of 4.4.x release. If that works, then go to the next major release.

Looking forward to hear your efforts with the new builds 8)

Top
jasminj
jasminj's picture
Level: New Member
Joined: Mon. Mar 19, 2012
Posts: 7 View posts
Location: Vienna, Austria
Posted by jasminj: Fri. Jul 13, 2012 - 12:41 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

kblomqvist wrote:
Hope you are still around. I would be keen to know how this would work out (building with the newer version of GCC). I don't know any reasons why not try. Don't know either if Atmel works on this.
Yes, I am still here, but had a lot of work for my homepage.
In the meantime a had an eMail contact with Atmel about newer avr32 tools. They told me, that they may come out with a new avr32 gcc, based on the 4.6.3 version.

kblomqvist wrote:

I have built the 32-bit Toolchain with the newer version of Newlib (1.19.0) and Binutils (2.22) using the James Snyder's Makefile as well.
which means you used my patches. Did the resulting Compiler/Assembler/Linker work as expected?

kblomqvist wrote:

The latest Newlib version, 1.20.0, did not build though. I have reported these experiment to Atmel and they have promised to look at updating to the latest Newlib version.
Aha. I know, that they plan a replacement for Newlib. An avr32-libc in assembler. But this is really a plan only, I guess.

kblomqvist wrote:

Would it be possible you to work at GitHub? This way it would be easier to see what has been changed and you may also like to send pull request to James.
First, I am not familiar with Git.
Second, I changed the internal structure of the Makefile really much, so that it is now a fork. I told this James, but got no answer.
If you want to see any changes, I have prepared the SVN Web access and the public SVN access.
My focus with the new Version is a simple way to test and develop patches. At the end I guess it is the best approach to add the resulting patches and versions to crosstool-ng, because this is a really simple tool to build the complete toolchain by everyone, without knowledge of make and other things.

kblomqvist wrote:

Looking forward to hear your efforts with the new builds 8)
I will wait until the end of summer, because I don't see any reason to do the work twice. I hope I can keep in touch with Atmel and get some information about the state of the tools.

The only think I know is, that GCC 4.7.x is very different and maybe I am able to port the GCC patches to 4.6.3, but definitely not to 4.7.x. I am not a compiler specialist and gcc is a big chunk of code and you need a lot of knowledge about it to write a working backend.

If I am honest. I would like to have a working toolchain to start my project and not to work on the compiler and gdb much.
I guess there will be a lot of things to do for me to bring my AT32UC3B0256 to life with freeRTOS and to write all the glue code and extensions for a comfortable environment, which I know from my company.

Top
kblomqvist
kblomqvist's picture
Level: Hangaround
Joined: Sun. Dec 11, 2011
Posts: 203 View posts
Location: Finland
Posted by kblomqvist: Sat. Jul 14, 2012 - 11:23 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

jasminj wrote:

In the meantime a had an eMail contact with Atmel about newer avr32 tools. They told me, that they may come out with a new avr32 gcc, based on the 4.6.3 version.
That would be greate. Hope that this will eventually happen.

jasminj wrote:
...which means you used my patches. Did the resulting Compiler/Assembler/Linker work as expected?
Unfortunately I did not use your patches. I just changed the version variable of the Binutils to 2.22 and updated the MD5 checksum. That did the trick. But I'm using Squeeze where you are on Lenny?

jasminj wrote:
Aha. I know, that they plan a replacement for Newlib. An avr32-libc in assembler. But this is really a plan only, I guess.
Wow, that would be nice. However, atm. the most important maneuver would be upgrading to the latest Newlib. It's not that bad. The 1.19.0 works out of the box with the current patches. And I guess that it won't take more than a week for Atmel engineer to update patches for Newlib 1.20.0.

jasminj wrote:
If I am honest. I would like to have a working toolchain to start my project and not to work on the compiler and gdb much.
Yes of course. Btw. what's holding you on Lenny? As said the Toolchain builds with Binutils 2.22 out of the box on Squeeze.

Top
jasminj
jasminj's picture
Level: New Member
Joined: Mon. Mar 19, 2012
Posts: 7 View posts
Location: Vienna, Austria
Posted by jasminj: Sat. Jul 14, 2012 - 01:08 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

kblomqvist wrote:

Unfortunately I did not use your patches. I just changed the version variable of the Binutils to 2.22 and updated the MD5 checksum. That did the trick.
The original Atmel patches (3.2.3.261: Binutis 2.20.1) did not apply without errors! Moreover I had to change the code, because Binutils did change the internal interface of the bfd library.
Please check, if you really use 2.22. I can't believe this!

kblomqvist wrote:

And I guess that it won't take more than a week for Atmel engineer to update patches for Newlib 1.20.0.
Currently I have no time to do it, Sorry.

kblomqvist wrote:

Yes of course. Btw. what's holding you on Lenny? As said the Toolchain builds with Binutils 2.22 out of the box on Squeeze.
I use my company Laptop and have to use our virtual machine. Currently this is still Lenny, but we will move to another platform. Maybe RedHat or Ubuntu LTS or ... .

If you compile the Tools yourself it doesn't matter which system you have. Lenny is good enough. The drawback is, that I can't use the prebuild binaries from Atmel.

Top
kblomqvist
kblomqvist's picture
Level: Hangaround
Joined: Sun. Dec 11, 2011
Posts: 203 View posts
Location: Finland
Posted by kblomqvist: Sat. Jul 14, 2012 - 02:23 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

jasminj wrote:
Please check, if you really use 2.22. I can't believe this!
In the Makefile I have set these variables:

BINUTILS_VERSION = 2.22
BINUTILS_MD5 = ee0f10756c84979622b992a4a61ea3f5

With these changes the build compiles and works in real projects. And if I check under the downloads directory I have binutils-2.22.tar.bz2 file there. I cannot see what ever the Binutils could be than 2.22 :wink:

jasminj wrote:
Currently I have no time to do it, Sorry.
You work at Atmel?

Edit: Oops... sorry my bad. Of course you have to update to the newest AVR patches from Atmel too:

AVR_PATCH_REV = 3.4.0.332
AVR32PATCHES_MD5 = 376926e2b4f889b4c422d4e1d3a7c4b6

I see it now. This was the reason why it worked for me in the first place. I think that these patches were not available when you have tried to build with Binutils 2.22.

Top
jasminj
jasminj's picture
Level: New Member
Joined: Mon. Mar 19, 2012
Posts: 7 View posts
Location: Vienna, Austria
Posted by jasminj: Sat. Jul 14, 2012 - 05:10 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

kblomqvist wrote:
You work at Atmel?
No, but I should continue with the whole toolchain, before I start to work with my chip :)
And I need some holidays end of July.
I hope I can get more in touch with the Atmel tools developers. Sharing resources save money and moves the community forward!

kblomqvist wrote:

AVR_PATCH_REV = 3.4.0.332
AVR32PATCHES_MD5 = 376926e2b4f889b4c422d4e1d3a7c4b6
I see it now. This was the reason why it worked for me in the first place. I think that these patches were not available when you have tried to build with Binutils 2.22.
No they were not available!
I did a very short look and they added some devices.
I need to apply the whole patches. They added a few more patches. After a short check, they fixed most of the things I found. I guess I fixed some warnings, too.
I added patches for the resulting autoconf/automake files, so that it is not necessary to use the maintainer mode. This simplifies the build process and makes it easier to contribute it to crosstool-ng.

I could be now a little bit angry, because they did it in March and I did it in April.
This means I wasted time :x

Would be nice, if they would work more with the community. They could make a public available SVN repository, so that other people could help them and get an early information, too.

Last Edited: Sun. Jul 15, 2012 - 08:24 AM
Top
kblomqvist
kblomqvist's picture
Level: Hangaround
Joined: Sun. Dec 11, 2011
Posts: 203 View posts
Location: Finland
Posted by kblomqvist: Sun. Jul 15, 2012 - 08:06 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

jasminj wrote:
I hope I can get more in touch with the Atmel tools developers. Sharing resources save money and moves the community forward!
Enterprising! Keep us updated :)

jasminj wrote:
They could make a public available SVN repository, so that other people could help them and get an early information, too.
I agree. +1 for this, although I would prefer git :wink:

Top