(Outdated) Script for building AVR-GCC 4.5.1 on Linux

Go To Last Post
343 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

[Moderator's note: as that thread is sticky now, please
avoid followups here. Rather open your own new thread
instead.]

Quote:
*** YOU MUST LOG IN TO DOWNLOAD THE SCRIPTS ***

Quote:
*** Experimental DEBUGGING of XMEGA's is supported on Linux. But the full protocol is still an Atmel secret.

See : http://www.avrfreaks.net/index.p...

Quote:
Now also as a .deb install package ... Read further on below

Quote:

Here is a list of Linux tools & tips i use on Ubuntu
http://www.avrfreaks.net/index.p...

Guyzz i have succeded in building avr-gcc-4.3.4 w. avr-libc-1.6.8 , and Jörg's latest patches on my Ununtu 10.04

Quote:
I'm only testing on the latest Ubuntu LTS.
All other version & distro's , are not guaranteed to work/compile. I'll try to help out , and so will the forum i'm sure. But don't demand support if it doesn't work , just ask nicely in the forum

I am enclosing the scripts i use (credits of A. Erasmus) , if they could be of any use

The steps are these:

Read Readme.txt
Then install the packages listed in pre-reqs.txt.

Note !!
Don't try to call the scripts from another directory location , always execute from same directory where the scripts are located.
The current scripts uses recursive deletes , that could erase the harddisk if the above isn't honored.

Then....

1: Make sure you are root (blushing) , or use sudo
2: Make a working directory , where you extract the files from the archive.
3: If desired edit the buildavr-no-insight.sh file , to change the prefix .. default is : prefix=/usr/local/avr
4: Make sure that the prefix dir is empty or nonexisting
5: Run : chmod +x *.sh
6: Run : ./getfiles.sh
7: Run : ./get-patches.sh
8: Run : ./buildavr-gdb.sh
9: Run: ./buildavr-toolchain.sh

You just answer yes to the existing directory question in step 9.

When building is done , you might want to free around 500MB of diskspace by removing the sources and binaries used to make avr-gcc.
To do so Run: ./buildavr-cleanup.sh

Note this little script expects the "build prefix" to be /usr/local/avr/

Edit:2
I have an avr user on my Linux-box for doing avr development , i have added this to my .bash_profile in my /home/avr directory , it sets up the path to avr-gcc.

Quote:

# User specific environment and startup programs
PREFIX=/usr/local/avr
export PREFIX

PATH=$PATH:$HOME/bin:$PREFIX/bin
export PATH

Quote:

The script builds avr-gcc-4.3.4 w. binutils2.20 and then avr-libc-1.6.8
The script now also automaticly builds avarice-2.10 and avrdude-5.9 , as per request of Jörg.

Note : gcc-4.3.x uses the GMP & MPFR libs , in order to function. So make sure to install the packets mentioned pre-reqs.txt

avr-insight is upgraded to ver 6.8 witch builds ok on 64-bit machines , and it has its own buildscript (buildinsight.sh) , as it takes ages to build.

Use: tar xvzf to extract it if it's a .tgz file, or unzip if it's a zipfile.

Just ansver yes if any of the scripts says that /usr/local/avr exists (ie. when building insight after gcc or the other way around.

But always delete /usr/local/avr before you are making a total/new rebuild.

Quote:

Updated the scriptfiles to build binutils and insight without the -Werror flag. This was caused by GCC 4.3.x (on Ubuntu 8.10) being unable to build the targets. And was due to a lot of new warnings being enabled by default.

Quote:

@20-jun-2009
Upgraded the "old" script building avr-gcc-4.2.2 to build avr-gcc-4.2.4 ... "Jörg did all the patches".
4.2.2 could produce more compact code in some cases.

Quote:

@14-jul-2009
Upgraded the script to build avr-libc-1.6.7 and avrdude-5.8 , no changes to avr-gcc.
As usual "Jörg & the others" did all the hard work.

Quote:

@12-aug-2009
Upgraded the avr-gcc-4.2.4 script to build avr-libc-1.6.7 and avrdude-5.8.
Also applied a "Hotfix patch" to binutils , to avoid a relocation error in the AVR25 architecture (tiny85 etc).
Everybody is urged to rebuild their toolchain

Quote:
@29-0ct-2009
Updated the avr-gcc-4.1.2 binutils 1-17 avr-libc-1.46
script , as it failed in makeinfo.
Moved the updated script to this post
http://www.avrfreaks.net/index.p...

Quote:
@03-Nov-2009
Updated the avr-gcc-4.3.3 script , with an avarice patch , to fix a problem when building with "native" gcc 4.4.1

Quote:
@01-Dec-2009
Made a Debian/Ubuntu ".deb" install package containing the binaries build with the above 03-Nov-2009 script.
Read more here
http://www.avrfreaks.net/index.p...

Quote:
@17-Dec-2009
Updated the ".deb" install package , w. a new avrdude binary , containing a PDI patch. (See .txt file in the download site)
Read more here
http://www.avrfreaks.net/index.p...

Quote:
@16-Jan-2010
Updated the avr-gcc-4.3.3 script , to build avrdude-5.9
Removed the two "interrim avrdude patches" , as 5.9 should fix that.
All other remains unchanged.
The script still includes the "AVR25 relocation fix" patch , and the avarice patch

Quote:
@18-Jan-2010
Updated the ".deb" install package (named 16-jan-2010) , w. avrdude-5.9. (See .txt file in the download site)
Read more here
http://www.avrfreaks.net/index.p...

Get the package here.
http://www.wrightflyer.co.uk/avr...

Quote:
@26-Jan-2010
Updated the scriptfiles and the ".deb" install package to 26-jan-2010 , Added avrdude-5.10 , all other unchanged.

Get the package here.
http://www.wrightflyer.co.uk/avr...

Quote:
@25-Feb-2010
Made a "Special Static" version , with the patches from WinAVR-20100110-install.exe , so it should be compatible.

Should be installable on both 32-bit & 64-bit versions.
See http://www.avrfreaks.net/index.p...

Get the package here.
http://www.wrightflyer.co.uk/avr...

Quote:
@09-Mar-2010
Updated the avr-gcc script , to build avr-gcc-4.3.4 and binutils-2.20.
Added 2 patches to avr-insight/avr-gdb.
Added a builtins.h file in the builddir , see readme for use

Added a package-versions file , now versions are only maintained in that file.
Added a new "automatic" way to patch binutils , gcc & insight.

Thanx to Jörg the linux (FreeBSD) build , now has the same patches as WinAVR-2010. A big thankyou to Jörg & EW.

Also uploaded as .deb package avr-gcc-4.3.4-avrfreaks-09-mar-2010.deb
Get the package here.
http://www.wrightflyer.co.uk/avr...

Quote:
@30-apr-2010
Rebuild the 09-mar-2010 packages on Ubuntu 10.04 LTS
This time i have a x64 system , so i build both 32bit (i386) and 64bit x64 packages.

Uploaded as .deb packages here
http://www.wrightflyer.co.uk/avr...
Only toolchain change is : Updated insight from 6.8 to 6.8-1

Quote:
@04-jun-2010
Updated buildscript to build avr-insight to 6.8-1
No other changes , and no new .deb's as the 30-apr deb's allready contains that.

Quote:
@12-sep-2011
Did a rebuild of the old trusty avr-gcc-4.3.4 toolchain , with avr-libc-1.7.1 and avrdude-5.11 - avr-insight has switched from 6.8-1 to 6.8-1a

Had to do a "kludge" in order to build avr-insight , ad the file is named 6.8-1a , but it extracts to 6.8-1 directory
Run ./repack-insight.sh , before ./buildinsight.sh

Removed all the rm -fr * , from the buildscript

See readme in zipfile

Also uploaded .deb files to http://www.wrightflyer.co.uk/avr...

Quote:
@20-sep-2011
Updated the 12-sep-2011 package (see install instructions there)

avrdude updated from 5.11 to 5.11.1 (Serious Bugfix)
avarice updated from 2.10 to 2.11 )minor compilation issues)

See readme in zipfile

Also uploaded .deb files to http://www.wrightflyer.co.uk/avr...

Quote:
@29-dec-2011
Updated the buildscript with the latest patches from the FreeBSD repos (Thanx Jörg)

avr-gcc updated to 4.5.1
avr-libc updated to 1.8.0
binutils updated to 2.20.1
avarice updated to 2.12
insight replaced with gdb 7.3.1

See readme in zipfile

More info & comments should go here
http://www.avrfreaks.net/index.p...

05-jan-2012
Also uploaded .deb files to http://www.wrightflyer.co.uk/avr...

Quote:
@08-mar-2012
Updated the buildscript with suggestions/patches from Axel W. (Uracoli)
The suggestions makes the get-patches.sh script more secure , and improves on the buildavr-cleanup.sh script.

The resulting toolchain is the same as the 29-dec-2011 TC.

Thanx Axel.

Quote:
@26-feb-2013
Updated the buildscript with working file mirrors

Quote:
@30-nov-2013
Updated the buildscript to build :
avrdude 6.0.1 (Thanx Jörg)
avr-gdb 7.6.1

Quote:
@26-apr-2014
Updated the buildscript to build :
avrdude 6.1 (Thanx Jörg)
and included the patches in the zipfile
So skip the get-patches.sh step

/Bingo
.
.
.

Attachment(s): 

Last Edited: Tue. Jul 19, 2016 - 03:53 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

This appears to have become an at least occasionally requested item.

Is there any interest of making this thread `sticky'?

(Please stop replying if you see there's an unanimous vote; I'll
have to split the thread otherwise to decouple the `noise' from
the actual content otherwise before making it sticky.)

Jörg Wunsch

Please don't send me PMs, use email if you want to approach me personally.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

dl8dtl wrote:

Is there any interest of making this thread `sticky'?

I think that would be a good idea. In particular, I find the information about patches (and where to get them) very useful.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'm a relative newbie to Linux, used SUSE a little. Just today I installed UBUNTU. Looks like it will help me brake that bad Windose and commercial-Linux habit.

Have played around with WINAVR a little and like it. Would like to go to GNU GCC on Linux.

Making this thread sticky has my vote.

Mike

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Just "Touching the date"

/Bingo

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hello,

compiling binutils with the your scripts failed for me with the following error message (using a current gentoo box with gcc 4.1.1):

gcc -DHAVE_CONFIG_H -I. -I../../../source/binutils-2.17/binutils -I. -D_GNU_SOURCE -I. -I../../../source/binutils-2.17/binutils -I../bfd -I../../../source/binutils-2.17/binutils/../bfd -I../../../source/binutils-2.17/binutils/../include -I../../../source/binutils-2.17/binutils/../intl -I../intl -DLOCALEDIR="\"/usr/local/avr/share/locale\"" -Dbin_dummy_emulation=bin_vanilla_emulation   -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Werror -g -O2 -c ../../../source/binutils-2.17/binutils/wrcoff.c
cc1: warnings being treated as errors
../../../source/binutils-2.17/binutils/wrcoff.c: In Funktion »coff_start_struct_type«:
../../../source/binutils-2.17/binutils/wrcoff.c:2277: Warnung: berechneter Wert ist unbenutzt
make[4]: *** [wrcoff.o] Fehler 1
make[4]: Leaving directory `/usr/local/avr/build/binutils-2.17/binutils'
make[3]: *** [all-recursive] Fehler 1
make[3]: Leaving directory `/usr/local/avr/build/binutils-2.17/binutils'
make[2]: *** [all] Fehler 2
make[2]: Leaving directory `/usr/local/avr/build/binutils-2.17/binutils'
make[1]: *** [all-binutils] Fehler 2
make[1]: Leaving directory `/usr/local/avr/build/binutils-2.17'
make: *** [all] Fehler 2
(./buildavr-no-insight.sh) binutils build failed

Any idea?

Regards:

Uwe Fechner

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Drop the -Werror. I'm not going to do anything about the COFF patch
anymore, given that AVR-COFF is close to be dead.

Jörg Wunsch

Please don't send me PMs, use email if you want to approach me personally.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hello,

thank you very mutch. Your script run successfully with Mandriva 2005. I made a little remark, it don't run with Mandriva 2007. There are some errors with "binutils build failed" message.

Regards.

Monmon :D

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi,

Is there an easy way to drop the -Werror using the script? It fails on a ubuntu 6.10 and I have tried to remove the -Werror but somehow it pops back again...

/Mikael

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

> Is there an easy way to drop the -Werror using the script? It fails
> on a ubuntu 6.10 ...

"Is there a way to get rid off these seat belts? They are always in
my way."

The correct solution is not to remove the -Werror but to remove the
warning triggering your problem. Not having Ubuntu Linux, and you not
quoting it, I can only guess, but I assume it's:

wrcoff.c: In function 'coff_start_struct_type':
wrcoff.c:2277: warning: value computed is not used

FreeBSD's CVS version recently also switched to GCC 4.x, and thus also
stumbled across that one.

I have just updated the COFF patch for this in my FreeBSD port. The
solution was much simpler than your attempt to get rid of the -Werror:
a "(void)" cast had to be placed before a function call that returned
a value that was not used. (Upon thinking of it, I'm asking myself
whether ignoring the return value is actually the right thing to do,
but at least, it's been that way all the time, and I don't really see
the Big Picture of all this anymore after that many years.)

I also updated the ATmega256x patch in binutils to get rid of that
annoying "operation is dangerous with linker stubs" warning that was
triggered by large C switch() statements. In a discussion with Björn
Haase, we agreed that this was a regression (it wasn't really
dangerous in the switch() situation anyway), and also not all that
useful as Björn initially believed, as there are many more other ways
to shoot into your feet with the linker stubs which cannot be warned
about anyway. So that warning is gone now. (This matches the patch
Eric is using for his most recent WinAVR.)

Jörg Wunsch

Please don't send me PMs, use email if you want to approach me personally.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks Jörg!

The void cast did the trick in Ubuntu 6.10 as well.

/Mikael

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

This script worked flawlessly on Arch linux.

Any hints on how build avr-insight, and/or avr-gdb?

Thanks,
Sam

EDIT

I am sorry, that didn't really follow http://www.catb.org/~esr/faqs/smart-questions.html

What I should say is that I have a difficult time determining what the latest stable package is. Right now I am building Insight 6.6.

./configure --prefix=/home/swinchen/opt/avr-insight --target=avr

I am just not sure if I will run into any problems with this version.

Thanks Again,
Sam

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Would it be a problem, for the purpose of consistency, to alter this script to install in the gcc directory (/usr/lib/gcc/gcc-4.1 not sure) along with the i486 target and the arm-elf target?

Thanks,
outer_space

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

outer_space wrote:
Would it be a problem, for the purpose of consistency, to alter this script to install in the gcc directory (/usr/lib/gcc/gcc-4.1 not sure) along with the i486 target and the arm-elf target?

Thanks,
outer_space

Maybe like this ??

Quote:

3: If desired edit the buildavr-no-insight.sh file , to change the prefix .. default is : prefix=/usr/local/avr

the prefix , is pointing to the final "Install dir"

/Bingo

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I mean to suggest altering the script to make it consistent with native and arm prefixes so all three end up in the same spot (for everybody)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I seem to recall having read that once upon a time the /usr/local/avr prefix was chosen so that it would be a simple matter of blowing away the entire directory to get rid of *everything* AVR-related from the filesystem without worrying about:
1) Accidentally removing anything non-AVR-related in the same operation
2) Accidentally losing track of some AVR components and orphaning them

I'm sure there are better ways to accomplish both of these tasks nowadays though.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

> I'm sure there are better ways to accomplish both
> of these tasks nowadays though.

Only if you are carefully tracking the files you did install.
That's where the package management systems of the various Unix
systems come into the game. If you are installing something
outside of these package managers, you have to track that
yourself.

Each of the tools should also come with a Makefile target
"make uninstall", but I wouldn't hold my breath to see whether
they are really removing everything (including perhaps empty
directories they once created): these targets probably belong
to the lesser tested features even if they come "for free"
along with autoconf/automake.

Jörg Wunsch

Please don't send me PMs, use email if you want to approach me personally.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If somenone wants to build packages for installation using the debian packaging system, I wrote a mini how-to:

http://blog.coldtobi.de/index.ph...

Enjoy!

(The patches are also filed against the debian packages, for your reference, these are the bug numbers:
#420061 #416924 )

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Just touching the date , to indicate the new avr-libc-1.4.6 build

/Bingo

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi,

I change my PC and now I installed Ubuntu 7.04. The script work perfectly with my old PC and Mandrake 2005 (not with 2007).

AVR-GCC package download don't work on tiny45. Then I want compile this version and patches (tiny45) but ./configure indicate : "C compiler cannot create executables". I try different options but there is always this error :oops:.

Thank for your help and for all Ubuntu users.

Monmon.
(Celeron 2500 + Ubuntu 7.04 + Tiny45 + Kontrollerlab)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

IIRC Ubuntu doesn't come with a native C compiler as part of the standard installation. You need to install GCC separately (using apt-get or Synaptic) before you can use it with Bingo's script to build AVR-GCC.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi Ifmorrison,

thank you for your answer but I have already install :
-------------------------------------------------------------
gcc -v
Utilisation des specs internes.
Target: i486-linux-gnu
Configuré avec: ../src/configure -v --enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --program-suffix=-4.1 --enable-__cxa_atexit --enable-clocale=gnu --enable-libstdcxx-debug --enable-mpfr --enable-checking=release i486-linux-gnu
Modèle de thread: posix
version gcc 4.1.2 (Ubuntu 4.1.2-0ubuntu4)
-------------------------------------------------------------

or I don't understand that you mean.

Thank you very much for your help. (excuse me for my english)

Monmon.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

This is snipped from the AVR32 section , but i think you need to install this on unbuntu , to be able to build a compiler.

sudo apt-get install build-essential

/Bingo

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi Bingo600,

I'm so sorry but now, there are another error after I installed build-essential :

config.status: creating po/Makefile.in
config.status: executing depfiles commands
config.status: executing default commands
make[3]: quittant le répertoire « /usr/local/avr/build/binutils-2.17/bfd/po »
make[3]: entrant dans le répertoire « /usr/local/avr/build/binutils-2.17/bfd/po »
make[3]: Rien à faire pour « info ».
make[3]: quittant le répertoire « /usr/local/avr/build/binutils-2.17/bfd/po »
make[3]: entrant dans le répertoire « /usr/local/avr/build/binutils-2.17/bfd »
make[3]: Rien à faire pour « info-am ».
make[3]: quittant le répertoire « /usr/local/avr/build/binutils-2.17/bfd »
make[2]: *** [info-recursive] Erreur 1
make[2]: quittant le répertoire « /usr/local/avr/build/binutils-2.17/bfd »
make[1]: *** [all-bfd] Erreur 2
make[1]: quittant le répertoire « /usr/local/avr/build/binutils-2.17 »
make: *** [all] Erreur 2
(./buildavr-no-insight.sh) binutils build failed

Thank you for your help and your time.

Monmon

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I hope this link will be useful for someone. Using that how-to I have installed avr-gcc on my Linux Suse 10.
Link: http://www.linuxjournal.com/arti...
I have compiled binutils, gcc and avr libc. When I was compiling simulavr I had been given a mistake.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Added script files for building avr-gcc-4.1.2 w. avr-libc-1.4.6

The following devices are supported :
A snip from the command : avr-gcc --target-help.

Known MCU names:
  avr1 avr2 avr3 avr4 avr5 avr6 at90s1200 attiny10 attiny11 attiny12
  attiny15 attiny28 at90s2313 at90s2323 at90s2333 at90s2343 attiny22
  attiny26 at90s4433 at90s4414 at90s4434 at90s8515 at90s8535 at90c8534
  at86rf401 attiny13 attiny2313 attiny261 attiny461 attiny861 attiny24
  attiny44 attiny84 attiny25 attiny45 attiny85 atmega603 atmega103
  at43usb320 at43usb355 at76c711 atmega48 atmega8 atmega83 atmega85
  atmega88 atmega8515 atmega8535 atmega8hva at90pwm1 at90pwm2 at90pwm3
  atmega16 atmega161 atmega162 atmega163 atmega164p atmega165 atmega165p
  atmega168 atmega169 atmega169p atmega32 atmega323 atmega324p atmega325
  atmega325p atmega329 atmega329p atmega3250 atmega3250p atmega3290
  atmega3290p atmega406 atmega64 atmega640 atmega644 atmega644p atmega128
  atmega1280 atmega1281 atmega645 atmega649 atmega6450 atmega6490
  atmega16hva at90can32 at90can64 at90can128 at90usb82 at90usb162
  at90usb646 at90usb647 at90usb1286 at90usb1287 at94k atmega2560
  atmega2561

/Bingo

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

monmon wrote:
Hi Bingo600,

I'm so sorry but now, there are another error after I installed build-essential :

config.status: creating po/Makefile.in
config.status: executing depfiles commands
config.status: executing default commands
make[3]: quittant le répertoire « /usr/local/avr/build/binutils-2.17/bfd/po »
make[3]: entrant dans le répertoire « /usr/local/avr/build/binutils-2.17/bfd/po »
make[3]: Rien à faire pour « info ».
make[3]: quittant le répertoire « /usr/local/avr/build/binutils-2.17/bfd/po »
make[3]: entrant dans le répertoire « /usr/local/avr/build/binutils-2.17/bfd »
make[3]: Rien à faire pour « info-am ».
make[3]: quittant le répertoire « /usr/local/avr/build/binutils-2.17/bfd »
make[2]: *** [info-recursive] Erreur 1
make[2]: quittant le répertoire « /usr/local/avr/build/binutils-2.17/bfd »
make[1]: *** [all-bfd] Erreur 2
make[1]: quittant le répertoire « /usr/local/avr/build/binutils-2.17 »
make: *** [all] Erreur 2
(./buildavr-no-insight.sh) binutils build failed

Thank you for your help and your time.

Monmon

Try to install "texinfo" with the synaptic install manager, then it builds OK for me on Ubuntu 7.04, Feisty Fawn!

ekh

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

As ekh wrote

on Ubuntu 7.04 do :

1: sudo apt-get install build-essential
2: then install texinfo , either via apt-get or the synaptic install/packet manager.

/Bingo

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi everybody,

thank you very much for your help,

now, it work fine with build-essential package, texinfo package, avr-gcc 4.1.2 and unbuntu 7.04.

I can play or work ;-) with my tiny 45 and KontrollerLab.

Regards.

Monmon.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi,

a simple information, script 4.1.2 work fine with Mandriva 2007 spring if "texinfo" package is installed.

Monmon.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

It seems to me that at some point someone in this community should realize that the preeminent source of stable code in this chan is maintained in the FreeBSD ports collection.

I have finally gotten around to working on a generalized 'portscrape' method. This will actually build the toolchain on SLES 10 and should keep up with whatever revision is blessed. (This seems to need some tweeking to work on OSX's bash.)

I am working on the automation of the packaging from here.

#!/bin/bash
function getfiles ()
{
for fname in $FILES ; do 
echo "GETTING ----- $fname -----"
case ${fname##*\.} in 
  bz2)
     echo "GETTING ----- $fname ----- using bunzip "
     curl ftp://ftp2.freebsd.org/pub/FreeBSD/distfiles/$fname \
      |bunzip2 -dc|tar -xf -
     ;;
  gz|tgz)
     echo "GETTING ----- $fname ----- using gunzip "
     curl ftp://ftp2.freebsd.org/pub/FreeBSD/distfiles/$fname \
      |gzip -dc|tar -xf -
     ;;
esac
done

}

function patchfiles () {
PORTNAME=`cat $port/Makefile |grep ^PORTNAME|cut -f2`
PORTVERSION=`cat $port/Makefile |grep ^PORTVERSION|cut -f2`
ocd=`pwd`
cd $PORTNAME-$PORTVERSION*
echo "-------- PATCHING HERE `pwd`  ------"
for p in $ocd/$port/files/patch* ; do
   patch -p0 -u <$p
done
cd $ocd

}

function makeit () {
PREFIX=/usr/local
LOCALBASE=/usr/local
CONFIGURE_ARGS=`cat $port/Makefile |grep ^CONFIGURE_ARGS|sed 's/^CONFIGURE_ARGS\=\t//'`
MAKE_ARGS=`cat $port/Makefile |grep ^MAKE_ARGS|sed 's/^MAKE_ARGS\=\t//'`
PORTNAME=`cat $port/Makefile |grep ^PORTNAME|cut -f2`
PORTVERSION=`cat $port/Makefile |grep ^PORTVERSION|cut -f2`
ocd=`pwd`
cd $PORTNAME-$PORTVERSION*
echo "-------- CONFIGURING HERE `pwd`  ------"
echo "$CONFIGURE_ENV ./configure $CONFIGURE_ARGS "
export `cat $port/Makefile |grep ^CONFIGURE_ENV|sed 's/\t/ /g'|sed 's/^CONFIGURE_ENV\=//'`
./configure $CONFIGURE_ARGS >config.out
echo "$MAKE_ENV make $MAKE_FLAGS && $MAKE_ENV make $MAKE_FLAGS install"
export `cat $port/Makefile |grep ^MAKE_ENV|sed 's/\t/ /g'|sed 's/^MAKE_ENV\=//'`
make $MAKE_FLAGS && make $MAKE_FLAGS install
# make $MAKE_FLAGS distclean
cd $ocd
}

for port in avr-binutils avr-gcc avr-libc avr-gdb avarice simulavr ; do
curl  "http://www.freebsd.org/cgi/cvsweb.cgi/ports/devel/$port/$port.tar.gz?tarball=1"|gzip -dc|tar -xvf -
export FILES=`grep MD5 $port/distinfo|cut -d\( -f2|cut -d\) -f1`
getfiles "$FILES"
patchfiles "$port" "$FILES"
makeit "$port" "$FILES"
done 
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

@08-Oct-2007
Added a new set of scriptfiles to avr-gcc-4.1.2
The only change is the WinAVR binutil patch of avr-size , to output %full , at end of compile.

To use the new avr-size function you have to modify the makefile.

Replace the old size stuff with this , in the makefile

# Display size of file.
HEXSIZE = $(SIZE) --target=$(FORMAT) $(TARGET).hex
ELFSIZE = $(SIZE) --mcu=$(MCU) --format=avr $(TARGET).elf

sizebefore:
   @if test -f $(TARGET).elf; then echo; echo $(MSG_SIZE_BEFORE); $(ELFSIZE); \
   2>/dev/null; echo; fi

sizeafter:
   @if test -f $(TARGET).elf; then echo; echo $(MSG_SIZE_AFTER); $(ELFSIZE); \
   2>/dev/null; echo; fi

Edit: If make complains , after insetting the above , make sure to replace the "spaces" in front of the @ , with a "tab"

/Bingo

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ddd7 wrote:
It seems to me that at some point someone in this community should realize that the preeminent source of stable code in this chan is maintained in the FreeBSD ports collection.

It is both FreeBSD and WinAVR. Joerg and I work together to share common patches.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

That would be my point with the exception of the patches that you discussed in the osx-avr thread.

Taking this one step further.

The /usr/ports/devel/avr-.* directories contain not only the current patches for .*x systems, but also the source locations, the environment and compiler flags to compile them. Which is why I suggested that a script would be better off extracting this data from the definitive source than rewriting a fresh script every time. The script above was an attempt to hack out a quick proof of concept. It isn't pretty but it works.

There is a good deal of other material in each ports Makefile including descriptions, dependencies, versions and file manifests which could be scripted into depots (hpux), packages(solaris), PackageMaker files(osx), .dpkg's (debian) or rpms.

pushing out from there
a) This could be rewritten in a more robust shell such as perl and generalized to create a framework from scraping the data into patched source trees or various package formats. This might serve to rapidly decrease the delay between your releases and releases by and for the rest of us.

b) More investigation on the OSX side could be done in carrying on the early "port the ports" efforts which were made when darwin first came out. If you pull the source manually into distfiles you can actually run bsdmake from an unmodified ports tree and get the more difficult work done (patch,configure,compile). It makes me wonder what a body could do with a few choice modifications to the /usr/ports/Mk directory.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I've tested the script on Ubuntu 7.10.
First the 'texinfo' package was missing. I've installed it with the 'Synaptic Package Manager' and then the script works perfectly!

Thanks for the updated avr-gcc-4.2.2 script,
Thomas

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The new script avr-gcc 4.2.2 & avr-libc 1.6.1 , now knows the following mcu's

Known MCU names:
  avr1 avr2 avr3 avr4 avr5 avr6 at90s1200 attiny10 attiny11 attiny12
  attiny15 attiny28 at90s2313 at90s2323 at90s2333 at90s2343 attiny22
  attiny26 at90s4433 at90s4414 at90s4434 at90s8515 at90s8535 at90c8534
  at86rf401 attiny13 attiny2313 attiny261 attiny461 attiny861 attiny24
  attiny44 attiny84 attiny25 attiny45 attiny85 attiny43u attiny48 attiny88
  atmega603 atmega103 at43usb320 at43usb355 at76c711 at90usb82 at90usb162
  atmega48 atmega48p atmega8 atmega83 atmega85 atmega88 atmega88p
  atmega8515 atmega8535 atmega8hva at90pwm1 at90pwm2 at90pwm2b at90pwm3
  at90pwm3b atmega16 atmega161 atmega162 atmega163 atmega164p atmega165
  atmega165p atmega168 atmega168p atmega169 atmega169p atmega32 atmega323
  atmega324p atmega325 atmega325p atmega328p atmega329 atmega329p
  atmega3250 atmega3250p atmega3290 atmega3290p atmega32hvb atmega406
  atmega64 atmega640 atmega644 atmega644p atmega128 atmega1280 atmega1281
  atmega1284p atmega645 atmega649 atmega6450 atmega6490 atmega16hva
  at90can32 at90can64 at90can128 at90pwm216 at90pwm316 at90usb6

/Bingo

Last Edited: Sun. Dec 23, 2007 - 08:54 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If anyone experiences errors with makeinfo , when building binutils.

Have a look here.

http://www.avrfreaks.net/index.p...

I have updated the scripts in the beginning of this thread with the one containg the makeinfo patches.

/Bingo

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks a lot. Got it working on Fedora core 8 (fc8), 64 bit machine. :D

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Here is a link to a CodeBlocks linux install (Ubuntu) , and there are hints how to build insight & gdb for avr
http://www.avrfreaks.net/index.p...

/Bingo

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Another excellent resource for installing CodeBlocks on Ubuntu Hardy 8.04

http://www.futuredesktop.org/codeblocks_on_ubuntu_8.04.html

IDE - Eclipse w/AVR Eclipse plugin
Programmer - AVRISP MKII
OS - Ubuntu (Intrepid) Linux

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I just finished this update on ubuntu 6.06 dapper drake and had to take two additional steps.

Prior to building

sudo apt-get install texinfo

post built

sudo cp /usr/local/avr/bin/* /usr/bin

thanks for producing this script, it fixed my compiler issues (ISRs not recognized)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

machs_fuel wrote:
I just finished this update on ubuntu 6.06 dapper drake and had to take two additional steps.

Prior to building

sudo apt-get install texinfo

post built

sudo cp /usr/local/avr/bin/* /usr/bin

thanks for producing this script, it fixed my compiler issues (ISRs not recognized)

Well if you have read the start you would have seen the texinfo part. And the hint to where the default toolchain would be build

/Bingo

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi friends i have downloaded
(1)binutils-2.15.tar.bz2:Assembler
(2)gcc-core-3.4.2.tar.bz2:GNU C Compiler
(3)avr-libc-1.0.4.tar.bz2:AVR C Library
from 'http://electronicsforu.com/efyco...' URL

assuming that i am in the path /usr/local/src/

Step1:
mkdir /usr/local/avr
cd binutils-2.15
mkdir avrobj;cd avrobj
../confugre --target=avr --prefix=/usr/local/avr --disable-nls
make;make install

Result of Step1:
Process ended with two errors

Step2:
export PATH=$PATH:/usr/local/avr/bin
cd gcc-3.4.2
mkdir avrobj;cd avrobj
../confugre --target=avr --prefix=/usr/local/avr --disable-nls --enable-language=c
make;make install

Result of Step1:
Process is not even getting started....
Error stating there is no such file or directory 'configure' and error in 'language=c'

Please can any one solve this problem.

i have 6 years of experience in AVR ICs but new to Linux....

:cry:

ATMEL--Heart Beat
Nothing Impossible

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Do you really need such an old compiler version ??

Why not use the 4.1.2 zip from the beginning of this script.
And maybe read the first post in full , meaning you might need the texinfo package etc ...

/Bingo

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks Mr.Bingo. I will try that one.... Will it work with Fedora linux?

ATMEL--Heart Beat
Nothing Impossible

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

srinivasandelta wrote:
Thanks Mr.Bingo. I will try that one.... Will it work with Fedora linux?

It should... :D

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi, where are the scripts for this now? Are they still available?

Thanks

Trev

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Reply to my own, now dumb question. After maximising the display, the shortcuts magically appeared at the top.

Sorry.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

There seems to be a bug with build-avr-gcc-4.2.2-libc-1.6.2-makeinfo-fixed.tar.gz.
On different Linux distributions i receive a avr.sc.rej while patching binutils.
The patch is unnable to find

  MEMORY
  {
-   text   (rx)   : ORIGIN = 0, LENGTH = $TEXT_LENGTH
-   data   (rw!x) : ORIGIN = $DATA_ORIGIN, LENGTH = $DATA_LENGTH
-   eeprom (rw!x) : ORIGIN = 0x810000, LENGTH = 64K
  }

because the 'data'-line in the source file looks different...

   data   (rw!x) : ORIGIN = 0x800060, LENGTH = $DATA_LENGTH

Changing this line in binutils-patch-newsections.diff to read like the source file fixed the problem.

edit: UPPS. you also need to change the replacement line or the resulting linker script will fail.

... the only thing you cannot unscramble is eggs...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

wBoellmann wrote:
There seems to be a bug with build-avr-gcc-4.2.2-libc-1.6.2-makeinfo-fixed.tar.gz.
On different Linux distributions i receive a avr.sc.rej while patching binutils.
The patch is unnable to find

  MEMORY
  {
-   text   (rx)   : ORIGIN = 0, LENGTH = $TEXT_LENGTH
-   data   (rw!x) : ORIGIN = $DATA_ORIGIN, LENGTH = $DATA_LENGTH
-   eeprom (rw!x) : ORIGIN = 0x810000, LENGTH = 64K
  }

because the 'data'-line in the source file looks different...

   data   (rw!x) : ORIGIN = 0x800060, LENGTH = $DATA_LENGTH

Changing this line in binutils-patch-newsections.diff to read like the source file fixed the problem.

edit: UPPS. you also need to change the replacement line or the resulting linker script will fail.

I can confirm the bug , and it seems to be in patch-newsections. Will contact the patch maintainer (jörg).

Edit: This is fixed in the new script in the first post (Oct-28-2008).

So you can skip the next 2 post , with the old patch , and the "Interrim script"

/Bingo

Last Edited: Tue. Oct 28, 2008 - 05:46 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

for now you can use the old patch

Please save the below to the direcory where you have the patches , and name it binutils-patch-newsections.diff
do remember the blank line at the end.

--- ld/scripttempl/avr.sc.old	2007-09-14 06:32:02.437500000 -0600
+++ ld/scripttempl/avr.sc	2007-09-14 06:50:28.854125000 -0600
@@ -4,9 +4,12 @@ OUTPUT_ARCH(${ARCH})
 
 MEMORY
 {
-  text   (rx)   : ORIGIN = 0, LENGTH = $TEXT_LENGTH
-  data   (rw!x) : ORIGIN = 0x800060, LENGTH = $DATA_LENGTH
-  eeprom (rw!x) : ORIGIN = 0x810000, LENGTH = 64K
+  text      (rx)   : ORIGIN = 0, LENGTH = $TEXT_LENGTH
+  data      (rw!x) : ORIGIN = 0x800060, LENGTH = $DATA_LENGTH
+  eeprom    (rw!x) : ORIGIN = 0x810000, LENGTH = 64K
+  fuse      (rw!x) : ORIGIN = 0x820000, LENGTH = 1K
+  lock      (rw!x) : ORIGIN = 0x830000, LENGTH = 1K
+  signature (rw!x) : ORIGIN = 0x840000, LENGTH = 1K
 }
 
 SECTIONS
@@ -196,6 +199,24 @@ SECTIONS
     ${RELOCATING+ __eeprom_end = . ; }
   } ${RELOCATING+ > eeprom}
 
+  .fuse ${RELOCATING-0}:
+  {
+    KEEP(*(.fuse))
+    KEEP(*(.lfuse))
+    KEEP(*(.hfuse))
+    KEEP(*(.efuse))
+  } ${RELOCATING+ > fuse}
+
+  .lock ${RELOCATING-0}:
+  {
+    KEEP(*(.lock*))
+  } ${RELOCATING+ > lock}
+
+  .signature ${RELOCATING-0}:
+  {
+    KEEP(*(.signature*))
+  } ${RELOCATING+ > signature}
+
   /* Stabs debugging sections.  */
   .stab 0 : { *(.stab) }
   .stabstr 0 : { *(.stabstr) }


/Bingo

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Guyzz i have made an interrim version to fix the patch problem.
I apply 2 new patches to binutils , but i'm not 100% sure that they are production ready , and i cant seem to get hold of jörg.

But here it comes :-)

From the included Readme file

Quote:

Start by reading this thread http://www.avrfreaks.net/index.p...
Or at least the first post.

This build is an interim version , to fix some patch problems with binutils.

It is almost 100% like the gcc4.2.2-libc1.6.2 from the top of the sticky script on freaks.

It has 2 new patches applied to binutils 2.1.8

patch-bug5523 <--------- New
patch-data-origin <--------- New

patch-xmega <--------- New , but fails miserably , and isn't commited yet. So this patch is not applyed

And it automaticly builds avarice-2.8 and avrdude-5.5
avr-insight has its own buildscript (buildinsight.sh) , as it takes ages to build.

All files are installed into /usr/local/avr/ , and one can delete the source & build directorys afterwards to save 500MB+ diskspace

Please make sure to install the packets from pre-reqs.txt , before building the toolchain.

I have given the apt-get commands for Ubuntu in pre-reqs-txt.

Be sure to adapt them to any other linux distro.

/Bingo

Ohh ... extract the file with : tar xvzf

/Bingo

Attachment(s): 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hello,

I tried to build avr-gcc on my Ubuntu 8.04 (x86_64) box. The
buildavr-no-insight.sh script works fine but the buildinsight.sh script stops with the following output:

/usr/local/avr/source/insight-6.7.1/itcl/itcl/generic \
         -I/usr/local/avr/source/insight-6.7.1/tcl/generic -I/usr/local/avr/source/insight-6.7.1/tk/generic     \
         ../../../source/insight-6.7.1/gdb/gdbtk/generic/gdbtk-register.c \
        -DGDBTK_LIBRARY=\"/usr/local/avr/share/insight1.0\"
cc1: warnings being treated as errors
../../../source/insight-6.7.1/gdb/gdbtk/generic/gdbtk-register.c: In function ‘get_register_name’:
../../../source/insight-6.7.1/gdb/gdbtk/generic/gdbtk-register.c:348: warning: cast from pointer to integer of different size
make[2]: *** [gdbtk-register.o] Error 1
make[2]: Leaving directory `/usr/local/avr/build/insight-6.7.1/gdb'
make[1]: *** [all-gdb] Error 2
make[1]: Leaving directory `/usr/local/avr/build/insight-6.7.1'
make: *** [all] Error 2
(./buildinsight.sh) insight build failed (0)

Has anyone an idea why it fails?

Is it possible to only build gdb without insight?

I've retried it without success, attached the build log.

Regards, Gilles

Attachment(s): 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

roodemol wrote:
Hello,

I tried to build avr-gcc on my Ubuntu 8.04 (x86_64) box. The
buildavr-no-insight.sh script works fine but the buildinsight.sh script stops with the following output:

/usr/local/avr/source/insight-6.7.1/itcl/itcl/generic \
         -I/usr/local/avr/source/insight-6.7.1/tcl/generic -I/usr/local/avr/source/insight-6.7.1/tk/generic     \
         ../../../source/insight-6.7.1/gdb/gdbtk/generic/gdbtk-register.c \
        -DGDBTK_LIBRARY=\"/usr/local/avr/share/insight1.0\"
cc1: warnings being treated as errors
../../../source/insight-6.7.1/gdb/gdbtk/generic/gdbtk-register.c: In function ‘get_register_name’:
../../../source/insight-6.7.1/gdb/gdbtk/generic/gdbtk-register.c:348: warning: cast from pointer to integer of different size
make[2]: *** [gdbtk-register.o] Error 1
make[2]: Leaving directory `/usr/local/avr/build/insight-6.7.1/gdb'
make[1]: *** [all-gdb] Error 2
make[1]: Leaving directory `/usr/local/avr/build/insight-6.7.1'
make: *** [all] Error 2
(./buildinsight.sh) insight build failed (0)

Has anyone an idea why it fails?

Is it possible to only build gdb without insight?

I've retried it without success, attached the build log.

Regards, Gilles

It seems that they have made the new insight 6.8 , more 64-bit friendly

Get it from here
ftp://sourceware.org/pub/insight...

And correct the version number in the top of the buildinsight.sh script

Then rerun ./buildinsight.sh

If it works for you i'll corerct the scriptfiles to use the new insight 6.8 , but i don't have a 64-bit to test on.

So please report error/success

/Bingo

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hello,

good news, insight 6.8 build without any problem on my computer.

Thanks for the support.

Gilles

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The script in the first post is now working again , and we have got Xmega support in avr-gcc.
I also updated avr-insight to ver 6.8 , and am also building avarice and avrdude.

The following devices are supported :
A snip from the command : avr-gcc --target-help

Known MCU names:
  avr1 avr2 avr3 avr31 avr35 avr4 avr5 avr51 avr6 avrxmega1 avrxmega2
  avrxmega3 avrxmega4 avrxmega5 avrxmega6 avrxmega7 at90s1200 attiny10
  attiny11 attiny12 attiny15 attiny28 at90s2313 at90s2323 at90s2333
  at90s2343 attiny22 attiny26 at90s4433 at90s4414 at90s4434 at90s8515
  at90s8535 at90c8534 at86rf401 attiny13 attiny2313 attiny261 attiny461
  attiny861 attiny24 attiny44 attiny84 attiny25 attiny45 attiny85
  attiny43u attiny48 attiny88 atmega603 atmega103 at43usb320 at43usb355
  at76c711 at90usb82 at90usb162 attiny167 atmega48 atmega48p atmega8
  atmega83 atmega85 atmega88 atmega88p atmega8515 atmega8535 atmega8hva
  at90pwm1 at90pwm2 at90pwm2b at90pwm3 at90pwm3b atmega16 atmega161
  atmega162 atmega163 atmega164p atmega165 atmega165p atmega168 atmega168p
  atmega169 atmega169p atmega32 atmega323 atmega324p atmega325 atmega325p
  atmega328p atmega329 atmega329p atmega3250 atmega3250p atmega3290
  atmega3290p atmega32hvb atmega406 atmega64 atmega640 atmega644
  atmega644p atmega128 atmega1280 atmega1281 atmega1284p atmega645
  atmega649 atmega6450 atmega6490 atmega16hva at90can32 at90can64
  at90can128 at90pwm216 at90pwm316 atmega32c1 atmega32m1 atmega32u4
  at90usb646 at90usb647 at90usb1286 at90usb1287 at94k atmega2560
  atmega2561 atxmega64a1 atxmega128a1

Be sure to read the readme.txt , and the pre-reqs.txt

/Bingo

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The download seems to be broken. :cry: Only 9.9 kB :shock:

Quote:
gzip: stdin: unexpected end of file
tar: Child returned status 1
tar: Error exit delayed from previous errors

... the only thing you cannot unscramble is eggs...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

wBoellmann wrote:
The download seems to be broken. :cry: Only 9.9 kB :shock:
Quote:
gzip: stdin: unexpected end of file
tar: Child returned status 1
tar: Error exit delayed from previous errors

Well the file is just 9.9 KB , as it is just the scripts.

I can confirm that the archive seems broken.
I will upload a new version.

But i think the contents is ok.

Strange ....

I have tried to extract the "local" .tar.gz file on 3 different Linux machines (2 Ubuntu , and a Centos) and they are ok.

But if i download and extract the tar.gz file from avrfreaks it fails , the extraction (on all 3).

The strange part is that neither WinZip nor WinRar complains about extraction , of the above file.

I wonder if Avr Freaks have a problem with tar.gz files ???
Could anyone else test by uploading/attaching a tar.gz file ?

Quote:
I added the archive as a WinZip file , and it seems to download & extract fine. So if extraction fails , use the zip archive.

/Bingo

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thank U :D

... the only thing you cannot unscramble is eggs...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Here is a link to build a portable avr-libc , on a linux machine
http://www.avrfreaks.net/index.p...

And a thread where the avr-gcc build process might be better described for a linux newbie
http://www.avrfreaks.net/index.p...

/Bingo

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hmm I think I used the script before a year+ ago, but now it "evolved" into something else.

Is there still a script that does the build without any frills ? I don't want Tk, I don't want tex, I don't want a graphical debugger (!) heck I don't want a debugger even ! And I certainly don't want that before I have a binutils/gcc toolchain working.

Has anyone documented the build process for "manual" build from the generic source file + patches ?

Author of simavr - Follow me on twitter : @buserror

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

@buserror

You don't need TK , if you skip the "insight" part,it's a separate build script.
You need texinfo , unless you can convince binutils not to build docs.

Avrdude and AVArice , is being build unless you hack the script , as per request of Jörg.

/Bingo

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Updated the 4.2.2 zipfile to build under Ubuntu 8.10

/Bingo

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

hi.. i am trying to configure gcc to /home/local/avr but getting configure error while binutils has been configured and installed. plz help

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

hi.. i am trying to configure gcc to /home/local/avr but getting configure error while binutils has been configured and installed. plz help

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

/home/local/avr is a strange path but ....

If you are using the scripts from this post , edit the scripts , and change the "Prefix" variable. To the path you would like.

Remember to be root or make sure the prefix path is writeable by your user

/Bingo

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Bingo600 wrote:
Updated the 4.2.2 zipfile to build under Ubuntu 8.10

/Bingo

I am running Ubuntu 8.10 and have avr-gcc 4.3.0 from the Ubuntu repositories. Does this script force a downgrade to 4.2.2?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

barney_1 wrote:
Bingo600 wrote:
Updated the 4.2.2 zipfile to build under Ubuntu 8.10

/Bingo

I am running Ubuntu 8.10 and have avr-gcc 4.3.0 from the Ubuntu repositories. Does this script force a downgrade to 4.2.2?

Yes this will install avr-gcc 4.2.2.

Don't run 2 avr gcc's at the same time.

If you use the script , then uninstall the ones you got from ubuntu , before using the script.

/Bingo

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If you need avr-gcc 4.3.2 for linux (Ubuntu) , have a look here

http://www.avrfreaks.net/index.p...

/Bingo

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have avr-gcc and avr-libc installed on my opensuse system. ive tested that im able to compile a very basic program (making a led light up when a button is pressed). is there any reason i should ditch my current setup and install things this way?
and btw, totally new to this =)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Do you know the phrase "if it ain't broke don't fix it?" :lol:

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

so what you are saying is that this script wont give me anything i havent got already?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

...but don not ask the forum why your compiler can't build code for your new AVR controller :idea:

... the only thing you cannot unscramble is eggs...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hr_Pengesekk wrote:
so what you are saying is that this script wont give me anything i havent got already?
IIRC the patches allow some syntax that the generic build does not.
My recollection is that it is syntax that I use.

International Theophysical Year seems to have been forgotten..
Anyone remember the song Jukebox Band?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Note to any other newbies like me out there... if it fails after running the getfiles and patches scripts asking for a lib from binutils be sure to read the pre-reqs file and install the necessary packages.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

For building AVR-GCC 4.3.3 have a look here (or directly at the FemtoOS site http://www.femtoos.org/ )

http://www.avrfreaks.net/index.p...

/Bingo

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

avr-gcc-4.2.2 toolchain - Minor update

Quote:
Still using binutils-2.1.8 ,avr-gcc-4.2.2

But the script is updated to build : avr-libc-1.6.6 , avarice-2.10 and avrdude-5.6.

avr-insight is still ver 6.8 witch builds ok on 64-bit machines , and it has its own buildscript (buildinsight.sh) , as it takes ages to build.

Use: tar xvzf to extract it

Just ansver yes if any of the scripts says that /usr/local/avr exists.

But always delete /usr/local/avr before you are making a new version build.

/Bingo

Attachment(s): 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I am having a failure building from Debian Lenny (amd64).
The script fails while building avr-dude, the error has to do with yyin and yylex not defined.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks So much!
I need to compile for the atmega32u4

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

kscharf wrote:
I am having a failure building from Debian Lenny (amd64).
The script fails while building avr-dude, the error has to do with yyin and yylex not defined.

You are quite right , you prob need flex & bison.

Have a look in the Readme :wink:
Doesn't it say you need to install the deb packages mentioned in the prereq.txt file. :D

/Bingo

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yes, I've installed flex and bison along with all the other prereq packages. I still get the error.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

kscharf wrote:
Yes, I've installed flex and bison along with all the other prereq packages. I still get the error.

That is strange ....

Could you post the full err mesgs ?

Or maybe this hint will work.
http://www.avrfreaks.net/index.p...

/Bingo

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Brad S.

Another avrfreak have made a script that builds avr-gcc 4.3.2 , w. WIN-Avr patches i think
It is untested by me , but the topic is here
http://www.avrfreaks.net/index.p...

/Bingo

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If the last update to the patch is from 2008 then perhaps you should unstick this link until someone takes over current concurrency in the linux domain.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Just updated the "old" 4.2.2 script to build 4.2.4 w. full xmega support (per 20-jul-2006)
Well Jörg did all the patches i just adapted the script.

This will prob. be the last 4.2.x version , but 4.2.x sometimes creates more compact code than 4.3.x.

Known MCU names:
  avr1 avr2 avr25 avr3 avr31 avr35 avr4 avr5 avr51 avr6 avrxmega1
  avrxmega2 avrxmega3 avrxmega4 avrxmega5 avrxmega6 avrxmega7 at90s1200
  attiny11 attiny12 attiny15 attiny28 at90s2313 at90s2323 at90s2333
  at90s2343 attiny22 attiny26 at90s4414 at90s4433 at90s4434 at90s8515
  at90c8534 at90s8535 attiny13 attiny13a attiny2313 attiny24 attiny44
  attiny84 attiny25 attiny45 attiny85 attiny261 attiny461 attiny861
  attiny43u attiny48 attiny88 at86rf401 at43usb355 at76c711 atmega103
  at43usb320 attiny167 at90usb82 at90usb162 atmega8 atmega48 atmega48p
  atmega88 atmega88p atmega8515 atmega8535 atmega8hva at90pwm1 at90pwm2
  at90pwm2b at90pwm3 at90pwm3b atmega16 atmega161 atmega162 atmega163
  atmega164p atmega165 atmega165p atmega168 atmega168p atmega169
  atmega169p atmega32 atmega323 atmega324p atmega325 atmega325p atmega3250
  atmega3250p atmega328p atmega329 atmega329p atmega3290 atmega3290p
  atmega406 atmega64 atmega640 atmega644 atmega644p atmega645 atmega649
  atmega6450 atmega6490 atmega16hva at90can32 at90can64 at90pwm216
  at90pwm316 atmega16u4 atmega32c1 atmega32m1 atmega32u4 atmega32u6
  at90usb646 at90usb647 at94k atmega128 atmega1280 atmega1281 atmega1284p
  atmega128rfa1 at90can128 at90usb1286 at90usb1287 atmega2560 atmega2561
  atxmega64a3 atxmega64a1 atxmega128a3 atxmega256a3 atxmega256a3b
  atxmega128a1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I would like to thank everyone who has contributed to this effort. The results are wonderful. I had spent 3 days by hand attempting to do what your scripts did in several hours. It looks like everything has compiled and installed properly. I am able to compile and burn images to a 3290p device without issue.

The last remaining piece I have is an issue with avr-insight. It seems to have an issue with tk.tcl not being installed properly. I checked the directories it was searching and found the files there, but no such luck. Anyone else have an issue with tk.tcl?

Thanks,
John.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

The last remaining piece I have is an issue with avr-insight. It seems to have an issue with tk.tcl not being installed properly. I checked the directories it was searching and found the files there, but no such luck. Anyone else have an issue with tk.tcl?

I had exactly the same problem. As ddd rather than insight is my poison of choice anyway I just did an apt-get on that and used it as the front end to avr-gdb

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

@johnny_sako & Clawson

I have just been building the toolchain (4.3.3) on my WIND , and don't get this error.

I started by building avr-insight , and then the gcc-tooolchain.

The only thing i get an error with is: when i try to start avr-insight , being su'ed to root or another user.

avr:~$ avr-insight
Tk_Init failed: no display name and no $DISPLAY environment variable

avr:~$ export DISPLAY=localhost:0.0

avr:~$ avr-insight
Tk_Init failed: this isn't a Tk applicationcouldn't connect to display "localhost:0.0"

But if i start it as my "login" user it starts up wo. any errors .... But i dont specify anything on the cmd line besides avr-insight.

/Bingo

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Ah, that may explain it. I hate all this protection nonsense in Linux (now creeping into Windows too) so just as I always run as Administrator in Windows I always run as root in Linux. Having said that I actually installed and built the toolchain as root so I should be the "login user" for it anyway.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

@Cliff

By loginuser i mean the user logging in on/via the graphical login page (if ubuntu)
I think he is the one owning the "DISPLAY"

This is an X (graphics) problem (who owns the display i guess ??) not the toolchain or root issue.

/Bingo

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

@14-Jul-2009

Updated script to build avr-libc-1.6.7 and avrdude-5.8 , no change to avr-gcc.

/Bingo

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Updated the buildscripts to fix an avr architecture 25 relocation error
http://www.avrfreaks.net/index.p...

/Bingo

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Bingo, perhaps you should note that to download (and even see!) the scripts, you have to be registered and logged in. I always come to get the scripts when I am logged out and look aimlessly for the scripts for about a minute before realising I have to log in!

Math is cool.
jevinskie.com

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi,
Thanks for this useful thread.
I got an error when compiling with ./buildavr-no-insight.sh on my system: the error is due to my version of gcc installed on my PC, version 4.4.1. I got an error with "const char *" instead of "char *" which stopped the compilation.

To solve it, I added a 'sed' instruction to /buildavr-no-insight.sh before the avarice compilation:

   sed -i '98s/jtagDeviceName/(char *)jtagDeviceName/g' ../../source/${avaricebase}/src/jtag2usb.cc
   echo "($0) configuring avarice source"

Olivier

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hello again,
Is there any chance that the Xmega 192A3 is also a recognized device by avr-gcc ?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Once you have built your avr-gcc use "avr-gcc --target-help" to get a list of the supported devices.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Here is the list, there is no atxmega192A3:

Known MCU names:
  avr1 avr2 avr25 avr3 avr31 avr35 avr4 avr5 avr51 avr6 avrxmega1
  avrxmega2 avrxmega3 avrxmega4 avrxmega5 avrxmega6 avrxmega7 at90s1200
  attiny11 attiny12 attiny15 attiny28 at90s2313 at90s2323 at90s2333
  at90s2343 attiny22 attiny26 at90s4414 at90s4433 at90s4434 at90s8515
  at90c8534 at90s8535 attiny13 attiny13a attiny2313 attiny24 attiny44
  attiny84 attiny25 attiny45 attiny85 attiny261 attiny461 attiny861
  attiny43u attiny48 attiny88 at86rf401 at43usb355 at76c711 atmega103
  at43usb320 attiny167 at90usb82 at90usb162 atmega8 atmega48 atmega48p
  atmega88 atmega88p atmega8515 atmega8535 atmega8hva at90pwm1 at90pwm2
  at90pwm2b at90pwm3 at90pwm3b atmega16 atmega161 atmega162 atmega163
  atmega164p atmega165 atmega165p atmega168 atmega168p atmega169
  atmega169p atmega32 atmega323 atmega324p atmega325 atmega325p atmega3250
  atmega3250p atmega328p atmega329 atmega329p atmega3290 atmega3290p
  atmega406 atmega64 atmega640 atmega644 atmega644p atmega645 atmega649
  atmega6450 atmega6490 atmega16hva at90can32 at90can64 at90pwm216
  at90pwm316 atmega16u4 atmega32c1 atmega32m1 atmega32u4 atmega32u6
  at90usb646 at90usb647 at94k atmega128 atmega1280 atmega1281 atmega1284p
  atmega128rfa1 at90can128 at90usb1286 at90usb1287 atmega2560 atmega2561
  atxmega16a4 atxmega16d4 atxmega32d4 atxmega32a4 atxmega64a3 atxmega64a1
  atxmega128a3 atxmega256a3 atxmega256a3b atxmega128a1

Should I use this one ?

avrxmega6 - XMEGA, > 128K, <= 256K FLASH, <= 64K RAM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'd just use atxmega256a3 (almost identical but for the code flash size) and just watch for the code size bursting 192K

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hello everybody,
I just wanted to say a big Thank you to Bingo600 for his script, it worked flawless... :D

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Updated the

Quote:
This package contains the buildscripts and the patchfiles , for binutils-2.1.7 (w. the avr-size patch), avr-gcc-4.1.2 and avr-libc-1.46. Skip the get-patches.sh step , as the patches are included.

to include a makeinfo patch.

It now compiles correctly on my Ubuntu 8.04

/Bingo

Attachment(s): 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

obor00 wrote:
Hi,
Thanks for this useful thread.
I got an error when compiling with ./buildavr-no-insight.sh on my system: the error is due to my version of gcc installed on my PC, version 4.4.1. I got an error with "const char *" instead of "char *" which stopped the compilation.

To solve it, I added a 'sed' instruction to /buildavr-no-insight.sh before the avarice compilation:

   sed -i '98s/jtagDeviceName/(char *)jtagDeviceName/g' ../../source/${avaricebase}/src/jtag2usb.cc
   echo "($0) configuring avarice source"

Olivier

In response to this , and this thread http://www.avrfreaks.net/index.p...

I have made a new buildscript , witch incorporates a patch from Jörg.

Edit: 20-nov-2009 , removed the attached file
See the first post in this thread , for the newest version

Last Edited: Fri. Nov 20, 2009 - 04:32 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi, I was wondering how this installer script differs from the WinAVR package. I see that the newest "stable" WinAVR release consists of GCC 4.3.2 + avr-libc 1.6.4 + a lot of patches. Bingo's script uses more recent sources but with less patches. Which of these would be the more bug-free package?

WinAVR has a pretty large user base, so I guess their packages get quite a lot of testing. Also, it would be nice (sometimes even compulsory) to get the exactly similar avr hex files from both Windows and Linux development environments.

So, my question is, would it be a good idea to also provide an installer script that installs a package exactly like the WinAVR but for Linux? Or do you think that Bingo's script is in all aspects better, and instead we should use this script also in windows?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

slintone wrote:
Hi, I was wondering how this installer script differs from the WinAVR package. I see that the newest "stable" WinAVR release consists of GCC 4.3.2 + avr-libc 1.6.4 + a lot of patches. Bingo's script uses more recent sources but with less patches. Which of these would be the more bug-free package?

WinAVR has a pretty large user base, so I guess their packages get quite a lot of testing. Also, it would be nice (sometimes even compulsory) to get the exactly similar avr hex files from both Windows and Linux development environments.

So, my question is, would it be a good idea to also provide an installer script that installs a package exactly like the WinAVR but for Linux? Or do you think that Bingo's script is in all aspects better, and instead we should use this script also in windows?

The script & patches i use is based on the FreeBSD repository (Jörg maintains it).

If you want to build a toolchain , that uses WinAVR patches (Eric.W/EW maintains it) , have a look here.

Its the toolchain builder that comes with FemtoOS , made by Ruud Vlaaming.
http://www.avrfreaks.net/index.p...

The choice is yours , but to build the toolchain on windows , seems like a waste of time. Since WinAVR is allready made there.

I would expect WinAVR & this script to generate the same code , but sometimes (well most of it ...) WinAVR is a bit ahead of the FreeBSD repository.

/Bingo

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi

buildavr-no-insight.sh will not build manily because of a missing file : binutils-patch-avr25-wraparound-reloc.diff

I use zip provided above, namely
build-avr-gcc-4.3.3-libc-1.6.7-insight6.8-arch25-fix.zip

EDIT:
In file get-pathes.sh i saw the note aboute skipping wget for this patch since its a part of atm package. However, I need to research more to understand what that means..

EDIT:
I did a super guess and assumed it refferes to patch-avr25-wrap at the freebsd server. I installed this and renamed it to binutils-patch-avr25-wraparound-reloc.diff and restarted build. That seems to fix the problem. Hope it was the correct patch though, from Joerg... :roll:

Regards
Vidar (Z)

----------------------------------------------------------

"The fool wonders, the wise man asks"

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

@Zainka

I don't understand the above mail.

The "get-patches.sh" script vould automaticly rename the included patch file to the needed .diff file , when running.

Quote:

# The AVR Architecture 25 Relocaction wraparound patch is included in the package atm , so skip the wget
#wget -c --user-agent=MyBrowser http://www.freebsd.org/cgi/cvswe...
#
# Rename to our patchname
#
mv patch-avr25-wraparound-reloc.patch binutils-patch-avr25-wraparound-reloc.diff
#

The reason i included the patch in the download , was that the FreeBSD repository wasn't updated with the new patch. When i made the buildscript.

I have has several messages about the file in the first post in this thread , building succesfully.

/Bingo

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Okay.. My fault I unpacked the zip and must have deleted patch-avr25-wraparound-reloc.patch, how I do not know... which it already contained. Sorry for that.

Regards
Vidar (Z)

----------------------------------------------------------

"The fool wonders, the wise man asks"

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Please, for the love of all that is holy, at the top of the very first post, in all caps, add the line:

YOU MUST LOG IN TO DOWNLOAD THE SCRIPTS

I banged my head against the wall for half an hour trying to find the gorram scripts everyone kept talking about and couldn't find them anywhere. Only after I gave up and decided to create a forum account to tell you all what nasty horrible evil people you all were did I actually see the download links for the scripts. If you're not logged in you don't see them. It's incredibly frustrating for a noob. Please, save other people from this frustration.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

@17-Dec-2009
Updated the ".deb" install package , w. a new avrdude binary , containing a PDI patch. (See .txt file in the download site)
Read more here

http://www.avrfreaks.net/index.p...

Get the package here.
http://www.wrightflyer.co.uk/avr...

/Bingo

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

@06-Jan-2010
Made an "interrim" release , that fixes a bug within avrdude , when using dragon and ISP

Source here
http://www.avrfreaks.net/index.p...

.deb here
http://www.wrightflyer.co.uk/avr...

/Bingo

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

@16-Jan-2010
Updated buildscript to include avrdude-5.9 , in below thread
http://www.avrfreaks.net/index.p...

I'll move it to this thread , when i come back to Denmark

/Bingo

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If you expierence this error :

cc1: error: missing argument to "-mmcu="  

Your make is to old ,the script requires minimum "make v3.81" , see here
http://www.avrfreaks.net/index.p...

/Bingo

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

@26-jan-2010 , updated script & .deb to avrdude 5.10 , all other unmodified.

/Bingo

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

@Bingo600

There is a little bug that does not appear in WinAVr 20100110.

Compiling the demo for Appnote AVR1300 (ATXmega128A1) the generated code for the ISR entry sequence has a bug.
This is only when compiled on Linux by the compiler generated by your last build script. The code generated by WinAVR 20100110 does not have this error.

Listing generated on Linux

...
ISR(ADCA_CH3_vect)
{
 244:  1f 92         push  r1
 246:  0f 92         push  r0
 248:  0f b6         in  r0, 0x3f  ; 63
 24a:  0f 92         push  r0
 24c:  08 b6         in  r0, 0x38  ; 56
 24e:  0f 92         push  r0
 250:  18 be         out  0x38, r1  ; 56
 252:  09 b6         in  r0, 0x39  ; 57
 254:  0f 92         push  r0
 256:  19 be         out  0x39, r1  ; 57
 258:  0b b6         in  r0, 0x3b  ; 59
 25a:  0f 92         push  r0
 25c:  1b be         out  0x3b, r1  ; 59
 25e:  11 24         eor  r1, r1
 260:  0f 93         push  r16
 ...

You see at address 250, 256, and 25c that R1 (__zero_reg__) is used to clear RAMPD, RAMPX, and RAMPZ before it is initialized in 25e.

Listing generated with WinAVR 20100110 does not generate this error.

...
ISR(ADCA_CH3_vect)
{
 244:	1f 92       	push	r1
 246:	0f 92       	push	r0
 248:	0f b6       	in	r0, 0x3f	; 63
 24a:	0f 92       	push	r0
 24c:	08 b6       	in	r0, 0x38	; 56
 24e:	0f 92       	push	r0
 250:	09 b6       	in	r0, 0x39	; 57
 252:	0f 92       	push	r0
 254:	0b b6       	in	r0, 0x3b	; 59
 256:	0f 92       	push	r0
 258:	11 24       	eor	r1, r1
 25a:	18 be       	out	0x38, r1	; 56
 25c:	19 be       	out	0x39, r1	; 57
 25e:	1b be       	out	0x3b, r1	; 59
...

I think there is a patch missing.

Edit: Jörg Wunsch is currently searching for the missing patch.

... the only thing you cannot unscramble is eggs...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Ok , i'll talk to Jörg

/Bingo

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Bingo,

If you are updating the script you might also want to take this request into consideration:

http://www.avrfreaks.net/index.p...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
Bingo,

If you are updating the script you might also want to take this request into consideration:

http://www.avrfreaks.net/index.p...

Will see what i can do ...

/Bingo

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

when can we expect the 32u2 support from the last winavr.

I cant get a working avr-libc from this plus the patches from the latest winavr and now have a toolchain that claims but it has the target but the freshly rebuilt libc cant link the crtmxxx files. Jeorge just send the linux folk with this problem to your script.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'm waiting for the WinAVR patches to be migrated over to the FreeBSD repository.
Until that happens , there is nothing i can do.

I haven't got any clue about the timeframe.

/Bingo

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I started there but the only place the patches seem to be is in the Winavr source directory (which requires access to a windblows machine !#@$@!#$@!!!! )

So ...

Yeah.

Whats up with the normal patch migration?
Are we all just stuck here until atmel puts a nail in the open source and open platform coffin?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'm sure Erik won't mind me posting the patches from the latest Winavr here , they are allready included in the exe package.

Now you can patch your own toolchain.

/Bingo

Attachment(s): 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Released a "Special Unsupported version" of avr-gcc , based on the above patches

See
http://www.avrfreaks.net/index.p...

/Bingo

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Rereleased this version
http://www.avrfreaks.net/index.p...

But hope i have linked gmp & mpfr static , meaning it ought to work on 64bit also.

See here

http://www.avrfreaks.net/index.p...

/Bingo

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

This is not related to GCC , but occationally someone asks id AvrStudio can be run under Linux
This post seems to have helped people to do just that.

http://www.avrfreaks.net/index.p...

/Bingo

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

@08-03-2010
Updated the script to build with binutils 2.20

But Jörg have updated avr-gcc also 8) 8)

Now i suppose we have a toolchain that is as up to date as the latest WinAVR.

I'll have to do that later hopefully in this week

/Bingo

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

@09-Mar-2010
Updated the avr-gcc script , to build avr-gcc-4.3.4 and binutils-2.20.
Added 2 patches to avr-insight/avr-gdb.
Added a builtins.h file in the builddir , see readme for use

Added a package-versions file , now versions are only maintained in that file.
Added a new "automatic" way to patch binutils , gcc & insight.

Thanx to Jörg the linux (FreeBSD) build , now has the same patches as WinAVR-2010. A big thankyou to Jörg & EW.

Also uploaded as .deb package avr-gcc-4.3.4-avrfreaks-09-mar-2010.deb
Get the package here (thanx to clawson for hosting).
http://www.wrightflyer.co.uk/avr...

/Bingo

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I tried using the package, and I got the following error:

Error: wrong architecture 'i386'

Is there any way of fooling my machine into believing it is of this architecture :P This seems to be one of the downsides of packages.

My architecture is x86_64

If we don't have a solution, I may just have to install a very small separate version of linux for compiling, but it's a real hassle to switch OSes just to test a program.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Can you confirm it was the 23rd Feb "special" version that Bingo built according to this thread:

http://www.avrfreaks.net/index.p...

He had hopes that WOULD work on x64 architecture.

Or were you simply saying that dpkg barfs because of an architecture flag in the .deb metadata? If so then from "man dpkg" I note:

Quote:
--force-things | --no-force-things | --refuse-things

Force or refuse (no-force and refuse mean the same thing)
to do some things. things is a comma separated list of
things specified below. --force-help displays a message
describing them. Things marked with (*) are forced by
default.

Warning: These options are mostly intended to be used by
experts only. Using them without fully understanding
their effects may break your whole system.


and
Quote:
architecture: Process even packages with the wrong archi-
tecture.

So maybe try "dpk -i --force-things architecture
.deb"

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
Can you confirm it was the 23rd Feb "special" version that Bingo built according to this thread:

http://www.avrfreaks.net/index.p...

Should have specified. I tried the latest version:

"avr-gcc-4.3.4-avrfreaks-09-mar-2010.deb"

I'll try the force flags. I was simply using the GUI version of the package manager, I'll try those options on the command line. Thanks!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:

So maybe try "dpk -i --force-things architecture
.deb"

I tried

sudo dpkg -i --force-things x86_64 avr-gcc-4.3.4-avrfreaks-09-mar-2010.deb

and got

dpkg: unknown force/refuse option `things'

Type dpkg --help for help about installing and deinstalling packages [*];
Use `dselect' or `aptitude' for user-friendly package management;
Type dpkg -Dhelp for a list of dpkg debug flag values;
Type dpkg --force-help for a list of forcing options;
Type dpkg-deb --help for help about manipulating *.deb files;
Type dpkg --license for copyright license and lack of warranty (GNU GPL) [*].

Options marked [*] produce a lot of output - pipe it through `less' or `more' !

So then I tried

sudo dpkg -i --force-architecture x86_64 avr-gcc-4.3.4-avrfreaks-09-mar-2010.deb

and got

dpkg: error processing x86_64 (--install):
 cannot access archive: No such file or directory
dpkg: warning: overriding problem because --force enabled:
 package architecture (i386) does not match system (amd64)
Selecting previously deselected package avr-gcc-4.3.4-avrfreaks-09-mar-2010.
(Reading database ... 139633 files and directories currently installed.)
Unpacking avr-gcc-4.3.4-avrfreaks-09-mar-2010 (from avr-gcc-4.3.4-avrfreaks-09-mar-2010.deb) ...
Setting up avr-gcc-4.3.4-avrfreaks-09-mar-2010 (0.1) ...
Errors were encountered while processing:
 x86_64

I get the same error when I try forcing the arch. as AMD64 (instead of x86_64). Not a very verbose error either :P

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

My reading of the man page is that the words literally are "--force-things architecture" not that either "things" or "architecture" is a placeholder for you to fill in with some value. All you are saying is that "usually you do an architecture check, this time skip it"

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
My reading of the man page is that the words literally are "--force-things architecture" not that either "things" or "architecture" is a placeholder for you to fill in with some value. All you are saying is that "usually you do an architecture check, this time skip it"

johnny@johnny-desktop:~/Installers and Packages/AVR-GCC$ dpkg -i --force-things architecture avr-gcc-4.3.4-avrfreaks-09-mar-2010.deb
dpkg: unknown force/refuse option `things'

Type dpkg --help for help about installing and deinstalling packages [*];
Use `dselect' or `aptitude' for user-friendly package management;
Type dpkg -Dhelp for a list of dpkg debug flag values;
Type dpkg --force-help for a list of forcing options;
Type dpkg-deb --help for help about manipulating *.deb files;
Type dpkg --license for copyright license and lack of warranty (GNU GPL) [*].

Options marked [*] produce a lot of output - pipe it through `less' or `more' !
johnny@johnny-desktop:~/Installers and Packages/AVR-GCC$ 
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You gotta love Linux man page documentation - I bet the utility's author knew what he was talking about when he wrote that - shame he's failed to convey it to the users!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Nothing wrong with the man page.

Since decades things written in bold in man pages are to be typed literally. Things in italic are placeholders. And that's how the dpkg man page is written, too.

So now guess what -force-thing means? And what architecture means in the -force-thing list of things?

And there is nothing about any kind of further parameter to -force-architecture, so why is the OP dreaming up an imaginary x86_64 argument?

Stealing Proteus doesn't make you an engineer.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

AH! I was reading the man page on a web site not a real Linux machine and they'd failed to copy the syntax highlighting:

http://unixhelp.ed.ac.uk/CGI/man...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Its only the special static that would work on 64bit
It's based on winavr-2010 patches.

As the other versions would try to load 32bit GMP & MPFR dynamic libs.

/Bingo

Last Edited: Tue. Apr 6, 2010 - 05:32 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ArnoldB wrote:
Nothing wrong with the man page.

Since decades things written in bold in man pages are to be typed literally. Things in italic are placeholders. And that's how the dpkg man page is written, too.

So now guess what -force-thing means? And what architecture means in the -force-thing list of things?

And there is nothing about any kind of further parameter to -force-architecture, so why is the OP dreaming up an imaginary x86_64 argument?

Thanks for clarifying that for me, and teaching me a thing or two about manpages in the process :D

I'm relatively new to Linux. I used it at school a bit, but never to install packages (wasn't allowed), or compile massive programs from source.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

There is a short thread about the 64bit version (well actually 32bit static linked version) here.
http://www.avrfreaks.net/index.p...

And damien_d shows how he's installing it on a 64bit AMD , and made a short succesfull compile.

/Bingo

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

bumping the insightver from 6.8 to 6.8-1 in package-versions fixes the tk.tcl error mentioned earlier in the thread. Both patches still apply. It now runs fine in ubuntu 9.10.
from the insight homepage:

Quote:

Updated Insight 6.8-1 available
Insight 6.8 has been available for some time, and the current release tarball has issues with newer versions of X11. As a result, I am making available a patched Inisght 6.8-1 release which should fix all outstanding issues with X11.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

alohre wrote:
bumping the insightver from 6.8 to 6.8-1 in package-versions fixes the tk.tcl error mentioned earlier in the thread. Both patches still apply. It now runs fine in ubuntu 9.10.
from the insight homepage:
Quote:

Updated Insight 6.8-1 available
Insight 6.8 has been available for some time, and the current release tarball has issues with newer versions of X11. As a result, I am making available a patched Inisght 6.8-1 release which should fix all outstanding issues with X11.

Thanx for the info ...

Will prob. incorporate it in the next script release ...

Until then ... One can just do as you did

/Bingo

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hello,
i'm running Ubuntu 9.10 on 64 bit and first tried to install the current .deb (at the moment 32 bit version) by

sudo dpkg --force-install -i avr-gcc-4.3.4-avrfreaks-09-mar-2010.deb

but had problems with libusb and libreadline, which couldn't be found... or with set LD_LIBRARY_PATH yields the error "wrong ELF class...".

But here, what works for me now:
- installed avr-gcc-4.3.3-avrfreaks-25-feb-2010-special-static.deb (was said that this runs for 64 bit)
- installed the package ia32-libs (for libusb-0.1-4 32 bit)
- downloaded libreadline5 (e.g. http://packages.ubuntu.com/lt/karmic/libreadline5 the i386 package!)
- not installed but unpacked the contained lib*.so-files to /lib32

I'm happy that i could getting it to run but it would be nice if there will be a out-of-the-box working .deb (i myself am only freshman).

Thanks a lot!
John

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

@30-apr-2010

Build a toolchain on Ubuntu 10.04 LTS - i386
avr-gcc-4.3.4-avrfreaks-30-apr-2010-u10.04.i386

Get it here
http://www.wrightflyer.co.uk/avr...

The only change to the toolchain is , the substitution of insight6.8 with insight 6.8.1

I will try to see if i can build an x64 version during the weekend.

/Bingo

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Uploaded a "Real" x64 package . build on Ubuntu 10.04 LTS - amd64

Same as above
http://www.avrfreaks.net/index.p...

http://www.wrightflyer.co.uk/avr...
avr-gcc-4.3.4-avrfreaks-30-apr-2010-u10.04.x64.deb

Please test ....

/Bingo

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi all,
however I used winavr on windows, I'm a novice in using avr-gcc on Linux. Winavr gave me the comfort to forget Makefile and now I'm in trouble.
I suppose I got the message below due to the wrong setting of makefile:

steve@apa:~/projects/avr/galvan$ make
avr-gcc -I. -I/usr/local/avr/avr/include -g -mmcu=atmega16 -Os -fpack-struct -fshort-enums -funsigned-bitfields -funsigned-char -Wall -Wstrict-prototypes -Wa,-ahlms=galvan.lst -c galvan.c -o galvan.o
avr-gcc -Wl,-Map,galvan.out.map -mmcu=atmega16 -lm /usr/local/avr/avr/lib -o galvan.out galvan.o
/usr/lib/gcc/avr/4.3.4/../../../avr/bin/ld: crtm16.o: No such file: No such file or directory
make: *** [galvan.out] Error 1

However I've asked Google and man as well, I didn't find the proper switches and paths for the "LIBS=" line of Makefile.

Please help me to start...

Thanks,
Istvan

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

dircon wrote:

/usr/lib/gcc/avr/4.3.4/../../../avr/bin/ld: crtm16.o: No such file: No such file or directory
make: *** [galvan.out] Error 1[/i]

Is this installed using one of the above .deb packages, the script, or did you apt-get the avr-gcc ?

-- Damien

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

Is this installed using one of the above .deb packages, the script, or did you apt-get the avr-gcc ?

It was installed by using the .deb package.
Istvan

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

dircon wrote:
Quote:

Is this installed using one of the above .deb packages, the script, or did you apt-get the avr-gcc ?

It was installed by using the .deb package.
Istvan

Can you please output the following command?

damien@damien-desktop:~$ which avr-gcc
/usr/local/avr/bin/avr-gcc
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

Can you please output the following command?
Code:

damien@damien-desktop:~$ which avr-gcc
/usr/local/avr/bin/avr-gcc

Uhhh... yes, a few hours later. You know, I am working now and the problem is at my home computer. (It is a hobby project.) I will check as I get home.
Istvan

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Damien,
you hit the nail on the head:

The command "which" says avr-gcc is here:
/usr/bin/avr-gcc
but there is another one in:
/usr/local/avr/bin/avr-gcc

Perhaps the first is from an unsuccessful installation - I guess due to the old date.
steve@apa:/usr/bin$ ls -l /usr/bin/avr-gcc
-rwxr-xr-x 2 root root 199912 2009-11-27 15:20 /usr/bin/avr-gcc
steve@apa:/usr/bin$ ls -l /usr/local/avr/bin/avr-gcc
-rwxr-xr-x 2 root root 203932 2010-04-30 10:43 /usr/local/avr/bin/avr-gcc

But "apt-get remove" says there is no avr-gcc file - in contrast of "which" who says avr-gcc is here:
/usr/bin/avr-gcc

Shell I delete all avr related programs from /usr/bin/ manually?
Istvan

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

To find out what .deb's are installed use:

dpkg --get-selections

to filter the results maybe try

dpkg --get-selections | grep gcc

To find out which files "belong" to a specific .deb and will be removed if you either "apt-get remove" or "dpkg -r" it then use:

dpkg -L 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

To find out which files "belong" to a specific .deb and will be removed if you either "apt-get remove" or "dpkg -r" it then use:
Code:
dpkg -L

Unfortunately it does not help. It seems that avr toolchain was installed from source and was not a .deb package. I've tryed to setup a toolchain earlier and now I am probably hindered due to the rest of that unsuccesful experiment. I have no idea how to remove a program installed from source. So I guess I should
- remove Bingo's package
- then manually clean up /usr/bin directory from all avr-related programs
- and then re-install Bingo's package.
Any better idea?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

dircon wrote:
. I have no idea how to remove a program installed from source. So I guess I should
- remove Bingo's package
- then manually clean up /usr/bin directory from all avr-related programs
- and then re-install Bingo's package.
Any better idea?

Technically you could make sure that /usr/local/avr/bin is on your path before the "other" place/package is.

But i'd clean out the "other" place , just to be sure.

There is no need for uninstalling the .deb
The deb only install files in /usr/local/avr , and as long as you don't touch anything there , you can leave it installed.

/Bingo

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

There is no need for uninstalling the .deb
The deb only install files in /usr/local/avr , and as long as you don't touch anything there , you can leave it installed

Thanks for all the answers.
The key of the mystery was the path. I've supposed the /usr/local/avr/bin path will be added to my path by the script - and even worse, there was that forgotten, partly aborted version of avr toolchain.
Now as I set the path, everything is right. Thanks for the script, Bingo!
Istvan

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

dircon wrote:
Quote:

I've supposed the /usr/local/avr/bin path will be added to my path by the script
Istvan

Nope :shock:

Neither the buildscript , nor the .deb packages adds /usr/local/avr/bin to the path.

This is left for the "user" to do , and will prob never change.

/Bingo

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Bingo,

It took me a while to remember how to do PHP but I've updated the index.php on the website to give some very brief instructions including a note about setting the PATH

Cliff

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
Bingo,

It took me a while to remember how to do PHP but I've updated the index.php on the website to give some very brief instructions including a note about setting the PATH

Cliff

Naajzzz 8)

Thanx Cliff :-)

/Bingo

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi,
I'm using avr-gcc-4.3.4-avrfreaks-09-mar-2010.deb package and I'm trying to program an avr ATXMega256A3. Compiling with avr-gcc and flashing with avrdude works great. I use an MKII Jtag ICE to upload the application on the flash and I'm trying on chip debugging. It looks like on chip debugging is working right as when I hit CTRL+C it stops running and gdb tells me the instruction where the application stopped.
However I can't watch / display variables nor set/delete breakpoints.
Xmega256A3 data is store in SRAM (0x802000 <-> 0x805FFF). when I try to print a variable, and watch avarice debug, I see something like this:

GDB: 

GDB: Read 2 bytes from 0x800001
jtagRead 
command[tries: 1, size: 10]: 
0x05 0xA0 0x02 0x00 0x00 0x00 0x00 0x00 0x00 0x00 
recv: 0x1b
recv: 0x19
recv: 0x00
recv: 0x03
recv: 0x00
recv: 0x00
recv: 0x00
recv: 0x0e
sDATA: reading 3 bytes
read:  82 20 00
recv: 0xde
recv: 0xea
CRC OK
Got message seqno 25 (command_sequence == 25)
response: 82 20 00 
->GDB: 0020

As you can see from the debug information, gdb asks for location (0x800000 + 1) and does not account for the data offset NOR for the fact that data is stored on the ATXMega starting from the higher addresses (0x805FFF) up to the lower ones).

I wonder if it's gdb or avarice responsibility to account for these offsets...

I'd really appreciate your help guys...

Thankx in advance
I'm be waiting for any comment help hint or scolding me..

R

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

@riccardomanfrin

Afaik there is no Xmega support in the "GNU" debugging tools , due to Atmel not releasing the neded info.

But i can see Jörg (avarice maintainer) inviting you to a dialog
http://www.avrfreaks.net/index.p...

/Bingo

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

@04-jun-2010
Updated the buildscript to build insight 6.8-1

/Bingo

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

@30-jun-2010
First release with avrlibc-1.7.0 here

http://www.avrfreaks.net/index.p...

/Bingo

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

FYI.
Xubuntu 10.04 are missing a few dependencies in its default setup which will make the buildscript fail.

For example does xubuntu not have Patch as a part of its default setup. Nor does it have libx11-dev. You will also find the build complain about termcap missing. In Ubuntu this has been replaced by ncurses lately which should be there. However, the dev package is missing and must be installed.

Patch:
sudo apt-get install patch

libx11-dev:
sudo apt-get install libx11-dev

Termcap:
sudo apt-get install libncurses5-dev

expat:
sudo apt-get install expat

libbfd.a:
sudo apt-get install libbfd-dev

yacc:
sudo apt-get install bison

flex:
sudo apt-get install flex

Regards
Vidar (Z)

----------------------------------------------------------

"The fool wonders, the wise man asks"

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

zainka wrote:
FYI.
Xubuntu 10.04 are missing a few dependencies in its default setup which will make the buildscript fail.

For example does xubuntu not have Patch as a part of its default setup. Nor does it have libx11-dev. You will also find the build complain about termcap missing. In Ubuntu this has been replaced by ncurses lately which should be there. However, the dev package is missing and must be installed.

Patch:
sudo apt-get install patch

libx11-dev:
sudo apt-get install libx11-dev

Termcap:
sudo apt-get install libncurses5-dev

expat:
sudo apt-get install expat

libbfd.a:
sudo apt-get install libbfd-dev

yacc:
sudo apt-get install bison

flex:
sudo apt-get install flex

@Zainka

Did you have a look in the Pre-reqs.txt , file in the package.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Uploaded Jörgs mfile tool mfile-ubuntu.tar.gz , adapted for ubuntu (1 line change)
http://www.wrightflyer.co.uk/avr...

See Readme.ubuntu

/Bingo

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

how about GCC 4.3.5?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

vitaly_v_ch wrote:
how about GCC 4.3.5?

What's in 4.3.5 that you "really" need ?

/Bingo

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Really? Mainly sport interest.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If you have used the above link
http://www.avrfreaks.net/index.p...

See
http://www.avrfreaks.net/index.p...
For fixing the delay bug in avr-libc-1.7.0

/Bingo

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The scripts use a dangerous approach of assuming various directory creation and navigation commands work and then executing "rm -fr *" without ensuring that the current directory is what it should be. I had to spend a good chunk of last Sunday restoring from backup after one of the scripts wiped out a large part of my home directory.

Following the scripts and attempting to replicate the build process by hand yields a toolchain that works for tiny26 and mega32 projects, but can not find C runtime files for the xmega32A4:

/Users/cjh/avr/bin/../lib/gcc/avr/4.3.4/../../../../avr/bin/ld: crtx32a4.o: No such file: No such file or directory

This file does exist, it's in /Users/cjh/avr/avr/lib/avrxmega2/crtx32a4.o (prefix is $HOME/avr/). Moving it into the project directory yields different errors with libmath and libc:

/Users/cjh/avr/bin/../lib/gcc/avr/4.3.4/../../../../avr/bin/ld: skipping incompatible /Users/cjh/avr/bin/../lib/gcc/avr/4.3.4/../../../../avr/lib/libm.a when searching for -lm
/Users/cjh/avr/bin/../lib/gcc/avr/4.3.4/../../../../avr/bin/ld: cannot find -lm

Omitting -lm yields:

/Users/cjh/avr/bin/../lib/gcc/avr/4.3.4/../../../../avr/bin/ld: skipping incompatible /Users/cjh/avr/bin/../lib/gcc/avr/4.3.4/../../../../avr/lib/libc.a when searching for -lc
/Users/cjh/avr/bin/../lib/gcc/avr/4.3.4/../../../../avr/bin/ld: cannot find -lc

The files appear to be the right type:

% avr-objdump -f crtx32a4.o 

crtx32a4.o:     file format elf32-avr
architecture: avr:103, flags 0x00000011:
HAS_RELOC, HAS_SYMS
start address 0x00000000

And similar for the libraries, but long lists of entries of the same format and architecture "avr".

I'm using Mac OS X 10.6.5. The major differences from the scripts are that I'm using avr-libc-1.7.0, more recent versions of GMP and MPFR, and removing an instance of tree-inline.o from the GCC makefiles to fix a duplicate symbols problem. (bug in Snow Leopard's linker...won't ignore duplicate symbols from static libraries)

Any suggestions?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'm sorry if the script has caused you trouble.

You dont write what buildscript-filename , shell-file and line that caused you trouble.
So i'll assume it's this buildscript http://www.avrfreaks.net/index.p... , and the buildavr-cleanup.sh script.

And there is actually a warning when using that.

In the readme it states

Quote:

Start by reading this thread http://www.avrfreaks.net/index.p...
Or at least the first post.

And in the post that the above url refers to : It states

Quote:

When building is done , you might want to free around 500MB of diskspace by removing the sources and binaries used to make avr-gcc.
To do so Run: ./buildavr-cleanup.sh

Note this little script expects the "build prefix" to be /usr/local/avr/

So if it was the cleanup script causing the trouble. The info (warning) was there , and you are the first that i know of , to have been "bitten".

The buildavr-cleanup.sh , was a quick "hack" because some users complained about the finished toolchain being 500MB+

As stated , the script are only tested on Ubuntu.
But a lot of people reports that with minor "adaptation" it also works on other *nixes.

/Bingo

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

For the problem . maybe try the toolchain from femtoos
http://www.femtoos.org/

Download
http://sourceforge.net/projects/...

Ruud's script is probably what you want (lots of checkking) , and is supposed to be functional on MAC.

/Bingo

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

That is the buildscript I used, but it was get-patches.sh that blew away part of my home directory. There's several times that it does mkdir's and cd's without checking for failure, blindly does "cd ..", and it simply experienced a couple failures and climbed up into my home directory before doing another "rm-fr *".

It would be much better to always specify full absolute paths, especially in the rm command. This alone would have prevented the issue, since it would have been trying to rm a nonexistent directory...it would not matter if it were in the wrong directory following a failure. I would also suggest simplifying it to put everything in a fully specified build directory rather than constantly creating and deleting this and that...it would be simpler, clearer, and less fragile.

As for the readme, I strongly suggest reorganizing it. There's no clear starting point for figuring out how to use the scripts, the quoted portion at first glance appearing to be an old portion of the revision history.

I will check out the femtoos scripts.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Funny, Bingo's scripts have always worked for me but then I just blindly followed the instructions and used /usr/local/avr - is there some reason not to do that then?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
Funny, Bingo's scripts have always worked for me but then I just blindly followed the instructions and used /usr/local/avr - is there some reason not to do that then?

It's good you've never had them run amok, because they would have done a lot more damage if you were blindly following those directions. Running the scripts with the root or sudo privileges needed for an install to /usr/local would not have improved matters...it would have made them a lot worse, especially if it had walked all the way up to the root directory and executed "rm -fr *" there. As it was, I noticed it was misbehaving when it started hitting files it didn't have the permissions needed to delete.

And yes, aside from limiting the potential damage from misbehaving scripts, building a standalone toolchain makes it trivially easy to switch between different versions of a toolchain, and keeps all the stuff related to that toolchain in one place. I didn't install to /usr/local because I didn't want it there.

It's clear that there's a major issue with the scripts' assumptions that directory creation and navigation will always succeed, coupled with running a dangerous command without any sanity checks. That you've never had trouble does not change the fact that failures can lead to it blindly deleting everything in higher level directories. Depending on the choice of download locations and how closely the directions are followed, it can delete nearly everything on the hard drive, OS included. Is your response to this really "it always worked for me" followed by questioning my choice of install locations?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

it would have made them a lot worse, especially if it had walked all the way up to the root directory and executed "rm -fr *" there

Wouldn't matter to me - I use VM's - if it ever gets corrupted I return to a previous snapshot or recreate it.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Well it's always nice with some feedback , even though you are the first i have heard about that has lost control.

And people has been using the scripts for four years now.
With the above mentioned readme et all.

I hope Ruud's script lives up to your expectations.

Edit: I can see it loose control if you are calling the scripts from another location. As it can't source the package-versions file.

Maybe i'll add a check for that.

/Bingo

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
Quote:

it would have made them a lot worse, especially if it had walked all the way up to the root directory and executed "rm -fr *" there

Wouldn't matter to me - I use VM's - if it ever gets corrupted I return to a previous snapshot or recreate it.

Well good for you! Can you at least admit that this might be something of an issue for other people?

It's simple. Potentially crawling up your directory tree and deleting everything in sight without warning is not desired behavior, okay?

Bingo600 wrote:
Well it's always nice with some feedback , even though you are the first i have heard about that has lost control.

And people has been using the scripts for four years now.
With the above mentioned readme et all.

I hope Ruud's script lives up to your expectations.

Edit: I can see it loose control if you are calling the scripts from another location. As it can't source the package-versions file.

Maybe i'll add a check for that.

:shock:

Look. Running the scripts as instructed is potentially equivalent to typing "sudo rm -rf *" in any containing directory, up to and including the root directory of the filesystem. This is a major issue that needs fixing, the scripts in their current state are brittle and fail catastrophically. That you haven't had reports of issues up to now is pure luck. You have now had such a report, and a clear description of what the problem is and why.

There is no reason to clear out unneeded files by attempting to cd to a location and then deleting everything in the current working directory. Simply working out what directory the items to be deleted should be in and passing that to rm will avoid the issue...if the directory doesn't exist, the script won't fail by crawling up the directory tree deleting everything in its path. This doesn't take a huge amount of effort to implement, and doesn't make things harder to maintain or follow...if anything, it makes it clearer what the scripts are doing and easier to ensure that they do only what you want.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If it's so easy for you to do , why don't you submit the modified script here.
Nothing stops you from helping out.
Then maybe i'll get my first patch , along with the first

Quote:

You have now had such a report, and a clear description of what the problem is and why.

Have a nice life , and i'll consider to make it a FLASH guide in my next version.

/Bingo

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi,

Sorry for the cross-posting. I am trying to make a 1-file-only build script for the last version of the avr-gcc/avr-libc tools, as mentioned here:
http://www.avrfreaks.net/index.p...

The script uses the information on Bingo's scripts but is adapted from the scripts used to install the cross-compilers for arm.

In short:

BINUTILS_VER="2.21"
GCC_VER="4.5.2"
GDB_VER="7.2"
GMP_VER="5.0.1"
MPFR_VER="3.0.0"
MPC_VER="0.8.2"
INSIGHT_VER="6.8-1"
AVARICE_VER="2.10"
AVRDUDE_VER="5.10"
AVRLIBC_VER="1.7.0"

I was able to build the version 4.5.1 previously but not sure why I run into some trouble now that I try with 4.5.2. After installation, when I use avr-gcc I get this message:

avr-gcc  -mmcu=at90usb1287 -Wl,-Map=SCD.map SCD.o EMV.o halSCD.o scdIO.o utils.o terminal.o  halSCD.S SCD.S    -o SCD.elf 
/usr/local/avr/lib/gcc/avr/4.5.2/../../../../avr/bin/ld: cannot find -lgcc 
/usr/local/avr/lib/gcc/avr/4.5.2/../../../../avr/bin/ld: cannot find -lgcc 
collect2: ld returned 1 exit status 

(more information on the link above).

I know there are packages for ubuntu, but they are broken (again, see my unreplied post at the link above).

I am not able to attach the script file (I think there is a problem with the avrfreaks website, not sure), so here it is:
http://www.cl.cam.ac.uk/~osc22/f...

I hope some of you will find it useful (especially if I manage to fix this error).

Thanks.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Nice script ..
But why do you want the latest GCC ? , especially for a target like AVR.
Those patches in my buildscript is actually enabling/fixing a lot of things in the various packages.

I haven't got a good idea for your problem , but was wondering why you have/need these two options on the "configure" --program-prefix=avr- --with-gcc

/Bingo

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The 2 parameters are a remainder from the original arm-gcc-cross-compiler building script. However both of them are correct and do not affect in a negative way the building of the tools (feel free to try).

The package for ubuntu, available here:
http://www.wrightflyer.co.uk/avr...
is broken as I have mentioned. It did not include the patch for delay.h.in in the avr-libc-1.7.0. One more reason why to have a building script functional that can be easily modified (I find more easy to modify my script than yours, no offence).

Why GCC-4.5.2? Well, I believe is better to go with the latest version, since they generally bring improvements. However, after a little Google (one of my friends suggested I need some practice on this...):
- from http://gcc.gnu.org/gcc-4.5/chang...
- new link-time-optimizer (sounds nice from description)
- automatic parallelisation pass
- optimising exception handling code (probably doesn't apply to our AVR targets, but still nice)
- just C related:
- -Wenum-compare option to warn about different enum types
- Added support for these new AVR devices:
ATmega8U2
ATmega16U2
ATmega32U2
- it is now possible to extend the compiler without having to modify its source code
- from http://gcc.gnu.org/ml/gcc-announ...
- improved loop optimization infrastructure
- GCC 4.5.0 also features improvements for a wide variety of specific
architectures, including support for recent CPUs using the ARM, AVR...
- many more ... (please read the links above).

Hope this will trigger some support.

Thanks.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The wisdom of the libc/avr-gcc maintainers is almost always the better place to start. It takes for fracking ever for anything to actually get released into gcc. And new processors are going to be unstable for a while. The patches that bingo uses which are from the toolchain maintainers mouths are based on the latest and most stable versions for this processor.

Period.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Ok, I've managed to fix the problem (thanks Bingo, gcc and avr-gcc community) - I was using a wrong parameter for make.

The last version of the building script is here:
http://www.cl.cam.ac.uk/~osc22/f...

Current versions (see the script to be sure):
BINUTILS_VER="2.21"
GCC_VER="4.5.2"
GDB_VER="7.2"
GMP_VER="5.0.1"
MPFR_VER="3.0.0"
MPC_VER="0.8.2"
INSIGHT_VER="6.8-1"
AVARICE_VER="2.10"
AVRDUDE_VER="5.10"
AVRLIBC_VER="1.7.0"

Bingo if you (and others) find it useful, feel free to add it on the first page.

Thanks.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

@goodhack

I suppose it was EW's hints on the avr-gcc list what brought you on track.

Congratulations in writing a very nice buildscript.

It still amazes me though :
That you chose to ignore the warnings in the last posts about using the unpatched upstream avr-gcc.
Instead of the proven 4.3.4 with the current maintainer patches applied.
These patches are created by Eric Weddington (WinAVR) , who adviced you on the "list". And Jörg Wunsch (avr-libc & FreeBSD port of avr-gcc).

And i sincerely hope your students won't be bitten , as these patches most likely haven't gone into the version of GCC that you are using.

/Bingo

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yes, it was EW's hints on the avr-gcc (as well as some other messages on the gcc-help list) that have helped me.

Well, it is not that I choose to ignore, I just want to provide a working script for the last version of GCC for those (like me) that want to use it.

Also, using your scripts, or the maintained 4.3.4 packages give extra work like applying missing patches.

I am sure the 4.3.4 version might be more stable, but why not trying to make it work with the current version?

Regarding the patches you refer to, I think that many patches have gone into the current (4.5.2) GCC version; at least from the Changelogs it seems that some things related to AVR have been aded.

Omar

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

@Omar
There has been some issues between Atmel & the GCC team , that has prevented the accept of the patches into mainstream GCC. The last i heard was , that they are "close to resolve the issues" but afaik.
Some patches still haven't gotten into mainstream GCC.

Btw: The reason i haven't updated the .deb packages with the new delay.h is that i follow the FreeBSD source like 99.9% , and Jörg hasn't released avr-libc-1.7.1 yet.

But your post actually made me upload the correct delay.h file , and write a warning in the "readme's" on http://www.wrightflyer.co.uk/avr...

Now you don't need to patch , just replace a file

/Bingo

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Nice to hear about the correct file.

Thanks.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi,

nice scripts, thank you. :)

However, it aborted while building avarice-2.10 with a linker error on Arch Linux (AMD64):

Quote:

g++ -g -O2 -o avarice crc16.o devdescr.o ioreg.o jtag2bp.o jtag2io.o jtag2misc.o jtag2prog.o jtag2run.o jtag2rw.o jtag2usb.o jtagbp.o jtaggeneric.o jtagio.o jtagmisc.o jtagprog.o jtagrun.o jtagrw.o main.o remote.o utils.o gnu_getopt.o gnu_getopt1.o -lusb -lbfd -liberty -lz
/usr/lib/libbfd.a(plugin.o): In function `try_load_plugin':
(.text+0x3f4): undefined reference to `dlopen'
/usr/lib/libbfd.a(plugin.o): In function `try_load_plugin':
(.text+0x417): undefined reference to `dlsym'
/usr/lib/libbfd.a(plugin.o): In function `try_load_plugin':
(.text+0x4a3): undefined reference to `dlerror'
collect2: ld gab 1 als Ende-Status zurück

On Arch Linux AMD64, avarice needs to be linked against libld:

I added

AC_CHECK_LIB([dl], [dlopen], , [ac_found_ld=no])

to the avarice-2.10 configure.ac file.
Then run autoreconf && autoconf , build a new tarball, exchange it and it works. :)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi bofh,

I am happy to hear you can use them as well.

Regarding the bfd problem, you should install libbfd. In ubuntu this is solved by installing binutils-dev, as mentioned in the header of the scripts.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Bingo600 wrote:
There has been some issues between Atmel & the GCC team , that has prevented the accept of the patches into mainstream GCC. The last i heard was , that they are "close to resolve the issues" but afaik.
Some patches still haven't gotten into mainstream GCC.

Would you give some details on that? What exactly was the issue? It's clear that non-GPLed patches will not go into GCC.

I intend to do some work on avr backend in the near future. As I won't copy-paste existing patches, this will probably invalidate some patches. Therefore, as Atmel guys are also GCC's avr backend maintainers, I am not sure if they are happy to see work being done on avr.

avrfreaks does not support Opera. Profile inactive.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

SprinterSB wrote:
Bingo600 wrote:
There has been some issues between Atmel & the GCC team , that has prevented the accept of the patches into mainstream GCC. The last i heard was , that they are "close to resolve the issues" but afaik.
Some patches still haven't gotten into mainstream GCC.

Would you give some details on that? What exactly was the issue? It's clear that non-GPLed patches will not go into GCC.

I intend to do some work on avr backend in the near future. As I won't copy-paste existing patches, this will probably invalidate some patches. Therefore, as Atmel guys are also GCC's avr backend maintainers, I am not sure if they are happy to see work being done on avr.

I don't have any examples , but i'm quite sure that it was Eric (EW) mentioning this on one of the mailinglists. As an answer to why patches wasn't moved upstream.

Ask Jörg or Eric.

/Bingo

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

goodhack wrote:
Ok, I've managed to fix the problem (thanks Bingo, gcc and avr-gcc community) - I was using a wrong parameter for make.

The last version of the building script is here:
http://www.cl.cam.ac.uk/~osc22/f...

Current versions (see the script to be sure):
BINUTILS_VER="2.21"
GCC_VER="4.5.2"
GDB_VER="7.2"
GMP_VER="5.0.1"
MPFR_VER="3.0.0"
MPC_VER="0.8.2"
INSIGHT_VER="6.8-1"
AVARICE_VER="2.10"
AVRDUDE_VER="5.10"
AVRLIBC_VER="1.7.0"

Thanks.


Mega2560 has a bug in 4.5.2

http://www.avrfreaks.net/index.p...
http://gcc.gnu.org/bugzilla/show...

/Bingo

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks Bingo.

I have added a patch for the bug and I see the bug has now been fixed for GCC 4.6. Also I updated my script to use this patch.

Maybe we can make a complete list of unsolved bugs for 4.5.2 and hope they will all be fixed for release 4.6. And we could try to start converging from there.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Is there a _single_ location available that at least links to all the files necessary to get up-to-date mcus working?

I must have spent have a day compiling (using the script and the manual on the avr-libc site) only to find out that e.g. my newly acquired ATtiny4313 is not supported by the compiled avr-gcc version I got. Woohooo! Happy happy joy joy.

I don't mind the compiling part too much (well it basically sucks, but it is still tolerable), but finding all the patches... good god! :x

How come they haven't been integrated into the source code yet? I could (hypothetically) use WinAVR of course, but I just fail to see how and why a 'port' is more up-to-date than the original software.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

madworm wrote:
How come they haven't been integrated into the source code yet? I could (hypothetically) use WinAVR of course, but I just fail to see how and why a 'port' is more up-to-date than the original software.

I have the impression that winavr is sometime more a fork than a port and that quite few things don't make it back into the gcc. maybe just due to the lack of motivation my Atmel to provide the work to make it happen. After all in winavr it works and other development platforms than Windows don't exist / are negligible (See the wonderful new Studio 5 based on Microsoft Visual Studio).

Markus

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I think I'll have to agree with the fork vs. port part, but Atmel could at least have had the decency to use QT instead of the horrid MS stuff. It looks more and more like MS-word. Does it have ribbons as well?

And why do I need to register just for downloading a free-of-charge IDE? Is that strictly legal, having to register to get access to software that is - at least partially - licensed under the GPL?

Sheesh. Isn't it enough that I buy some of their chips already. Knowing who I am and what I do won't miraculously octuplicate their sales and blow away their competitors...

/rant

Now back to business please :D

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I installed AVR Studio 5 yesterday - it supports Tiny4313. When it was pointed out to Atmel that they'd shot themselves in the foot by delivering (again) a Windows only package the retort was that while the IDE may be tied to Windows the toolchain was "cross platform". Now I don't know how they can make that claim without providing Linux binaries x386 for the avr-* tools in the toolchain - but maybe they are lurking in there (I haven't looked)?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

It was Dean, who said that the underlying stuff is cross-platform and only the IDE is Windows specific. This might be correct in theory and marketing speak (gcc is cross-platform), but in practice this is clearly false. After I pointed out to him that an 500MB exe file is not cross-platform did not venture any further comment.

I respect Dean and suspect he was carried away with his remark. I don't think he works in the Studio team, so he might just defend them without knowing all the details first hand.

I don't need a single click 500MB installer for linux, the script provided here is sufficient for most of us Linux guys. But it looks like we are deliberately ignored.

Markus

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The script is fine!

It basically does all the work. Only currently (well yesterday) it unfortunately does not produce a version of avr-gcc that supports the tiny4313.

The best I could do myself was to apply a patch to avr-devices.c to make the compiler aware of that chip. But later the linker barfed about a missing .o file - which existed.

If atmel is so stuck-up to ignore everything beside windows, they can't be helped and will pay the price once MS faces its inevitable end. I just love companies taking advantage of open source software and give back nowt.

I'm no expert in this, but I doubt it can be considered as terribly hard/impossible for well experienced c/c++ programmers to transfer the 'Studio' to something that compiles 'everywhere' using QT or GTK and at least provide up-to-date binaries for major flavours of linux/mac-os.

Maybe it's time that someone shoves that message up the a*ses of the bean counters in management.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

madworm wrote:
I'm no expert in this, but I doubt it can be considered as terribly hard/impossible for well experienced c/c++ programmers to transfer the 'Studio' to something that compiles 'everywhere' using QT or GTK and at least provide up-to-date binaries for major flavours of linux/mac-os.

I doubt that this is easily possible, as Studio 5 is based on the Microsoft proprietary Visual Studio environment. However, the C/C++ compiler is already cross-platform compatible, only that Atmel, in its infinite wisdom has choose only to distribute the Windows version. Over time they will have to release all the patches they have applied to it as gcc is licensed under the GPL.

It would have been very easy for them to base their Studio environment on a cross-platform environment like Eclipse, like most of the industry is doing it right now. It might even have been less work.

Markus