#61

I’ve tried it clean a few times since Sunday the error is at the same place each time. I don’t get any git errors when cloning the repo. When I get home tonight after work ill try again and capture all the output to make sure thigns are working correctly up to that point?

Have you done a clean build of the tool chain recently? It doesn’t look like that repo has had a successful automated build in over a year:

https://travis-ci.org/monome/libavr32/builds

But again, this will be my first hack at a full embedded toolchain build (Ive only done some minor tweaking of teensy code for my O+c’s), so I am definitely super clueless

#62

i set up the toolchain a year ago, so possible something changed in bash that now doesn’t work like it did before. those travis errors can be ignored, those are basically from older firmwares failing due to some breaking changes introduced in libavr32, they’re not related to the toolchain set up.

1 Like
#63

@Fma are you able to try using this repo?

The relevant commands would become:

cd
git clone https://github.com/noah95/avr32-toolchain
cd avr32-toolchain
PREFIX=$HOME/avr32-tools make install-cross

Basically, the Makefile that builds the toolchain is really brittle, and many small things end up breaking it. Usually when it does I check the network view on GitHub to see if anyone else has a fork with recent commits, as they might have fixes, and at the very least can show that they’ve had it working recently.

I can’t make any promises that the noah95 fork will work, or that it won’t eat all the files on your computer and transport it to a parallel dimension, but trying that is the first place to start. You can view the changes between our version and theirs here, the biggest difference is that they’ve bundled a lot of the header files into the repo.

Has anyone tried running the Atmel Linux binaries under WSL recently? One of the bugs that stopped it working has been fixed (#1048), but the other hasn’t had any updates for a while (#1462).

Ultimately the pre-compiled Linux binaries are pretty solid, you may need to contemplate going down the virtual machine route, or if you know how to use it vagrant might be a good option (that’s what Mutable Instruments use to provide a reproducible build environment for their modules).

2 Likes
#64

Yeah I started poking around to other avr32-toolchains this morning to see if any was less than a couple of years old. Ill give this a shot tonight also.

Cool. If other repos are not working ill poke around at this also.

#65

Ok the Noah95 repo has been building well past where the monome repo errors out. Im going to let it roll tonight and see if I can build ansible binaries in the morning. Thanks for all the help folks!

1 Like
#66

Excellent. Let us know how it goes.

My gut feeling is that the issue is that all the download URLs in the Makefile are broken after the Microchip (boo!) takeover of Atmel. I suspect it’s broken for OSX users too.

#67

Ok so the avr tool chain compiled, but when then I

> export PATH="$HOME/avr32-tools/bin:$PATH"
> cd
> git clone --recursive https://github.com/monome/ansible 
> cd ansible
> cd src
> make

I get this:

CC      ../src/main.o
In file included from ../libavr32/asf/common/services/clock/sysclk.h:89,
                 from ../libavr32/asf/common/services/delay/delay.h:53,
                 from ../src/main.c:30:
../libavr32/asf/common/services/clock/uc3b0_b1/sysclk.h: In function 'sysclk_enable_peripheral_clock':
../libavr32/asf/common/services/clock/uc3b0_b1/sysclk.h:709: error: 'AVR32_ABDAC_CLK_PBA' undeclared (first use in this function)
../libavr32/asf/common/services/clock/uc3b0_b1/sysclk.h:709: note: each undeclared identifier is reported only once for each function it appears in
../libavr32/asf/common/services/clock/uc3b0_b1/sysclk.h: In function 'sysclk_disable_peripheral_clock':
../libavr32/asf/common/services/clock/uc3b0_b1/sysclk.h:801: error: 'AVR32_ABDAC_CLK_PBA' undeclared (first use in this function)
../libavr32/asf/avr32/utils/make/Makefile.avr32.in:402: recipe for target '../src/main.o' failed
make: *** [../src/main.o] Error 1

I’m guessing something is getting properly referenced?

#68

Can you search for references to AVR32_ABDAC_CLK_PBA in the $HOME/avr32-tools directory?

There should be a few of them.

The relevant one on my computer is in avr32-tools/avr32/include/avr32/uc3b0512.h, do you have that file?

#69

Ill get my grep on tonight when I get home.

#70

Yup its there in a few of the header files, none of them the same as yours though (uc3a0512.h):

$ grep -r AVR32_ABDAC_CLK_PBA
avr32/include/avr32/uc3a0128.h:#define AVR32_ABDAC_CLK_PBA                79
avr32/include/avr32/uc3a0256.h:#define AVR32_ABDAC_CLK_PBA                79
avr32/include/avr32/uc3a0512.h:#define AVR32_ABDAC_CLK_PBA                79
avr32/include/avr32/uc3a1128.h:#define AVR32_ABDAC_CLK_PBA                79
avr32/include/avr32/uc3a1256.h:#define AVR32_ABDAC_CLK_PBA                79
avr32/include/avr32/uc3a1512.h:#define AVR32_ABDAC_CLK_PBA                79
#71

i’ll check what i have when i get home.

i think we do need to set up vagrant or something similar…

#72

If that’s all you’ve got then there are some missing headers (at the least).

You can get the missing headers from here:

Download avr32-headers-6.2.0.742.zip

You’ll need to delete $HOME/avr32-tools/avr32/include (or move them somewhere else).

Then the following should unzip the headers into the correct place:

unzip avr32-headers-6.2.0.742.zip -d $HOME/avr32-tools/avr32/include
2 Likes
#73

Grabbed those missing headers! thanks. Put them in the right place and then proceed to try and build ansible firmware. Unfortunately, one step forward. a mountain of errors backwards. First two lines of my mountain of errors are troubling:

../src/main.c:26:19: error: stdio.h: No such file or directory
../src/main.c:27:30: error: string.h: No such file or directory

Just to test I built a small hello world .c file, including stdio.h & string.h and it compiled just fine, so those are at least installed. My guess is the rest of the errors are all from these not being found for some reason? I’m starting to miss visual studio at this point, which is frightening. :slight_smile:

This is the full output of running make in my ansible/src directory.
make.ouput (68.3 KB)

#74

Right. Final (easy) roll of the dice…

@scanner_darkly can you zip or otherwise archive your avr32-tools directory and upload?

I’m afraid I’m somewhat lacking in free time at the moment (stay at home dad, 9 month old baby, etc, etc), otherwise I’d try fixing the Makefile. I have a feeling it’s pretty easy to do. I’m pretty sure the URLs just need updating.

#75

it’s a bit big (~37Mb) so using dropbox instead of uploading here:

1 Like
#76

Thank you guys so much. I really don’t want to be a drain on anyone’s time. So please no worries @sam about support. I can certainly paw through stuff slowly, and report back here where my errors are and what I am fixing.

@scanner_darkly, I grabbed the zip, unpacked and started working through the various permission issues that are popping up. Basically after unzipping everything is rw for all groups, but nothing (including executable) is rwx. No big deal, it will just take me a bit of time to verify this is working. I am assuming something got borked in the packing.

1 Like
#77

Final info dump from me:

noah95's fork looks like he’s fixed the main issue, the URLs all being broken with the Microchip takeover of Atmel (again, grrrrr).

However it looks like he’s not that interested in the uc3b version of the chip, so when he copies the headers into his git repo he seems to have skipped them.

What someone needs to do is go through his commit history, fixing up the URLs, etc, but making sure that nothing for the uc3 is left out.

This commit:

adds in a headers.zip file, which is smaller than the Atmel version, perhaps that file just needs replacing?

And again the other alternatives for Windows users are:

  • Get Microsoft to fix the issue with static binaries in WSL (see earlier for the tickets), that way we can use the official Atmel binaries
  • Get Vagrant set up (which will help OSX users too, I doubt the toolchain build is working on OSX either at the moment)

I’ll try and keep an eye on this thread.

1 Like
#78

i don’t think permissions are included in archives, likely windows just doesn’t give execute permission on anything that was downloaded or comes from an archive.

yeah, vagrant would be a better option i think as it would be more future proof. this is completely outside of my knowledge zone though…

#79

re: vagrant - this is fairly old but could be used as a starting point https://github.com/bensteinberg/aleph-development

2 Likes
#80

I’m stuck setting up the avr32-toolchain: I’ve followed the windows-portion of https://github.com/monome/libavr32 and installed ubuntu. Followed the guide successfully until

PREFIX=$HOME/avr32-tools make install-cross

it starts building, but at some point it fails with these messages:

make[5]: *** No rule to make target 'tc-avr32.o', needed by 'as-new'.  Stop.
make[5]: Leaving directory '/home/mirko/avr32-toolchain/binutils-2.23.1/gas'
Makefile:2130: recipe for target 'all-recursive' failed
make[4]: *** [all-recursive] Error 1
make[4]: Leaving directory '/home/mirko/avr32-toolchain/binutils-2.23.1/gas'
Makefile:662: recipe for target 'all' failed
make[3]: *** [all] Error 2
make[3]: Leaving directory '/home/mirko/avr32-toolchain/binutils-2.23.1/gas'
Makefile:4616: recipe for target 'all-gas' failed
make[2]: *** [all-gas] Error 2
make[2]: Leaving directory '/home/mirko/avr32-toolchain/binutils-2.23.1'
Makefile:837: recipe for target 'all' failed
make[1]: *** [all] Error 2
make[1]: Leaving directory '/home/mirko/avr32-toolchain/binutils-2.23.1'
Makefile:377: recipe for target 'stamps/build-binutils' failed
make: *** [stamps/build-binutils] Error 2

Sadly, I have not the slightest clue about how to interpret this or how i could even start fixing this. Can anyone help?

edit: see below, I solved the issue by going with linux in virtualbox.