Module firmware development: avr32 toolchain

shankzz · 2019-10-16T02:58:47.805Z

@scanner_darkly, @sam - it would be great if you could update the Makefile at https://github.com/scanner-darkly/avr32-toolchain since that is being referred to in the main readme at https://github.com/monome/libavr32 and it is referring to the non-existant atmel file for avr32 patches. It was a bit of a head-scratcher until I read through this thread fully and stumbled upon @sam’s attachment. Thanks!

scanner_darkly · 2019-10-16T03:16:59.737Z

yep, i can do that - but looking at my fork it looks like it’s just that, a fork with no local modifications. might be a better idea to update the instructions on libavr32 repo and add a proper makefile there?

shankzz · 2019-10-16T03:19:24.500Z

I agree. That would be the most stable option. Thanks for chiming in!

scanner_darkly · 2019-10-16T03:44:16.665Z

do you want to post the makefile here? i can update the repo.

shankzz · 2019-10-16T03:50:48.320Z

Will do tomorrow. Just now shut down for the day

shankzz · 2019-10-18T00:49:43.256Z

The file attachment provided by sam was uploaded with the short-url feature of lines and mangles the name. It is better if we uploaded the file avr32.patches.tar.gz to an avr32-toolchain repo and link to it in the Makefile. Also, the Makefile is for the avr32-toolchain and not libavr32 itself. So, I think we gotta just have a stable fork of the avr32-toolchain (which could be yours or could be a fork of yours by monome org), in which we update the Makefile.

scanner_darkly · 2019-10-18T00:52:35.852Z

sounds good. should i pull the latest into my fork first or do we want that specific commit?

shankzz · 2019-10-18T00:59:37.402Z

Your fork in its current shape worked well for me with that file. I think you could just pull latest (to cover for anything new from denravonska) and add the attached file at the root level (or under some folder, whatever you think is the best way to keep it). Then we can just update the Makefile to something like:

…
AVR32PATCHES_ARCHIVE = avr32-patches.tar.gz
AVR32PATCHES_URL = $(CURDIR)/$(AVR32PATCHES_ARCHIVE)
…

avr32-patches.tar.gz (379.9 KB)

scanner_darkly · 2019-10-18T19:15:17.829Z

thanks, will do it this weekend!

Dewb · 2019-10-20T21:33:11.197Z

What’s the story with this patch zipfile? Is it only necessary for 3.4.2?

The Docker container I made last year incorporates avr32-gnu-toolchain-3.4.3.820 and doesn’t need any patches. I haven’t had any issues building with that version. Might be easier to just update the official Makefile to 3.4.3.

scanner_darkly · 2019-10-21T00:15:48.535Z

i haven’t updated my fork yet - do i need to do anything there?

docker is probably a much better way moving forward (thank you for putting it together!). should we just recommend that in the libavr32 readme?

shankzz · 2019-10-21T00:56:04.413Z

Been sometime since I worked with docker on windows. The only option still is vagrant? That might be the only downer, since working with WSL on windows 10 (and launching vscode right from the command line) has been super awesome.

csboling · 2019-10-21T01:06:16.817Z

I use Docker Toolbox on Windows (which runs the Docker daemon and containers inside a VirtualBox-hosted linux VM) and I use this dockerfile to successfully compile libavr32 and the Teletype and Ansible firmwares this way. In the WSL you may just be able to install Docker normally for all I know? Haven’t used the WSL hardly at all.

Dewb · 2019-10-21T01:16:01.403Z

scanner_darkly:

docker is probably a much better way moving forward (thank you for putting it together!). should we just recommend that in the libavr32 readme?

I think there’s value in having both approaches, not everyone can/wants to use docker in all situations (I’m not going to install docker on norns, but I might install the avr toolchain.) But yeah, the readme could mention both, and they probably ought to be on the same version of the avr toolchain.

shankzz · 2019-10-21T01:20:27.696Z

In the teletype repo readme, both the docker and toolchain approaches are documented. So, that looks alright. Only in the toolchain repo readme, it goes through the whole nine yards, which when executed fails with this dead reference to an atmel avr32 patch.

scanner_darkly · 2019-10-24T21:14:42.385Z

so sounds like i should keep my fork at the commit it’s at right now?

shankzz:

Only in the toolchain repo readme

do you mean the libavr32 one? i can copy the one from teletype.

shankzz · 2019-10-25T00:42:04.693Z

Sorry about the vagueness . I am referring to the following repos:

Teletype repo - main teletype code. Describes both libavr32 build approach and docker approach, providing documentation on both.
Libavr32 repo - main libavr32 code. If you choose the libavr32 build approach, you will come here. Before you build libavr32, you need to build the toolchain first. In the windows section of readme, it points to…
Your fork of the avr32 toolchain - this and other forks of avr32 toolchain all have the same problem. Their config.mks refer to atmel patch url that doesn’t exist anymore and instead need to be replaced with a new url or have the file manually added to the folder so that the build can pass.

Hope that helps explain what I have seen so far.

scanner_darkly · 2019-10-25T17:53:36.373Z

thank you - this is very helpful.

i’ve added the atmel patches file to my fork - could you let me know what else needs to be changed (makefile / instructions)?

Dewb · 2019-10-26T04:18:03.006Z

My rec for libavr32 and forks would be to modify the Makefile & readmes to consume avr32-gnu-toolchain-3.4.3.820 and drop the patch zip completely. And then also mention the docker option in the readmes.

shankzz · 2019-10-26T14:07:07.889Z

As a long term fix, this is the best option. I will try to rebuild libavr32 this weekend with this toolchain and see what mods need to be done on config and readme.